Auf dieser Seite

Seit dem 01.01.2025 müssen inländische B2B-Empfänger strukturierte E-Rechnungen technisch empfangen können, ohne Einwilligung des Absenders. Das schafft erstmals die Voraussetzung für echte Dunkelverarbeitung: Rechnungen, die vollautomatisch geprüft, freigegeben und verbucht werden, ohne dass ein Mitarbeiter sie anfasst. Dieser Artikel erklärt die Architektur dahinter, für ERP-Verantwortliche, IT-Leiter und Steuerberater, die verstehen wollen, was technisch tatsächlich passiert.

Einen nüchternen Überblick aus Entscheidersicht bietet die Lösungsseite Rechnungseingang automatisieren. Die übrigen Themen rund um Automatisierung und Liquidität listet die Lösungsübersicht.

OCR versus XML-Parsing: der fundamentale Unterschied

Wer Papier- oder klassische PDF-Rechnungen verarbeitet, kommt um OCR nicht herum. Die Software fotografiert den Beleg, erkennt Zeichen, destilliert Felder und macht dabei Fehler. Zuverlässigkeit liegt je nach Belegqualität zwischen 85 und 95 Prozent. Jede Erkennungsungenauigkeit muss ein Mensch korrigieren; der Aufwand sinkt, verschwindet aber nicht.

Bei einer strukturierten E-Rechnung nach EN 16931 gibt es nichts zu erkennen. Die Daten liegen als maschinenlesbares XML vor:

<!-- Auszug aus einer XRechnung (UBL-Syntax) -->
<cbc:IssueDate>2026-06-15</cbc:IssueDate>
<cbc:DueDate>2026-07-15</cbc:DueDate>
<cbc:TaxPointDate>2026-06-15</cbc:TaxPointDate>
<cac:PaymentMeans>
  <cbc:PaymentMeansCode>58</cbc:PaymentMeansCode>
  <cac:PayeeFinancialAccount>
    <cbc:ID>DE89370400440532013000</cbc:ID>
  </cac:PayeeFinancialAccount>
</cac:PaymentMeans>
<cac:TaxTotal>
  <cbc:TaxAmount currencyID="EUR">190.00</cbc:TaxAmount>
</cac:TaxTotal>

Der Parser liest die XML-Datei, extrahiert die Business Terms (BT-Codes) und schreibt sie direkt in die Datenbank. Kein Konfidenzwert, keine Nachkorrektur-Queue, kein Rauschen. Der Qualitätssprung gegenüber OCR ist strukturell, nicht graduell.

Die zwei XML-Syntaxen im Markt

Die EN 16931 definiert das semantische Datenmodell (über 160 BT-Codes), lässt aber zwei XML-Syntaxen zu:

Syntax Format Typischer Einsatz
UBL 2.1 (Universal Business Language) .xml XRechnung (Standard in Deutschland, öffentliche Auftraggeber)
CII (UN/CEFACT Cross Industry Invoice) .xml ZUGFeRD, Factur-X (hybrid: PDF/A-3 mit eingebettetem XML)

Beide Syntaxen bilden dieselben Pflichtfelder ab; ein Parser muss beide beherrschen. ZUGFeRD ist für den Übergang besonders praxisrelevant: Die Rechnung sieht für den Menschen aus wie ein normales PDF, enthält aber maschinenlesbares CII-XML, sodass auch Empfänger, die noch kein XML-System haben, die menschenlesbare Ansicht öffnen können.

Pflichtfelder, die Dunkelverarbeitung erst ermöglichen

Für die automatische Buchung sind insbesondere diese BT-Codes entscheidend:

  • BT-9 DueDate: Fälligkeitsdatum (direkte Grundlage für Liquiditätsplanung und Skontofenster)
  • BT-10 BuyerReference: Bestellreferenz des Käufers (Grundlage für 3-way-match)
  • BT-13 PurchaseOrderReference: Bestellnummer
  • BT-84 PaymentAccountID: IBAN des Zahlungsempfängers
  • BT-92 DebitedAccountID: Kontonummer für Lastschrift
  • BT-112 TaxBasisAmount / BT-110 TaxAmount: Nettobetrag und Steuer je Steuerkategorie

