E-Rechnung-Empfangsprozess richtig einrichten

Ein belastbarer E-Rechnung-Empfangsprozess in Deutschland besteht aus acht Stufen: Eingangskanal, Formatklassifizierung, Validierung, Visualisierung, Buchungsregeln, Freigabe, ERP-Routing und Archivierung. Rechtlich reicht mindestens ein dediziertes E-Mail-Postfach für den Empfang aus. Operativ reicht das allein fast nie, weil AP-Teams zusätzlich Regeln für XRechnung, ZUGFeRD, Ausnahmen und die Aufbewahrung des Originalformats brauchen.

Genau hier unterscheidet sich der neue Soll-Prozess vom früheren PDF-zentrierten Kreditorenablauf. Früher begann die eigentliche Prüfung oft erst dort, wo eine Rechnung sichtbar im Team lag und manuell kontiert oder freigegeben wurde. Mit der E-Rechnung verschiebt sich ein Teil dieser Arbeit nach vorne. Das Format muss früh erkannt werden, Validierung wird zu einem eigenen Gate, und bei strukturierten Rechnungen ist nicht mehr die sichtbare Darstellung der führende Bezugspunkt, sondern das XML beziehungsweise die eingebettete strukturierte Ebene.

Für AP-Teams entsteht damit kein einzelner Pflichtpunkt, sondern ein neues Betriebsmodell. Ein Eingangskanal ohne klare Klassifizierung erzeugt Rückstau. Eine XRechnung ohne Viewer ist technisch eingegangen, aber fachlich noch nicht sinnvoll prüfbar. Eine ZUGFeRD-Datei ohne Regel, welche Daten in Buchung und Freigabe weitergegeben werden, löst das Prozessproblem ebenfalls nicht. Dazu kommt die Übergangsrealität: Viele Unternehmen erhalten parallel XRechnung, ZUGFeRD und weiterhin PDF-only sonstige Rechnungen. Der Empfangsprozess muss also nicht nur korrekt, sondern auch mischformatfähig sein.

Der Markt ist davon noch ein gutes Stück entfernt. Laut Bitkom-Studie zur E-Rechnungs-Empfangsfaehigkeit deutscher Unternehmen konnten im Dezember 2024 erst 45 Prozent der Unternehmen in Deutschland E-Rechnungen empfangen. Das ist für AP-Verantwortliche ein nützlicher Realitätscheck: Die Herausforderung liegt selten darin, das Mandat zu kennen, sondern darin, einen belastbaren Zielprozess aufzubauen.

Die rechtliche Einordnung braucht deshalb nur einen kurzen Platz am Anfang. Wer die regulatorische Ausgangslage oder Fristen noch einmal im Detail prüfen will, findet sie in den deutschen E-Rechnungs-Pflichten ab 2025. Für die operative Umsetzung ist entscheidend, wie diese Pflicht in einen Tagesprozess übersetzt wird. Die folgenden acht Stufen bilden genau dieses Zielbild ab, vom ersten Eingang bis zur prüfbaren Ablage.

Eingangskanäle festlegen: E-Mail als Minimum, Peppol und Portale für Skalierung

Der erste Architekturentscheid betrifft nicht das Format, sondern den Eingangskanal. Für viele Unternehmen beginnt der E-Rechnung-Empfang damit, dass ein dediziertes E-Mail-Postfach eingerichtet wird. Das ist ein sinnvoller Mindeststandard, weil Verantwortlichkeiten klarer werden als bei verstreuten Lieferantenrechnungen in persönlichen Postfächern. Ein Team kann Monitoring, Vertretung und Erstannahme daran aufhängen. Wer den Empfang sauber aufsetzen will, sollte deshalb nicht mit Toollisten beginnen, sondern mit der Frage, welcher Kanal verbindlich betrieben und überwacht wird.

Für kleinere Lieferantenvolumina oder für eine frühe Stabilisierungsphase kann E-Mail ausreichend sein. In dem Moment, in dem Lieferantenanzahl, Antwortfristen oder internationale Gesellschaftsstrukturen steigen, werden die Grenzen sichtbar. Das Postfach muss nicht nur empfangen, sondern auch sauber überwacht, vertreten und gegen Medienbrüche abgesichert werden. Fehlt diese Disziplin, wandern Rechnungen zwar ins Unternehmen, aber nicht zuverlässig in den Prozess.

