700 Eingangsrechnungen im Monat, und der Agent genehmigt null davon

Elf getrennte Verwaltungen. Eine Freizeitgruppe. Durchschnittlich 713 Eingangsrechnungsbuchungen pro Monat, verteilt über Einheiten mit jeweils eigenen Kostenstellen, eigenen Mehrwertsteuer-Eigenheiten und eigenen Vorstellungen davon, wie ein Lieferant kodiert werden sollte.

Also haben wir dafür einen Agent gebaut. Er liest die Rechnung, gleicht den Lieferanten ab, schlägt das Sachkonto vor, trägt die Kostenstelle ein, setzt den Mehrwertsteuer-Code und schreibt alles in Exact Online. Jeden Arbeitstag, ohne zu fragen.

Und er genehmigt davon exakt null.

Das ist keine Einschränkung, an der wir noch arbeiten. Das ist das Design. Denn die eigentlich interessante Frage bei der Automatisierung der Rechnungsverarbeitung ist nicht, wie viel sie leisten kann. Es ist, wo sie aufhören muss, und ob sich überhaupt jemand die Mühe gemacht hat, das bewusst zu entscheiden.

Der Mythos vom selbstsicheren Agent

Die meiste Automatisierung wird mit Selbstvertrauen verkauft. Sie liest das Dokument, kennt die Antwort, bucht die Zeile. Demos lieben das. Man lädt ein PDF hoch, die Felder füllen sich von selbst, alle im Raum nicken.

Diese Demo verbirgt jedoch die einzige Zahl, die im Finanzwesen wirklich zählt: Was passiert mit den Fällen, bei denen es falsch lag?

Ein Modell zur Rechnungsverarbeitung, das zu 95 Prozent richtig liegt, klingt nach einem starken Ergebnis. In einem Klassifizierungsbenchmark ist es das auch. In einem Hauptbuch ist es ein langsames Leck. Denn die 5 Prozent kündigen sich nicht an. Sie sehen exakt aus wie die 95 Prozent: ein ausgefülltes Feld, ein plausibles Konto, eine Buchung, die durch die Prüfung rutscht, weil nichts daran auffällig wirkt.

Ein Agent, der zu 95 Prozent richtig rät, bringt bei 713 Rechnungen trotzdem etwa 35 falsche Zeilen pro Monat in Ihr Hauptbuch. Wir bauen lieber einen, der sagt: bei diesen sieben weiß ich es nicht.

35 falsche Zeilen pro Monat sind 420 pro Jahr. Verteilt über elf Verwaltungen, von denen keine groß genug ist, um allein einen Alarm auszulösen. Man findet sie zum Jahresende, oder der Steuerberater findet sie, oder man findet sie nie, und das Kostenstellen-Reporting liegt seit drei Quartalen still und leise daneben.

Sieben leere Felder mit einer angehängten Begründung sind an einem Dienstagmorgen eine Zehn-Minuten-Aufgabe.

Designentscheidung eins: Er entwirft, er unterschreibt nie

Der Agent erstellt Entwürfe. Er genehmigt nie und zahlt nie. Das steht im Vertrag, den wir mit dem Kunden geschlossen haben, nicht in einem Einstellungsbildschirm, wo ein künftiger Administrator es bequemerweise umschalten könnte.

Das klingt banaler, als es ist. In dem Moment, in dem eine Automatisierung ihre eigene Arbeit genehmigen kann, haben Sie die letzte Stelle entfernt, an der ein Mensch eine Zahl liest, bevor Geld bewegt wird. Und der Druck, diesen Schalter umzulegen, kommt immer später, immer aus gutem Grund: Die Entwürfe stapeln sich, die Qualität ist offensichtlich gut, jemand ist im Urlaub.

Deshalb haben wir es strukturell unmöglich gemacht. Der Agent hat Schreibzugriff auf Entwurfsbuchungen. Er hat keine Berechtigung zur Genehmigung. Nicht weil wir dem Modell misstrauen, sondern weil die Person, die Ausgaben absegnet, auch die Person sein sollte, die dafür verantwortlich ist. Automatisierung sollte die Arbeit vor dieser Unterschrift verdichten, nicht die Unterschrift entfernen.

Außerdem ist genau das der Grund, warum das Ganze überhaupt akzeptiert wird. Ein Controller lässt einen Agent 713 Buchungen vorbereiten. Kein Controller lässt einen Agent 713 Rechnungen bezahlen, und zu Recht nicht.

Designentscheidung zwei: unbekannt ist nicht null

Das ist das Rückgrat der gesamten Konstruktion.