Fehlt ein Pflichtfeld im XML, ist die Rechnung technisch nicht EN-16931-konform und muss als Ausnahme behandelt werden, unabhängig davon, was im visuellen PDF-Layer steht. Das BMF hat klargestellt: ab 2025 zählt, was im XML-Feld steht, nicht was die PDF-Ansicht zeigt.

3-way-match: Bestellung, Wareneingang, Rechnung

Der 3-way-match ist die zentrale Prüflogik für Wareneinkäufer. Das System gleicht drei Dokumente maschinell ab:

  1. Purchase Order (PO): enthält vereinbarte Menge, Einzelpreis, Lieferbedingungen
  2. Goods Receipt (GR): dokumentiert tatsächlich eingegangene Menge und Qualität
  3. Vendor Invoice (VI): enthält fakturierte Position, Menge, Preis, IBAN

Der Abgleich erfolgt feldgenau:

Prüfkriterium PO-Feld GR-Feld Rechnungsfeld (BT-Code)
Bestellnummer PO-ID PO-Referenz BT-13
Artikelnummer Item-ID Item-ID BT-155
Menge Ordered Qty Received Qty BT-129
Einzelpreis Unit Price - BT-146
Gesamtbetrag Line Total - BT-131

Toleranzregeln konfigurieren

Kein Betrieb arbeitet mit Null-Toleranz: Das würde zu viele Rechnungen in manuelle Prüfung treiben. Praxisübliche Schwellenwerte:

  • Mengenabweichung: ±2 bis 5 % (je nach Lieferant und Materialart)
  • Preisabweichung: ±1 bis 3 % (Rundungsdifferenzen, Währungsschwankungen)
  • Absoluter Wertbetrag: Rechnungen unter einem definierten Schwellenwert (z. B. 500 €) gehen ohne PO-Matching direkt in Freigabe

Die Schwellenwerte sind keine Konstanten: Sie sollten lieferantenbezogen und positionsspezifisch konfigurierbar sein. Ein Systemlieferant mit jahrelanger Partnerschaft darf weiter toleriert werden als ein Neuzugang.

Was passiert bei Abweichung?

Überschreitet eine Rechnungszeile die konfigurierten Toleranzen, löst das System automatisch Exception Routing aus: Der zuständige Einkäufer oder Kostenstellenverantwortliche erhält eine Aufgabe mit vorausgefüllten Abweichungsdetails. Er entscheidet: freigeben (mit Begründungsfeld), ablehnen (Lieferant wird notifiziert) oder eskalieren. Jede Entscheidung wird mit Zeitstempel und Benutzer-ID im Audit-Trail festgehalten.

Freigabe-Regeln und Eskalation

Dunkelverarbeitung bedeutet nicht, dass Menschen nie eingreifen. Es bedeutet, dass Menschen nur dann eingreifen, wenn ihre Entscheidung tatsächlich gefragt ist. Das erfordert klare Regelwerke:

Stufe 1: Vollautomatische Buchung (kein Eingriff)

Voraussetzungen: 3-way-match positiv, alle Toleranzen eingehalten, Lieferant in Whitelist, keine Auffälligkeiten in der IBAN (Abgleich gegen Stammdaten).

Die Rechnung wird automatisch vorgebucht, Zahlungsauftrag in der Zahlungsvorschlagsliste angelegt, Fälligkeitsdatum in die Liquiditätsvorschau übernommen.

Stufe 2: Freigabe durch Sachbearbeiter

Tritt ein, wenn: Toleranz überschritten (aber unterhalb Eskalationsschwelle), kein PO vorhanden (Dienstleistungsrechnung), Lieferant nicht in Whitelist, Rechnung erstmalig über neuem Kanal empfangen.

Der Sachbearbeiter sieht vorausgefüllte Felder und muss nur Abweichungen beurteilen: keine Dateneingabe, nur Entscheidung.

Stufe 3: Vier-Augen-Freigabe (Abteilungsleiter / Prokurist)

Greift ab einem konfigurierbaren Betragsschwellenwert (typisch 5.000 bis 10.000 € je nach Unternehmensrichtlinie) oder wenn die sachbearbeitende Person und der Kostenstellenverantwortliche identisch sind. Verhindert Kompetenzüberschreitungen ohne zusätzliche Genehmigungsebene im Normalfall.

