Wo ERP-Agenten aufhören

Die Konzerncontrollerin hatte in einem Fenster die Release Notes von Microsoft offen, im anderen die Checkliste für den Monatsabschluss. Zwei Länder der Gruppe arbeiten mit Business Central, einem ERP von Microsoft: dem Geschäftssystem, das Aufträge, Rechnungen und Buchhaltung eines Unternehmens hält. Das dritte führt seine Bücher noch im lokalen System aus der Zeit vor der Übernahme, und Zahlungen kommen von vier Banken als Kontoauszugsdateien, den Listen der Banken über Geldein- und -ausgänge. Ihre Frage war kurz: Microsoft liefert jetzt KI-Agenten für Rechnungen und Abstimmung. Welche der geplanten Arbeiten brauchen wir noch?

Ein Teil davon war gerade überflüssig geworden. Der größte Teil des schwierigen Stücks hatte sich nicht bewegt.

Was ausgeliefert wurde, in den Worten des Herstellers

Business Central hat jetzt einen Payables Agent, der als allgemein verfügbar geführt wird. Microsoft beschreibt ihn als Agenten, der "monitors mailboxes for incoming vendor invoices, uses AI to analyze invoice content, and shows invoice drafts to agent supervisors for review." Er überwacht also Postfächer auf Lieferantenrechnungen, analysiert sie und legt die Entwürfe zur Prüfung vor. Er liest PDF-Rechnungen aus einem Microsoft-365-Postfach, erkennt den Lieferanten, schlägt die Rechnungszeilen vor, gleicht sie mit dem Bestellten ab und macht aus einem freigegebenen Entwurf eine Lieferantenrechnung im System.

Daneben gibt es einen Sales Order Agent und einen Expense Agent. Die Tabelle unten stellt alle vier nebeneinander.

Dynamics 365 Finance, das andere Finanz-ERP von Microsoft, hat einen Account Reconciliation Agent, ebenfalls in der Vorschau. Abstimmung heißt: prüfen, ob die Detaillisten, etwa was jedem Lieferanten und Kunden zusteht, mit den Summen in den Hauptbüchern übereinstimmen. Der Agent "evaluates exceptions and provides a recommended action for each one", bewertet also Abweichungen und empfiehlt für jede eine Maßnahme. Die ersten Releases decken Lieferanten- und Kundensalden, Steuern und Bank ab.

Nichts davon ist eine Demonstration. Es läuft in den Produkten, unter deren Sicherheitsregeln, und jeder Agent arbeitet als eigener Benutzer. Seine Arbeit erscheint deshalb in denselben Feldern "Erstellt von" und "Geändert von" wie die einer Person.

Was sie bewusst den Menschen überlassen

Die nützlichsten Sätze in der Dokumentation sagen, was die Agenten nicht tun.

Der Payables Agent "doesn't post purchase invoices": Er bucht keine Rechnung, erfasst sie also nie endgültig in den Büchern, wodurch sie verbindlich und zahlbar würde. Einen eigenen Freigabeprozess hat er nicht. Ein Lieferant, den er anlegt, bleibt gesperrt, bis jemand ihn freigibt, und die Dokumentation sagt klar, dass Bankdaten von Lieferanten wie bisher bestätigt werden: mit einem Anruf beim Lieferanten. Der Sales Order Agent erstellt zuerst ein Angebot, auch wenn der Kunde um einen Auftrag bittet. Der Abstimmungsagent empfiehlt für jede Abweichung eine Korrektur; eine Person nimmt sie an, storniert sie, verknüpft die Buchungen oder akzeptiert die Differenz.

Das liest sich weniger wie eine Lücke als wie eine Designentscheidung: Der Agent bereitet vor, eine Person legt sich fest, und der Datensatz zeigt, wer was getan hat. Genau dort würde ein sorgfältiges Finanzteam die Linie ziehen, und es lohnt sich, sie beizubehalten, auch wenn ein späteres Release erlaubt, sie zu verschieben.

Wo sie aufhören

Für die Controllerin war die entscheidende Grenze der Rand jedes einzelnen Systems.

Diese Agenten arbeiten in Business Central online oder in Dynamics 365 Finance, mit den Daten, die diese Systeme halten. Rechnungen kommen als PDF über ein überwachtes Microsoft-365-Postfach. Es gibt einen Payables Agent pro Gesellschaft. Zu Systemen anderer Hersteller, zu lokalen Büchern, die nach einer Übernahme weitergeführt werden, und zu Kontoauszugsdateien sagt die Dokumentation nichts, und dieses Schweigen ist die Grenze. Die Agenten behaupten nicht, dort zu arbeiten, also sollte man sie auch nicht so einplanen.