Peppol, Lieferantenportale und EDI erweitern deshalb nicht nur die technische Empfangsfähigkeit, sondern auch die Steuerbarkeit des Workflows. Peppol ist besonders relevant, wenn ein Unternehmen standardisierte B2B- oder grenzüberschreitende Austauschpfade aufbauen will. Ein Lieferantenportal kann sinnvoll sein, wenn Rechnungen zusammen mit Zusatzinformationen oder Freigabevorgaben in einem kontrollierten Rahmen eingehen sollen. EDI bleibt vor allem dort sinnvoll, wo hohe Volumina und langfristig standardisierte Lieferantenbeziehungen bestehen. Kein Kanal ist pauschal der beste. Entscheidend sind Lieferantenmix, Volumen, SLA-Anforderungen und die Frage, wie stark der spätere Freigabe- und Buchungsprozess automatisiert werden soll.

Ein deutscher Empfangsprozess für B2B-E-Rechnungen braucht deshalb meist keinen radikalen Kanalwechsel, sondern einen gesteuerten Kanal-Mix. E-Mail kann das Mindestsetup bleiben, während Peppol für bestimmte Lieferantengruppen ergänzt wird und Portale oder EDI dort andocken, wo das Geschäft es rechtfertigt. Wichtig ist nur, dass jeder Kanal denselben Zielprozess bedient. Wenn E-Mail-Rechnungen anders klassifiziert, anders priorisiert oder anders eskaliert werden als Peppol-Rechnungen, entsteht keine robuste Empfangsarchitektur, sondern nur ein Sammelsurium paralleler Teilprozesse.

Eingangsformate sauber trennen: XRechnung, ZUGFeRD und sonstige Rechnungen

Sobald der Eingangskanal steht, muss der Prozess die eingehende Datei zuverlässig einordnen. Genau an dieser Stelle trennt sich ein stabiler Empfang von einem bloßen Sammelpostfach. Für die weitere Verarbeitung ist entscheidend, ob eine Rechnung als XRechnung, als ZUGFeRD oder als sonstige Rechnung eingeht. Diese Unterscheidung ist keine Formalität, sondern bestimmt, welche Prüfungen möglich sind, welche Darstellung dem Sachbearbeiter vorliegt und welches Originalformat später archiviert werden muss.

XRechnung ist ein reines XML-Format. Es enthält strukturierte Daten, aber keine menschenfreundliche Sichtdarstellung. Für den Prozess bedeutet das: Die Rechnung ist technisch präzise, fachlich aber erst dann gut bearbeitbar, wenn ein Viewer oder eine geeignete Visualisierung eingebunden ist. ZUGFeRD funktioniert anders. Hier liegt eine PDF/A-3-Datei mit eingebettetem XML vor. Das erleichtert die fachliche Prüfung, weil eine sichtbare Belegansicht direkt vorhanden ist, ändert aber nichts daran, dass die strukturierte Ebene für die Weiterverarbeitung und steuerliche Einordnung mitgedacht werden muss.

Daneben bleibt in der Übergangsphase der ZUGFeRD-Empfang nicht der einzige Sonderfall. Viele AP-Teams bekommen weiterhin PDF-only Rechnungen, die prozessual als sonstige Rechnungen behandelt werden müssen. Sie verschwinden nicht dadurch, dass der Soll-Prozess auf E-Rechnung umgestellt wird. Solche Belege gehören in einen bewusst definierten Nebenpfad, nicht stillschweigend in denselben Bearbeitungsweg wie strukturierte XML-Rechnungen. Gerade in einem gemischten Eingang muss sehr früh klar sein, welche Datei direkt in strukturierte Prüf- und Buchungslogik laufen kann und welche erst gesondert behandelt oder aufbereitet werden muss.

Praktisch heißt das, dass Formatklassifizierung am Anfang des Prozesses sitzen sollte. Nicht erst der Bearbeiter im Freigabelauf darf erkennen, dass eine Datei eigentlich eine XML-Rechnung ohne visuelle Ebene ist oder dass eine PDF-Rechnung nur unter Übergangsregeln akzeptiert wurde. Wer die Dateiformate früh trennt, verhindert, dass unpassende Dokumente in falsche Prüfschritte geraten. Wer sie spät trennt, verlagert Unsicherheit nur in spätere Prozessstufen, wo Korrekturen teurer und langsamer werden.

Validierung und Visualisierung früh in den Workflow einbauen

