Accounty

1. Persönlicher Ausgangspunkt

Accounty begann als persönliches Experiment.

Ich wollte herausfinden, wie viel von der Buchhaltung meiner eigenen Firma realistisch mit KI-Agenten automatisiert werden kann - nicht als poliertes Produkt, sondern als praktischer Test mit echten Arbeitsabläufen.

Die ersten Anwendungsfälle waren einfach, aber wichtig: Rechnungen erstellen, eingehende und ausgehende Rechnungen archivieren, Banktransaktionen mit Rechnungen und Gutschriften abgleichen und tägliche Archive für Serverdaten automatisieren.

Das Ziel war keine vollständige Autonomie. Das Ziel war kontrollierte Automatisierung: spezialisierte Agenten, klare Schnittstellen, Prüfbarkeit und menschliche Kontrolle dort, wo sie wichtig ist.

Die wichtigste Erkenntnis bisher ist einfach: Nützliche Automatisierung im Unternehmen ist nicht ein großer KI-Agent. Sie ist ein System kleinerer Workflows, die jeweils eine Aufgabe gut erledigen.

Das bereinigte öffentliche Referenzrepository ist auf GitHub verfügbar: easyplatform/Accounty.

2. Das MCP-Zoo-Problem

Mein erster Ansatz war, einen zentralen Agenten mit einem kleinen “Zoo” von MCP-Servern zu verbinden. Jeder MCP-Server konnte einen Teil des Workflows ausführen, aber der zentrale Agent musste den Prozess trotzdem jedes Mal selbst entscheiden.

In der Praxis war das für Geschäftsprozesse zu unzuverlässig.

Der Agent konnte die Werkzeuge nutzen, musste aber den Workflow oft von Grund auf neu rekonstruieren: welcher Schritt zuerst kommt, welche Daten benötigt werden, welches Tool verwendet werden soll, ob das Ergebnis sicher geschrieben werden darf und wann ein Mensch es prüfen sollte.

Für Experimente kann das akzeptabel sein. Für Buchhaltung, Rechnungen, Dokumente und Zahlungen ist es zu fragil.

Die wichtigste Erkenntnis war klar: Zuverlässige Automatisierung braucht eine kontrollierte Umgebung. Der zentrale Geschäftsprozess sollte nicht nur in einem Prompt leben. Er sollte als klarer Workflow mit definierten Eingaben, Ausgaben, Berechtigungen und Review-Punkten implementiert sein.

3. Architekturidee

Accounty ist um klar definierte Subagenten herum aufgebaut.

Ein Subagent ist kein frei formulierender Chatbot. Er ist ein fokussierter Worker mit genau einer Verantwortung: eine Rechnung erstellen, ein Dokument hochladen, Archivnachweise abrufen, Transaktionen aktualisieren, Zahlungen abgleichen oder einen Archivworkflow ausführen.

Diese Subagenten werden über explizite API-Endpunkte bereitgestellt. Der Agent Harness kann sie aufrufen, aber die Geschäftslogik ist nicht im Harness versteckt. Der Workflow existiert als normale Software und kann getestet, geloggt, verbessert und eingeschränkt werden.

In meinem Setup ist der Harness Hermes Agent. Hermes verwaltet die Arbeit rund um die Subagenten: den passenden Workflow auswählen, den richtigen Skill laden, Freigaben einholen, Folgeschritte koordinieren, Jobs planen und Logs führen.

Diese Trennung ist der Kern der Architektur:

• Subagenten implementieren den Geschäftsprozess
• die API stellt sichere Operationen bereit
• Hermes orchestriert die Arbeit rund um diese Operationen
• Menschen behalten an Review- und Freigabepunkten die Kontrolle

Für mich wurde das zur Grundlage zuverlässigerer Automatisierung: nicht nur bessere Prompts, sondern bessere Infrastruktur rund um Agenten.

4. Geschäftlicher Nutzen

Der nützlichste Teil von Accounty ist nicht, dass es “Buchhaltung mit KI macht”. Der eigentliche Wert liegt darin, kleine repetitive Schritte aus der täglichen Arbeit zu entfernen und den Workflow dabei nachvollziehbar zu halten.