Wenn sich der Agent bei der Kostenstelle nicht sicher ist, lässt er die Kostenstelle leer. Wenn er die Mehrwertsteuerbehandlung nicht mit Sicherheit bestimmen kann, lässt er den Mehrwertsteuer-Code leer. In beiden Fällen fügt er eine kurze Begründung hinzu: neuer Lieferant ohne Buchungshistorie, Rechnungsposition betrifft zwei Einheiten, Mehrwertsteuerangabe auf dem Dokument widerspricht der üblichen Behandlung des Lieferanten.

Er trägt nicht den wahrscheinlichsten Wert ein.

Die meisten Systeme machen das Gegenteil, weil ein vollständig ausgefüllter Datensatz fertig wirkt und ein leeres Feld wie ein Versagen aussieht. Aber ein leeres Feld fällt einem Menschen auf. Ein plausibler, falscher Wert nicht. Diese Asymmetrie ist der ganze Punkt. Ihr Prüfprozess ist darauf ausgelegt, Lücken zu finden, nicht darauf, selbstsicheren Antworten erneut nachzugehen.

Das Ergebnis des Agents lautet also nicht "713 Buchungen, erledigt". Es lautet "706 vollständige Entwürfe, 7 mit offenen Feldern, und hier die Gründe dafür". Die menschliche Arbeit verlagert sich von der Kontrolle von allem hin zur Klärung von Ausnahmen, und das ist die einzige Variante davon, die tatsächlich Zeit spart, statt sie nur zu verschieben.

Jede Buchung trägt ihre Begründung bei sich

Jeder Entwurf hält fest, warum er so gebucht wurde, wie er gebucht wurde: welche Lieferantenregel angewendet wurde, mit welchen historischen Buchungen abgeglichen wurde, welcher Einheit sie zugeordnet wurde und auf welcher Grundlage. Kein Konfidenzwert. Eine Prüfzeile, die ein Controller lesen kann.

Denn "das System hat es so gemacht" ist keine Antwort, die Sie Ihrem Steuerberater geben können, und es ist auch keine Antwort, die irgendjemandem erlaubt, die Regeln zu verbessern. Wenn Sie eine Buchung nicht auf die Regel zurückführen können, die sie erzeugt hat, können Sie die Regel nicht korrigieren. Sie können nur mit dem Ergebnis streiten, Rechnung für Rechnung, auf unbestimmte Zeit. Das ist dasselbe Fehlermuster wie bei einer schwachen Architektur hinter einem starken Modell: Die Intelligenz ist in Ordnung, die Struktur darum herum macht sie unbrauchbar.

Designentscheidung drei: Er lernt, aber erst ab einem Quorum

Selbstlernen ist das Feature, nach dem jeder fragt und das kaum jemand sauber eingrenzt. Der Pitch ist naheliegend: einmal korrigieren, und der Fehler passiert nie wieder. Effizient. Bei einer Elf-Entitäten-Verwaltung aber auch gefährlich.

Denn eine einzelne Korrektur ist kein Wissen. Es könnte ein Einzelfall sein. Es könnte jemand sein, der in Eile etwas auf die falsche Kostenstelle gebucht hat. Es könnte eine vorübergehende Regelung sein, die nur für ein Projekt gilt und für sonst nichts. Macht man daraus eine Regel, hat man dem Agent nichts beigebracht. Man hat zugelassen, dass die Ausnahme einer einzelnen Person zur Richtlinie für elf Verwaltungen wird.

Deshalb haben wir ein Quorum festgelegt. Eine Korrektur wird zur Regel, wenn zwei verschiedene Personen dieselbe Korrektur vornehmen, oder wenn eine Person dieselbe Korrektur dreimal vornimmt. Alles unterhalb dieser Schwelle wird als Signal protokolliert, nicht als Regel. Es wartet.

Außerdem laufen Regeln ab. Eine gelernte Regel hat eine Lebensdauer von 60 Tagen. Bestätigt sie niemand in diesem Zeitfenster erneut, fällt sie heraus, und der Agent fragt wieder nach. Lieferanten ändern sich, Verträge ändern sich, Projekte enden. Eine im März gelernte Regel sollte im November nicht still und heimlich Ihre Buchungen bestimmen, nur weil niemand daran gedacht hat, danach zu schauen.

Und es gibt einen einzigen Schalter, der das Lernen vollständig abschaltet, ohne den Agent zu deaktivieren. Monatsabschluss, eine Prüfung, eine Migration, ein Zeitraum, in dem das Verhalten eingefroren werden soll: umlegen. Der Agent bucht weiterhin Entwürfe nach den vorhandenen Regeln und übernimmt keine neuen mehr. Dieser Schalter existiert, weil "wir müssen das Lernen stoppen" niemals bedeuten sollte, dass die Automatisierung offline geht.

