Rechnungsprüfung automatisieren: ZUGFeRD, XRechnung & Three-Way-Match (2026)

Die E-Rechnungs-Pflicht verändert Eingangsrechnungsprozesse in Deutschland grundlegend. Seit 1. Januar 2025 müssen Unternehmen E-Rechnungen im strukturierten Format annehmen können. Ab 1. Januar 2027 wird der Versand im B2B-Bereich für Firmen >800.000 € Jahresumsatz verpflichtend, ab 2028 gilt es für alle. Wer heute noch ausschließlich PDF-Rechnungen manuell ins ERP tippt, baut gerade eine tickende Uhr in seinen Buchhaltungsprozess ein. Dieser Artikel zeigt, wie eine Rechnungsprüfungs-Pipeline aussieht, die XRechnung, ZUGFeRD und klassisches PDF parallel verarbeitet — mit automatischem Three-Way-Match, rollenbasierter Freigabe und GoBD-konformer Archivierung. Er ergänzt unseren Praxisguide zur Rechnungsverarbeitung mit OCR und KI um die Prüf-, Freigabe- und E-Rechnungs-Perspektive.

Die regulatorische Zeitlinie: Warum das kein freiwilliges Thema ist

Das Wachstumschancengesetz hat die Umstellungs-Fahrpläne festgelegt. Wichtig zu verstehen: die Empfangspflicht liegt bereits hinter uns. Der Versand-Zwang rollt.

Für die Rechnungsprüfung heißt das: Bereits 2026 werden Sie einen zunehmenden Anteil struktureller E-Rechnungen empfangen. Ein Workflow, der nur PDF-OCR kann, produziert einen Medienbruch zwischen zwei Paralleluniversen — und muss spätestens 2027 ausgetauscht werden, wenn Sie selbst versenden müssen.

Die drei Einfallstore — warum alle drei parallel bleiben

Trotz E-Rechnungs-Pflicht werden auch 2028 noch klassische PDF-Rechnungen eintreffen: von ausländischen Lieferanten ohne Peppol-Anschluss, von B2C-Transaktionen, oder schlicht von Unternehmen, die die Pflicht ignorieren. Eine realistische Rechnungsprüfungs-Pipeline muss drei Einfallstore parallel bedienen können:

1. XRechnung (reines XML, Struktur-only)

Format: UBL 2.1 oder UN/CEFACT Cross Industry Invoice (CII) D16B, validierbar nach EN 16931. Einfallsweg: Peppol-Netzwerk (Access Point), E-Mail mit XML-Anhang, Upload-Portal. Besonderheit: Reiner Maschinenlesbar-Content, keine menschliche Lesefassung ohne Visualizer. Vorteile in der Pipeline: Null Extraktion nötig, alle Pflichtfelder nach EN 16931 vorhanden, Validierung zweifelsfrei.

2. ZUGFeRD (hybrides PDF/A-3 mit eingebettetem XML)

Format: Sichtbarer PDF-Teil plus eingebettetes CII-XML, seit Version 2.x EN-16931-konform. Einfallsweg: Klassischer E-Mail-PDF-Anhang. Besonderheit: Für Menschen lesbar, für Maschinen strukturiert — der beste Kompromiss während der Transition. Vorteile in der Pipeline: XML wird direkt geparst, PDF dient als Fallback-Lesefassung und Archivdokument.

3. Klassisches PDF / Scan (ohne XML)

Format: Beliebiges PDF, gescannte Papierrechnung, Handyfoto. Einfallsweg: E-Mail, Upload-Portal, Post (nach Scan). Besonderheit: Kein Struktur-Anker, alles muss extrahiert werden. Vorteile in der Pipeline: Weiterhin Mehrheit der realen Eingangsrechnungen 2026; ohne robusten OCR-Pfad brechen Sie 60-80% Ihres Volumens. Der Schlüssel einer belastbaren Pipeline: Alle drei landen nach der Eingangserkennung in einem einheitlichen Datenmodell. Ab Schritt 2 ist der Prozess identisch, egal ob XRechnung, ZUGFeRD oder PDF-OCR die Quelle war. Das hält die Freigabe-, Klärungs- und Buchungs-Logik wartbar.

Format-Detektion in der Praxis

Die erste echte Logik-Stufe ist die Format-Erkennung am eingehenden Dokument. Das klingt trivial, ist aber der häufigste Stolperpunkt schlecht gebauter Pipelines.

Saubere Detektions-Logik:

1. Ist es eine .xml-Datei?
   → Parse als XRechnung (UBL oder CII-Detektion über Namespace).