Rechnungen zu erstellen wird schneller und konsistenter. Eingehende und ausgehende Rechnungen werden an einem strukturierten Ort archiviert. Banktransaktionen können gegen Rechnungen, Gutschriften und archivierte Dokumente geprüft werden, statt manuell in Ordnern und E-Mails zu suchen.

Das hilft auch bei der Serverwartung. Tägliche Archivierung macht den Backup-Prozess wiederholbar, statt dass ich jedes Mal daran denken oder ihn manuell kontrollieren muss.

Für mich ist der wichtigste Vorteil einfach: weniger manuelle Suche, weniger Copy-and-paste-Arbeit und bessere Nachvollziehbarkeit zwischen Dokumenten, Rechnungen, Zahlungen und Backups.

Ein weiterer wichtiger Punkt: Die Basisinfrastruktur kann mit Open-Source-Werkzeugen aufgebaut werden. Für dieses Experiment wollte ich das Setup praktisch und bezahlbar halten, ohne neue Softwarelizenzkosten hinzuzufügen.

5. Technischer Stack

Beim technischen Stack habe ich versucht, das Setup praktisch, modular und weitgehend auf Open-Source-Komponenten aufzubauen.

Der zentrale Einstiegspunkt ist Hermes Agent. Ich nutze ihn als Agent Harness: den Ort, an dem Agenten gestartet, überwacht, geplant und mit Human-in-the-loop-Workflows verbunden werden können.

Die API-Schicht ist mit FastAPI gebaut. Dadurch bekommt jede Teilaktion eine klare HTTP-Schnittstelle, sodass die Automatisierung nicht in einem großen Prompt versteckt ist. Jede wichtige Aufgabe kann einzeln aufgerufen, getestet, geloggt und wiederverwendet werden.

Für Agenten-Workflows nutze ich LangGraph. Damit lassen sich Workflows als kontrollierte Schritte modellieren, statt einen Agenten jedes Mal den gesamten Prozess von Grund auf entscheiden zu lassen.

Für die Dokumentenarchivierung nutze ich Paperless-ngx. Es stellt das Archiv für eingehende Rechnungen, ausgehende Rechnungen, Gutschriften und andere Unternehmensdokumente bereit.

Für strukturierte Informationen verwendet Accounty eine Datenbankschicht für Transaktionen, Rechnungspositionen, Dokumentreferenzen und Verknüpfungen zwischen Zahlungen und archivierten Dokumenten.

Für die Serverarchivierung nutze ich BorgBackup. Es übernimmt wiederholbare Archivworkflows für die Serverinfrastruktur.

Für LLM-Observability nutze ich Langfuse. Jeder relevante LLM-Aufruf sollte nachvollziehbar sein, weil Debugging und Verbesserung von Agenten ohne gute Logs fast unmöglich sind.

6. Datenschutz, lokale Modelle und Least Privilege

Buchhaltungsdaten, Rechnungen, Banktransaktionen, Verträge und Unternehmensdokumente sind sensibel. Für diese Art von Workflow ist es nicht immer wünschenswert, jeden Prompt, jedes Dokument oder jede Transaktion an einen externen Modellanbieter zu senden.

Deshalb funktioniert Accounty auch mit Open-Weight-Modellen, die auf eigener Hardware laufen. In meinem Setup wurde das mit einem lokalen Qwen3.6-35B-A3B-Modell getestet, das auf einem NVIDIA DGX Spark-Minicomputer lief.

Das bedeutet nicht, dass jeder Workflow lokal laufen muss. Es gibt aber eine wichtige Option: sensible Workflows können in der eigenen Infrastruktur bleiben, während dieselbe Agentenarchitektur weiterhin externe APIs nutzen kann, wo das akzeptabel ist.

Datenschutz betrifft nicht nur den Modellanbieter. Es geht auch um Berechtigungen.

In dieser Architektur sollte Hermes nicht als Administrator, Datenbankbesitzer oder Root-User laufen. Der Agent bekommt eigene technische Nutzer für die Systeme, auf die er zugreifen muss: einen dedizierten Datenbanknutzer, einen dedizierten API-Token und, wo Serverzugriff nötig ist, einen dedizierten Unix-Nutzer auf dem Server.

