E-Rechnung verarbeiten: Auslesen, Validieren und Freigeben

Strukturiertes Format und PDF. Ein gewöhnliches PDF enthält nicht automatisch strukturierte Rechnungsdaten. Die deutsche BMF-FAQ unterscheidet elektronische Rechnungen im vorgesehenen strukturierten Format von sonstigen Rechnungen wie einfachen PDFs. Für den deutschen inländischen B2B-Bereich gelten seit 2025 entsprechende Regeln einschließlich Übergängen und Ausnahmen. Die konkrete Verpflichtung ist für den eigenen Fall zu prüfen. BMF: Fragen und Antworten zur E-Rechnung, geprüft am 26. September 2026.

Welche Daten vorhanden sind. Für die Technik ist entscheidend, welche Daten tatsächlich vorhanden sind. Ein XML-Dokument kann direkt gelesen werden. Ein hybrides Format enthält strukturierte Daten und eine visuelle Darstellung. Ein Bildscan benötigt dagegen zunächst Texterkennung. Wenn Sie alle drei Eingänge gleich behandeln, verschenken Sie die verlässlichere Struktur und schaffen unnötige Erkennungsfehler.

Umwandlung ist eine andere Aufgabe. „PDF in E-Rechnung umwandeln“ ist außerdem eine andere Aufgabe als eine empfangene E-Rechnung auszulesen. Bei der Umwandlung müssen die erforderlichen Informationen aus einer unstrukturierten Quelle korrekt übernommen und in ein geeignetes Format gebracht werden. Eine optisch gelungene Datei beweist noch keine technisch oder fachlich richtige Rechnung.

Österreich beschreibt für Rechnungen an den Bund eine Einbringung in elektronisch strukturierter Form. Die Anforderungen dieses B2G-Verfahrens sind von einem allgemeinen innerbetrieblichen Rechnungseingang zu unterscheiden. USP: E-Rechnung.

Die Schweizer Eidgenössische Finanzverwaltung nennt für Rechnungen an den Bund sowohl strukturierte Datensätze über Dienstleister als auch PDF-Einreichungen über die vorgesehenen Kanäle. EFV: E-Rechnungen in Kürze. Schon diese Unterschiede zeigen, weshalb eine pauschale „DACH-E-Rechnungspflicht“ kein brauchbarer Implementierungsauftrag ist.

Deutschland, Österreich und die Schweiz beschreiben E-Rechnungen in den hier zitierten Quellen unterschiedlich:

Speichern Sie deshalb Land, Empfängerart, vereinbarten Übertragungsweg und erwartetes Format als Prozesskontext. Klären Sie mit der zuständigen Fachperson, welche Regeln im konkreten Geschäft gelten. Die technische Verarbeitung kann gemeinsame Komponenten nutzen; die rechtlichen und empfängerbezogenen Anforderungen bleiben getrennt.

Ein international tätiges Unternehmen kann gleichzeitig Dokumente nach mehreren Regelungen erhalten. Steuern Sie diese anhand eines ausdrücklichen Kontexts, statt anzunehmen, dass die Rechnungssprache die anzuwendenden Regeln erkennen lässt. Eine deutschsprachige Rechnung kann zu jedem der drei Märkte gehören.

Format und Profil. Ein Parser sollte nicht nur „XML“ erkennen. Er muss feststellen, welchem Format und Profil die Datei entspricht und welche Regeln angewendet werden sollen. Die KoSIT veröffentlicht Konfigurationen für die Validierung von XRechnung. FeRD veröffentlicht Spezifikationen und Prüfartefakte für ZUGFeRD; am Recherchetag ist dort auch das Paket 2.5.2 vom 4. August 2026 aufgeführt. KoSIT-Validierung, FeRD-Veröffentlichungen.

Versionen. Das bedeutet nicht, dass Sie bei jeder Veröffentlichung sofort jede bestehende Rechnung mit den neuesten Regeln neu bewerten müssen. Legen Sie fest, welche Eingangsprofile unterstützt werden, welche Prüfversion zu welchem Eingang gehört und wie unbekannte Versionen behandelt werden. Halten Sie die verwendeten Artefakte im Prüfprotokoll fest.

