Um 12:15 Uhr landen die ersten Rechnungen auf dem Tisch der Buchhaltung. Eine Mitarbeiterin öffnet DATEV, sucht nach dem passenden Sachkonto und stellt fest, dass die Bestellung nie als Purchase Order erfasst wurde. Der Einkauf lief per E-Mail, der Wareneingang steht auf einem Block neben dem Telefon, und der Beleg kommt erst jetzt ins System.
Genau dort bricht ein Purchase Order Workflow auseinander. Zwischen Bedarfsmeldung, Genehmigung, Bestellung, Wareneingang und Rechnung fehlt die durchgehende Referenz. Für Österreich ist das besonders kritisch, weil strukturierte E-Rechnungen, B2G-Kanäle und revisionssichere Archivierung den Prozess nicht am Rechnungseingang beginnen lassen. Die PO muss vorher existieren, eindeutig referenziert werden und mit Lieferung und Rechnung zusammenpassen.
Inhaltsverzeichnis
- Wenn die Bestellung erst mit der Rechnung entsteht
- Vom Bedarf zur Purchase Order im DATEV- und Navision-Stack
- Freigaben oder Compliance zuerst die AT-Falle im PO-Design
- Agent-Orchestrierung über MCP und ERP-Connectoren
- Audit-Logging und Prüfstufen für revisionssichere Workflows
- Rollout-Checkliste für den produktiven Einsatz
Wenn die Bestellung erst mit der Rechnung entsteht
Die Mitarbeiterin in der Buchhaltung öffnet also die Rechnung und arbeitet sich rückwärts vor. Sie sucht in ihrem 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.
Der Finance-Lead kennt diese Situation. Täglich stopft er die Lücke zwischen Bedarfsanfrage, Bestellung, Lieferung und Rechnung. Er lässt sich Screenshots schicken, gleicht Positionen ab und entscheidet, ob eine Rechnung trotz fehlender PO weiterbearbeitet werden darf. Das kostet Aufmerksamkeit an Stellen, an denen eigentlich Zahlungsfreigaben, Liquiditätsplanung und Kontrollen stattfinden sollten.
Praktische Regel: Eine Bestellung, die erst beim Rechnungseingang angelegt wird, ist keine Kontrolle. Sie ist nachträgliche Dokumentation.
Der Bruch sitzt vor der Buchhaltung
Die TU Wien weist darauf hin, dass Bestellungen häufig erst beim Rechnungseingang angelegt werden. Das widerspricht dem SAP-Prinzip, die Bestellung vor oder spätestens bei der Bestellung beim Lieferanten zu erzeugen. Fehlt die PO-Referenz, entstehen manuelle Klärungen, und der Zahlungslauf kann sich verzögern, wie die österreichischen Lieferantenanforderungen zur Rechnungsverarbeitung zeigen.
Der technische Fehler ist meist unspektakulär: Die Rechnung enthält keine PO-Nummer, die Leistungsbeschreibung weicht vom Bestelltext ab oder der Lieferant ist in DATEV und Navision unterschiedlich angelegt. Trotzdem blockiert dieser kleine Bruch den gesamten Ablauf. Ein sauberer Drei-Wege-Abgleich kann nur prüfen, was als drei konsistente Objekte existiert: Purchase Order, Wareneingang und Rechnung.
Was Automatisierung zuerst lösen muss
AI sollte hier nicht mit einer hübschen 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 an.
- Wareneingang verbinden: Eine manuelle Bestätigung oder ein ERP-Ereignis schreibt den Lieferstatus an die richtige Bestellposition.
- Rechnung prüfen: Die Rechnung darf nur dann automatisch weiterlaufen, wenn PO, Lieferung und Rechnungsdaten zusammenpassen.
- Ausnahme eskalieren: Abweichungen gehen an eine definierte Person, nicht in einen allgemeinen E-Mail-Posteingang.
Der konkrete Auslöser für Automatisierung ist deshalb nicht der Wunsch nach einem schnelleren Freigabeklick. Es ist die fehlende Verbindung zwischen den Belegen. Solange diese Verbindung nicht existiert, automatisiert man nur die Weiterleitung von Problemen.
Vom Bedarf zur Purchase Order im DATEV- und Navision-Stack
Ein belastbarer Ablauf beginnt nicht mit der Rechnung, sondern mit einer Bedarfsmeldung. Diese kann aus einem Intranet-Formular, einer ERP-Eingangsmaske oder einer strukturierten E-Mail kommen. Ein Connector übernimmt die Anfrage, validiert Pflichtfelder und bildet sie auf die Stammdaten von DATEV und Microsoft Dynamics Navision ab.
Für die Buchhaltung braucht der Connector ein passendes DATEV-Buchungskonto, für Navision einen vollständigen Bestellkopf. Dazu gehören mindestens Lieferanten-ID, Kostenstelle, Bestellmenge und Warenempfänger. Fehlt eines dieser Felder, sollte der Workflow nicht stillschweigend einen Defaultwert einsetzen. Er muss die Anfrage zurückstellen und den fehlenden Kontext beim Antragsteller einholen.
Das Mapping entscheidet über die Qualität
Im Bestelldokument müssen Belegnummer, Bestelldatum, Lieferbedingung, Warenempfänger und Steuerschlüssel konsistent gefüllt sein. Der Connector sollte außerdem die ursprüngliche Bedarfs-ID speichern, damit sich die PO später bis zur Anfrage zurückverfolgen lässt.
| Feld | Quelle DATEV | Ziel Navision | Typische Falle |
|---|---|---|---|
| Lieferantennummer | Kreditorenstamm | Vendor No. | Doppelte Lieferanten-Stammdaten |
| Kostenstelle | Buchungsdimension | Dimension Code | Fehlende Synchronisation |
| Bestellmenge | Bedarfsposition | Quantity | Einheit nicht eindeutig |
| Belegnummer | Belegreferenz | External Document No. | Nummernkreis nicht abgestimmt |
| Bestelldatum | Belegdatum | Order Date | Zeitzone oder falsches Format |
| Lieferbedingung | Einkaufsparameter | Shipment Method Code | Freitext statt Code |
| Warenempfänger | Organisationsdaten | Location Code oder Empfänger | Falscher Standort |
| Steuerschlüssel | Steuerlogik | VAT Prod. Posting Group | Fehler bei Reverse Charge |
Die häufigsten Fehler liegen nicht in der API, sondern in den Stammdaten. DATEV und Navision können denselben Lieferanten mit unterschiedlichen IDs führen. Kostenstellen werden in einem System geändert und im anderen nicht nachgezogen. Bei Reverse Charge greift eine scheinbar passende Steuerautomatik, obwohl der konkrete Vorgang eine andere Behandlung verlangt.
Schnittstellen brauchen Rückmeldung
Der Connector sollte die Transformation in eine IDoc- oder DATEV-ASCII-Schnittstelle nicht als Einbahnstraße bauen. Nach der Übergabe muss er die erzeugte Bestellnummer, den ERP-Status und eventuelle Validierungsfehler zurückbekommen. Erst dann kann die antragstellende Person eine belastbare Referenz erhalten.
Bei Navision kommen dafür je nach Installation OData oder Web-Services infrage. DATEVconnect beziehungsweise eine ReSt-API können die Buchhaltungsseite anbinden. Die konkrete Wahl hängt von Version, Berechtigungsmodell und bestehender Systemlandschaft ab. Entscheidend ist, dass der Connector keine eigene Schatten-PO führt, die später vom ERP abweicht.
Ein häufiger Irrtum lautet: Ohne physischen Wareneingang braucht es keine PO. Das stimmt bei Dienstleistungen, Abos oder Beratungsleistungen nicht. Gerade dort braucht der Drei-Wege-Abgleich ein anderes Referenzobjekt, etwa eine Leistungsbestätigung oder ein Service Entry Sheet. Wer die PO nur für Lagerware verwendet, lässt einen großen Teil des Spend-Prozesses unkontrolliert.
Für die technische Einordnung lohnt sich ein Blick auf KI in ERP-Systemen. Der Kern bleibt einfach: Bedarf rein, Stammdaten prüfen, PO im führenden ERP erzeugen, ERP-Nummer zurückgeben.
Freigaben oder Compliance zuerst die AT-Falle im PO-Design
Ein schneller Approval-Step ist nicht automatisch ein guter Purchase Order Workflow. In Österreich muss die PO so gestaltet sein, dass sie später mit E-Rechnung, B2G-Kanal, Wareneingang und Archiv zusammenpasst. Wer nur die Freigabekette beschleunigt, verschiebt den Engpass in die Rechnungsprüfung.
Für Bundesstellen gilt in Österreich seit 1. Januar 2014 die Pflicht zur strukturierten elektronischen Rechnung. Lieferanten reichen über USP beziehungsweise e-Rechnung.gv.at ein, und Bundesbehörden müssen für öffentliche Aufträge oberhalb der EU-Schwellenwerte elektronische Rechnungen nach dem europäischen Standard akzeptieren und verarbeiten, wie die EU-Übersicht zur österreichischen E-Rechnung beschreibt.
Ein schneller Schritt kann den falschen Prozess beschleunigen
Ein Bauzulieferer automatisiert beispielsweise nur die Genehmigung. Der Projektleiter klickt die Anfrage frei, der Einkauf sendet die Bestellung per E-Mail, und der Lieferant stellt später eine Rechnung ohne PO-Referenz. Der Drei-Wege-Abgleich schlägt fehl, weil die Rechnung keinem eindeutigen Bestellbezug zugeordnet werden kann. Die Buchhaltung korrigiert manuell, obwohl der Approval-Step technisch erfolgreich war.
Eine PO ohne Verbindung zur strukturierten E-Rechnung nach EN 16931 ist im B2G-Segment praktisch wertlos. Ebenso genügt eine schnelle Freigabe nicht, wenn Vier-Augen-Logik, UID-Prüfung oder die Zuordnung zum öffentlichen Auftrag fehlen. Compliance ist daher kein nachgelagerter Prüfpunkt, sondern ein Architekturentscheid für die PO selbst.
Die österreichischen Rahmenbedingungen verändern das Design
Auf Bundesebene ist B2G über USP und Peppol zentralisiert. Der Empfang ist für alle öffentlichen Auftraggeber verpflichtend. Die Archivierungsfristen liegen bei 7 Jahren für bewegliche Güter und 22 Jahren für unbewegliche Güter, wie die österreichische Einordnung von E-Invoicing und Post-Audit zusammenfasst.
Das bedeutet für die PO-Architektur:
- Referenzen müssen stabil sein: Die PO-Nummer darf nicht erst bei 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 muss als Ausnahme mit Besitzer und Korrekturpfad gespeichert werden.
- Archivdaten müssen zusammengehören: PO, Liefernachweis und Rechnung dürfen nicht in getrennten Ablagen verschwinden.
Die richtige Optimierungsfrage lautet deshalb nicht, wie viele Klicks eine Freigabe braucht. Sie lautet: Kann das System den Vorgang vom Bedarf bis zum archivierten Beleg ohne Medienbruch erklären?
Agent-Orchestrierung über MCP und ERP-Connectoren
Ein AI-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 gefährlich zu betreiben. Besser funktioniert ein Orchestrations-Layer, der kleine, überprüfbare Aufgaben an spezialisierte Agenten delegiert.
Der Request landet im MCP-Dispatcher. Von dort erhält der PurchaseOrderAgent die Anfrage und zerlegt sie in Validierung, Duplikatprüfung und ERP-Roundtrip. Der ErpGatewayAgent hält die Connector-Instanzen für DATEV und Navision bereit. Ein ApprovalAgent verwaltet Freigabe-Queues, während ein AuditAgent jeden Statuswechsel in den Trail schreibt.
Jeder Agent braucht einen begrenzten Auftrag
Der PurchaseOrderAgent darf Felder normalisieren und fehlende Angaben erkennen. Er sollte aber nicht selbst entscheiden, ob eine steuerliche Ausnahme zulässig ist. Diese Entscheidung gehört in eine explizite Regel oder an Finance.
Ein MCP-Tool-Call kann typisierte Daten weitergeben:
create_purchase_order(
supplier_number: string,
order_quantity: decimal,
cost_centre: string,
goods_recipient: string,
idempotency_key: string
)
Der ErpGatewayAgent übersetzt diese Struktur in die jeweilige Schnittstelle. DATEV kann über DATEVconnect beziehungsweise eine ReSt-API angesprochen werden, Navision über OData oder Web-Services. Der Agent gibt nicht nur Erfolg oder Fehler zurück, sondern auch ERP-Belegnummer, Status und fachlich verwertbare Fehlermeldung.
Architekturentscheidung: Synchrone Aufrufe eignen sich für die Rückgabe der Belegnummer. Status-Webhooks sollten asynchron verarbeitet werden, damit ein langsames ERP nicht die gesamte Konversation blockiert.
Retries dürfen keine Doppelbestellungen erzeugen
Netzwerkfehler und abgelaufene Sessions sind normal. Ohne Idempotency-Key kann ein Retry jedoch eine zweite PO anlegen. Der Key muss aus der stabilen Bedarfs-ID und einem eindeutigen Vorgangskontext entstehen. Das ERP oder ein Gateway speichert, ob dieser Schlüssel bereits verarbeitet wurde.
ERP-Sessions sind außerdem oft kurzlebig. Connection-Pooling, Token-Refresh und erneute Authentifizierung gehören in den Lebenszyklus des ErpGatewayAgent, nicht in die Fachlogik des PurchaseOrderAgent. So bleibt der fachliche Ablauf testbar, während der Connector die Eigenheiten des Zielsystems kapselt.
Für größere Umgebungen ist ein Enterprise-Automation-Platform-Ansatz sinnvoll, sofern Governance, Berechtigungen und Tool-Versionen zentral kontrolliert werden. AI bringt hier den größten Nutzen bei Klassifikation, Duplikatprüfung, Ausnahmebegründung und Routing. Die eigentliche Buchung bleibt deterministisch und nachvollziehbar.
Audit-Logging und Prüfstufen für revisionssichere Workflows
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. Im österreichischen Kontext gilt das besonders dann, 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 die Belegdaten und die Wertgrenze. Danach folgt die fachliche Freigabe durch die Kostenstellenverantwortlichen. Vor der ERP-Buchung läuft eine technische Validierung, anschließend vergleicht der Audit-Agent den erzeugten Datensatz mit der archivierten E-Rechnung.
Jeder Statuswechsel braucht Evidenz
Ein Logeintrag sollte Akteur, Zeitstempel, Hash der Nutzlast und referenzierten ERP-Beleg enthalten. Wichtig ist die Unveränderlichkeit. Ein späterer Korrekturlauf darf den ursprünglichen Status nicht überschreiben, sondern muss einen neuen Eintrag mit Grund, Auslöser und verantwortlicher Person erzeugen.
Die österreichische e-Rechnung-GV arbeitet mit einer Fehlercodetabelle aus Error ID, Kategorie, Kontext und Fehlermeldung. Das ist für AI-Workflows 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, wie die Fehlercodetabelle der e-Rechnung-GV zeigt.
| Prüfstufe | Beispiel-Fehlercode | Bedeutung | Reaktion |
|---|---|---|---|
| Stammdatenprüfung | Error ID aus der e-Rechnung-GV | UID-Nummer oder Empfänger ist nicht plausibel | Harte Sperre, Stammdatenverantwortliche informieren |
| B2G-Routing | Error ID aus der e-Rechnung-GV | Leitweg-ID oder Empfängerregistrierung fehlt | Nicht weiterleiten, Auftraggeberdaten korrigieren |
| Positionsprüfung | Error ID aus der e-Rechnung-GV | Rechnungsposition passt nicht zur PO | Abweichung an Einkauf oder Fachbereich geben |
| Kopfprüfung | Error ID aus der e-Rechnung-GV | Pflichtfeld im Rechnungskopf fehlt | Rechnung zur Korrektur zurückweisen |
| Archivprüfung | Interner Validierungsstatus | Archivobjekt stimmt nicht mit Nutzlast überein | Buchung stoppen und Trail markieren |
Die Tabelle verwendet bewusst die Kategorien und Fehlerzustände des Systems, statt nicht belegte Beispielcodes zu erfinden. Auf der e-Rechnung-GV müssen Fehler im Kopf- und Positionsbereich separat behoben werden, bevor die Rechnung insgesamt als „Processed“ gesetzt wird, wie die Anleitung zur Fehlerkorrektur beschreibt.
Vier Augen müssen technisch erzwungen werden
Eine Freigabe durch dieselbe Person, die die Bestellung erstellt hat, ist keine wirksame Trennung. Das System muss Rollen und Ausschlüsse prüfen, bevor es den nächsten Zustand setzt. Der ApprovalAgent darf keine manuelle Umgehung anbieten, die nicht ebenfalls im Audit-Trail landet.
Wer diese Kontrollen als Bürokratie behandelt, baut einen Workflow, der nur bei störungsfreien Vorgängen funktioniert. SAP berücksichtigt in der Rechnungsverarbeitung neben Bestellpositionen auch Wareneingänge und Service Entry Sheets in der Drei-Wege-Prüfung mit Referenzobjekten. Genau diese Referenzen müssen im Log sichtbar bleiben. Ein Audit-Log-Management ist deshalb eine operative Kontrollschicht, kein nachträgliches Reporting.
Rollout-Checkliste für den produktiven Einsatz
Der Go-Live scheitert selten an der PO-Maske. Er scheitert an einem nicht getesteten Connector, einem unklaren Verantwortungsübergang oder einem Provider-Ausfall, für den niemand einen Ersatzprozess kennt. Die ersten zwei Wochen sollten deshalb nicht als allgemeine Schulungsphase laufen, sondern als kontrollierter Nachweis, dass jede kritische Transaktion Ende zu Ende funktioniert.
Woche 1 mit technischen Belegen
Der Engineering-Lead richtet Health-Checks für DATEV und Navision ein. Jeder Check muss nicht nur die Erreichbarkeit, sondern auch eine ungefährliche Leseoperation und die erwartete Berechtigungsantwort prüfen. Danach folgen Idempotency-Tests mit wiederholten Requests, MCP-Token-Rotation und Monitoring für Agent-Latenzen sowie ERP-Fehlerraten.
Der Finance-Lead definiert die Vier-Augen-Regeln, prüft das Kostenstellen-Mapping und validiert UID-Daten gegen ATR. Die Tests sollten echte Lieferanten-UIDs verwenden, allerdings in einer kontrollierten Umgebung. Procurement legt Test-POs für alle Freigabepfade an, inklusive Dienstleistungen ohne klassischen Wareneingang.
- Engineering-Lead: Connector-Health-Checks, Retry-Verhalten und Idempotency-Nachweise dokumentieren.
- Finance-Lead: Konten, Kostenstellen, Steuerlogik und UID-Prüfung abnehmen.
- Procurement: Lieferanten, Bestelltexte und Ausnahmewege testen.
- IT-Betrieb: VPN- und Firewall-Regeln für DATEV-Rechenzentrum und Navision-Web-Service prüfen.
Am dritten Tag muss die erste erfolgreiche Loop-Transaktion nachgewiesen sein. Dazu gehören Bedarf, PO-Erzeugung, Freigabe, ERP-Rückmeldung und ein simulierter Rechnungsabgleich. Ein Screenshot allein reicht nicht. Der Anhang braucht Request-ID, ERP-Belegnummer, Audit-Log und das erwartete Ergebnis.
Woche 2 mit Schattenbetrieb
In der zweiten Woche läuft der neue Ablauf zunächst parallel zum bestehenden Prozess. Der Schattenbetrieb sollte mindestens eine vollständige Buchungsperiode abdecken, damit auch Korrekturen, verspätete Lieferungen und unterschiedliche Lieferantenformate sichtbar werden.
Der IT-Lead sichert die Audit-Trail-Datenbank und dokumentiert den Rollback-Plan für den Fall, dass der E-Rechnungs-Provider ausfällt. Finance testet manuelle Wiederaufnahme nach einem Provider- oder ERP-Fehler. Der Steuerberater bestätigt die fachliche Abnahme, bevor der Prozess für eine Gesellschaft produktiv geschaltet wird.
- Tag 10: Abnahme durch die Fachabteilung mit dokumentierten Abweichungen.
- IT-Betrieb: Backup-Wiederherstellung und Provider-Fallback belegen.
- Finance: Rechnungsstatus, Korrekturpfade und Archivbezug kontrollieren.
- Management: Sign-off je Gesellschaft und klarer Go-Live-Verantwortlicher.
Für die Aktivierung empfiehlt sich eine schrittweise Reihenfolge nach Gesellschaft, Lieferantengruppe oder Prozesskategorie. Jede Box braucht einen Owner, ein Datum und eine Evidenz im Anhang. So wird aus „läuft im Test“ ein belastbarer Nachweis, dass der Purchase Order Workflow in DATEV, Navision, E-Rechnung und Archiv tatsächlich zusammenarbeitet.
Die wirtschaftliche Logik ist ebenfalls klar. Eine von der australischen Steuerbehörde zitierte Whitepaper-Angabe beziffert die manuelle Verarbeitung eines einzelnen PDF-Belegs mit etwa 27 bis 30 US-Dollar und automatisierte Verarbeitung mit unter 10 US-Dollar. Der Wert stammt nicht aus Österreich, zeigt aber den Mechanik-Nachweis hinter der Automatisierung: Weniger manuelle Datenerfassung und weniger Nacharbeit senken den Stückkostenblock, sofern die Regeln und Schnittstellen sauber implementiert sind, wie das zitierte Whitepaper zur Belegverarbeitung.pdf) beschreibt.
Wenn Ihr Unternehmen DATEV, Navision, BMD oder andere Bestandssysteme mit AI-Agenten, ERP-Connectoren und einem revisionssicheren MCP-Layer verbinden will, unterstützt Specialty Tokens bei Architektur, Implementierung und Rollout. Besuchen Sie Specialty Tokens, um den bestehenden Purchase Order Workflow prüfen und einen produktiven End-to-End-Automatisierungsplan entwickeln zu lassen.