Agent für die eigene Buchhaltung

Einordnung

Dieser Agent führt meine eigene Buchhaltung, er ist kein Produkt für Kunden. Ich beschreibe ihn hier abstrahiert: Aufgabe und Aufbau, keine Zahlen aus meinen Büchern.

Problem

Belege kommen aus mehreren Richtungen und stapeln sich. Die Handarbeit daran ist nicht schwer, sie ist lästig: herunterladen, Betrag ablesen, Kategorie wählen, ablegen, und am Jahresende alles noch einmal sortieren. Sie fällt außerdem genau dann an, wenn anderes wichtiger ist, und wird deshalb liegen gelassen, bis der Berg groß genug für einen verlorenen Abend ist.

Ansatz

Ein Ablageordner ist der Eingang. Ein Zeitplan sieht alle fünf Minuten nach, ob etwas Neues liegt, und reiht eine Aufgabe ein. Der Agent liest den Beleg, schlägt Buchung, Kategorie und Steuersatz vor und notiert dazu, wie sicher er sich ist. Unter einer Schwelle wandert der Fall in die Sichtung statt in die Bücher. Nach der Auswertung landet die Datei im Monatsordner. Ein täglicher Lauf sucht Doppelbuchungen, Stornos und andere Auffälligkeiten und markiert sie zur Prüfung. Freigegeben wird von mir, nicht vom Agenten. Für die Steuerberatung fällt ein Export im DATEV-Format nach SKR03 an.

Stack

Postgres bei Supabase mit Rechten auf Zeilenebene, Edge Functions in Deno, eine Aufgabenliste in der Datenbank mit einem Zeitplan als Taktgeber, Claude für das Lesen der Belege, Google Drive als Ablage, Resend für Benachrichtigungen. Die Oberfläche ist eine React-Insel auf dieser Website.

Ergebnis

Belege laufen ohne Handgriff vom Eingang bis zur erfassten Buchung, der Export für die Steuerberatung entsteht auf Knopfdruck. Was bei mir bleibt, ist das Prüfen und Freigeben, und das soll auch so bleiben. Offen ist die wöchentliche Zusammenfassung: der Versand ist gebaut, läuft aber auf keinem Zeitplan.

Learnings

Die wichtigste Zahl im System ist nicht der Betrag, sondern die Sicherheit der Erkennung. Ein Agent, der im Zweifel trotzdem bucht, kostet mehr Zeit als er spart, weil das Aufräumen später teurer ist als das Sichten sofort. Der zweite Punkt ist unbequemer: einzelne Änderungen habe ich früher direkt an der Datenbank gemacht, statt sie als Datei zu versionieren. Heute weichen Repository und Datenbank an ein paar Stellen voneinander ab, und jede dieser Stellen musste ich einzeln nachmessen, um sie überhaupt zu kennen.