In ihrer Gruppe blieben die Agenten damit nützlich für den Großteil der Lieferantenrechnungen und für die Abstimmung in den beiden Business-Central-Ländern. Unberührt blieb die Arbeit, die tatsächlich bestimmte, wann der Monatsabschluss, also das Fertigstellen und Prüfen der Monatszahlen, erledigt war: die Beträge, die sich die drei Gesellschaften gegenseitig schulden, der Abgleich der Kontoauszugszeilen von vier Banken mit offenen Rechnungen in drei Buchhaltungen und die Erklärung, warum die Zahlen der Gruppe am letzten Tag übereinstimmten.

Die Rechnung kommt pro Aktion

Die Agenten werden in Copilot Credits, den Verbrauchseinheiten von Microsoft, pro Aktion abgerechnet. Microsofts eigenes Beispiel für den Payables Agent rechnet mit 50 Credits für die Verarbeitung einer Rechnung und 5 für jede Zeile. 100 Rechnungen mit je drei Zeilen im Monat ergeben also 6.500 Credits. Sind die Credits aufgebraucht, nimmt der Agent keine neuen Rechnungen mehr an und arbeitet den Rückstand ab, sobald wieder Kapazität da ist.

Daraus folgen zwei Konsequenzen für das Design, und keine betrifft den Preis, den wir dem Lizenzgespräch überlassen. Erstens gehören Routineprüfungen, die reine Arithmetik sind, etwa eine Menge gegen eine Lieferung oder eine Summe gegen einen Sollwert, in gewöhnlichen Code, wo sie pro Durchlauf nichts kosten. Zweitens gehört das Credit-Guthaben in den Abschlusskalender. Ein Agent, der am 29. pausiert, weil die Kapazität des Monats aufgebraucht ist, ist ein Risiko für den Abschluss und sollte auch so geplant werden.

Um sie herum planen, nicht gegen sie

Der Plan, den wir der Controllerin gaben, hatte drei Teile.

Den eingebauten Agenten in jedem System nutzen. Wo der Agent von Business Central die Arbeit abdeckt, schalten Sie ihn ein und lassen ihn die routinemäßigen Rechnungen und Angebote übernehmen. Der Hersteller pflegt ihn, er folgt den Berechtigungen des Produkts, und niemand in der Gruppe muss seinen Code verantworten.

Nur die Ebene bauen, die sie nicht sehen. Eine Ebene über die Systeme hinweg liest die drei Buchhaltungen und die Kontoauszugsdateien der vier Banken, hält die Regeln, die das Finanzteam schon heute für Geld zwischen den eigenen Gesellschaften anwendet, und bereitet die Zuordnungen und Ausnahmen für eine Person vor. Sie wiederholt nicht, was die eingebauten Agenten tun. Sie beginnt dort, wo deren Dokumentation verstummt.

Einen einzigen Nachweispfad führen. Jeder eingebaute Agent protokolliert seine Aktionen bereits unter seinem eigenen Benutzernamen. Die systemübergreifende Ebene protokolliert ihre Vorschläge und die Entscheidungen der prüfenden Person genauso, verknüpft mit denselben Belegen. Am Monatsende kann die Controllerin eine Zahl von der Bankzeile bis zum Eintrag in den Büchern verfolgen, über jeden Agenten und jede Person, die sie berührt haben, in einem Pfad statt in dreien. Die Freigabe selbst bleibt im Geschäftssystem, bei den Menschen, denen sie schon heute gehört.

Der erste Monat

Wir haben vorgeschlagen, klein anzufangen, mit ihren eigenen Zahlen. Der Payables Agent hat einen Testmodus, der bis zu 50 Rechnungen verarbeitet, ohne abrechenbare Credits zu verbrauchen. Der erste Schritt kostete also nichts: ihn auf die Rechnungen einer Gesellschaft aus einem bereits abgeschlossenen Monat ansetzen und seine Entwürfe mit dem vergleichen, was das Team tatsächlich gebucht hat. Wo die Entwürfe übereinstimmen, können die Routinerechnungen dieser Gesellschaft zum Agenten wandern. Wo nicht, zeigen die Gründe, welche Lieferanten oder Rechnungslayouts weiterhin eine Person brauchen.

Der zweite Schritt war die systemübergreifende Ebene, beschränkt auf eine Aufgabe: die Beträge, die sich die drei Gesellschaften gegenseitig schulden. Sie entschieden am häufigsten über den letzten Tag des Abschlusses, und dort brachte Engineering-Zeit am meisten. Die Kontoauszüge kamen danach, als die Ebene einen Abschluss lang gehalten hatte.