Die Validierung gehört in einen XRechnung-Empfangsprozess nicht an das Ende, sondern möglichst nah an den Eingang. Ihr Zweck ist nicht, eine bereits fast gebuchte Rechnung noch einmal technisch abzunicken. Sie soll früh entscheiden, ob die eingegangene Datei formal und inhaltlich so belastbar ist, dass sie überhaupt in den fachlichen Bearbeitungsfluss weiterlaufen darf. Genau deshalb ist E-Rechnung-Validierung ein eigener Gate-Schritt und kein unsichtbarer Unterpunkt der Buchung.

In der Praxis hilft eine einfache Trennung. Harte Fehler stoppen den Prozess. Dazu zählen typische Fälle wie nicht verarbeitbare XML-Strukturen oder klare Verstöße gegen das erwartete Formatprofil. Weiche Warnungen sind anders zu behandeln. Sie können auf Unstimmigkeiten oder fehlende Komfortinformationen hinweisen, ohne dass die Rechnung zwingend unbrauchbar ist. In einem robusten Prozess laufen solche Fälle nicht kommentarlos weiter, sondern in eine gekennzeichnete Ausnahmebehandlung mit klarer Verantwortlichkeit.

Zur technischen Prüfung kommt die Frage der fachlichen Lesbarkeit. Eine XRechnung ist ohne Viewer für viele AP-Teams keine gut prüfbare Arbeitsgrundlage. Wer klären muss, wie sich strukturierte Rechnungen im Alltag lesbar machen lassen, findet dazu einen kompakten Leitfaden zum XRechnung-XML anzeigen und als PDF nachvollziehbar prüfen. ZUGFeRD bringt immerhin eine PDF-Ansicht mit, was die Sichtprüfung deutlich erleichtert. Daraus folgt eine wichtige Prozessregel: Validierung und Visualisierung sind zwei benachbarte, aber nicht identische Funktionen. Die Validierung sagt, ob die Rechnung strukturell in Ordnung ist. Die Visualisierung macht sie für Sachbearbeiter bearbeitbar. Erst zusammen ergeben sie einen praxistauglichen Kontrollpunkt.

Wer diesen Schritt überspringt, verschiebt Probleme nur ins ERP, in den Genehmigungsworkflow oder in Rückfragen an den Lieferanten. Dann tauchen Fehler dort auf, wo eigentlich schon kontiert, gematcht oder freigegeben werden sollte. Ein sauberer Kontrollpunkt am Anfang verkürzt Liegezeiten, weil unklare Fälle früh sortiert werden. Gleichzeitig schafft er einen disziplinierten Umgang mit Warnungen und echten Ausnahmefällen, statt technische und fachliche Probleme im selben Postkorb zu vermischen.

Buchungsregeln und Datenübergabe auf strukturierte Eingangsrechnungen ausrichten

Nach der technischen Prüfung beginnt die fachliche Arbeit. Jetzt geht es nicht mehr nur darum, ob eine Datei gültig ist, sondern ob sie mit den Regeln der Kreditorenbuchhaltung sauber in den Folgeprozess übergeben werden kann. Dazu gehören Umsatzsteuerlogik, Kontierung, Kostenstellen, Bestellbezug und gegebenenfalls Dreifachabgleich. Ein guter Prozess für die E-Rechnungsverarbeitung in AP-Teams behandelt diese Regeln nicht als letzten manuellen Rest, sondern als bewusst gestaltete Schicht zwischen Empfang und Buchung.

Der operative Vorteil strukturierter Rechnungen liegt genau hier. Wenn XML-Daten verlässlich vorliegen, lassen sich Steuerkennzeichen, Beträge, Stammdatenbezug und Routingregeln konsistenter anwenden als in einem rein PDF- oder OCR-zentrierten Ablauf. Das bedeutet nicht, dass jede Rechnung automatisch richtig gebucht wird. Es bedeutet aber, dass Auto-Coding, Plausibilisierung und Zuordnung auf stabileren Eingangsdaten aufsetzen können. Für AP-Teams ist das der eigentliche Gewinn der E-Rechnung: weniger Interpretationsarbeit an der Rechnung selbst und mehr steuerbare Logik im Folgeprozess.