Jeder dieser Nutzer sollte nur die Berechtigungen haben, die für seine Aufgabe erforderlich sind. Ein Datenbanknutzer sollte nur die Tabellen, Spalten oder Stored Procedures sehen oder ändern können, die der Workflow braucht. Ein Servernutzer sollte keine breiten sudo-Rechte haben. Ein Paperless- oder Rechnungs-API-Token sollte nur die Operationen freigeben, die die Automatisierung tatsächlich benötigt.

Änderungen sollten nach Möglichkeit über explizite APIs geleitet werden, statt dem Agenten breiten Direktzugriff zu geben. Zum Beispiel sollte die Verknüpfung einer erzeugten Rechnung mit einem Paperless-Dokument über einen dedizierten Endpunkt wie POST /invoice/assign-paperless-document laufen. Die Verknüpfung einer Banktransaktion mit einem Dokument kann über einen fokussierten Endpunkt wie POST /fints/paperless laufen.

Das hat zwei Vorteile. Erstens kann die API die Anfrage validieren und Geschäftsregeln erzwingen. Zweitens braucht der Agent Harness keine mächtigen Zugangsdaten. Er benötigt nur die Berechtigung, die sichere Operation aufzurufen, die für den Prozess entworfen wurde.

Für mich ist das eines der stärksten Argumente für diesen Ansatz. Mit der richtigen Infrastruktur muss KI-Automatisierung nicht bedeuten, Kontrolle über die eigenen Daten aufzugeben oder einem Agenten uneingeschränkten Systemzugriff zu geben.

7. Skills vs. Subagenten

Eine weitere wichtige Unterscheidung in dieser Architektur ist der Unterschied zwischen Skills und Subagenten.

Ein Subagent ist der technische Worker. Er führt eine definierte Aktion aus, normalerweise hinter einem API-Endpunkt. Ein Subagent kann zum Beispiel eine Rechnung erstellen, ein anderer ein Dokument ins Archiv hochladen, und ein weiterer kann Banktransaktionen mit vorhandenen Dokumenten vergleichen.

Ein Skill ist etwas anderes. Ein Skill sagt dem Agent Harness, wie diese Subagenten richtig genutzt werden. Er beschreibt, wann ein Subagent verwendet werden soll, welche Eingaben erforderlich sind, wie das Ergebnis interpretiert werden soll und was danach passieren soll.

Anders gesagt: Der Subagent erledigt die Arbeit, während der Skill den Prozess rund um die Arbeit beschreibt.

Ein Rechnungs-Subagent kann zum Beispiel eine Eingabedatei und Rechnungsnummern erhalten, die Rechnungs-PDFs erstellen und eine ZIP-Datei zurückgeben. Der Skill sagt dem Agenten dann, was mit diesem Ergebnis passieren soll: wo die erzeugten Rechnungen gespeichert werden sollen, ob sie ins Dokumentenarchiv hochgeladen werden sollen, welche Metadaten angehängt werden sollen und wann ein Mensch das Ergebnis prüfen sollte.

Dadurch wird das Setup deutlich wiederverwendbarer. Derselbe Subagent kann von verschiedenen Workflows aufgerufen werden, während verschiedene Skills unterschiedliche Geschäftsprozesse darum herum beschreiben können.

In Hermes sind Skills Teil des Agent-Harness-Konzepts. Sie können über den Hermes Skills Hub entdeckt und installiert werden, und das Skillsystem ist in der Hermes Skills-Dokumentation beschrieben. Für Accounty bedeutet das: Skills werden zur operativen Wissensschicht zwischen Nutzer, Agent Harness und spezialisierten Subagenten.

8. Accounty-Subagenten

Die konkrete Accounty-Implementierung ist als kleine Gruppe fokussierter Subagenten rund um die Spark API aufgebaut. Das öffentliche Repository zeigt den API-Einstiegspunkt in main.py und die Agenten-Workflows unter src/agent/. Wichtig ist nicht, dass jeder einzelne für sich spektakulär ist. Wichtig ist, dass jeder eine enge Verantwortung und eine klare Schnittstelle hat.

