Skip to main content

​
Playbook: Back-Office und Buchhaltung

Dieses Playbook veranschaulicht, wie das Agenten-Blueprint-Muster auf eine Abteilung angewendet wird, deren Kernaufgabe die Verarbeitung interner Geschäftsvorgänge ist – Rechnungen, Freigaben, Abstimmungen, Speseneinreichungen und ähnliche finanzielle oder administrative Abläufe. Sie werden darin Ihre Kreditorenbuchhaltung, Ihren Finanzoperations-Bereich oder ein allgemeines Back-Office-Koordinationsteam wiedererkennen. Nutzen Sie dieses Dokument als Referenz, wenn Sie das Blueprint-Muster auf Ihre eigene Abteilung übertragen. Alle Platzhalter („Abteilung C”, „VM-3”, „Ihr ERP-System”) stehen für die realen Bezeichnungen, die Sie im Rahmen eines Scoping-Projekts einsetzen würden.
Dieses Playbook beschreibt ein strukturelles Muster, keine fertige Implementierung. Konkreter Umfang, Zeitrahmen und die genaue Eignung für Ihre Situation werden im Beratungsprozess festgelegt. Siehe Umfang & Grenzen für die Beschreibung des Scoping-Vorgehens.

​
Abteilungsprofil

​
Rollendefinition

Die Rollenbeschreibung des Agenten für eine Back-Office-Abteilung:
VM-3 ist zuständig für den Empfang finanzieller und administrativer Dokumente, deren Prüfung anhand definierter Regeln sowie die Weiterleitung an den zuständigen Freigeber – mit vollständig vorbereiteten Kontextinformationen. Der Agent genehmigt, lehnt ab und führt keine Zahlungen aus. Alle finanziellen Entscheidungen erfordern die ausdrückliche Zustimmung eines Menschen.
Diese Einschränkung ist für Back-Office-Agenten nicht verhandelbar. Der Agent bereitet vor und leitet weiter; eine Person entscheidet. Der Prüfpfad dokumentiert beides.

​
Standardarbeitsanweisungen (SOPs)

Auslöser: Ein neues Dokumentereignis geht aus einer verbundenen Eingabequelle ein (z. B. ein neuer Rechnungsdatensatz in Ihrem ERP-System oder eine Einreichung im gemeinsamen Rechnungspostfach).Schritte:
  1. Die Dokumentfelder extrahieren: Dokumenttyp, Referenznummer, Betrag, Lieferanten- oder Anbieterkennung sowie Datum.
  2. Prüfen, ob die erforderlichen Felder vorhanden und im erwarteten Format vorliegen.
  3. Den zugehörigen Bestellauftrag oder Referenzdatensatz in Ihrem ERP-System nachschlagen.
  4. Schlüsselfelder (Betrag, Lieferant, Positionen sofern vorhanden) mit dem Referenzdatensatz abgleichen.
  5. Einen Prüfstatus zuweisen: übereinstimmend, Abweichung gefunden oder Referenz nicht gefunden.
  6. Das Prüfergebnis am Dokumentdatensatz protokollieren.
  7. Den Vorgang mit dem angehängten Prüfergebnis an SOP 2 (Freigabe-Routing) übergeben.
Eskalationsregel: Wenn das Dokument nicht ausgewertet werden kann oder erforderliche Felder fehlen, wird es mit dem Vermerk „unvollständiges Dokument” an die menschliche Prüfwarteschlange weitergeleitet, ohne einen Prüfversuch zu unternehmen.
Auslöser: Geprüftes Dokument mit Status aus SOP 1.Schritte:
  1. Den zuständigen Freigeber anhand der für dieses Deployment konfigurierten Weiterleitungsregeln ermitteln (Regeln können auf Dokumenttyp, Betragshöhe, Abteilung oder Lieferantenkategorie basieren).
  2. Eine Freigabe-Benachrichtigung verfassen, die Folgendes enthält: Dokumentreferenz, Betrag, Lieferant, Prüfstatus, ggf. Zusammenfassung der Abweichung sowie einen Link zum Dokumentdatensatz in Ihrem ERP-System.
  3. Die Benachrichtigung über den konfigurierten Kanal an den Freigeber senden (z. B. internes Benachrichtigungssystem oder E-Mail).
  4. Die Weiterleitungsmaßnahme mit Freigeber-ID und Zeitstempel protokollieren.
  5. Eine Erinnerung setzen, falls innerhalb des konfigurierten Zeitfensters keine Rückmeldung eingeht.