Zeitbasierte Eskalation

Rechnungen mit nahendem Fälligkeitsdatum oder aktivem Skontofenster erhalten automatisch erhöhte Priorität. Liegt eine Rechnung nach 48 Stunden noch unbearbeitet in der Freigabe-Queue, wechselt die Aufgabe an den Vorgesetzten. Das System schützt so Skontokonditionen, ohne dass jemand aktiv überwachen muss.

Regelbasierte Eskalation konfigurieren: praktische Empfehlung

Die Regeln sollten in der Software als wartbares Regelwerk abgebildet sein, nicht als Hard-coded-Logik:

WENN Rechnungsbetrag > 10.000 €
  UND kein PO vorhanden
  DANN Vier-Augen-Freigabe Prokurist

WENN Abweichung Menge > 5 %
  DANN Einkäufer + Kostenstellenverantwortlicher

WENN Fälligkeit < heute + 5 Tage
  DANN Priorität HOCH, Eskalation nach 24 h

GoBD-konforme automatische Verbuchung

BMF-Schreiben vom 14. Juli 2025: was sich ändert

Das Bundesfinanzministerium hat am 14.07.2025 die zweite Änderung der GoBD veröffentlicht, die ohne Übergangsfrist sofort gilt. Zwei Punkte sind für automatisierte Systeme direkt relevant:

1. XML-Datei reicht für die Archivierung

Für E-Rechnungen nach § 14 Abs. 1 Satz 3 und 6 UStG genügt es, den strukturierten XML-Teil aufzubewahren. Die eingebettete PDF-Ansicht (bei ZUGFeRD) muss nur dann zusätzlich archiviert werden, wenn sie steuerlich relevante Zusatzinformationen enthält, die im XML nicht abgebildet sind, etwa handschriftliche Buchungsvermerke oder nachträglich ergänzte Lieferscheinnummern. Eine Umwandlung der XML-Rechnung in ein Bildformat vor der Archivierung bleibt unzulässig.

2. Aufbewahrungsfrist: 8 Jahre (statt bisher 10)

Aufgrund des Bürokratieentlastungsgesetzes IV gilt für Buchungsbelege (damit auch für Eingangsrechnungen) ab dem 01.01.2025 eine Aufbewahrungsfrist von 8 Jahren (§ 147 Abs. 3 AO in der ab 2025 geltenden Fassung). Diese neue Frist ersetzt die bisherigen 10 Jahre für Rechnungsbelege. Im Zweifel empfiehlt sich die Rücksprache mit dem Steuerberater, da individuelle Sachverhalte abweichen können.

Was GoBD von automatischen Buchungssystemen verlangt

Die GoBD schreiben keine bestimmte Software vor, aber klare Verfahrensprinzipien:

GoBD-Anforderung Technische Umsetzung
Unveränderlichkeit Archiviertes XML wird unveränderlich gespeichert (Write-Once-Speicher oder kryptografische Prüfsumme)
Vollständigkeit Lückenloser Eingangsnachweis: Empfangszeitstempel, Kanal (E-Mail, Peppol, Upload)
Richtigkeit Audit-Trail für jede Buchung: wer hat wann was freigegeben
Ordnung Systematische Indexierung nach Belegdatum, Lieferant, Rechnungsnummer
Zeitgerechtheit Verbuchung zeitnah nach Eingang, Verzögerungen dokumentiert
Nachvollziehbarkeit Verfahrensdokumentation des automatischen Prozesses muss schriftlich vorliegen

Verfahrensdokumentation nicht vergessen: Wer Rechnungen automatisch verbucht, braucht eine schriftliche Verfahrensdokumentation, die den Prüfer in die Lage versetzt, den automatisierten Prozess nachzuvollziehen. Diese Dokumentation ist Bestandteil der GoBD-Konformität, nicht die Software allein.

Mehr zur GoBD-konformen E-Rechnungsarchivierung findet sich im separaten Artikel zu ZUGFeRD.

DATEV-Integrationswege im Vergleich

