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

Das Wichtigste in Kürze:

• Seit dem 1. Januar 2025 gilt die E-Rechnungspflicht für Umsätze zwischen inländischen Unternehmen.
• Relevant sind vor allem XRechnung (reines XML) und ZUGFeRD (PDF mit eingebettetem XML), beide auf Basis der europäischen Norm EN 16931.
• Der größte Hebel liegt nicht im Empfang, sondern in der Validierung der strukturierten Daten.
• Archiviert wird im Originalformat, unveränderbar, 8 Jahre lang nach § 14b UStG.

Problem und Zielgruppe

Drei Welten treffen aufeinander. Wer heute Eingangsrechnungen verarbeitet, bekommt das klassische PDF, die gescannte Papierrechnung und die strukturierte E-Rechnung als XML oder XML-in-PDF auf den Tisch. Die dritte Kategorie wird zum Regelfall.

Warum? Seit dem 1. Januar 2025 gilt die Pflicht zur E-Rechnung für Umsätze zwischen inländischen Unternehmen, mit gestaffelten Übergangsfristen für die Ausstellung. Für Empfänger:innen ändert sich damit 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 und zugleich eine schlechte Nachricht. Die gute: Strukturierte Formate lassen sich ohne Texterkennung maschinell auslesen, denn 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 wieder auf einem Schreibtisch. Dort tippt ein Mensch die Felder von Hand ab. Diesmal aus einer XML-Datei, die er ohne Werkzeug kaum lesen kann.

Das war nicht das Ziel.

Dieser Artikel richtet sich an Geschäftsführung, Operations, IT und Fachbereich in KMU, also an Teams, die Empfang, Prüfung und Weiterverarbeitung von E-Rechnungen automatisieren wollen. Der Fokus liegt bewusst auf dem, was an E-Rechnungen spezifisch ist: Formate, Empfangswege, Validierung, Sonderfälle und Archivierung. Die komplette Kette von der Erkennung bis zur Freigabe, 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

Drei Begriffe gehen im Alltag oft durcheinander. Eine saubere Trennung lohnt sich, bevor es um Formate und Workflows geht.

• E-Rechnung: im rechtlichen Sinn eine Rechnung, die in einem strukturierten elektronischen Format ausgestellt, übermittelt und empfangen wird und sich elektronisch verarbeiten lässt. Der Maßstab dafür ist die europäische Norm EN 16931.
• Sonstige Rechnung: alles andere in elektronischer Form, also ein einfaches PDF, ein Bild oder eine gescannte Papierrechnung. Solche Formate bleiben nur innerhalb der gesetzlichen Übergangsfristen oder für bestimmte Fallgruppen zulässig, etwa Kleinbetragsrechnungen.
• EN 16931: definiert das semantische Datenmodell und die Geschäftsregeln einer E-Rechnung, unabhängig vom konkreten Dateiformat. XRechnung und ZUGFeRD sind zwei technische Umsetzungen dieser Norm.

Diese Abgrenzung ist keine Formalie. Ob eine eingehende Datei rechtlich als E-Rechnung gilt, entscheidet über die geltenden Prüf- und Aufbewahrungspflichten. Davon hängt auch ab, ob sich der Inhalt direkt 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. Daneben tauchen im Alltag zwei weitere Kategorien auf.

• XRechnung: reines XML ohne visuelles Layout. Ursprünglich für die öffentliche Verwaltung entwickelt, zunehmend auch im B2B-Einsatz. Vollständig strukturiert, für Menschen ohne Werkzeug aber kaum lesbar.

• ZUGFeRD (ab Profil COMFORT): hybrid aufgebaut, ein sichtbares PDF mit eingebettetem XML. Im B2B-Alltag verbreitet, weil Mensch und Maschine dieselbe Datei nutzen können. Der strukturierte Datenteil ist vollständig auslesbar, die PDF-Ansicht bleibt für Menschen lesbar.

• Peppol BIS Billing: XML nach dem europäischen Peppol-Netzwerkstandard, vollständig strukturiert. Typisch für den grenzüberschreitenden Rechnungsversand über Peppol-Zugangspunkte.