Ist es eine .pdf-Datei?
   → PDF/A-Version prüfen (ZUGFeRD-Pflicht: PDF/A-3).
   → Existieren Embedded Files? Extrahiere XML-Anhang.
     → Namespace "urn:cen.eu:en16931:2017" gefunden?
       → Ja: Parse als ZUGFeRD-CII.
       → Nein: Behandle als klassisches PDF + OCR.
   → Keine Embedded Files: Klassisches PDF + OCR.
Ist es ein Bildformat (JPG, PNG, TIFF)?
   → Direkt zur OCR-Stufe.

Wichtig: Viele Unternehmen versenden heute PDF-Rechnungen mit XML-Anhang getrennt. Das ist keine ZUGFeRD-konforme Hybridrechnung und muss als zwei Dokumente behandelt werden (oder — besser — Sie bitten den Lieferanten um ZUGFeRD-konforme Einbettung).

Three-Way-Match: Die eigentliche Prüf-Logik

Der Three-Way-Match ist das Herzstück professioneller Rechnungsprüfung in Unternehmen mit Bestellprozess. Er gleicht drei Datenquellen ab:

1. Die Eingangsrechnung (vom Lieferanten) 2. Die Bestellung (aus Ihrem ERP) 3. Der Wareneingang / die Leistungsabnahme (aus Ihrem Lager- oder Service-System)

Nur wenn alle drei zusammenpassen, darf die Rechnung ohne weitere Rückfragen gebucht werden. Abweichungen werden strukturiert geklärt, nicht ignoriert.

Was positionsgenau geprüft wird

Für jede Rechnungsposition:

Toleranzkorridore sind unternehmensspezifisch. Die meisten unserer Kunden fahren 2% Preis-Toleranz exakt-mengenbasiert. Das bedeutet: Rohstoffpreis-Schwankungen bis 2% gehen automatisch durch, alles darüber wird geklärt. Bei exakter Mengenprüfung verhindern Sie die häufigsten Betrugsmuster (falsch-positive Mengen in manipulierter Rechnung).

Abweichungs-Workflow

Sobald eine Abweichung außerhalb der Toleranz gefunden wird, startet ein strukturierter Klärungs-Workflow:

Automatische Nachricht an den verantwortlichen Einkäufer oder Wareneingangs-Verantwortlichen (via Slack oder E-Mail) mit allen Abweichungen auf einen Blick.

Drei Ein-Klick-Optionen: Genehmigen (trotz Abweichung), Ablehnen (Rechnung zurück an Lieferanten), Teilweise (Menge korrigieren).

Antwort fließt zurück in die Pipeline, der Prozess setzt automatisch fort — kein E-Mail-Ping-Pong, keine verloren gegangenen Tickets.

Audit-Trail dokumentiert, wer wann was entschieden hat — GoBD-konform.

OCR + KI-Extraktion: Was realistisch funktioniert

Für den PDF-/Scan-Pfad ist die Extraktion der kritische Engpass. Die Qualität hier entscheidet, ob der gesamte Workflow gerade läuft oder manuelle Nacharbeit produziert.

Schicht 1: OCR

Für die Texterkennung sind drei Anbieter im Realbetrieb robust:

• Google Cloud Document AI (Invoice Processor) — hoch spezialisiert auf Rechnungen, erkennt Lieferant, Rechnungsnummer, Positionen, Mehrwertsteuer out of the box.
• Azure Document Intelligence (prebuilt-invoice) — Microsoft-Pendant, enge Integration zu Dynamics 365, ähnliche Genauigkeit.
• AWS Textract (AnalyzeExpense) — für AWS-First-Stacks; etwas weniger spezialisiert auf deutsche Rechnungsformate.

Kosten: typisch 0,03-0,10 € pro Rechnung bei Volumen ab 1.000/Monat. Bei 300 Rechnungen/Monat also ~10-30 € monatlich — vernachlässigbar gegenüber dem Zeitgewinn.

Schicht 2: KI-Strukturierung (wenn OCR reicht nicht)

Bei komplexen Positionslisten, schwachen Scans oder ungewöhnlichen Layouts reicht reines OCR nicht. Dann schickt man den OCR-Output an ein LLM (Claude 3.5 Sonnet, GPT-4 Turbo) mit strukturiertem Prompt:

System: Du bist ein Rechnungs-Extraktor. Antworte ausschließlich valides JSON 
nach diesem Schema: {...}. Wenn ein Feld nicht eindeutig erkennbar ist, gib 
null zurück und setze confidence auf 0.

User: [OCR-Output der Rechnung]