Rund 500.000 KMU in Deutschland arbeiten mit einem DATEV-Steuerberater zusammen. Für die Integration des automatisierten Rechnungseingangs in den DATEV-Workflow gibt es drei etablierte Wege, jeder mit anderem Anwendungsfall:

Weg 1: DATEV Unternehmen Online

DATEV Unternehmen Online ist eine Cloud-Plattform, über die Unternehmen Belege digital an ihren Steuerberater übergeben. Das Unternehmen lädt Rechnungen (inkl. E-Rechnungs-XML) in den gemeinsamen Datenraum; der Steuerberater bucht in seinem DATEV-System.

Voraussetzungen: DATEV-Zugang für das Unternehmen (DATEV SmartCard oder mIDentity), aktive Steuerberaterbeziehung mit DATEV-Software.

Was übertragen wird: Originaldokumente (XML, PDF), keine Buchungssätze vom Unternehmen.

Stärke: Einfachste Einrichtung, keine eigene Buchhaltungssoftware erforderlich. Steuerberater behält volle Kontrolle über die Verbuchung.

Grenze: Das Unternehmen hat wenig Einblick in den Buchungsstand; Echtzeit-Daten für die Liquiditätsplanung laufen über den Steuerberater.

Weg 2: ASCII-Schnittstelle (DATEVclassic)

Die klassische Dateiübergabe: Das Unternehmen exportiert Buchungssätze als CSV-Datei im DATEV-ASCII-Format, die der Steuerberater importiert.

Voraussetzungen: Keine DATEV-Software im Unternehmen nötig. Kompatible Buchhaltungssoftware (nahezu alle ERP-Systeme bieten DATEV-CSV-Export).

Was übertragen wird: Buchungssätze (Konto, Gegenkonto, Betrag, Text, Belegdatum). Keine Dokumentenbilder.

Stärke: Maximale Kompatibilität, keine technischen Abhängigkeiten, seit Jahrzehnten erprobt.

Grenze: Unidirektional (Unternehmen → Steuerberater), kein Feedback-Kanal, keine Echtzeitanbindung, keine Belegbilder.

Weg 3: REST-API (DATEVconnect)

DATEVconnect ist eine bidirektionale REST-API, die eine direkte Echtzeit-Verbindung zwischen der Unternehmenssoftware und dem lokalen DATEV-System des Steuerberaters herstellt.

Voraussetzungen: Lokale DATEV-Installation beim Steuerberater, DATEVconnect-Lizenz, technische Anbindung durch den Softwareanbieter.

Was übertragen wird: Buchungssätze, Stammdaten, Kostenstellendaten, bidirektional. Keine Dokumentenbilder.

Stärke: Vollautomatisch, Echtzeit, bidirektional: Der Steuerberater sieht Buchungen in Echtzeit, das Unternehmen bekommt Buchungsrückmeldungen direkt ins System.

Grenze: Hohe technische Komplexität, setzt lokale DATEV-Installation voraus, teurer in der Implementierung.

Vergleichstabelle

Kriterium Unternehmen Online ASCII (DATEVclassic) REST-API (DATEVconnect)
Richtung Unternehmen → StB Unternehmen → StB Bidirektional
Belegbilder Ja Nein Nein
Automatisierungsgrad Manueller Upload Geplanter Export Vollautomatisch
DATEV-Software im Unternehmen Nein Nein Ja (beim StB, lokal)
Einrichtungsaufwand Gering Mittel Hoch
Echtzeit Nein Nein Ja
Typischer Einsatz Kleinstbetriebe, Freiberufler KMU mit eigenem ERP KMU mit hohem Buchungsvolumen

Empfehlung für die Praxis: Wer den Rechnungseingang vollautomatisiert und gleichzeitig einen DATEV-Steuerberater hat, kommt mit dem ASCII-Export für die laufende Buchübergabe gut aus, solange das Volumen überschaubar bleibt. Ab höherem Transaktionsvolumen oder wenn Echtzeit-Sichtbarkeit auf beiden Seiten gefragt ist, lohnt die Investition in DATEVconnect.

Dunkelverarbeitungsrate messen und verbessern

Die Dunkelverarbeitungsrate (DVR) ist der zentrale KPI für jedes automatisierte Rechnungseingangs-System:

DVR = (Rechnungen ohne manuellen Eingriff / Rechnungen gesamt) × 100

Realistisch erreichbare Werte variieren stark nach Unternehmensstruktur:

Ausgangssituation Erreichbare DVR
Nur PDF- und Papierrechnungen, kein PO-System 0 bis 20 %
Mix aus E-Rechnung und PDF, PO-System vorhanden 40 bis 65 %
>80 % strukturierte E-Rechnungen, vollständiges PO-System 70 bis 85 %

Die DVR lässt sich durch drei Hebel systematisch steigern:

Hebel 1: Lieferantenstruktur verbessern: Je mehr Lieferanten E-Rechnungen senden, desto höher die DVR. Die E-Rechnungspflicht ab 2027/2028 wird das automatisch treiben.

Hebel 2: PO-Abdeckung erhöhen: Jede Rechnung, die keine Bestellreferenz trägt, muss manuell zugeordnet werden. Interne Prozesse so gestalten, dass Einkauf konsequent Bestellnummern vergibt und Lieferanten diese auf der Rechnung zwingend angeben.

Hebel 3: Toleranzregeln kalibrieren: Zu enge Toleranzen erzeugen unnötige Ausnahmen. Historische Buchungsdaten analysieren: Welche Abweichungstypen treten regelmäßig auf und sind wirtschaftlich unbedeutend? Diese systematisch über Toleranzanpassungen aus der manuellen Queue herausnehmen.

Die DVR allein ist kein ausreichendes Ziel. Parallel messen: Durchlaufzeit (von Rechnungseingang bis Buchungsbeleg) und Fehlerquote (Buchungen, die nachträglich korrigiert werden müssen). Alle drei KPIs zusammen zeigen, ob Automatisierung wirklich Qualität liefert oder nur Volumen verschiebt.

Sicherheitsaspekte: IBAN-Abgleich und Lieferantenvalidierung

Automatisierung macht Prozesse schneller und damit potenziell auch Angriffe. CEO-Fraud und IBAN-Manipulation sind reale Risiken, die das System adressieren muss:

  • IBAN-Abgleich gegen Stammdaten: Die Empfänger-IBAN aus der eingehenden Rechnung (BT-84) wird vor jeder Zahlung gegen die im System hinterlegte Stamm-IBAN des Lieferanten geprüft. Abweichungen lösen automatisch manuellen Freigabeschritt aus.
  • Absendervalidierung: Bei E-Mail-Eingang wird die Absenderdomäne gegen bekannte Lieferanten-Domains geprüft (SPF/DKIM/DMARC als technische Grundlage).
  • Erstmaliger Kanal: Kommt eine Rechnung von einem bekannten Lieferanten erstmalig über einen neuen Kanal (neue E-Mail-Adresse, neues Peppol-ID), wird dies als Ausnahme markiert.

Die Automatisierung macht diese Prüfungen nicht überflüssig, sondern führt sie systematisch durch, anstatt sie dem Augenschein des Sachbearbeiters zu überlassen.

Zusammenfassung: was ein vollständiges System braucht

Schicht Komponente Aufgabe
Eingang Multichannel-Empfang E-Mail, Peppol, Upload-Portal, Postfach-Scan
Parsing XML-Parser (UBL + CII) BT-Codes extrahieren, Schema validieren
Prüfung 3-way-match Engine PO/GR/Invoice abgleichen, Toleranzen prüfen
Freigabe Workflow Engine Regeln ausführen, Aufgaben routen, eskalieren
Verbuchung Buchungsmodul Kontierung vorschlagen, in Buchhaltung schreiben
Archiv GoBD-konformes DMS XML unveränderlich speichern, 8 Jahre, indiziert
Export DATEV-Schnittstelle ASCII, DATEVconnect oder Unternehmen Online
Monitoring KPI-Dashboard DVR, Durchlaufzeit, Fehlerquote

Die Software bildet diese Schichten end-to-end ab, von der eingehenden XRechnung bis zum Buchungsbeleg im Steuerberater-System. Die Fälligkeitsdaten fließen dabei direkt in die Liquiditätsvorschau, sodass automatisch gebuchte Rechnungen sofort in der rollierenden Cashflow-Planung sichtbar sind.

