Automatisierung braucht nicht immer KI: Wie ich meine Buchhaltung weitgehend automatisiert habe

KI ist aktuell gefühlt die Antwort auf fast jede Frage in der Softwareentwicklung.

• Dokumente auslesen? KI.
• Daten klassifizieren? KI.
• Geschäftsprozesse automatisieren? Natürlich KI.

Dabei gibt es viele Prozesse, bei denen ein Sprachmodell weder notwendig noch unbedingt die beste Lösung ist.

Ein gutes Beispiel dafür ist meine eigene Buchhaltung.

In den vergangenen Wochen habe ich mein ML Desk so erweitert, dass ein großer Teil der wiederkehrenden Arbeit rund um Ausgangs- und Eingangsrechnungen inzwischen automatisiert abläuft.

Das Ziel war dabei nicht, möglichst viel KI einzusetzen.

Das Ziel war, möglichst wenig Zeit mit Tätigkeiten zu verbringen, die eine Software genauso gut, oder evtl. besser erledigen kann.

Von einem abgeschlossenen Ticket bis zur E-Rechnung

Im ML Desk verwalte ich unter anderem Projekte, Tickets und die dafür erfassten Leistungen.

Ist ein abrechenbares Ticket abgeschlossen, muss daraus irgendwann eine Rechnung entstehen. Früher bedeutete das zwangsläufig, dass ich selbst aktiv werden musste.

Inzwischen übernimmt das System diesen Prozess weitgehend selbst.

Zum Monatsende werden abgeschlossene und noch nicht fakturierte Tickets ermittelt. Aus den hinterlegten Leistungen können anschließend automatisch die entsprechenden Rechnungen erstellt werden.

Die Rechnung wird als E-Rechnung erzeugt und an den Kunden versendet.

Damit endet die Automatisierung allerdings noch nicht.

Nach der Erstellung wird der Beleg ebenfalls automatisiert an DATEV übertragen und steht dort für die weitere buchhalterische Verarbeitung zur Verfügung.

Aus:

Ticket → Rechnung erstellen → Rechnung versenden → Beleg übertragen

wird damit ein definierter Prozess, der ohne mein Zutun ablaufen kann.

Eingangsrechnungen funktionieren in die andere Richtung

Mindestens genauso interessant war für mich die Frage, was mit Rechnungen passiert, die ich selbst erhalte.

Dafür gibt es ein eigenes Rechnungspostfach.

Das ML Desk ruft dieses Postfach regelmäßig ab und untersucht eingehende Nachrichten zunächst darauf, ob ein entsprechender PDF-Anhang vorhanden ist.

Anschließend wird geprüft, ob es sich bei dem Dokument um eine E-Rechnung handelt.

Ist das der Fall, wird es interessant: Eine E-Rechnung enthält die relevanten Rechnungsinformationen bereits in strukturierter und maschinenlesbarer Form.

Informationen wie Rechnungsnummer, Rechnungsdatum, Beträge und weitere Rechnungsdaten müssen deshalb nicht erst aus dem optischen Erscheinungsbild eines PDFs erraten werden.

Die Daten können automatisiert eingelesen und im ML Desk weiterverarbeitet werden.

Anschließend kann auch dieser Beleg automatisiert an DATEV übertragen werden.

Und was passiert mit klassischen PDF-Rechnungen?

Natürlich bekomme ich weiterhin Rechnungen, die keine strukturierte E-Rechnung sind.

Auch dafür gibt es einen Prozess, welcher allerdings ganz bewusst nicht vollständige automatisiert wurde.

Das System versucht zunächst zu erkennen, ob es sich bei dem eingegangenen Dokument wahrscheinlich um eine Rechnung handelt und liest die verfügbaren Informationen aus.

An dieser Stelle gibt es jedoch einen manuellen Zwischenschritt.

Die Rechnung wird mir zur Überprüfung vorgelegt. Ich kontrolliere die erkannten Rechnungsdaten und kann sie gegebenenfalls korrigieren.

Erst anschließend gebe ich den Import frei.

Das ist für mich ein wichtiger Bestandteil sinnvoller Automatisierung:

Nicht jeder Prozess muss um jeden Preis zu 100 Prozent autonom ablaufen.

Wenn eine zuverlässige technische Grundlage vorhanden ist, kann die Software selbstständig arbeiten. Wo Unsicherheit besteht, wird ein Mensch in den Prozess eingebunden (Human in the loop).

Das Ganze funktioniert ohne KI

Das vielleicht Interessanteste an diesem System ist für mich, was darin nicht vorkommt:

• Keine Anfrage an ChatGPT.
• Keine API zu einem externen LLM.
• Kein lokales Sprachmodell.

Die laufenden Prozesse basieren auf meiner eigenen Software, strukturierten Daten, klar definierten Regeln und regelmäßig ausgeführten Hintergrundprozessen, s.g. Cronjobs.

Gerade bei E-Rechnungen ist das naheliegend.

