TL;DR
Diese Woche habe ich den ersten Teil meines neuen Steuer-Cockpits gebaut: das Backend, das meine bisherigen n8n-Workflows für Belegverarbeitung und Rechnungserstellung ablöst.
Der Grund für den Umbau ist nicht, dass n8n nicht funktioniert hätte. Im Gegenteil: Der alte Workflow hat mir viel Arbeit abgenommen. Aber ich möchte ihn jetzt deutlich erweitern: mit einem Dashboard für Monatsübersichten, einer Review-Ansicht für neue Belege und später einem Steuer-Modul, das mir konkret zeigt, welche Zahlen ich wo eintragen muss.
Dafür brauche ich eine eigene Datenbasis. Deshalb landen Belege jetzt nicht mehr direkt in Google Sheets, sondern zuerst in einer lokalen SQLite-Datenbank. Google Drive bleibt die Dateiablage, Google Sheets wird nur noch aus der Datenbank exportiert.
Warum ich den Workflow neu baue
Mein bisheriger Buchhaltungsworkflow lief in n8n. Neue Belege kamen in Google Drive an, wurden erkannt, umbenannt, einsortiert und in meine EÜR-Tabellen geschrieben. Dazu gab es einen zweiten Workflow für eine monatliche Rechnung.
Das war ein guter Start, aber mit der Zeit wollte ich mehr als reine Automatisierung.
Ich möchte sehen können, wie sich Einnahmen und Ausgaben über die Monate entwickeln. Ich möchte neue Belege prüfen und korrigieren können, bevor sie endgültig gebucht werden. Und ich möchte am Ende nicht nur eine Tabelle haben, sondern eine Ansicht, die mir für Steuererklärung und Umsatzsteuervoranmeldung konkret zeigt, welche Summen relevant sind.
An dem Punkt war klar: Wenn ich den Workflow sowieso erweitere, lohnt es sich, ihn auf eine stabilere Grundlage zu stellen.
Die neue Grundlage
Die wichtigste Entscheidung: Die Datenbank ist die einzige Wahrheit.
Im Steuer-Cockpit liegen Buchungen, Belegdateien, Positionen, Nummernkreise und Verarbeitungsschritte in SQLite. Google Drive bleibt die Ablage für die Originaldateien. Google Sheets bleibt erhalten, aber nur noch als Export.
Das macht den Workflow besser erweiterbar. Ein Dashboard kann direkt auf die Datenbank zugreifen und ein Steuer-Modul kann Summen nach Monat, Tätigkeit und Steuerkategorie berechnen. Tests können prüfen, ob Parser, Nummernkreise und Buchungslogik so funktionieren, wie sie sollen.
Der Motor: scannen, vorschlagen, buchen
Teil 1 dieses Projekts ist der Backend-Motor.
Der Ablauf ist zweiphasig:
1. Scan: Neue Dateien im Drive-Input werden geladen, erkannt, geparst und als Vorschlag im Journal gespeichert.
2. Buchung: Vollständige Vorschläge werden bestätigt, bekommen eine Belegnummer und werden in der Datenbank verbucht. Danach wird die Datei in Drive umbenannt und einsortiert.
Diese Trennung ist wichtig, weil ein Scan nichts Endgültiges tut. Er sammelt Informationen. Wenn etwas unklar ist, entsteht ein Review-Fall statt einer falschen Buchung.
Deterministische Erkennung statt Blackbox
Ich wollte für die Belegerkennung bewusst keine LLM-Blackbox verwenden. Bei Buchhaltungsdaten möchte ich nachvollziehen können, warum eine Datei als Etsy-Verkauf, Deutsche-Post-Beleg oder OpenAI-Rechnung erkannt wurde. Die Pipeline arbeitet deshalb mit klaren Regeln.
Manche Belege sind über den Dateinamen eindeutig erkennbar: Etsy-CSV, Ravelry-Export, Kontoauszug, Deutsche Post. Andere Dateien heißen generisch invoice oder receipt. Bei ihnen wird der Dokumenttext extrahiert und nach wiederkehrenden Merkmalen gesucht, zum Beispiel Anbietername, Betragsfelder oder Steuerhinweise.
Wenn keine Regel sicher greift, wird nicht geraten. Der Beleg landet im Review.
Das ist einer der Gründe, warum ich den Workflow aus n8n herauslöse: Die Regeln liegen jetzt im Code, direkt neben Tests. Wenn ein Anbieter sein Format ändert, kann ich eine Beispieldatei ergänzen, den Parser anpassen und prüfen, ob alte Fälle weiter funktionieren.
Tests gegen stille Fehler
Bei Buchhaltung sind die gefährlichsten Fehler nicht unbedingt die, bei denen etwas abstürzt. Die sieht man meistens. Gefährlicher sind stille Falschbuchungen.
Deshalb habe ich neben klassischen Parser-Tests auch einen Testkatalog angelegt: Was passiert bei kaputten PDFs? Bei doppelten Dateien? Bei negativen Beträgen? Bei einem Postbank-Kontoauszug, der wegen „post“ falsch erkannt werden könnte?
Wir sind ja alle nur Menschen. Ich werde irgendwann eine Datei falsch ablegen, ein Anbieter wird sein Format ändern, und eine API wird genau dann nicht erreichbar sein, wenn ich gerade „nur schnell“ etwas erledigen will. Das System muss solche Fälle nicht magisch verhindern, aber es soll sie sichtbar machen.
AI im Prozess
Auch dieses Projekt entsteht mit LLM-Unterstützung. Ich lasse mir viel Code schreiben, nutze Claude Code für Gegenchecks, Testideen und Struktur. Bilder habe ich von Codex und ChatGPT erstellen lassen.
Aber gerade bei diesem Projekt wird gut sichtbar, wo meine Arbeit liegt: Ich entscheide, welche Datenquelle die Wahrheit ist, wann automatisch gebucht werden darf, welche Fälle ins Review gehören und welche Fehler gefährlich sind.
AI beschleunigt die Umsetzung. Die Verantwortung für Anforderungen, Architektur und Abnahme bleibt bei mir.
Was jetzt steht / was in Teil 2 kommt
Nach Teil 1 kann das Backend neue Belege scannen, klassifizieren, parsen, Vorschläge speichern und vollständige Vorschläge verbuchen. Es vergibt Belegnummern, legt Buchungen in SQLite an, sortiert Dateien in Google Drive ein und exportiert die EÜR-Sheets aus der Datenbank.
Die Bedienung läuft aktuell noch per Kommandozeile. Das ist für diesen ersten Schritt okay: Erst musste der Motor stimmen.
Als Nächstes kommt das Cockpit: eine React-Oberfläche mit Monatsübersicht, Buchungsliste, Review-Ansicht und Import/Export per Klick. Dann wird aus dem technischen Backend ein Werkzeug, das ich wirklich jeden Monat nutzen kann.
Fazit
Woche 32: ✅
Ich habe diese Woche meinen n8n-Workflow durch Python ersetzt und erweitert. Ich habe damit einen bestehenden Workflow auf eine Grundlage gestellt, die sich erweitern lässt:
mit eigener Datenbank, klarer Belegerkennung, Review-Schritt und Tests.
Nächste Woche geht es dann mit der Benutzeroberfläche weiter.