• PDF ohne eingebettete Struktur oder Scan: Bestand aus der Zeit vor der E-Rechnungspflicht sowie viele Auslandsrechnungen. Nur über Texterkennung (OCR) auswertbar und keine E-Rechnung im rechtlichen Sinn.

Die KoSIT als Betreiberin der XRechnung weist darauf hin: Sowohl UBL 2.1 als auch UN/CEFACT CII gelten als zulässige Syntax für EN-16931-konforme Rechnungen. XRechnung nutzt beide Syntaxen, ZUGFeRD setzt auf UN/CEFACT CII. So weit die Norm.

Für die Praxis in einem KMU heißt das: Ein System, das ZUGFeRD und XRechnung zuverlässig einliest, deckt den Großteil der eingehenden E-Rechnungen ab. Reine PDF- und Scan-Rechnungen bleiben trotzdem im Postfach, solange nicht jeder Geschäftspartner umgestellt hat. Der Workflow muss deshalb beide Wege gleichzeitig unterstützen.

Wie werden Rechnungen empfangen?

Ein Workflow braucht zuerst einen definierten, überwachten Empfangskanal. In der Praxis sind das meist 2 bis 3 parallele Wege.

E-Mail-Postfach als Anhang. Der häufigste Fall in KMU: Die E-Rechnung kommt als ZUGFeRD-PDF oder XRechnung-XML an ein zentrales Rechnungspostfach. Ein Workflow-Werkzeug wie n8n oder Power Automate überwacht dieses Postfach per Trigger, erkennt neue E-Mails mit passenden Anhängen 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 den eigenen Zugangspunkt ab. Das ist technisch sauberer als E-Mail, weil Format und Übertragungsweg standardisiert sind. Dafür braucht es eine eigene Peppol-Anbindung oder einen Dienstleister.

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

Unabhängig vom Kanal gilt derselbe erste Schritt: Der Workflow erkennt anhand von Dateiendung, MIME-Type und eingebetteten Metadaten, ob XRechnung, ZUGFeRD oder eine sonstige Datei vorliegt. Strukturierte Formate gehen direkt in die Extraktion der XML-Felder. Unstrukturierte PDFs oder Scans durchlaufen zusätzlich eine Texterkennung.

Genau diese Weiche entscheidet über den Aufwand der weiteren Verarbeitung. Der Unterschied ist groß. 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 3 Validierungsebenen unterscheiden. Sinnvoll ist genau diese Reihenfolge.

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

2. Geschäftsregeln-Validierung. Stimmen die in EN 16931 definierten Business Rules? Ergibt die Zwischensumme plus Steuerbetrag die Gesamtsumme, ist der Steuersatz zulässig, sind Rechnungsnummer, Ausstellungsdatum und Steuernummer vorhanden? Diese Prüfungen laufen bei strukturierten Formaten vollautomatisch, weil jedes Feld eindeutig adressierbar ist.

3. Fachliche Plausibilitätsprüfung. Diese Ebene betrifft den Geschäftskontext, unabhängig vom Format. Gibt es eine passende Bestellung, ist die Rechnungsnummer eine Dublette, liegt der Betrag in einem plausiblen Rahmen? Solche Prüfungen brauchen einen Abgleich mit den eigenen Systemen, also ERP, Einkauf und Buchhaltung. Aus der Rechnungsdatei allein lassen sie sich nicht beantworten.

Der entscheidende Unterschied zur klassischen PDF-Rechnung: Bei XRechnung und ZUGFeRD sind Ebene 1 und 2 ohne OCR automatisierbar. Die Daten liegen bereits als benannte Felder vor. Bei einer gescannten Rechnung hängt die Qualität dieser Ebenen dagegen von der Güte der Texterkennung ab. Genau das unterschätzen viele Projekte, wenn sie „E-Rechnung“ und „digitalisierte Rechnung“ gedanklich gleichsetzen.

Wie behandelt man Sonderfälle?