Selbstlernen ohne Quorum ist kein Agent, der klüger wird. Es ist ein Agent, der seine eigenen Fehler zementiert, immer schneller, mit jeder Korrektur, die er als Lektion missversteht.

Sieben Fragen für Ihre eigene Rechnungsautomatisierung

Wenn Sie die Verarbeitung von Eingangsrechnungen bereits automatisieren, oder ein Anbieter Ihnen das gerade verkaufen will, gehen Sie das Folgende durch. Die Antworten sagen mehr aus als jede Genauigkeitsangabe auf einer Folie.

• Ihre Automatisierung endet bei einem Entwurf, den ein Mensch absegnen muss, und kann nicht selbst genehmigen oder zahlen
• Wenn sie sich bei einem Feld nicht sicher ist, lässt sie dieses Feld mit einer Begründung leer, statt die beste Vermutung einzutragen
• Jede Buchung lässt sich auf die konkrete Regel oder Historie zurückführen, die sie erzeugt hat, ohne dass man dem System einfach glauben muss
• Eine Korrektur ändert das Verhalten erst ab einer definierten Schwelle, und Sie wissen, wie viele Personen und wie viele Wiederholungen dafür nötig sind
• Gelernte Regeln laufen von selbst ab, wenn niemand sie erneut bestätigt, statt so lange bestehen zu bleiben, bis jemand merkt, dass sie falsch sind
• Es gibt einen einzigen Schalter, der den Agent am Lernen hindert, ohne die Automatisierung abzuschalten
• Sie kennen das tägliche API-Limit Ihrer Buchhaltungsplattform und wissen, wie nah Ihre Automatisierung diesem Limit in Spitzenzeiten kommt

Zwei oder mehr nicht erfüllte Punkte sind eine Designlücke, kein Feintuning-Problem. Sind die ersten beiden nicht erfüllt, haben Sie keine Rechnungsautomatisierung. Sie haben einen unbeaufsichtigten Buchhalter ohne Rechenschaftspflicht mit einem sehr guten Gedächtnis für die eigenen Fehler.

Hier geht es nicht um Exact Online

Wir haben das auf Exact Online aufgebaut, und die API-Limits haben das Batching, die Retry-Logik und das Tempo, mit dem sich der Agent über elf Verwaltungen hinweg bewegt, geprägt. Das ist echte Ingenieursarbeit, und bei 713 Rechnungen im Monat spielt sie eine Rolle.

Aber nichts von der oben beschriebenen Logik ist an Exact gebunden. Nur-Entwurf-Berechtigungen, leer statt geraten, nachvollziehbare Buchungen, quorumbasiertes Lernen, ablaufende Regeln: Jedes Buchhaltungspaket mit einer brauchbaren API kann das tragen. Die Integration ist die leichtere Hälfte.

Die schwierigere Hälfte ist, die eigenen Buchungsregeln des Kunden zu kodieren. Welcher Lieferant geht auf welches Konto in welcher Einheit. Wie Intercompany-Posten aufgeteilt werden. Welche Kostenstellen projektgebunden sind und welche dauerhaft bestehen. Wann eine Mehrwertsteuerbehandlung abweicht und warum. Dieses Wissen steckt in den Köpfen zweier Personen und in einer Tabelle, die seit 2022 niemand mehr aktualisiert hat, und es herauszuholen macht den Großteil des Projekts aus.

Das ist auch der Grund, warum "einfach eine KI anschließen" hier nie funktioniert. Es gibt kein Modell, das Ihre Buchungsregeln kennt. Es gibt nur die Arbeit, sie zum ersten Mal richtig schriftlich festzuhalten.

The ODB Way

Wir fragen nicht zuerst, was der Agent automatisieren kann. Wir fragen zuerst, wo er aufhören muss, wer unterschreibt, und was mit den Fällen passiert, bei denen er falsch liegt. Von dort aus bauen wir nach innen.

In der Praxis bedeutet das: den tatsächlichen Prozess kartieren, bevor eine API berührt wird, die echten Buchungsregeln des Kunden kodieren statt generischer Best Practices, und etwas ausliefern, das jeden Tag im Produktivbetrieb läuft, statt eines Piloten, der einmal beeindruckt. Die Verweigerungen sind Teil der Spezifikation, keine Einschränkung, die in Version zwei entfernt werden soll.

Wenn Sie das größere Argument dafür lesen möchten, warum Automatisierung Handlungen und Entscheidungen hervorbringen sollte statt Antworten, lesen Sie warum Ihre KI zum Handeln führen sollte. Und wenn Sie sich fragen, warum so viele Finanz- und Back-Office-Piloten in der Demo großartig aussehen und dann stocken, behandelt die vier Stellen, an denen KI-Piloten still und leise sterben die meisten Gründe, auf die wir stoßen.