Die KI löst Standardprobleme, an denen reine OCR scheitert: Zusammenführung mehrzeiliger Positionen, Erkennung von Netto/Brutto-Bezeichnungen in ungewöhnlichen Sprachen, Deutung von handgeschriebenen Stempeln. Wichtig: Immer confidence scores mit ausgeben und ab einer Schwelle (meist 85%) automatisch durchlaufen lassen; darunter menschliche Prüfung.

Schicht 3: Geschäftsregel-Validierung

Nach Extraktion laufen harte Geschäftsregeln, die die KI nicht ersetzen kann:

• Ist der Lieferant im Kreditorenstamm angelegt? Wenn nein, Onboarding-Flow.
• Stimmt die IBAN mit dem hinterlegten Bankkonto des Lieferanten überein? Wenn nein, Warnung (häufigster Phishing-Vektor: manipulierte Lieferanten-Bankverbindung).
• Berechnet sich die MwSt korrekt (Netto × Satz = MwSt-Betrag)? Wenn nein, Flag.
• Existiert die Rechnungsnummer schon einmal (Duplikatsprüfung)? Zwei Ebenen: exakter Hash der Datei und semantischer Match der Rechnungsnummer-Lieferant-Kombination.

Kostenstellenvorschlag: Wo KI echt hilft

Das mühsame an der manuellen Rechnungsprüfung ist die Kontierung: welches Sachkonto, welche Kostenstelle, welche Kostenträger-Zuordnung? Dafür haben Unternehmen Regeln, aber die leben oft im Kopf eines Buchhalters.

Eine KI kann diese Regeln aus historischen Buchungen ableiten — und erreicht bei wiederkehrenden Lieferanten mit 20+ Vorbuchungen hohe Trefferquoten (typisch 90-95%). Vorgehen:

Historische Buchungen indexieren: Lieferant, Rechnungstext, Betragsbereich, Kontierung aus den letzten 24 Monaten.

Bei neuer Rechnung: Embedding des Rechnungsinhalts + Metadaten; ähnlichste 5-10 historische Buchungen suchen.