Hybride Dokumente. Bei einem hybriden Dokument bewahren Sie die empfangene Gesamtdatei auf und verarbeiten den strukturierten Bestandteil gezielt. Die sichtbare Darstellung hilft Menschen bei der Orientierung. Widersprüche zwischen Darstellung und Daten werden als eigener Prüffall behandelt. Sie sollten nicht durch die Auswahl des bequemeren Werts verschwinden.

Darstellung. Testen Sie neben dem Parser auch die gewählte Darstellungskomponente (Renderer). Eine prüfende Person muss denselben Datensatz verstehen, den die Integration weitergibt. Lässt die Prüfansicht wichtige Felder aus, beruht eine scheinbar erfolgreiche Freigabe womöglich auf unvollständigen Informationen.

Vier Prüfungen beantworten unterschiedliche Fragen zu einer E-Rechnung:

Ergebnisse getrennt halten. Bewahren Sie die Ergebnisse getrennt. Ein technischer Fehler sollte mit verständlichem Grund und konkreter Fundstelle erscheinen. Ein fachlicher Konflikt benötigt dagegen eine Aufgabe an Einkauf oder Buchhaltung. Wer alles als „ungültige Rechnung“ bezeichnet, erschwert die gezielte Korrektur.

Deterministische Regeln. Die Validierung soll deterministische Regeln reproduzierbar ausführen. Ein Sprachmodell kann eine Fehlermeldung verständlich erklären, sollte aber nicht eigenständig eine gescheiterte Regel überstimmen. Ebenso darf es fehlende Pflichtangaben nicht ergänzen, als wären sie im Original enthalten.

Umgang mit Warnungen. Legen Sie fest, welche Warnungen die weitere Verarbeitung blockieren und welche nach einem vereinbarten Ausnahmeverfahren geprüft werden können. Diese Entscheidung gehört in eine kontrollierte Richtlinie und nicht in eine improvisierte Modellantwort. Halten Sie die Version der Richtlinie zusammen mit der Entscheidung fest, wenn sie für eine spätere Rekonstruktion wichtig ist.

Internes Modell. Übernehmen Sie Rechnungsnummer, Aussteller, Empfänger, Datum, Währung, Summen und benötigte Positionen in ein definiertes internes Modell. Bewahren Sie dabei die Quelle jedes Werts. Für die Weitergabe müssen die Referenzen des Zielsystems separat aufgelöst werden: Ein Lieferantenname im Dokument ist noch keine Kreditorenkennung.

Herkunft der Werte. Unterscheiden Sie drei Wertearten: direkt gelesene Information, nach einer freigegebenen Regel berechnete Information und menschlich bestätigte Zuordnung. Diese Herkunft hilft später, Fehler einzugrenzen. Bei einer falschen Kostenstelle muss erkennbar sein, ob die Ursache im Beleg, im Stammdatenabgleich oder in einer manuellen Entscheidung liegt.

Rundung und Datentypen. Legen Sie Rundung und Datentypen fest. Geldbeträge dürfen nicht durch beiläufige Textumwandlungen ihre Bedeutung ändern. Eine Währung muss ausdrücklich mitgeführt werden. Tests sollten mehrere Steuersätze, Rabatte, Zuschläge und Gutschriften enthalten, soweit diese im vorgesehenen Prozess vorkommen. Die fachliche Berechnungsregel wird von der zuständigen Buchhaltung festgelegt.

Positionen und Summen. Erhalten Sie den Zusammenhang zwischen Positionen und Summen. Ein korrekter Gesamtbetrag kann falsch zugeordnete Positionen verdecken. Verlangt der nachfolgende Ablauf eine Kostenstellenzuordnung je Position, erfüllt die Übernahme reiner Kopfsummen die Anforderung nicht.

Der Fall. Ein erfundener Betrieb erhält eine formal lesbare strukturierte Rechnung über 100 bestellte Einheiten. Der vereinbarte Einzelpreis beträgt zehn Euro, die Rechnungssumme für diese Position also 1.000 Euro vor weiteren Bestandteilen. Im Wareneingang sind bisher nur 80 Einheiten bestätigt.

Auslesen und Abgleich. Der Parser liest die Position ohne OCR aus. Die technische Validierung liefert keinen blockierenden Formatfehler. Der anschließende Bestell- und Wareneingangsabgleich erkennt jedoch eine Mengenabweichung von 20 Einheiten. Der Workflow erstellt eine Aufgabe für den Einkauf und lässt die Rechnung fachlich offen.

