E-Rechnung automatisieren: Empfang, Prüfung und Weiterverarbeitung

Problem und Zielgruppe

Wer heute Eingangsrechnungen verarbeitet, bekommt zunehmend einen Mix aus drei Welten auf den Tisch: dem klassischen PDF-Anhang, der eingescannten Papierrechnung – und der strukturierten E-Rechnung als XML oder XML-in-PDF. Die dritte Kategorie wird zum Regelfall, weil seit dem 1. Januar 2025 die Pflicht zur E-Rechnung für Umsätze zwischen inländischen Unternehmen gilt, mit gestaffelten Übergangsfristen für die Ausstellung. Für Empfänger:innen ändert sich dabei etwas Grundsätzliches: Eine E-Rechnung muss man annehmen können, sobald der Aussteller sie schickt – unabhängig von der eigenen Systemlandschaft.

Das ist eine gute Nachricht und eine schlechte zugleich. Die gute: Strukturierte Formate lassen sich, anders als ein eingescanntes PDF, ohne Texterkennung maschinell auslesen – die Daten stehen bereits als Felder im XML. Die schlechte: „Empfangen können” heißt nicht „automatisch verarbeiten”. Ohne Validierung, Fehlerbehandlung und eine klare Anbindung an Buchhaltung oder ERP-System landet die E-Rechnung trotzdem wieder auf dem Schreibtisch eines Menschen, der die Felder von Hand abtippt – nur diesmal aus einer XML-Datei, die er ohne Werkzeug gar nicht lesen kann.

Dieser Artikel richtet sich an Geschäftsführung, Operations, IT und Fachbereich in KMU, die den Empfang, die Prüfung und die Weiterverarbeitung von E-Rechnungen automatisieren wollen. Er konzentriert sich bewusst auf das, was an E-Rechnungen spezifisch ist – Formate, Empfangswege, Validierungsebenen, Sonderfälle und Archivierung. Wie die komplette Kette von Rechnungserkennung bis Freigabe aufgebaut wird, inklusive Extraktion aus unstrukturierten PDFs, vertiefen weitere Artikel im Themen-Cluster Backoffice-Automatisierung.

Meine Position aus Projekten: Der größte Hebel bei E-Rechnungen liegt nicht im Empfang, sondern in der Validierung. Wer ein strukturiertes Format bekommt, es aber nur wie ein PDF behandelt und die eingebetteten Daten ignoriert, verschenkt den eigentlichen Vorteil der Umstellung.

Begriffe und Abgrenzung

Bevor es um Formate und Workflows geht, lohnt sich eine saubere Trennung von drei Begriffen, die im Alltag oft durcheinandergehen:

• E-Rechnung ist im rechtlichen Sinn eine Rechnung, die in einem strukturierten elektronischen Format ausgestellt, übermittelt und empfangen wird und eine elektronische Verarbeitung ermöglicht. Der Maßstab dafür ist die europäische Norm EN 16931.
• Sonstige Rechnung ist alles andere in elektronischer Form – ein einfaches PDF, ein Bild, eine eingescannte Papierrechnung. Diese Formate bleiben zulässig, aber nur innerhalb der gesetzlichen Übergangsfristen beziehungsweise für bestimmte Fallgruppen (etwa Kleinbetragsrechnungen).
• EN 16931 definiert das semantische Datenmodell und die Geschäftsregeln, die eine E-Rechnung erfüllen muss – unabhängig vom konkreten Dateiformat. XRechnung und ZUGFeRD sind zwei unterschiedliche technische Umsetzungen dieser Norm.

Diese Abgrenzung ist keine Formalie: Ob eine eingehende Datei rechtlich als E-Rechnung gilt, entscheidet auch, welche Prüf- und Aufbewahrungspflichten greifen – und ob sich der Inhalt überhaupt maschinell auslesen lässt oder ob zusätzlich eine Texterkennung nötig ist.

Welche Formate gibt es?

Für die E-Rechnungspflicht zwischen inländischen Unternehmen sind praktisch zwei Formate relevant, beide auf Basis von EN 16931:

Format	Aufbau	Typischer Einsatz	Maschinenlesbarkeit
XRechnung	Reines XML, kein visuelles Layout	Ursprünglich für die öffentliche Verwaltung entwickelt, zunehmend auch B2B	Vollständig strukturiert, aber ohne Werkzeug für Menschen kaum lesbar
ZUGFeRD (ab Profil COMFORT)	Hybrid: sichtbares PDF mit eingebettetem XML	B2B-Alltag, weil sowohl Mensch als auch Maschine dieselbe Datei nutzen können	Strukturierter Datenteil vollständig auslesbar, PDF-Ansicht bleibt für Menschen lesbar
Peppol BIS Billing	XML nach europäischem Peppol-Netzwerkstandard	Grenzüberschreitender Rechnungsversand über Peppol-Zugangspunkte	Vollständig strukturiert
PDF ohne eingebettete Struktur / Scan	Bild oder unstrukturierter Text	Bestand aus der Zeit vor der E-Rechnungspflicht, Auslandsrechnungen	Nur über Texterkennung (OCR) auswertbar, keine E-Rechnung im rechtlichen Sinn

Der KoSIT-Betreiber der XRechnung weist ausdrücklich darauf hin, dass sowohl UBL 2.1 als auch UN/CEFACT CII als zulässige Syntax für EN-16931-konforme Rechnungen gelten – XRechnung nutzt beide, ZUGFeRD setzt auf UN/CEFACT CII. Für die Praxis in einem KMU heißt das: Wenn ein automatisiertes System ZUGFeRD- und XRechnung-Dateien zuverlässig einlesen kann, deckt es den überwiegenden Teil der eingehenden E-Rechnungen ab. Reine PDF- und Scan-Rechnungen bleiben trotzdem im Postfach, solange nicht jeder Geschäftspartner umgestellt hat – ein Automatisierungsworkflow muss deshalb beide Wege gleichzeitig unterstützen.

Wie werden Rechnungen empfangen?

Ein Automatisierungsworkflow braucht zuerst einen definierten, überwachten Empfangskanal. In der Praxis sind das meist zwei bis drei parallele Wege:

E-Mail-Postfach als Anhang. Der häufigste Fall in KMU: Die E-Rechnung kommt als ZUGFeRD-PDF oder XRechnung-XML im Anhang einer E-Mail an ein zentrales Rechnungspostfach. Ein Workflow-Werkzeug wie n8n oder Power Automate überwacht dieses Postfach per Trigger, erkennt neue E-Mails mit passenden Anhangsformaten und stößt die Weiterverarbeitung an.

Peppol-Zugangspunkt. Für den europäischen und öffentlichen Bereich läuft der Versand zunehmend über das Peppol-Netzwerk: Der Aussteller schickt über seinen Zugangspunkt, der Empfänger holt über seinen eigenen Zugangspunkt ab. Das ist technisch sauberer als E-Mail, weil Format und Übertragungsweg standardisiert sind, erfordert aber eine eigene Peppol-Anbindung oder einen Dienstleister dafür.

Upload-Portal oder direkte Schnittstelle. Größere Lieferanten oder öffentliche Auftraggeber stellen teils eigene Portale (etwa die zentrale Rechnungseingangsplattform des Bundes) oder API-Schnittstellen bereit, über die Rechnungen abgeholt werden.

Unabhängig vom Kanal gilt derselbe erste Automatisierungsschritt: Der Workflow muss anhand von Dateiendung, MIME-Type und – bei PDFs – eingebetteten Metadaten erkennen, ob es sich um XRechnung, ZUGFeRD oder eine sonstige Datei handelt, und die Datei entsprechend weiterleiten. Strukturierte Formate gehen direkt in die Extraktion der XML-Felder, unstrukturierte PDFs oder Scans zusätzlich durch eine Texterkennungs-Engine. Genau diese Weiche – strukturiert versus unstrukturiert – ist der Punkt, an dem sich der Aufwand der weiteren Verarbeitung um ein Vielfaches unterscheidet: Bei einer sauberen XRechnung liest man Felder aus einem definierten Schema, bei einem Scan schätzt ein Erkennungsmodell, was dort wahrscheinlich steht.

Welche Validierungen sind nötig?

Bei strukturierten E-Rechnungen lassen sich drei Validierungsebenen unterscheiden, die in dieser Reihenfolge sinnvoll sind:

1. Schema-Validierung. Ist die XML-Datei überhaupt eine gültige EN-16931-Instanz? Fehlt ein Pflichtfeld, stimmt die Struktur nicht, bricht die Validierung hier ab – die Rechnung geht als technisch fehlerhaft zurück an den Aussteller, bevor überhaupt inhaltlich geprüft wird. Für XRechnung stellt der Betreiber KoSIT dafür offizielle Validierungsartefakte bereit.

2. Geschäftsregeln-Validierung. Stimmen die in EN 16931 definierten Business Rules – etwa: Ergibt Zwischensumme plus Steuerbetrag die Gesamtsumme? Ist der Steuersatz zulässig? Sind Pflichtangaben wie Rechnungsnummer, Ausstellungsdatum und Steuernummer vorhanden? Diese Prüfungen lassen sich bei strukturierten Formaten vollautomatisch durchführen, weil jedes Feld eindeutig adressierbar ist.

3. Fachliche Plausibilitätsprüfung. Diese Ebene ist formatunabhängig und betrifft den Geschäftskontext: Gibt es eine passende Bestellung oder einen Rahmenvertrag? Wurde diese Rechnungsnummer vom selben Lieferanten schon einmal eingereicht (Dublettenprüfung)? Liegt der Betrag in einem plausiblen Rahmen? Diese Prüfungen brauchen einen Abgleich mit den eigenen Systemen – ERP, Einkauf, Buchhaltung – und lassen sich nicht allein aus der Rechnungsdatei beantworten.

Der entscheidende Unterschied zur klassischen PDF-Rechnung: Bei XRechnung und ZUGFeRD sind Ebene 1 und 2 ohne OCR und ohne Interpretationsspielraum automatisierbar, weil die Daten bereits als benannte Felder vorliegen. Bei einer gescannten Rechnung hängt die Qualität dieser beiden Ebenen von der Güte der Texterkennung ab – ein grundsätzlicher Unterschied, den viele Projekte unterschätzen, wenn sie „E-Rechnung” und „digitalisierte Rechnung” gedanklich gleichsetzen.

Wie behandelt man Sonderfälle?

Ein Workflow, der nur den Normalfall abbildet, produziert in der Praxis ständig Fehlalarme oder – schlimmer – falsch verarbeitete Sonderfälle. Vier Gruppen kommen in KMU regelmäßig vor:

• Kleinbetragsrechnungen. Für Rechnungen bis zu einem geringen Bruttobetrag gelten vereinfachte Rechnungsangaben. Ein Workflow sollte diese Fälle erkennen und mit einer schlankeren Prüftiefe behandeln, statt die volle Validierungslogik anzuwenden.
• Rechnungen von Kleinunternehmer:innen. Wer die Kleinunternehmerregelung nutzt, stellt Rechnungen ohne Umsatzsteuerausweis – die Business-Rule-Prüfung zur Steuerlogik muss diesen Fall als gültig erkennen, nicht als Fehler.
• Auslandsrechnungen. Rechnungen von Lieferanten außerhalb Deutschlands folgen oft anderen Formatstandards oder liegen gar nicht strukturiert vor. Hier braucht der Workflow einen expliziten Ausnahmepfad mit OCR- oder manueller Prüfung, statt die deutsche EN-16931-Logik zu erzwingen.
• Fehlerhafte oder unlesbare E-Rechnungen. Wenn Schema- oder Geschäftsregel-Validierung scheitert, ist die Standardreaktion eine automatische Rückmeldung an den Aussteller mit der konkreten Fehlerursache – nicht eine manuelle Reparatur der Datei im eigenen Haus, die im Zweifel gegen die Formatvorgaben verstößt.

Eine gute Faustregel: Jeder Sonderfall braucht einen eigenen, benannten Pfad im Workflow – nicht, weil er häufig vorkommt, sondern weil ein unbehandelter Sonderfall im Zweifel entweder den ganzen Workflow blockiert oder, schlimmer, unbemerkt falsch durchläuft.

Wie erfolgt Archivierung?

Nach der Prüfung ist die Rechnung nicht „fertig”, sondern muss GoBD-konform archiviert werden. Drei Anforderungen sind dabei zentral:

Originalformat erhalten. Eine ZUGFeRD-Rechnung besteht aus PDF und eingebettetem XML – archiviert werden muss diese Kombination, nicht nur der visuelle PDF-Teil. Wird nur die PDF-Ansicht gespeichert und das XML verworfen, geht die maschinenlesbare Struktur verloren, die eigentlich der Zweck der Umstellung war.

Unveränderbarkeit. Einmal archivierte Rechnungen dürfen nicht unbemerkt änderbar sein. Korrekturen erfolgen als neue, nachvollziehbare Version, nicht als Überschreiben des Originals.

Maschinelle Auswertbarkeit über die gesamte Aufbewahrungsfrist. Nach § 14b UStG müssen empfangene Rechnungen acht Jahre aufbewahrt werden, gerechnet ab Ende des Kalenderjahres der Ausstellung. Bei elektronischer Aufbewahrung mit vollständigem Online-Zugriff dürfen die Daten laut Gesetz sogar im übrigen EU-Gebiet gespeichert werden – die Finanzbehörden müssen aber jederzeit online darauf zugreifen können.

Für die Automatisierung heißt das praktisch: Der Workflow braucht am Ende der Prüfkette einen Ablagepunkt (Dokumentenmanagementsystem, revisionssicheres Archiv oder eine entsprechend konfigurierte DATEV-/ERP-Anbindung), der Original-Dateiformat, Validierungsergebnis und – falls vorhanden – den Freigabestatus gemeinsam und unveränderbar speichert. Eine lose Ablage im Dateisystem erfüllt diese Anforderungen in aller Regel nicht.

Umsetzung: Wie geht man vor?

Für die technische Umsetzung stehen in KMU meist zwei Wege zur Auswahl, die sich in Aufwand, Kontrolle und Integrationstiefe unterscheiden. Die folgende Matrix ist meine eigene Einschätzung aus Projekten, keine Herstellerbewertung:

Kriterium	Low-Code-Plattform (z. B. Power Automate)	Selbst gehostete Workflow-Automatisierung (z. B. n8n)
Einstiegsaufwand	Niedrig, viele fertige Konnektoren für Microsoft-Umfeld (Genehmigungen, SharePoint, Dataverse)	Mittel, mehr Konfigurationsaufwand, dafür volle Kontrolle über Workflow-Logik
Passt gut, wenn …	Ihr bereits im Microsoft-365-Ökosystem arbeitet und Standard-Genehmigungsprozesse braucht	Ihr eigene XML-Validierung, Sonderfall-Logik oder mehrere externe Systeme flexibel verknüpfen wollt
Hosting/Datenkontrolle	Cloud-Dienst des Anbieters	Selbst hostbar, dadurch mehr Kontrolle über Datenverbleib
Grenzen	Tiefe XML-Schema-Validierung nach EN 16931 meist über Zusatzkomponenten oder externe Bibliotheken nötig	Erfordert eigene Wartung der Infrastruktur, kein Support-Vertrag „aus einer Hand”

Praktisches Vorgehen in vier Schritten, wie ich es in Projekten aufsetze:

1. Empfangskanal festlegen und Formaterkennung bauen. Postfach oder Peppol-Zugangspunkt anbinden, Weiche zwischen strukturierten Formaten und PDFs/Scans einrichten.
2. Schema- und Geschäftsregel-Validierung integrieren. Entweder über eine vorhandene Bibliothek beziehungsweise einen Validierungsdienst, der EN-16931-Regeln prüft, oder über einen spezialisierten Dienstleister – das selbst nachzubauen lohnt sich für die wenigsten KMU.
3. Plausibilitätsprüfung an die eigenen Systeme anbinden. Abgleich gegen Bestellungen, Dublettenprüfung, Schwellenwerte für Freigaben – meist über eine Schnittstelle zu ERP oder Buchhaltung.
4. Archivablage und Sonderfall-Pfade definieren, bevor der erste Produktivlauf startet. Wer diesen Schritt nachträglich einbaut, migriert im Zweifel bereits verarbeitete Rechnungen ein zweites Mal.

Ein Hinweis zu Kosten und Zeit, nur als grobe Bandbreite mit Annahmen: Ein schlanker Workflow für einen einzelnen Empfangskanal mit Standardvalidierung lässt sich in wenigen Wochen aufsetzen, sofern Postfach- oder Peppol-Anbindung, ERP-Schnittstelle und Freigabelogik bereits klar definiert sind. Sobald mehrere Empfangskanäle, individuelle Sonderfall-Regeln und eine tiefe ERP-Integration zusammenkommen, verlängert sich das spürbar – seriös beziffern lässt sich das erst nach einer kurzen Bestandsaufnahme der vorhandenen Systeme.