Ein Workflow, der nur den Normalfall abbildet, produziert ständig Fehlalarme oder 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. Scheitert die Schema- oder Geschäftsregel-Validierung, ist die Standardreaktion eine automatische Rückmeldung an den Aussteller mit der konkreten Fehlerursache. Eine manuelle Reparatur der Datei im eigenen Haus verstößt im Zweifel gegen die Formatvorgaben.

Eine gute Faustregel: Jeder Sonderfall braucht einen eigenen, benannten Pfad im Workflow. Nicht, weil er häufig vorkommt. Sondern weil ein unbehandelter Sonderfall 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. Genau diese Struktur war aber der Zweck der Umstellung.

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 volle Frist. Nach § 14b UStG müssen empfangene Rechnungen 8 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 definierten Ablagepunkt. Das kann ein Dokumentenmanagementsystem sein, ein revisionssicheres Archiv oder eine passend konfigurierte DATEV- oder ERP-Anbindung. Dort werden Original-Dateiformat, Validierungsergebnis und, falls vorhanden, der Freigabestatus gemeinsam und unveränderbar gespeichert. 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. Beide tragen. Sie unterscheiden sich in Aufwand, Kontrolle und Integrationstiefe. Die folgende Einordnung ist meine eigene Einschätzung aus Projekten, keine Herstellerbewertung.

Low-Code-Plattform, zum Beispiel Power Automate. Der Einstiegsaufwand ist niedrig, es gibt viele fertige Konnektoren für das Microsoft-Umfeld (Genehmigungen, SharePoint, Dataverse). Das passt gut, wenn ihr bereits im Microsoft-365-Ökosystem arbeitet, Standard-Genehmigungsprozesse braucht und das Hosting als Cloud-Dienst des Anbieters für euch passt. Die Grenze: Tiefe XML-Schema-Validierung nach EN 16931 braucht meist Zusatzkomponenten oder externe Bibliotheken.

Selbst gehostete Workflow-Automatisierung, zum Beispiel n8n. Der Einstieg kostet mehr Konfigurationsaufwand, dafür behaltet ihr volle Kontrolle über die Workflow-Logik, was gut passt, wenn ihr eigene XML-Validierung, Sonderfall-Logik oder mehrere externe Systeme flexibel verknüpfen wollt. n8n ist selbst hostbar, dadurch habt ihr mehr Kontrolle über den Datenverbleib. Die Grenze: Ihr wartet die Infrastruktur selbst, einen Support-Vertrag „aus einer Hand“ gibt es nicht.

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

1. Empfangskanal festlegen und Formaterkennung bauen. Postfach oder Peppol-Zugangspunkt anbinden, dann die Weiche zwischen strukturierten Formaten und PDFs oder Scans einrichten.

2. Schema- und Geschäftsregeln-Validierung integrieren. Nutzt eine vorhandene Bibliothek, einen Validierungsdienst für EN-16931-Regeln oder 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 und 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.

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

Risiken & Grenzen

Diese 5 Punkte solltet ihr von Anfang an einplanen.

• 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äftsregeln-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, mit neuen Versionen und neuen 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 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 oder 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 oder Scans, bevor er sie weiterverarbeitet.

3. Die Schema-Validierung nach EN 16931 läuft automatisiert, bevor eine Rechnung inhaltlich geprüft wird.

4. Geschäftsregeln wie Summenlogik, Steuersätze und Pflichtfelder werden maschinell geprüft, nicht nur stichprobenhaft von Menschen.

5. Eine fachliche Plausibilitätsprüfung gegen Bestellungen und Verträge sowie eine Dublettenprüfung sind angebunden.

6. Sonderfälle wie Kleinbetragsrechnungen, Kleinunternehmer:innen, Auslandsrechnungen und 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 eine regelmäßige Prüfung der Workflow-Logik.

10. Bei rechtlichen Detailfragen zu Fristen und Ausnahmen ziehen wir Steuerberatung oder die offizielle BMF-FAQ heran.

Ihr wollt diesen Ablauf bei euch einordnen, 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 bieten sich zudem gezielte Schulungen an.