Klärung. Die zuständige Person klärt, ob eine weitere Lieferung noch nicht erfasst wurde, ob die Rechnung zu früh kam oder ob eine Korrektur erforderlich ist. Ihre Entscheidung wird mit dem Beleg verbunden. Erst anschließend folgt die vorgesehene Freigabe. Die erfolgreiche XML-Prüfung hat dabei ihren Zweck erfüllt, ohne eine Aussage über die tatsächliche Lieferung vorzutäuschen.

Zweiter Test. Ein zweiter Test verändert absichtlich die Summen im strukturierten Dokument. Nun muss die Regelprüfung einen anderen Fehlergrund ausgeben. Diese Trennung zwischen Format- beziehungsweise Rechenfehler und tatsächlicher Geschäftsabweichung gehört in die Abnahme.

Dritter Test. Ein dritter Test reicht das Original erneut ein. Der Workflow sollte es mit dem bestehenden Vorgang verknüpfen, statt eine neue Verbindlichkeit anzulegen. Zusammen decken diese Tests das Auslesen, die fachlichen Kontrollen und die wiederholte Zustellung ab.

Geeignete Aufgaben. KI kann einen unstrukturierten Begleittext zusammenfassen, eine zuständige Person vorschlagen oder eine Rückfrage als Entwurf formulieren. Sie kann auch bei der Klassifikation von Anlagen helfen. Dafür sollte sie nur die Daten erhalten, die diese konkrete Aufgabe benötigt.

Beispiel. Ein Beispiel ist der Satz „Die zweite Teillieferung folgt nächste Woche“ in einer begleitenden E-Mail. Das Modell kann diese Information als Hinweis mit Quellenbezug bereitstellen. Es darf daraus nicht selbstständig einen bestätigten Wareneingang erzeugen. Ein Hinweis aus Kommunikation ist eine andere Evidenz als ein freigegebener Liefervorgang.

Keine unnötige Neuerkennung. Vermeiden Sie unnötige Neuerkennung: Liegt ein Betrag strukturiert vor, sollte eine zusätzliche visuelle Modellantwort diesen Wert nicht unbemerkt ersetzen. Bei einem Widerspruch entsteht eine Prüfung. Diese Regel hält den Ablauf nachvollziehbar und reduziert vermeidbare Modellkosten.

Erklärungen bleiben an die Validierung gebunden. KI-erzeugte Erklärungen sollten an das tatsächliche Validierungsergebnis gebunden bleiben. Eine Erklärung kann eine fehlende Referenz beschreiben, sollte aber weder eine wahrscheinliche Referenz erfinden noch der prüfenden Person ohne freigegebene Regel versichern, dass eine Warnung harmlos ist.

Fehler, Wiederholung und bestätigte Übergabe

Zustände. Führen Sie getrennte Zustände für empfangen, technisch geprüft, fachlich offen, freigegeben und übertragen. Ein Datensatz wird erst als abgeschlossen gezählt, wenn der Zielprozess seine Übernahme bestätigt. Bleibt die Antwort nach einer Übertragung aus, ist der Zustand unklar; eine blinde Neuanlage kann eine Dublette erzeugen.

Nachvollziehbarkeit. Ein Prüfprotokoll sollte die interne Kennung, Originalreferenz, Formatversion, Prüfregelstand, Fehler, Freigabe und Zielkennung verbinden. Speichern Sie nicht unnötig vollständige Beleginhalte in technischen Logs. Die fachliche Nachvollziehbarkeit lässt sich über kontrollierte Verweise auf die dafür vorgesehene Ablage herstellen.

Nicht lesbare Eingänge. Unbekannte Formate, beschädigte Dateien und verschlüsselte Eingänge benötigen eine sichtbare Warteschlange. Definieren Sie, wer den Absender kontaktiert und wie ein korrigierter Eingang mit dem ursprünglichen Fall verbunden wird. Der neue Eingang soll keine bereits erteilte Freigabe stillschweigend übernehmen.

Wiederholung oder Ablehnung. Trennen Sie wiederholbare Übertragungsprobleme von einer fachlichen Ablehnung. Warten und erneutes Senden können eine vorübergehende Verbindungsstörung beheben, eine ungültige Lieferantenreferenz aber nicht korrigieren. Die bedienende Person braucht einen Grund, mit dem sie etwas anfangen kann, und einen sicheren nächsten Schritt.