LLM schlägt Kontierung vor: mit Konfidenzwert und Begründung („Ähnlich wie 3 vorherige Rechnungen vom gleichen Lieferanten für Marketing-Beratung, kontiert auf 4380 / KSt 520").

Mensch bestätigt mit einem Klick oder ändert ab. Jede Korrektur fließt als Lernsignal in den Index.

Nach 3-4 Monaten Realbetrieb sinkt die Korrekturrate deutlich. Im Zusammenspiel mit DATEV Rechnungswesen oder SAP FI ergibt das einen spürbar schnelleren Rechnungsdurchlauf.

Rollenbasierte Freigabe: Die häufigsten Freigabe-Muster

Die Freigabe ist dort, wo sich die Geister scheiden. Zu wenig Freigabe = Compliance-Risiko. Zu viel Freigabe = jede Rechnung blockiert 3 Tage.

Pragmatisches Standard-Modell:

Zusätzlich:

• Stellvertreter-Regel: Jede Freigabe-Rolle hat einen automatischen Stellvertreter, der bei Abwesenheit (aus HR-System oder manuell eingepflegt) einspringt.
• Eskalation: Nach 48 Stunden ohne Antwort automatisch an den Vorgesetzten.
• Kanal: Slack für unter 20.000 €, E-Mail für darüber (bessere Nachvollziehbarkeit).

Diese Kaskade lässt sich vollständig als Workflow in n8n oder Make.com modellieren — mit Ein-Klick-Freigabe-Links direkt aus der Slack- oder E-Mail-Nachricht heraus.

ERP-Integration: Saubere Buchung nach Freigabe

Nach der Freigabe muss die Rechnung gebucht werden. Die Integration ist hier system-spezifisch, aber das Grundmuster ist gleich:

DATEV Rechnungswesen

Über DATEVconnect (REST API) wird ein Beleg in der richtigen Periode mit korrektem Buchungssatz, Steuer-Code und Kostenstellenzuordnung angelegt. Bild-PDF wird als Beleg-Anhang hochgeladen. Typischerweise 2-3 Sekunden pro Buchung.

SAP S/4HANA / ECC

Über OData-APIs (für S/4HANA) oder BAPI (BAPI_INCOMINGINVOICE_CREATE für klassisches ECC) wird ein Logistikrechnungs-Beleg angelegt. Der Beleg-Typ hängt vom Modul ab (MIRO für MM-Lieferantenrechnungen mit Bestellbezug, FB60 für FI-Einzelbelege ohne Bestellbezug).

Odoo / ERPNext

Über die REST-API (in Odoo: account.move mit move_type='in_invoice') wird eine Eingangsrechnung mit Positionen, Kostenstellen und Anhang angelegt. Saubere Integration, sehr offen, ideal für wachsende Mittelständler.

Microsoft Business Central

Über die Microsoft Graph API oder direkt die Business Central Web Services wird eine "Purchase Invoice" angelegt mit Verlinkung zur Bestellung (für Three-Way-Match-Dokumentation).

Wichtig in allen Fällen: Die Originalrechnung (PDF, ZUGFeRD, XRechnung) wird vor der Buchung in einem GoBD-konformen Archiv abgelegt und mit dem Buchungsbeleg verknüpft. Das Archiv ist unveränderbar, typischerweise ein S3-kompatibles Object Storage mit Object-Lock-Funktion.

Skonto-Wächter: Der oft vergessene Liquiditätshebel

Ein Detail, das in der ROI-Rechnung meist unterschlagen wird: Skonto-Nutzung. Typisch sind 2% Skonto bei Zahlung innerhalb 10 Tagen statt 30 Tagen (2/10 netto 30). In der manuellen Welt werden ~40% der Skonti nicht genutzt, weil Rechnungen zu lange im Freigabe-Zyklus hängen.

Ein einfacher Skonto-Wächter im Workflow eliminiert das Problem:

Nach Freigabe-Entscheidung:
Zahlungsfrist Skonto-Ziel < 5 Tage entfernt?
Skonto-Betrag > 20 €?
→ High-Priority-Alert an Buchhaltung: "Zahlung heute auslösen oder Skonto verfällt: 245 € (2%)"

Bei einem B2B-Unternehmen mit 5 Mio € Einkaufsvolumen und 30% skonto-berechtigten Rechnungen sind das ~30.000 € pro Jahr, die nicht mehr verloren gehen. Das allein rechtfertigt meist die Workflow-Investition.

Typische ROI-Rechnung für ein Mittelstands-Szenario

Unternehmen: Mittelständischer Großhändler, 4.500 Eingangsrechnungen/Jahr, 20 Mio € Einkaufsvolumen. Vorher (manuell):

• 14 Min pro Rechnung × 4.500 = 1.050 Stunden/Jahr Prüfzeit
• Bei 35 €/Stunde vollbelastet = 36.750 €/Jahr Personalaufwand
• Skonto-Nutzung 40% → Verlust ~60.000 €/Jahr
• Durchschnittliche Durchlaufzeit 12 Tage → Working-Capital-Bindung ~657.000 €
• Audit-Vorbereitungsaufwand ~80 Stunden/Jahr = 2.800 €

Nachher (automatisiert):

• 2 Min pro Rechnung × 4.500 = 150 Stunden/Jahr (nur Freigabe) = 5.250 €/Jahr
• Skonto-Nutzung >90% → Verlust ~6.000 €/Jahr
• Durchlaufzeit 2 Tage → Working-Capital-Bindung ~110.000 € (-547.000 € freigesetzt)
• Audit-Export auf Knopfdruck: ~2 Stunden/Jahr = 70 €

Einsparung Jahr 1:

• Personalaufwand: ~31.500 €
• Skonti: ~54.000 €
• Audit: ~2.700 €
• Freigesetztes Working Capital × 6% Kapitalkosten: ~33.000 €
• Summe: ~121.000 €/Jahr

Investition:

• Implementierung (6-10 Wochen): einmalig 25.000-45.000 €
• Laufende Kosten: 1.200-3.000 €/Monat (OCR-Credits, Hosting, Wartung)

Der Payback liegt in den meisten Fällen bei 3-6 Monaten. Das Entscheidende ist nicht die Amortisation, sondern der permanente Liquiditäts- und Kapitalkostenvorteil.

Häufige Fragen

Müssen wir die E-Rechnung selbst schon 2026 versenden können?

Nicht automatisch. Die Versandpflicht greift erst 01.01.2027 für B2B-Umsätze > 800.000 € Vorjahresumsatz. Aber: Viele größere Kunden verlangen bereits heute XRechnung, und öffentliche Auftraggeber ausnahmslos. Wenn Sie B2B-geschäftlich tätig sind, sollten Sie den Versand spätestens 2026 H2 aktivieren.

Welches Format für den Versand — XRechnung oder ZUGFeRD?

Beide sind EN-16931-konform und gesetzlich gleichwertig. Praxis:

• XRechnung für öffentliche Auftraggeber (verpflichtend)
• ZUGFeRD 2.x für B2B-Versand, weil Ihre Empfänger das PDF im Zweifel einfach öffnen können — auch wenn ihr Empfangssystem noch nicht XRechnung-fähig ist

Können wir unsere bestehende OCR-Lösung weiterverwenden?

Ja, meist. Wenn Sie bereits Google Cloud Vision, Azure Document Intelligence oder AWS Textract nutzen, sind die Extraktionsergebnisse gut genug. Der Wert einer neuen Pipeline entsteht im Three-Way-Match, Freigabe-Workflow und E-Rechnungs-Handling — nicht in der OCR an sich.

Wie sieht das mit Lieferanten aus, die keine E-Rechnung versenden?

Die Pipeline bleibt rückwärtskompatibel. Für Lieferanten ohne ZUGFeRD/XRechnung läuft der klassische OCR-Pfad. Mit der Zeit dringen Sie systematisch auf Umstellung — mit Lieferanten-Kommunikations-Templates wie: "Ab Q2 2027 können wir nur noch EN-16931-konforme Rechnungen vorsteuerabzugsfähig verarbeiten."

Wie lange dauert die Einführung?

Typisch 6-10 Wochen bei einem mittelgroßen Unternehmen (200-800 Rechnungen/Monat):

• Woche 1-2: Ist-Analyse, Anbindung ERP (DATEV, SAP, Odoo), Kreditorenstamm-Sync, Format-Detektion konfigurieren
• Woche 3-4: Three-Way-Match-Regeln, Toleranzen, Freigabe-Kaskade definieren, Slack/Teams-Integration
• Woche 5-6: KI-Kontierungs-Training mit historischen Buchungen, Klärungs-Workflow aufsetzen
• Woche 7-8: Paralleltest, Schulung Buchhaltung und Einkauf
• Woche 9-10: Rollout in Produktion, Feinjustierung

Siehe unseren Showcase Rechnungsprüfung & Freigabe-Workflow für den detaillierten Projekt-Ablauf inklusive Workflow-Diagramm.

Ist das GoBD-konform auch ohne Software-Zertifizierung?

Ja, wenn die Pipeline die GoBD-Kernanforderungen erfüllt: Unveränderbarkeit der Originalbelege, lückenlose Protokollierung aller Änderungen, maschinell auswertbare Daten für 10 Jahre, nachvollziehbare Freigabe-Kette. Eine formale Zertifizierung ist rechtlich nicht vorgeschrieben — eine saubere technische Umsetzung und ein Verfahrensdokumentation nach GoBD-Anforderungen reichen. Bei großen Setups lassen wir das Konzept vorab mit dem Steuerberater des Unternehmens abstimmen.

Was kostet die OCR bei unserem Volumen?

Bei 500 Rechnungen/Monat typisch 10-25 €/Monat OCR-Credits (Google oder Azure), plus 5-15 € für LLM-Kostenstellenvorschläge. Unter 50 € laufende Cloud-Kosten für die reine Erkennung — Hauptkostenstelle ist die einmalige Implementierung, nicht der Betrieb.

Fazit

Die E-Rechnungs-Pflicht ist keine regulatorische Belastung, sondern der Auslöser, den Eingangsrechnungsprozess endlich sauber zu bauen. Unternehmen, die jetzt eine Pipeline aufsetzen, die XRechnung, ZUGFeRD und klassisches PDF parallel verarbeitet, haben ab 2027 nicht nur Compliance abgehakt — sie haben einen Prozess, der strukturell schneller, fehlerärmer und liquiditätsschonender läuft als jede manuelle Prüfung.

Wenn Sie konkret durchspielen wollen, wie eine solche Pipeline für Ihr ERP (DATEV, SAP, Odoo, Business Central) und Ihr Rechnungsvolumen aussieht: Unser Showcase zur Rechnungsprüfungs-Automation zeigt den vollständigen Workflow mit Three-Way-Match, Freigabe-Kaskade und GoBD-Archivierung. Alternativ: 30 Minuten Gespräch über Ihr Setup — unverbindlich Termin anfragen.

Weiterführende Artikel:

• Rechnungsverarbeitung mit OCR und KI – die OCR-Basis-Perspektive
• Mahnwesen-Software im Vergleich: Lexoffice, DATEV, sevDesk & Eigenbau – die Ausgangsseite der Buchhaltung
• DATEV automatisieren: Der Praxis-Guide – Integrationstiefe in DATEV
• Buchhaltung automatisieren: Von der Rechnung bis DATEV – der Gesamtprozess
• SAP-Automatisierung mit Python, n8n oder Make – Integrationspattern für SAP-Häuser
• Automatisierung für Steuerberater – Sicht der Kanzlei