Buchungsqualität, die Prüfern standhält

Wer den Rechnungseingang nicht nur automatisiert, sondern mit lückenlosem Audit-Trail, GoBD-konformer XML-Archivierung und dokumentierter Verfahrensbeschreibung betreibt, hat die Grundlage, die ein Prüfer einfordert. Damit entsteht die Glaubwürdigkeit gegenüber Finanzamt und Bank, die im Ernstfall zählt.

Im Navigator das Passende finden Live-Demo ansehen
Christopher Helm, Maximilian Geissinger, Uwe Martens - die Gründer von liqui.de

Gebaut von Leuten, die denselben Engpass aus der Praxis kennen.

Navigator: Alle Inhalte entlang der Financial Supply Chain auf einen Blick
Navigator: der visuelle Index entlang der Financial Supply Chain
Reicht die XML-Datei für die GoBD-Archivierung aus?

Ja, seit dem BMF-Schreiben vom 14.07.2025 genügt für E-Rechnungen nach § 14 UStG die Aufbewahrung des XML-Teils, sofern alle steuerlich relevanten Inhalte vollständig darin enthalten sind. Die PDF-Ansicht (bei ZUGFeRD) muss nur dann zusätzlich archiviert werden, wenn sie Zusatzinformationen enthält, die im XML fehlen. Eine Umwandlung der XML-Rechnung in ein Bildformat vor der Archivierung ist unzulässig. Im Zweifel: Steuerberater fragen.

Wie lange müssen Eingangsrechnungen aufbewahrt werden?

Seit dem 01.01.2025 gilt aufgrund des Bürokratieentlastungsgesetzes IV eine Aufbewahrungsfrist von 8 Jahren für Buchungsbelege (§ 147 Abs. 3 AO). Die frühere Frist von 10 Jahren ist für ab 2025 eingehende Rechnungen nicht mehr maßgeblich. Stand: Juli 2025, im Zweifel Steuerberater konsultieren, da individuelle Sachverhalte abweichen können.

Was ist der Unterschied zwischen XRechnung und ZUGFeRD?

Beide basieren auf der europäischen Norm EN 16931. XRechnung ist reines XML (UBL-Syntax), für Menschen ohne Viewer nicht lesbar, Standard bei öffentlichen Auftraggebern. ZUGFeRD ist ein Hybrid-Format: PDF/A-3-Datei mit eingebettetem CII-XML. Die PDF-Ansicht ist für Menschen lesbar, das XML für Maschinen. Für den automatischen Rechnungseingang sind beide gleich gut geeignet; der Parser extrahiert in beiden Fällen das XML.

Welche DATEV-Anbindung ist für ein KMU sinnvoll?

Das hängt vom Buchungsvolumen und der Arbeitsteilung mit dem Steuerberater ab. Für kleine Betriebe, die alle Belege beim Steuerberater lassen, ist DATEV Unternehmen Online oft ausreichend. Wer ein eigenes ERP nutzt und Buchungsdaten regelmäßig übergibt, kommt mit der ASCII-Schnittstelle gut aus. DATEVconnect (REST-API) lohnt sich, wenn hohe Buchungsvolumen und Echtzeit-Sichtbarkeit auf beiden Seiten gefragt sind.

Was ist eine realistische Dunkelverarbeitungsrate?

Bei einem Mix aus E-Rechnungen und klassischen PDFs mit vorhandenem PO-System sind 40 bis 65 % realistisch. Mit >80 % strukturierten E-Rechnungen und konsequentem PO-System sind 70 bis 85 % erreichbar. Kein seriöser Anbieter verspricht 100 %, sobald ein Lieferant keine Bestellreferenz angibt oder die IBAN von der Stammdaten-IBAN abweicht, ist menschliche Prüfung sinnvoll und gewollt.

Brauche ich für automatische Verbuchung eine Verfahrensdokumentation?

Ja. Die GoBD verlangen, dass ein Prüfer den automatisierten Buchungsprozess anhand einer schriftlichen Verfahrensdokumentation vollständig nachvollziehen kann. Diese Dokumentation ist unabhängig davon, welche Software eingesetzt wird; sie liegt in der Verantwortung des Unternehmens.