Validierungsfehler für Mitarbeitende übersetzen

Verständliche Beschreibungen. Eine technische Regelkennung sollte im Arbeitsbestand eine verständliche Beschreibung erhalten. Bewahren Sie die ursprüngliche Meldung daneben auf, damit der Betreiber den Fehler reproduzieren kann. Die Buchhaltung benötigt vor allem das betroffene Feld, die Quelle und die nächste erlaubte Handlung. Eine Erläuterung darf den Inhalt der Regel verständlicher machen, aber ihren Schweregrad nicht eigenmächtig verändern.

Unterschiedliche Zuständige. Bei einem fehlenden Empfängerbezug lautet die Aufgabe beispielsweise, die korrekte Zuordnung mit dem Absender beziehungsweise der zuständigen Stelle zu klären. Bei einer nicht unterstützten Formatversion prüft der Betreiber dagegen die Parser- und Validierungskonfiguration. Beide Fälle sind offen, erfordern aber unterschiedliche Personen. Diese Zuordnung beschleunigt die Bearbeitung ohne eine fachliche Entscheidung vorwegzunehmen.

Fehlerergebnis in der Abnahme. Nehmen Sie die vollständige Fehlermeldung in den Testsatz auf. Nach einem Update darf aus einem bisher blockierenden Fall nicht unbemerkt eine Warnung werden, die niemand mehr sieht. Vergleichen Sie deshalb nicht nur ausgegebene Beträge, sondern auch Fehlerklassen und resultierende Zustände. Ein technischer Versionswechsel kann das Verhalten verändern, obwohl die Benutzeroberfläche gleich aussieht.

Rückmeldung an Lieferanten. Vereinbaren Sie schließlich, wie Rückmeldungen an Lieferanten formuliert werden. Benennen Sie konkrete fehlende oder widersprüchliche Informationen. Vermeiden Sie pauschale Aussagen, eine gesamte Rechnung sei rechtlich unwirksam, wenn der Workflow lediglich einen technischen Verarbeitungsfehler festgestellt hat. Die Rückfrage soll eine Korrektur ermöglichen und den tatsächlichen Prüfstatus korrekt wiedergeben.

Ein Abnahmesatz für den Start

Fälle. Verwenden Sie je unterstütztem Format mindestens normale und absichtlich fehlerhafte Beispiele. Ergänzen Sie falschen Empfänger, fehlende Referenz, Gutschrift, Mehrfachzusendung, abweichende Darstellung, Teilmenge und unterbrochene Übergabe. Die Auswahl richtet sich nach Ihrem Geschäft; ein einzelnes Muster-XML reicht nicht.

Bestätigung. Die Fachperson bestätigt für jeden Fall erwarteten Status und nächsten Bearbeiter. Die Technik weist die verwendete Prüfregelversion und das vom Zielsystem tatsächlich akzeptierte Ergebnis nach. Ein Pilot sollte danach auch Mengen abstimmen: Eingänge gleich abgeschlossene Fälle plus bewusst offene oder ausgesonderte Fälle, unter Berücksichtigung mehrerer Dateien je Vorgang.

Ergebnis. So entsteht ein E-Rechnungsworkflow, der die Stärke strukturierter Daten nutzt und schwierige Entscheidungen sichtbar lässt. Für die nächste Umsetzung brauchen Sie vor allem Beispielrechnungen, die Anforderungen der Empfänger, das Zielsystem und die Verantwortlichen für fachliche Regeln. Damit können Parser, Validierung und ergänzende KI klar abgegrenzt beschafft und getestet werden.

Diese Leitfäden und Leistungsseiten behandeln die Entscheidungen rund um die Verarbeitung von E-Rechnungen:

• KI-Dokumentenverarbeitung: vom Eingang bis zur Freigabe
• Rechnungen automatisch auslesen: Felder, Prüfung und Übergabe
• Digitale Rechnungsfreigabe: Regeln, Vertretung und Ausnahmen
• DATEV-Dokumentenworkflow: welche Übergabe wirklich gebraucht wird

Für eine konkrete Ablaufprüfung reichen zunächst eine Prozessbeschreibung, die beteiligten Systeme und typische Ausnahmen. Mit modernagents besprechen.