Gleichzeitig bleibt der Mischbetrieb Realität. Solange PDF-only und hybride Eingangsrechnungen neben strukturierten XML-Rechnungen ankommen, braucht der Prozess eine saubere Normalisierung. Genau dort ist automatisierte Rechnungsverarbeitung fachlich relevant. Invoice Data Extraction ersetzt weder Peppol noch Validierung, Freigabe oder Archivierung. Das Produkt konvertiert eingehende Rechnungen anhand eines Prompts in strukturierte Excel-, CSV- oder JSON-Ausgaben und ist damit dort sinnvoll, wo AP-Teams unstrukturierte oder hybride Eingänge in ein einheitliches Datenformat für den Folgeprozess überführen müssen.

Wichtig ist die Trennung der Aufgaben. Buchungsregeln definieren, wie eine Rechnung fachlich behandelt wird. Datenaufbereitung stellt sicher, dass die nötigen Informationen konsistent und weiterverarbeitbar vorliegen. Wer beides vermischt, baut Regeln auf unsichere Eingangsdaten. Wer beides sauber trennt, schafft einen Prozess, in dem strukturierte E-Rechnungen direkt sauber weiterlaufen und gemischte Eingänge kontrolliert auf dasselbe Verarbeitungsniveau gebracht werden.

Ausnahmebehandlung und Genehmigungsworkflow als eigenen Prozess bauen

Ein belastbarer Empfangsprozess entsteht nicht dadurch, dass Ausnahmen selten sind, sondern dadurch, dass sie geordnet behandelt werden. Typische Fälle sind ungültige XML-Dateien, fachlich unplausible Inhalte, unzureichende ZUGFeRD-Profile, PDF-only Rechnungen in der Übergangszeit oder fehlender Bestellbezug. Solche Eingänge dürfen nicht einfach im normalen Fluss mitlaufen. Sie brauchen einen eigenen Pfad mit klarer Entscheidung, ob die Rechnung an den Lieferanten zurückgeht, intern nachbearbeitet wird oder mit dokumentierter Ausnahme weiterlaufen darf.

Gerade hier lohnt sich die Trennung zwischen Validierung und Genehmigung. Die Validierung beantwortet, ob das Dokument strukturell und formal tragfähig ist. Der Genehmigungsworkflow beantwortet eine andere Frage: Ist die Rechnung wirtschaftlich berechtigt, fachlich korrekt zugeordnet und organisatorisch freigegeben. Wer beides im selben Schritt vermischt, macht den Prozess unübersichtlich. Dann werden technische Fehler von Fachbereichen geklärt, während AP gleichzeitig auf fehlende Kostenstellen oder ungeklärte Leistungsbezüge stößt.

Für die Praxis ist deshalb eine einfache Eskalationslogik hilfreich. Harte technische Fehler gehören in eine Rückfrage- oder Rückweisungsroutine an den Lieferanten. Weiche Warnungen oder fehlende Kontextdaten können intern in einen gesteuerten Ausnahmeprozess laufen. Rechnungen ohne Bestellbezug oder mit strittiger Leistungserbringung brauchen meist eine fachliche Entscheidung im Unternehmen, nicht sofort einen technischen Reject. Wichtig ist nur, dass jeder Fall einen Besitzer, eine Frist und einen dokumentierten Status hat.

Ein guter Genehmigungsworkflow versucht nicht, jede Abweichung im Vorfeld auszuschließen. Er sorgt dafür, dass Sonderfälle schnell sichtbar, zugeordnet und nachvollziehbar entschieden werden. Genau das hält Liegezeiten kurz. Für AP-Leiter ist das oft der eigentliche Reifegrad eines Soll-Prozesses: nicht wie glatt der Happy Path aussieht, sondern wie diszipliniert das Team mit Abweichungen umgeht.

ERP- und Fibu-Routing für DATEV, SAP, Lexware und sevdesk definieren

Wenn Klassifizierung, Validierung und fachliche Regeln stehen, kann das Routing in die Zielsysteme sauber definiert werden. Genau hier scheitern viele Einführungen, weil das ERP oder die Fibu zu früh als Hauptlösung betrachtet werden. In Wirklichkeit funktioniert Routing erst dann zuverlässig, wenn vorher klar ist, welche Rechnungen in welcher Qualität ankommen und welche Datenfelder im Folgeprozess verfügbar sein müssen.

