Kurz nach Mittag landen die ersten Rechnungen in der Buchhaltung. Eine Mitarbeiterin öffnet den Beleg, sucht die passende Bestellung und stellt fest, dass nie eine Purchase Order angelegt wurde. Der Einkauf lief per E-Mail, der Wareneingang steht auf einem Zettel neben dem Telefon, und der Vorgang kommt erst jetzt ins System.
Genau dort bricht ein Purchase Order Workflow auseinander. Zwischen Bedarfsmeldung, Genehmigung, Bestellung, Wareneingang und Rechnung fehlt die durchgehende Referenz. In Österreich ist das besonders unangenehm, weil strukturierte E-Rechnungen, die Anforderungen öffentlicher Auftraggeber und die Aufbewahrungspflichten den Prozess nicht erst beim Rechnungseingang beginnen lassen. Die Bestellung muss vorher existieren, eindeutig referenziert sein und mit Lieferung und Rechnung zusammenpassen.
Dieser Beitrag zeigt, wie Sie den Bestellprozess mit KI und ERP-Konnektoren automatisieren: vom Bedarf zur PO, über Freigaben und österreichische Rahmenbedingungen bis zu Agenten, Audit-Logging und einem Rollout in zwei Wochen.
Wenn die Bestellung erst mit der Rechnung entsteht
Die Buchhaltung arbeitet sich also rückwärts vor. Sie sucht im Postfach nach dem Lieferanten, durchsucht Chats und fragt beim Fachbereich nach. Niemand kann sofort sagen, wer die Leistung bestellt hat, welche Menge vereinbart war oder ob der Wareneingang tatsächlich stattgefunden hat. Die Finance-Leitung stopft täglich die Lücke zwischen Bedarf, Bestellung, Lieferung und Rechnung, lässt sich Screenshots schicken, gleicht Positionen ab und entscheidet, ob eine Rechnung trotz fehlender PO weiterbearbeitet werden darf.
Praktische Regel: Eine Bestellung, die erst beim Rechnungseingang angelegt wird, ist keine Kontrolle. Sie ist nachträgliche Dokumentation.
Der Bruch sitzt vor der Buchhaltung
In vielen Unternehmen entstehen Bestellungen erst im Nachhinein, obwohl sie vor der Bestellung beim Lieferanten angelegt sein sollten. Fehlt die PO-Referenz, entstehen manuelle Klärungen, und der Zahlungslauf verzögert sich. Viele größere Kunden verlangen deshalb von ihren Lieferanten die Bestellnummer auf jeder Rechnung und weisen Rechnungen ohne diese Referenz zurück.
Der technische Fehler ist meist unspektakulär: Die Rechnung enthält keine Bestellnummer, die Leistungsbeschreibung weicht vom Bestelltext ab, oder der Lieferant ist im ERP und in der Buchhaltung unterschiedlich angelegt. Trotzdem blockiert dieser kleine Bruch den gesamten Ablauf. Ein Drei-Wege-Abgleich kann nur prüfen, was als drei konsistente Objekte existiert: Bestellung, Wareneingang und Rechnung.
Was Automatisierung zuerst lösen muss
KI sollte hier nicht mit einer Chat-Oberfläche beginnen. Der erste sinnvolle Schritt ist die Erkennung von Belegen, Lieferanten und Positionen, gefolgt von einer harten Validierung gegen den Bestellbestand.
- Bedarf erfassen: Eine E-Mail, ein Intranet-Formular oder eine ERP-Anfrage wird in strukturierte Felder überführt.
- PO erzeugen: Das System legt die Bestellung sofort mit Lieferant, Kostenstelle, Menge und Referenz im ERP an.
- Wareneingang verbinden: Eine Bestätigung oder ein ERP-Ereignis schreibt den Lieferstatus an die richtige Bestellposition.
- Rechnung prüfen: Die Rechnung läuft nur dann automatisch weiter, wenn Bestellung, Lieferung und Rechnungsdaten zusammenpassen.
- Ausnahme eskalieren: Abweichungen gehen an eine definierte Person, nicht in einen allgemeinen Posteingang.
Der Auslöser für Automatisierung ist also nicht der Wunsch nach einem schnelleren Freigabeklick, sondern die fehlende Verbindung zwischen den Belegen. Solange diese Verbindung fehlt, automatisiert man nur die Weiterleitung von Problemen.
Vom Bedarf zur Bestellung im ERP
Ein belastbarer Ablauf beginnt mit einer Bedarfsmeldung aus einem Formular, einer ERP-Eingangsmaske oder einer strukturierten E-Mail. Ein Konnektor übernimmt die Anfrage, validiert Pflichtfelder und legt die Bestellung im führenden ERP an, etwa in Microsoft Dynamics NAV oder Business Central, SAP oder BMD. Die Buchhaltung, zum Beispiel in BMD oder DATEV, erhält später die Buchung aus Wareneingang und Rechnung, nicht die Bestellung selbst.
Für den Bestellkopf braucht der Konnektor mindestens Lieferantennummer, Kostenstelle, Bestellmenge mit Einheit und Warenempfänger. Fehlt eines dieser Felder, setzt der Workflow keinen Standardwert ein. Er stellt die Anfrage zurück und holt den fehlenden Kontext beim Antragsteller ein. Außerdem speichert er die ursprüngliche Bedarfs-ID, damit sich jede Bestellung bis zur Anfrage zurückverfolgen lässt.
Das Mapping entscheidet über die Qualität
| Feld | Führend im ERP (Beispiel Business Central) | Übergabe an die Buchhaltung | Typische Falle |
|---|---|---|---|
| Lieferant | Kreditorennummer (Vendor No.) | Kreditorenkonto | Doppelte oder abweichende Lieferantenstammdaten |
| Kostenstelle | Dimension Code | Kostenstelle oder Kostenträger | Änderungen werden nicht synchronisiert |
| Bestellmenge | Quantity mit Einheit | Nicht übergeben, nur für den Abgleich | Einheit nicht eindeutig |
| Bestellnummer | Bestellnummer aus dem Nummernkreis | Referenz auf Rechnung und Buchung | Nummernkreis nicht abgestimmt |
| Lieferantenreferenz | External Document No. | Belegnummer der Rechnung | Freitext statt eindeutiger Nummer |
| Bestelldatum | Order Date | Nicht übergeben | Falsches Datumsformat |
| Lieferbedingung | Shipment Method Code | Nicht übergeben | Freitext statt Code |
| Steuer | VAT Prod. Posting Group | Steuercode der Buchung | Reverse Charge falsch zugeordnet |
Die häufigsten Fehler liegen nicht in der API, sondern in den Stammdaten. ERP und Buchhaltung führen denselben Lieferanten unter unterschiedlichen Nummern, Kostenstellen werden in einem System geändert und im anderen nicht, und bei Reverse Charge greift eine scheinbar passende Steuerautomatik, obwohl der Vorgang eine andere Behandlung verlangt.
Schnittstellen brauchen Rückmeldung
Der Konnektor darf keine Einbahnstraße sein. Nach der Übergabe braucht er die erzeugte Bestellnummer, den ERP-Status und eventuelle Validierungsfehler zurück. Erst dann erhält die antragstellende Person eine belastbare Referenz. Bei Business Central kommen dafür die OData- und REST-APIs infrage, bei älteren NAV-Versionen SOAP-Webservices. Die Buchhaltungsseite wird je nach Produkt über die jeweilige Schnittstelle angebunden, etwa DATEVconnect oder die BMD-Schnittstellen. Entscheidend ist, dass der Konnektor keine eigene Schatten-Bestellung führt, die später vom ERP abweicht.
Ein häufiger Irrtum lautet: Ohne physischen Wareneingang braucht es keine PO. Bei Dienstleistungen, Abos und Beratungsleistungen stimmt das nicht. Dort braucht der Drei-Wege-Abgleich ein anderes Referenzobjekt, etwa eine Leistungsbestätigung. Wer die Bestellung nur für Lagerware nutzt, lässt einen großen Teil der Ausgaben unkontrolliert. Mehr zur Einbindung von KI in ERP-Landschaften beschreibt der Beitrag zu KI in ERP-Systemen. Der Kern bleibt einfach: Bedarf rein, Stammdaten prüfen, Bestellung im führenden ERP erzeugen, ERP-Nummer zurückgeben.
Freigaben oder Compliance zuerst: die österreichische Falle im PO-Design
Ein schneller Genehmigungsschritt macht noch keinen guten Purchase Order Workflow. In Österreich muss die Bestellung so gestaltet sein, dass sie später mit E-Rechnung, Wareneingang und Archiv zusammenpasst. Wer nur die Freigabekette beschleunigt, verschiebt den Engpass in die Rechnungsprüfung.
Ein Bauzulieferer automatisiert zum Beispiel nur die Genehmigung. Der Projektleiter gibt die Anfrage frei, der Einkauf bestellt per E-Mail, und der Lieferant stellt später eine Rechnung ohne Bestellbezug. Der Drei-Wege-Abgleich schlägt fehl, die Buchhaltung korrigiert manuell, obwohl der Genehmigungsschritt technisch erfolgreich war.
Die österreichischen Rahmenbedingungen
E-Rechnung an den Bund: Bundesdienststellen akzeptieren seit 1. Jänner 2014 nur strukturierte elektronische Rechnungen, eingebracht über e-Rechnung.gv.at, das Unternehmensserviceportal oder Peppol. Nach der EU-Richtlinie 2014/55/EU müssen öffentliche Auftraggeber E-Rechnungen nach der europäischen Norm EN 16931 empfangen und verarbeiten können, wie die EU-Übersicht zur österreichischen E-Rechnung beschreibt.
Auftragsreferenz statt Freitext: Rechnungen an den Bund brauchen verpflichtend eine Auftragsreferenz, also entweder die zehnstellige Bestellnummer des Bundes oder die dreistellige Einkäufergruppe, sowie die vom Auftraggeber vergebene Lieferantennummer. Bei Bestellnummern ist zusätzlich die Bestellpositionsnummer je Rechnungszeile anzugeben. Ihr PO-Workflow muss diese Referenzen aus dem Auftrag übernehmen und bis zur Rechnung durchreichen.
UID-Prüfung: Die UID-Nummer eines Geschäftspartners wird über das UID-Bestätigungsverfahren in FinanzOnline oder über das EU-System MIAS geprüft. Diese Prüfung gehört in die Stammdatenanlage, nicht in die Rechnungsprüfung.
Aufbewahrung: Bücher, Belege und Geschäftspapiere sind nach § 132 BAO grundsätzlich sieben Jahre aufzubewahren. Für Unterlagen zu Grundstücken gelten nach § 18 Abs. 10 UStG zwölf Jahre, für bestimmte Grundstücke sogar 22 Jahre, wie das Unternehmensserviceportal zusammenfasst.
Für die PO-Architektur bedeutet das:
- Referenzen müssen stabil sein: Die Bestellnummer darf nicht erst mit der Rechnung entstehen.
- Daten müssen strukturiert bleiben: Freitext in E-Mails reicht für den späteren Abgleich nicht.
- Fehler brauchen Zustände: Eine abweichende Position wird als Ausnahme mit Owner und Korrekturpfad gespeichert.
- Archivdaten gehören zusammen: Bestellung, Liefernachweis und Rechnung dürfen nicht in getrennten Ablagen verschwinden.
Die richtige Optimierungsfrage lautet deshalb nicht, wie viele Klicks eine Freigabe braucht, sondern: Kann das System den Vorgang vom Bedarf bis zum archivierten Beleg ohne Medienbruch erklären?
Agenten-Orchestrierung über MCP und ERP-Konnektoren
Ein KI-gestützter Purchase Order Workflow braucht eine klare Arbeitsteilung. Ein einzelner Agent, der gleichzeitig Lieferanten sucht, Buchungslogik entscheidet und ERP-Daten schreibt, ist schwer zu testen und riskant im Betrieb. Besser funktioniert eine Orchestrierung, die kleine, überprüfbare Aufgaben an spezialisierte Agenten verteilt.
Die Anfrage landet in der MCP-Schicht. Ein Bestell-Agent zerlegt sie in Validierung, Dublettenprüfung und ERP-Roundtrip. Ein ERP-Gateway hält die Konnektoren für ERP und Buchhaltung bereit. Ein Freigabe-Agent verwaltet die Genehmigungswarteschlangen, und ein Audit-Agent schreibt jeden Statuswechsel in den Audit-Trail.
Jeder Agent braucht einen begrenzten Auftrag
Der Bestell-Agent darf Felder normalisieren und fehlende Angaben erkennen. Er entscheidet aber nicht, ob eine steuerliche Ausnahme zulässig ist. Diese Entscheidung gehört in eine explizite Regel oder zu Finance. Ein MCP-Tool-Aufruf übergibt typisierte Daten:
create_purchase_order(
supplier_number: string,
order_quantity: decimal,
unit_of_measure: string,
cost_centre: string,
goods_recipient: string,
idempotency_key: string
)
Das ERP-Gateway übersetzt diese Struktur in die jeweilige Schnittstelle und gibt nicht nur Erfolg oder Fehler zurück, sondern auch Belegnummer, Status und eine fachlich verwertbare Fehlermeldung.
Architekturentscheidung: Synchrone Aufrufe eignen sich für die Rückgabe der Belegnummer. Statusänderungen sollten asynchron verarbeitet werden, damit ein langsames ERP nicht den ganzen Ablauf blockiert.
Wiederholungen dürfen keine Doppelbestellungen erzeugen
Netzwerkfehler und abgelaufene Sessions sind normal. Ohne Idempotenzschlüssel kann ein Wiederholungsversuch jedoch eine zweite Bestellung anlegen. Der Schlüssel entsteht aus der stabilen Bedarfs-ID und einem eindeutigen Vorgangskontext, und das Gateway speichert, ob er bereits verarbeitet wurde. Session-Handling, Token-Erneuerung und erneute Authentifizierung gehören in das Gateway, nicht in die Fachlogik des Bestell-Agenten. So bleibt der fachliche Ablauf testbar.
KI bringt hier den größten Nutzen bei Klassifikation, Dublettenprüfung, Begründung von Ausnahmen und Routing. Die eigentliche Buchung bleibt deterministisch und nachvollziehbar. Wie eine solche Architektur als Plattform zentral gesteuert wird, beschreibt unser Beitrag zur Enterprise Automation Platform.
Audit-Logging und Prüfstufen
Audit-Logging ist kein Protokoll für den Notfall. Es ist die Grundlage dafür, dass Finance einen automatisierten Vorgang später erklären kann, besonders wenn E-Rechnungen über Peppol oder das Unternehmensserviceportal verarbeitet werden und mehrere Rollen an der Freigabe beteiligt sind.
Eine brauchbare Pipeline trennt die Prüfstufen. Zuerst prüft das System Belegdaten und Wertgrenze. Danach folgt die fachliche Freigabe durch die Kostenstellenverantwortlichen. Vor der Buchung läuft eine technische Validierung, anschließend vergleicht der Audit-Agent den erzeugten Datensatz mit der archivierten Rechnung.
Jeder Statuswechsel braucht Evidenz
Ein Logeintrag enthält Akteur, Zeitstempel, einen Hash der Nutzlast und den referenzierten ERP-Beleg. Wichtig ist die Unveränderlichkeit: Ein späterer Korrekturlauf überschreibt den ursprünglichen Status nicht, sondern erzeugt einen neuen Eintrag mit Grund, Auslöser und verantwortlicher Person.
e-Rechnung.gv.at arbeitet mit einer Fehlerliste aus Fehler-ID, Kategorie, Kontext und Meldung. Für KI-Workflows ist das relevant, weil das System nicht bloß „Rechnung ungültig“ melden darf. Es muss den Fehlerzustand erkennen, den passenden Korrekturpfad wählen und die Bearbeitung nachvollziehbar speichern.
| Prüfstufe | Typischer Fehlerzustand | Reaktion |
|---|---|---|
| Stammdaten | UID-Nummer oder Empfänger nicht plausibel | Harte Sperre, Stammdatenverantwortliche informieren |
| Routing an den Bund | Auftragsreferenz oder Lieferantennummer fehlt oder ist falsch | Nicht weiterleiten, Referenz aus der Bestellung ergänzen |
| Positionen | Rechnungsposition passt nicht zur Bestellposition | Abweichung an Einkauf oder Fachbereich geben |
| Rechnungskopf | Pflichtfeld fehlt | Rechnung zur Korrektur zurückweisen |
| Archiv | Archivobjekt stimmt nicht mit der Nutzlast überein | Buchung stoppen und Audit-Trail markieren |
Mehr zur Gestaltung solcher Protokolle beschreibt der Beitrag zum Audit-Log-Management.
Vier Augen müssen technisch erzwungen werden
Eine Freigabe durch dieselbe Person, die die Bestellung erstellt hat, ist keine wirksame Trennung. Das System prüft Rollen und Ausschlüsse, bevor es den nächsten Zustand setzt. Der Freigabe-Agent bietet keine manuelle Umgehung an, die nicht ebenfalls im Audit-Trail landet. SAP berücksichtigt in der Rechnungsprüfung neben Bestellpositionen auch Wareneingänge und Leistungserfassungsblätter als Referenzobjekte im Drei-Wege-Abgleich. Genau diese Referenzen müssen im Log sichtbar bleiben. Wie Sie Funktionstrennung systematisch aufsetzen, zeigt der Beitrag zur Segregation of Duties.
Rollout-Checkliste für den produktiven Einsatz
Der Go-live scheitert selten an der Bestellmaske. Er scheitert an einem nicht getesteten Konnektor, einem unklaren Verantwortungsübergang oder einem Ausfall des E-Rechnungs-Providers, für den niemand einen Ersatzprozess kennt. Die ersten zwei Wochen sind deshalb keine allgemeine Schulungsphase, sondern ein kontrollierter Nachweis, dass jede kritische Transaktion durchgängig funktioniert.
Woche 1: technische Nachweise
Der Engineering-Lead richtet Health-Checks für ERP und Buchhaltung ein. Jeder Check prüft nicht nur die Erreichbarkeit, sondern auch eine ungefährliche Leseoperation und die erwartete Berechtigungsantwort. Danach folgen Idempotenztests mit wiederholten Anfragen, die Rotation der Zugangstoken und Monitoring für Agentenlatenzen und ERP-Fehlerraten.
- Engineering-Lead: Health-Checks, Wiederholungsverhalten und Idempotenz dokumentieren.
- Finance-Lead: Vier-Augen-Regeln, Konten, Kostenstellen, Steuerlogik und UID-Prüfung abnehmen.
- Einkauf: Test-Bestellungen für alle Freigabepfade anlegen, einschließlich Dienstleistungen ohne klassischen Wareneingang.
- IT-Betrieb: Netzwerk- und Firewall-Regeln für die ERP- und Buchhaltungsschnittstellen prüfen.
Bis zum dritten Tag ist die erste vollständige Transaktion nachgewiesen: Bedarf, Bestellung, Freigabe, ERP-Rückmeldung und simulierter Rechnungsabgleich. Ein Screenshot genügt nicht. Der Nachweis enthält Request-ID, ERP-Belegnummer, Audit-Log und das erwartete Ergebnis.
Woche 2: Schattenbetrieb
In der zweiten Woche läuft der neue Ablauf parallel zum bestehenden Prozess. Der Schattenbetrieb sollte eine vollständige Buchungsperiode abdecken, damit auch Korrekturen, verspätete Lieferungen und unterschiedliche Lieferantenformate sichtbar werden. Die IT sichert die Audit-Trail-Datenbank und dokumentiert den Rollback-Plan für einen Ausfall des E-Rechnungs-Providers. Finance testet die manuelle Wiederaufnahme nach einem Provider- oder ERP-Fehler, und die Steuerberatung bestätigt die fachliche Abnahme, bevor der Prozess für eine Gesellschaft produktiv geht.
- Fachabteilung: Abnahme mit dokumentierten Abweichungen.
- IT-Betrieb: Wiederherstellung aus dem Backup und Ausweichweg für den Provider belegen.
- Finance: Rechnungsstatus, Korrekturpfade und Archivbezug kontrollieren.
- Geschäftsführung: Freigabe je Gesellschaft und ein klar benannter Verantwortlicher für den Go-live.
Aktivieren Sie schrittweise nach Gesellschaft, Lieferantengruppe oder Prozesskategorie. Jeder Punkt braucht einen Owner, ein Datum und einen Nachweis. So wird aus „läuft im Test“ ein belastbarer Beleg, dass Bestellprozess, ERP, E-Rechnung und Archiv tatsächlich zusammenarbeiten. Wie der Bestellprozess in die übrige Finanzautomatisierung passt, beschreibt der Beitrag zur Automatisierung von Finanzprozessen.
Sprechen Sie mit uns
Wenn Sie Ihren Bestellprozess mit KI-Agenten, ERP-Konnektoren und revisionssicherem Audit-Logging automatisieren wollen, sprechen Sie mit uns.