Eskalationsregel: Wenn der Freigeber anhand der Weiterleitungsregeln nicht ermittelt werden kann, wird der Vorgang mit dem Vermerk „Freigeber unbekannt” an die menschliche Prüfwarteschlange weitergeleitet.
Auslöser: Eine Freigabe- oder Ablehnungsantwort geht von einem Freigeber ein.Schritte:
  1. Die Antwort lesen und die Entscheidung identifizieren: genehmigt, abgelehnt oder zur Klärung zurückgegeben.
  2. Den Dokumentstatus in Ihrem ERP-System entsprechend der Entscheidung aktualisieren.
  3. Die Entscheidung mit Freigeber-ID, Zeitstempel und eventuellen Kommentaren protokollieren.
  4. Bei Genehmigung: Das Dokument als bereit zur Zahlungsabwicklung markieren (keine Zahlung wird vom Agenten ausgelöst).
  5. Bei Ablehnung: Den betreffenden Kontakt oder das Team mit dem Ablehnungsgrund benachrichtigen.
  6. Bei Rückgabe zur Klärung: Das Dokument mit der angehängten Klärungsanfrage an die menschliche Prüfwarteschlange zurückleiten.
Eskalationsregel: Der Agent löst niemals eine Zahlung aus. „Bereit zur Zahlungsabwicklung” ist ausschließlich ein Statusmerkmal – die Zahlungsausführung ist stets ein manueller Schritt durch eine autorisierte Person.
Auslöser: Zeitgesteuerter Auslöser (z. B. Wochenende, Monatsende – wird pro Deployment konfiguriert).Schritte:
  1. Ihr ERP-System nach den im Berichtszeitraum verarbeiteten Dokumenten abfragen: Gesamtanzahl empfangen, übereinstimmend, Abweichungen gefunden, ausstehende Freigabe, genehmigt, abgelehnt.
  2. Die Anzahlen in einer strukturierten Zusammenfassung kompilieren.
  3. Die Zusammenfassung anhand der genehmigten Berichtsvorlage formatieren.
  4. Die Zusammenfassung an die konfigurierten Empfänger senden.
  5. Das Berichtserstellungsereignis mit Zeitstempel protokollieren.
Hinweis: Der Bericht enthält ausschließlich Anzahlen und Status. Er enthält keine Zahlungsdetails oder Kontostände.

​
Eingabequellen

​
Ausgehende Schnittstellen

​
Eskalationsregeln

Die folgenden Situationen werden stets an einen Menschen weitergeleitet:
  • Dokument kann nicht ausgewertet werden oder erforderliche Felder fehlen
  • Referenzdatensatz (Bestellauftrag oder Äquivalent) kann im ERP-System nicht gefunden werden
  • Abweichung zwischen Dokument und Referenzdatensatz festgestellt – diese werden niemals automatisch genehmigt
  • Freigeber kann anhand der Weiterleitungsregeln nicht ermittelt werden
  • Jedes Dokument, das den konfigurierten Betragsschwellenwert überschreitet (Schwellenwert wird pro Deployment festgelegt)
  • Freigabeantwort enthält eine Klärungsanfrage
Der Agent kann Dokumente nicht genehmigen, Zahlungen ausführen oder Finanzdatensätze jenseits von Statusmerkmalen ändern. Diese Einschränkungen werden auf Ebene der Integrationsberechtigungen durchgesetzt, nicht nur in der SOP-Logik.

​
JSON-Nachrichtenfluss (vereinfacht)

Ein vereinfachter Dokumentverarbeitungsereignis-Datensatz, der in das Prüfprotokoll geschrieben wird:
Bei einem Dokument mit einer Abweichung nimmt validation_status den Wert "discrepancy_found" an, discrepancy enthält eine verständliche Beschreibung, und escalated ist true.

​
Prüfpfad

Jede Maßnahme, die der Agent ergreift, wird in ein unveränderliches Prüfprotokoll (Append-Only) geschrieben. Jeder Eintrag dokumentiert:
  • Das Eingabeereignis, das die Maßnahme ausgelöst hat
  • Den ausgeführten SOP-Schritt
  • Die gelesenen und geschriebenen Daten
  • Die beteiligte Person (sofern vorhanden – Freigeber-ID, Prüfer-ID)
  • Einen Zeitstempel
Dieses Protokoll ist die primäre Aufzeichnung für jede nachträgliche Überprüfung oder Rückfrage zur Verarbeitung eines Dokuments. Es kann vom Agenten nach dem Schreiben nicht mehr verändert werden.

​
Stufenweise Ausweitung

Der Einstieg in Phase 1 ermöglicht es dem Team, den Prüf-SOP anhand echter Dokumente zu validieren, bevor Benachrichtigungen an Freigeber versendet werden. In dieser Phase kann die Abweichungserkennung ohne das Risiko einer Fehlweiterleitung von Freigaben kalibriert werden.

​
Querverweise