Für viele deutsche Mittelständler ist DATEV der wichtigste Referenzpunkt. Dort geht es praktisch um den Weg von der eingegangenen E-Rechnung in die E-Rechnungsplattform, in Belege online, gegebenenfalls in Belegfreigabe online und anschließend in die Buchführung. Wer tiefer sehen will, wie sich strukturierte Daten in diesem Umfeld nutzen lassen, findet dazu einen eigenen Beitrag über Rechnungsdaten in DATEV weiterverarbeiten. Für SAP-S/4HANA-Umgebungen liegt der Fokus stärker auf dem Zusammenspiel mit nativen oder ergänzenden Komponenten für Empfang, Validierung und Weitergabe in nachgelagerte Prozesse, etwa wenn SAP DRC den formalen Empfang abbildet und nachgelagerte Lösungen den operativen AP-Ablauf übernehmen.

Lexware und sevdesk sind für kleinere und mittlere Setups relevant, weil sie den operativen Empfang und die Weiterverarbeitung näher an der Buchhaltungsanwendung zusammenführen. In der Praxis ist das für Teams attraktiv, die E-Rechnungen möglichst direkt im bestehenden Buchhaltungsablauf empfangen, prüfen und weiterreichen wollen. Das ändert aber nichts an der Grundregel: Auch dort muss vorher klar sein, wie mit XRechnung, ZUGFeRD und Ausnahmen umgegangen wird. Die Anwendung nimmt dem Team nicht die Entscheidung ab, welche Fälle automatisch weiterlaufen und welche in einen fachlichen Sonderpfad gehören.

In internationalen oder heterogenen Landschaften liegt zwischen deutschem Eingangsformat und Zielsystem häufig noch ein Connector- oder iPaaS-Layer. Das ist bei NetSuite, Dynamics 365 oder Odoo besonders typisch. Für den Soll-Prozess ist das kein Nachteil, solange die Rollen sauber getrennt bleiben. Der Empfangsprozess soll Rechnungen korrekt einordnen, prüfen und anreichern. Das Zielsystem soll verbuchen, reporten und den Folgeprozess tragen. Wer diese Grenze sauber zieht, bekommt ein robustes ERP-Routing statt einer späten Fehlerverlagerung.

Archivierung und Verfahrensdokumentation von Anfang an mitplanen

Der Empfangsprozess ist erst dann belastbar, wenn auch Archivierung und Nachweisfähigkeit sauber geregelt sind. Für Rechnungen, die ab dem 1. Januar 2025 entstehen, gilt eine Aufbewahrungsfrist von acht Jahren. Für ältere Rechnungen bleibt es bei zehn Jahren. Diese Frist ist nur die sichtbare Oberfläche. Wichtiger für den Prozess ist, dass das Originalformat erhalten bleibt und nicht erst am Ende des Projekts improvisiert behandelt wird.

Bei XRechnung bedeutet das, dass das ursprüngliche XML archiviert werden muss. Eine nachträgliche Visualisierung ist für die Bearbeitung hilfreich, ersetzt aber nicht den Primärbeleg. Bei ZUGFeRD ist die originale PDF/A-3-Datei mit eingebettetem XML maßgeblich. Wer nur eine abgeleitete Darstellung speichert, verliert genau die strukturierte Ebene, auf die sich der E-Rechnungs-Prozess stützt. Darum sollte E-Rechnung-Archivierung nicht als IT-Nebenthema laufen, sondern als fester Bestandteil des Soll-Prozesses.

Dazu gehört auch die Verfahrensdokumentation E-Rechnung. Sie ist kein Anhang für den späteren Audit-Fall, sondern die schriftliche Beschreibung dessen, was das Unternehmen tatsächlich betreibt. Mindestens dokumentiert sein sollten Eingangskanäle, Formatklassifizierung, Validierung, Rollen, Ausnahmebehandlung, Genehmigungslogik, Archivierung und Aufbewahrungsregeln. Viele Teams arbeiten dafür sinnvoll mit vorhandenen Mustern von Verbänden oder Beraterorganisationen und passen sie auf den eigenen Soll-Prozess an. Erst wenn diese Punkte zusammenpassen, ist aus einem technischen Empfang ein prüfbarer Geschäftsprozess geworden.

Für tiefergehende Detailfragen zu Nachweis- und Archivthemen lohnt sich der separate Beitrag zu den GoBD-Anforderungen fuer Archivierung und Verfahrensdokumentation. Für den hier beschriebenen Zielprozess reicht die Leitlinie: Der Empfang ist nicht abgeschlossen, wenn eine Rechnung sichtbar im System liegt, sondern erst dann, wenn sie im richtigen Originalformat nachvollziehbar weiterverarbeitet und prüfbar aufbewahrt werden kann.