TL;DR
Letzte Woche stand der Unterbau: Backend, Pipeline, die Entscheidung gegen ein LLM in der Kernlogik. Diese Woche kam die Oberfläche dazu, außerdem zwei wichtige Korrekturen, die erst beim Testen gegen echte Daten aufgefallen sind. Die Screenshots in diesem Post stammen aus einer Demo-Version mit Fake-Daten, die ich parallel fürs Portfolio baue, dazu unten mehr.
Optimiert: was jetzt besser läuft als vorher
Ein paar Dinge, die der alte n8n-Workflow im Prinzip auch hätte richtig machen können, aber nicht tat:
- Zufluss statt Rechnungsdatum
Die Kundenrechnung hat bisher am Rechnungsdatum gebucht statt am Tag des tatsächlichen Zahlungseingangs, wie es §11 EStG für die EÜR verlangt. Der Kontoauszug-Parser erkennt jetzt die Rechnungsnummer in der Gutschrift und korrigiert das Buchungsdatum automatisch. - Kontoauszüge
Die Bank-Erkennung läuft jetzt über den Inhalt des Kontoauszugs statt über meine eigene Dateinamens-Konvention, mit einem eigenen Nummernkreis pro Bank. - Robustere Zuordnung
Mehrere weitere Fälle erkennen den passenden Beleg jetzt zusätzlich am Inhalt statt nur am Dateinamen.
Erweitert: was komplett neu dazugekommen ist
Das, was es in n8n so nie gab:
- Ein React-Dashboard mit Charts für Einnahmen/Ausgaben je Tätigkeit, kumuliertem Gewinnverlauf über das Jahr, einem Anteil-Gewerbe-vs-Freiberuf-Donut und Verlaufs-Charts für einzelne Einnahmequellen.
- Eine UStVA-Kennzahlen-Ansicht, die zeigt, welcher Betrag in welche Kennzahl der Umsatzsteuer-Voranmeldung eingetragen werden sollte, inklusive Status pro Kategorie („geklärt“ / „zu prüfen“), statt so zu tun, als wäre jede Zuordnung gleich sicher.
- Eine EÜR-Jahresübersicht je Tätigkeit, mit Aufschlüsselung nach Gegenpartei.
- Eine Sicherung per Knopfdruck: eine Zip-Datei aus Datenbank, frischen EÜR-Exporten und allen Beleg-Dateien.
Der Belastungstest
Bevor ich n8n endgültig abgeschaltet habe, wollte ich mehr als grüne Unit-Tests. Ich habe alle rund 70 Belege, die dieses Jahr schon durch n8n gelaufen und einsortiert waren, noch einmal read-only durch die neue Pipeline gejagt und mit meiner alten Buchhaltung verglichen.
48 von 51 Buchungen stimmten exakt überein, zwei der restlichen drei waren erwartete Sonderfälle. Der dritte war interessant: Ein Sammelbeleg für Marktplatz-Verkäufe wies zwei Verkäufe zu viel aus, weil der alte n8n-Workflow monatliche Export-Dateien in falscher Reihenfolge verarbeitet und dadurch doppelt gebucht hatte. Eine Unit-Test-Suite findet so etwas nicht, sie prüft ja nur, ob der neue Code tut, was er soll, nicht ob die Prämisse des alten Systems stimmte. Erst der Abgleich mit echten, historischen Daten hat die Lücke gezeigt.
Architekturentscheidungen
Zwei Prinzipien, die sich durch die Arbeit dieser Woche ziehen und die ich bewusst so festgelegt habe:
- Lieber warnen als raten.
Wenn der Monat aus einem Kontoauszug nicht sicher erkennbar ist, fällt das System auf den normalen Zähler zurück und meldet das, statt zu raten. Wenn ein erkannter Zahlungseingang einen abweichenden Betrag hat, wird die Buchung nicht automatisch korrigiert, nur gewarnt. Und schon beim Sammelbeleg-Fund: ein Export mit Verkäufen aus mehr als einem Kalendermonat landet jetzt automatisch in der manuellen Review. Das ist keine Ansammlung von Einzelfällen, sondern eine durchgängige Haltung: Ein System, das mit Geld und Steuern arbeitet, darf niemals still irren. Lieber ein sichtbarer Stopp als eine unsichtbare Fehlbuchung. - Automatisierung nur unter einer harten Bedingung.
Die Zufluss-Korrektur läuft vollautomatisch, aber nur wenn der Betrag im Kontoauszug exakt mit der gebuchten Rechnung übereinstimmt. Weicht er ab, greift keine Automatik, nur eine Meldung. Der Grund: Die Rechnungsnummer im Kontoauszug ist Text in einem PDF, keine garantiert eindeutige Referenz. Ich wollte den Komfort der vollen Automatisierung, ohne dass eine falsch zugeordnete Rechnungsnummer eine echte Buchung stillschweigend verändern kann. Automatisierungsgrad und Absicherung sind hier bewusst gegeneinander abgewogen, nicht pauschal entschieden.
Von der lokalen App zur Portfolio-Demo
Das Cockpit läuft aktuell lokal auf meinem eigenen Rechner, ich buche darüber schon jetzt meine echten Belege. Für mein Portfolio entsteht parallel eine öffentliche Demo-Version mit Fake-Daten, die zu großen Teilen schon steht. Die Screenshots in diesem Post stammen aus dieser Demo, nicht aus meinen echten Finanzdaten. Sobald die Demo deployed ist, verlinke ich sie hier nachträglich.
Fazit
Woche 33: ✅
Damit ist das Steuer-Cockpit als Wochenprojekt abgeschlossen. Als nächstes werde ich die Demo für mein Portfolio fertig stellen. Wie es nächste Woche weitergeht, steht noch nicht fest. Eventuell werde ich anfangen, den Blog zu überarbeiten, damit hier zukünftig ein übersichtliches Portfolio entsteht.