Wenn mir Daten bereits strukturiert zur Verfügung stehen, brauche ich kein Sprachmodell, das versucht, genau diese Informationen erneut aus einem Dokument zu interpretieren.

Eine Rechnungsnummer ist eine Rechnungsnummer. Ein Rechnungsdatum ist ein Rechnungsdatum. Ein Betrag ist ein Betrag.

Je klarer ein Prozess definiert werden kann, desto interessanter sind klassische deterministische Verfahren.

Datenschutz spielt dabei ebenfalls eine Rolle

Bei Rechnungen kommt für mich noch ein weiterer Punkt hinzu.

Rechnungsdokumente können personenbezogene und geschäftlich sensible Informationen enthalten: Namen, Anschriften, Kundendaten, Leistungen, Preise, Bankverbindungen oder andere Informationen über Geschäftsbeziehungen.

Für eine KI-gestützte Verarbeitung über einen externen Dienst müssten solche Daten, abhängig von der konkreten technischen Lösung, gegebenenfalls an einen weiteren Anbieter übertragen und dort verarbeitet werden.

Das bedeutet nicht, dass der Einsatz eines solchen Dienstes grundsätzlich datenschutzrechtlich problematisch oder unzulässig wäre.

Es bedeutet aber, dass eine weitere Datenverarbeitung und gegebenenfalls ein weiterer externer Empfänger in die Betrachtung einbezogen werden muss.

Wenn ich dasselbe Problem zuverlässig innerhalb meines bestehenden Systems lösen kann, stellt sich für mich deshalb eine einfache Frage:

Warum sollte ich sensible Rechnungsdaten zusätzlich an einen KI-Dienst übertragen, wenn ich ihn für die Aufgabe überhaupt nicht benötige?

In meinem Fall bleiben die Daten innerhalb der für diesen Prozess vorgesehenen Systeme und werden nur dorthin übertragen, wo es für den Geschäftsprozess erforderlich ist.

Datensparsamkeit kann schließlich auch bedeuten, einen zusätzlichen Dienst gar nicht erst einzubinden.

KI war trotzdem beteiligt

Ganz ohne KI ist die Geschichte allerdings nicht.

Denn während ich bewusst auf KI im produktiven Rechnungsprozess verzichte, nutze ich sie inzwischen bei der Entwicklung von Software.

Auch Teile dieser Erweiterungen sind mit Unterstützung von Vibe Coding entstanden.

Für mich bedeutet das allerdings nicht:

Prompt schreiben, generierten Code übernehmen und hoffen, dass alles funktioniert.

KI-generierter Code wird genauso behandelt wie anderer Code.

Die Implementierung wird engmaschig begleitet, nachvollzogen und getestet. Anschließend erfolgt ein Code Review. Wo es sinnvoll ist, wird die Funktionalität testgetrieben entwickelt und durch automatisierte Tests abgesichert.

Gerade bei Prozessen, die Rechnungen erzeugen oder Finanzdaten verarbeiten, möchte ich mich nicht darauf verlassen, dass etwas wahrscheinlich funktioniert.

Es muss reproduzierbar funktionieren.

KI und deterministische Software sind kein Widerspruch

Genau darin liegt für mich eine der interessanteren Entwicklungen der aktuellen KI-Welle.

Wir müssen uns nicht zwischen klassischer Softwareentwicklung und künstlicher Intelligenz entscheiden.

KI kann ein hervorragendes Werkzeug sein, um Software effizienter zu entwickeln.

Die daraus entstehende Software muss deshalb aber noch lange keine KI benötigen.

Für einen unstrukturierten oder schwer vorhersehbaren Prozess kann ein KI-Modell die richtige Lösung sein.

Für einen klar definierten Geschäftsprozess mit strukturierten Daten sind klassische Regeln dagegen häufig einfacher, nachvollziehbarer und kostengünstiger.

Und je nach Anwendungsfall kann es zusätzlich von Vorteil sein, wenn sensible Daten nicht noch an einen weiteren externen Dienst übertragen werden müssen.

Die entscheidende Frage sollte deshalb aus meiner Sicht nicht lauten:

„Wo können wir KI einsetzen?“

Sondern:

„Welches Problem wollen wir lösen und welche Technologie löst es am sinnvollsten?“

Am Ende zählt die eingesparte Arbeit

Die Automatisierung meiner Buchhaltung ist für mich kein Selbstzweck.

Ich habe das ML Desk nicht erweitert, damit ich behaupten kann, meine Rechnungsverarbeitung automatisiert zu haben.

Ich habe es erweitert, weil meine eigene Zeit begrenzt ist.

Jede Minute, in der ich Rechnungsdaten von einem System in ein anderes übertrage, kann ich nicht für die Entwicklung von Software, die Unterstützung meiner Kunden oder die Weiterentwicklung ihrer Geschäftsprozesse einsetzen.

Genau darin sehe ich letztendlich den Wert guter Individualsoftware.

Sie muss nicht spektakulär sein.

Sie muss auch nicht zwangsläufig KI verwenden.

Sie sollte ein konkretes Problem lösen und Menschen Arbeit abnehmen.