Risiken & Grenzen

• Formaterkennung ist kein Selbstläufer. Nicht jede eingehende Datei ist sauber gekennzeichnet. ZUGFeRD-PDFs ohne korrekt eingebettetes XML oder falsch benannte XRechnung-Dateien führen zu Fehlklassifikationen, wenn die Erkennung nicht robust genug geprüft wird.
• Automatisierte Validierung ersetzt keine rechtliche Prüfung. Schema- und Geschäftsregel-Validierung stellen die technische Konformität sicher, nicht automatisch die steuerliche Korrektheit im Einzelfall. Bei Unsicherheit gehört das Thema zur Steuerberatung.
• Übergangszeit bedeutet Doppelbetrieb. Solange nicht alle Geschäftspartner umgestellt haben, muss der Workflow parallel strukturierte E-Rechnungen und klassische PDFs verarbeiten – das erhöht die Komplexität gegenüber einer reinen „Alles ist XRechnung”-Lösung.
• Ohne Owner verfällt die Lösung. Formatspezifikationen wie XRechnung werden regelmäßig aktualisiert (neue Versionen, neue Business Rules). Ein Workflow ohne benannte Zuständigkeit für Pflege und Updates funktioniert nach der ersten Formatänderung nicht mehr zuverlässig.
• Legal-Hinweis (Stand Juli 2026, keine Rechtsberatung): Die konkreten Übergangsfristen für die Ausstellungspflicht von E-Rechnungen zwischen inländischen Unternehmen sind gestaffelt und hängen unter anderem vom Vorjahresumsatz ab. Für den aktuellen Stand und Ausnahmen gilt ausschließlich die jeweils aktuelle Fassung des BMF-Schreibens beziehungsweise der FAQ des Bundesministeriums der Finanzen – im Zweifel gehört die Einordnung zur Steuerberatung.

Checkliste: E-Rechnung automatisieren

1. Wir wissen, über welche Kanäle E-Rechnungen bei uns eingehen (E-Mail-Postfach, Peppol, Portal) – und überwachen jeden davon automatisiert.
2. Unser Workflow unterscheidet zuverlässig zwischen XRechnung, ZUGFeRD und sonstigen PDFs/Scans, bevor er in die Weiterverarbeitung geht.
3. Schema-Validierung nach EN 16931 läuft automatisiert, bevor eine Rechnung inhaltlich geprüft wird.
4. Geschäftsregeln (Summenlogik, Steuersätze, Pflichtfelder) werden maschinell geprüft, nicht nur stichprobenhaft von Menschen.
5. Eine fachliche Plausibilitätsprüfung gegen Bestellungen/Verträge und eine Dublettenprüfung sind angebunden.
6. Sonderfälle – Kleinbetragsrechnungen, Kleinunternehmer:innen, Auslandsrechnungen, fehlerhafte Dateien – haben jeweils einen definierten Pfad im Workflow.
7. Fehlerhafte E-Rechnungen lösen eine automatische, konkrete Rückmeldung an den Aussteller aus.
8. Die Archivablage speichert das Originalformat inklusive eingebettetem XML, unveränderbar, für die gesetzliche Aufbewahrungsfrist.
9. Es gibt eine benannte Zuständigkeit für Formatänderungen und regelmäßige Prüfung der Workflow-Logik.
10. Bei rechtlichen Detailfragen zu Fristen und Ausnahmen ziehen wir Steuerberatung oder die offizielle BMF-FAQ heran, statt uns auf Drittquellen zu verlassen.

Wenn ihr diesen Ablauf bei euch einordnen wollt, bevor ihr in ein Werkzeug investiert: Ein kostenloses Erstgespräch oder eine Einschätzung eures Backoffice-Ablaufs klärt in kurzer Zeit, wo der größte Hebel liegt – Empfang, Validierung oder Archivierung. Für den Kompetenzaufbau im Team rund um Automatisierungswerkzeuge bieten sich zudem gezielte Schulungen an.