Der FinTS-Transaktionsagent aktualisiert das Transaktionsledger. Er ist über POST /fints/update verfügbar, ruft aktuelle Banktransaktionen aus konfigurierten Konten ab, normalisiert sie und speichert sie ohne Duplikate. Er entscheidet nicht, zu welcher Rechnung eine Zahlung gehört. Er stellt nur die Bankdaten in strukturierter Form bereit.

Der Paperless-Upload-Agent verarbeitet Dokumenteingänge über POST /paperless/upload_document. Er erhält ein PDF, extrahiert relevante Inhalte und Metadaten und speichert das Dokument in Paperless mit sinnvollen Tags, einem Korrespondenten, einem Datum und einer Dokumentnummer, wenn eine existiert. Dadurch werden lose Dateien zu durchsuchbaren Archivdatensätzen.

Der Dokumentsuch-Agent ist der lesende Archiv-Worker. Er nutzt GET /paperless/search_document und GET /paperless/get_document/{document_id}, um Dokumente nach Text, Tags oder ID zu finden und extrahierten Inhalt zurückzugeben, wenn ein anderer Workflow Nachweise benötigt. Das ist wichtig, weil Matching- und Review-Workflows Archivfakten abrufen sollten, ohne das Archiv zu verändern.

Der Rechnungserstellungs-Agent erstellt Entwürfe für Ausgangsrechnungen. Er ist über POST /invoice/create verfügbar und erhält ein Timesheet-PDF plus Rechnungsnummern. Das Ergebnis ist ein ZIP-Archiv mit erzeugten Rechnungs-PDFs und Rechnungsmetadaten. Zugehörige Endpunkte wie GET /invoice/next-numbers, POST /invoice/create-row und POST /invoice/assign-paperless-document unterstützen Rechnungsnummerierung, Ledger-Zeilen und die Verknüpfung erzeugter Rechnungen zurück zu Paperless.

Der Transaktionsabgleich-Agent ist die Reconciliation-Schicht. Seine Aufgabe ist es, Banktransaktionen mit Rechnungszeilen, Gutschriften und Paperless-Dokumenten zu vergleichen. Er sollte exakte Rechnungsnummern, Betragsprüfungen, zeitliche Nähe, Namen von Gegenparteien und Tags bevorzugen. Sichere Treffer können über einen dedizierten Endpunkt verknüpft werden; mehrdeutige Treffer sollten zu manuellen Review-Fällen werden, statt stillschweigend angewendet zu werden.

Der Backup-/Archiv-Workflow ist die operative Sicherheitsschicht. Es geht weniger um Buchhaltungslogik und mehr um Wiederholbarkeit: Das System sollte wissen, was archiviert werden muss, wann das Archiv gelaufen ist und ob das Ergebnis erfolgreich war. Selbst in einem kleinen persönlichen Setup ist das wichtig, weil Automatisierung nur dann nützlich ist, wenn die zugrunde liegenden Daten wiederhergestellt werden können.

Zusammen bilden diese Subagenten ein praktisches Muster: Bankdaten, Dokumente, Rechnungen, Matching und Betrieb sind getrennte Verantwortlichkeiten. Hermes sitzt darüber als Harness, der die richtige Aktion aufrufen, das Ergebnis prüfen, Freigaben einholen und mit dem nächsten Schritt fortfahren kann.

9. Skills als operative Wissensschicht

Subagenten erledigen die Arbeit. Skills beschreiben, wie diese Arbeit genutzt werden soll.

Diese Unterscheidung wurde im Accounty-Setup wichtig. Der Endpunkt zur Rechnungserstellung kann PDFs generieren, aber der umliegende Prozess ist mehr als ein API-Aufruf. Der Agent muss auch wissen, wann er zur Prüfung anhalten soll, wo Dokumente archiviert werden sollen, wie Paperless-Ergebnisse zu interpretieren sind und welche Folgeschritte erst nach Freigabe sicher sind.

Für das öffentliche Repository halte ich die Skill-Schicht auf die Workflows beschränkt, die tatsächlich Teil von Accounty sind. Die Skills liegen im Ordner skill/:

• paperless beschreibt, wie archivierte PDF-Dokumente hochgeladen, gesucht und gelesen werden.
• invoice-stream beschreibt den Eingangspfad für Rechnungen vom PDF-Eingang bis zu Paperless und dem Dateisystemarchiv.
• spark-invoice-create beschreibt den direkten API-Aufruf, der aus einem Timesheet-PDF erzeugte Rechnungsentwürfe erstellt.
• timesheet beschreibt den vollständigen Workflow für Ausgangsrechnungen, einschließlich Validierungspunkten vor Sheet-Updates, Archivschritten oder E-Mail.
• invoice-management beschreibt die Regeln für das Rechnungsregister: erst Snapshot, vorsichtig schreiben, Berichte neu erzeugen und Änderungen verifizieren.
• fints-paperless-matcher beschreibt, wie Banktransaktionen mit archivierten Dokumenten abgeglichen werden und wann manueller Review erforderlich ist.
• hook-receiver beschreibt den Human-in-the-loop-Mechanismus für Freigaben und fehlende Informationen.
• stirling-pdf beschreibt unterstützende PDF-Operationen, etwa das Zusammenführen einer Rechnung mit ihrem Timesheet-Nachweis.

Das ist das operative Wissen, das das System wiederverwendbar macht. Ohne Skills muss der Agent den Prozess jedes Mal neu entdecken. Mit Skills kann der Agent das relevante Verfahren laden und dieselben Regeln erneut anwenden: zuerst hochladen, prüfen, vor irreversiblen Aktionen stoppen, Nachweise erhalten und Menschen dort in Kontrolle halten, wo der Workflow Urteilskraft braucht.

Die Skills im Repository sind bewusst für die Veröffentlichung bereinigt. Sie beschreiben die Workflow-Struktur, Namen von Umgebungsvariablen und API-Pfade, aber keine privaten Hostnamen, Tokens, Passwörter, Spreadsheet-IDs, E-Mail-Adressen oder persönlichen Signaturen.

10. GitHub / Open-Source-Teil

Der Open-Source-Wert von Accounty liegt im Muster, nicht in meinen privaten Buchhaltungsdaten.

Das GitHub-Repository kann zeigen, wie die Teile zusammenpassen: eine kleine FastAPI-Schicht, fokussierte Agenten-Workflows, Paperless-Integration, Rechnungserstellung, Transaktionssynchronisierung, Matching-Logik und Hermes Skills, die die Betriebsverfahren rund um diese Aktionen beschreiben.

Öffentlich sein sollten die wiederverwendbaren Schnittstellen und Beispiele: Endpunktformen, Verantwortlichkeiten der Agenten, Skill-Templates, Berechtigungsgrenzen und die Unterscheidung zwischen Subagenten und Skills. Deployment-spezifische Details gehören in Umgebungsvariablen oder private Konfiguration, nicht ins Repository.

11. Consulting-Perspektive

Accounty ist mein persönliches Beispiel, aber das Muster dahinter ist deutlich breiter.

Fast jedes Unternehmen hat Workflows dieser Art: Dokumente müssen gesammelt, geprüft, archiviert, abgeglichen, freigegeben, berichtet oder zwischen Systemen übertragen werden. Oft sind diese Prozesse theoretisch nicht schwierig, aber sie verteilen sich über E-Mails, Ordner, Excel-Dateien, Datenbanken, Web-Tools und manuelle Prüfungen.

Genau hier kann kontrollierte KI-Automatisierung helfen.

Das Ziel ist nicht, bestehende Systeme zu ersetzen. Das Ziel ist, sie besser zu verbinden, repetitive manuelle Arbeit zu reduzieren und Prozesse transparenter zu machen. Mit der richtigen Infrastruktur können Agenten konkrete Geschäftsworkflows unterstützen und Menschen trotzdem dort in Kontrolle halten, wo es wichtig ist.

Für mich ist Accounty eine praktische Demonstration, wie das aussehen kann: mit einem echten Workflow beginnen, klare Aktionen definieren, sichere API-Operationen bereitstellen, Least-Privilege-Zugangsdaten nutzen, Logging ergänzen und dann spezialisierte Agenten den Prozess Schritt für Schritt unterstützen lassen.

Das ist auch die Art von Arbeit, bei der ich Unternehmen helfe: repetitive Geschäftsprozesse in strukturierte, beobachtbare und kontrollierte Automatisierungsworkflows zu überführen.