Rechnungseingang automatisieren: vom Postfach bis zur Buchung im ERP

Was bedeutet es, den Rechnungseingang zu automatisieren?

Ein automatisierter Rechnungseingang übernimmt fünf Schritte, die heute oft von Hand laufen: empfangen, auslesen, prüfen, freigeben und an das ERP übergeben. Ihr ERP bleibt das führende System. Die Automatisierung arbeitet über dessen Schnittstellen und legt nur die Fälle vor, die eine Entscheidung brauchen.

Der wichtigste Unterschied liegt im Eingangsformat. Eine E-Rechnung bringt ihre Daten strukturiert mit, sie muss nicht ausgelesen, sondern nur gelesen und geprüft werden. Ein PDF oder ein Scan dagegen muss erst in Daten übersetzt werden, und jedes ausgelesene Feld ist eine Annahme, bis es geprüft ist. Bis mindestens Ende 2027 kommen beide Arten parallel an, deshalb braucht ein tragfähiger Eingang beide Wege.

Automatisierung heißt dabei nicht, dass Rechnungen ungesehen bezahlt werden. Das Ziel ist ein Eingang, der jede Rechnung nach festen Regeln prüft, die unauffälligen durchlaufen lässt und jede Abweichung mit Begründung an die richtige Person gibt.

• Empfangen: Postfach, Portal, Upload, EDI, Papier per Scan
• Lesen oder auslesen: XML direkt, PDF und Scan mit Texterkennung
• Prüfen: Format, Pflichtangaben, Rechnerik, Dubletten, Bankdaten, Bestellung, Wareneingang
• Freigeben: nach Betrag, Kostenstelle und Art der Abweichung
• Übergeben: als Beleg oder Buchungsvorschlag in SAP, Business Central, DATEV oder Abacus

Welche E-Rechnungspflichten gelten seit 2025 und was ändert sich 2027 und 2028?

Seit dem 1. Januar 2025 müssen inländische Unternehmer die technischen Voraussetzungen schaffen, um E-Rechnungen zu empfangen, das gilt auch für Kleinunternehmer. Für den Versand gelten Übergangsregeln nach § 27 Abs. 38 UStG, die Pflicht zur E-Rechnung im inländischen B2B folgt aus § 14 Abs. 2 UStG.

Eine E-Rechnung ist nach § 14 Abs. 1 UStG eine Rechnung in einem strukturierten elektronischen Format, das eine elektronische Verarbeitung ermöglicht. Ein PDF per Mail ist keine E-Rechnung, sondern eine sonstige Rechnung. Für den Empfang per E-Mail ist laut BMF kein eigenes Postfach nur für E-Rechnungen nötig. Wer E-Rechnungen technisch nicht empfangen kann oder ablehnt, hat keinen Anspruch darauf, stattdessen eine sonstige Rechnung zu bekommen.

Für Ihren Eingang heißt das: Bis Ende 2027 kommen Papier, PDF, XRechnung, ZUGFeRD und EDI gemischt an. Erst für Umsätze ab 2028 wird die strukturierte E-Rechnung im inländischen B2B zur Regel.

Rechtsstand 5. November 2026 nach Gesetzestext und BMF-Schreiben vom 15. Oktober 2025. Für Ihren konkreten Fall, etwa Leistungen an Betriebsstätten im Ausland, stimmen Sie die Einordnung mit Ihrer Steuerberatung ab.

Welche Formate muss ein automatisierter Rechnungseingang lesen?

Ein automatisierter Rechnungseingang muss mindestens XRechnung in beiden Syntaxen und ZUGFeRD lesen, dazu PDF und Scan für sonstige Rechnungen. Laut BMF erfüllen die Formate XRechnung und, unter bestimmten Voraussetzungen, ZUGFeRD die Anforderungen an eine E-Rechnung nach der europäischen Norm EN 16931. Auch andere Formate nach dieser Norm sind zulässig, welches verwendet wird, entscheiden die Vertragsparteien.

XRechnung ist ein rein strukturiertes XML-Format, das die KoSIT im Auftrag des IT-Planungsrats betreibt. Es gibt sie in zwei Syntaxen, UBL 2.1 und UN/CEFACT CII. Ein Leser, der nur eine Syntax kennt, lässt die andere still liegen. ZUGFeRD ist ein hybrides Format: ein PDF mit eingebetteter XML-Datei. Factur-X und ZUGFeRD sind laut dem französischen Forum FNFE-MPE technisch identisch, aktuell ist ZUGFeRD 2.5.2 vom 4. August 2026.

Bei hybriden Rechnungen zählt der strukturierte Teil. Weicht das PDF inhaltlich vom XML ab, etwa durch einen anderen Steuerbetrag, ist ein Vorsteuerabzug laut BMF nur aus dem strukturierten Teil möglich, und das abweichende Bild kann eine weitere Rechnung darstellen. Ein automatisierter Eingang vergleicht deshalb Bild und Daten, statt nur das PDF anzuzeigen.

Microsoft beschreibt für die deutsche Lokalisierung von Business Central ab Version 26.3 die Formate XRechnung (nur UBL), Peppol BIS 3 und ZUGFeRD. Eine XRechnung in CII-Syntax braucht dort also einen eigenen Weg.

Welche Prüfungen sollte ein automatisierter Rechnungseingang durchführen?

Ein automatisierter Rechnungseingang sollte jede Rechnung in einer festen Reihenfolge prüfen: Format, Pflichtangaben, Rechnerik, Dublette, Lieferant und Bankverbindung, dann Bestellung und Wareneingang. Das BMF unterscheidet drei Fehlerarten. Formatfehler machen aus der Datei eine sonstige Rechnung. Geschäftsregelfehler betreffen logische Abhängigkeiten der Daten. Inhaltsfehler, also Verstöße gegen die Pflichtangaben nach §§ 14 Abs. 4 und 14a UStG, machen die Rechnung nicht ordnungsmäßig.

Eine erfolgreiche Validierung ist laut BMF eine Hilfe, aber kein Ersatz für die Prüfpflicht des Empfängers: Ein falscher Steuersatz kann formal fehlerfrei durch jede Validierung laufen. Das BMF empfiehlt, den Validierungsbericht aufzubewahren. Ein fehlendes Feld „BT-10 Buyer reference“ ist dagegen umsatzsteuerlich unbeachtlich, auch wenn ein Validator es als Fehler meldet.

Besonders ernst ist die geänderte Bankverbindung. Das Landeskriminalamt Nordrhein-Westfalen beschreibt die Masche so: Täter nehmen echte Rechnungen mit korrekten Daten und Summen als Vorlage und setzen eine angeblich neue Kontoverbindung ein. Betroffen sind vor allem Unternehmen, Organisationen und Verwaltungen. Das LKA rät, Änderungen der Bankverbindung beim Absender über einen anderen Kommunikationskanal zu bestätigen. Ein automatisierter Eingang macht daraus eine harte Regel.

Wie funktionieren 2-Wege-Abgleich, 3-Wege-Abgleich und Toleranzen?

Der 2-Wege-Abgleich vergleicht die Rechnung mit der Bestellung, der 3-Wege-Abgleich zusätzlich mit dem gebuchten Wareneingang. Der 2-Wege-Abgleich passt für Leistungen ohne Wareneingang, der 3-Wege-Abgleich für Material und Handelsware. Toleranzen legen fest, welche Abweichung ohne Menschen durchlaufen darf.

SAP S/4HANA zeigt die Logik gut nachvollziehbar: Das System prüft jede Rechnungsposition gegen Bestellung bzw. Wareneingang, die Arten von Abweichungen sind über Toleranzschlüssel definiert, die Grenzen gelten je Buchungskreis. Bei der Mengenabweichung (DQ) rechnet SAP Bestellnettopreis mal Rechnungsmenge abzüglich der noch nicht berechneten gelieferten Menge. Dadurch bekommen kleine Positionen relativ viel Spielraum und große Positionen wenig. Wird eine obere Grenze überschritten, sperrt das System die Rechnung beim Buchen zur Zahlung, ausgenommen die Schlüssel BD und VP, und sie muss in einem gesonderten Schritt freigegeben werden.

Microsoft Dynamics 365 Business Central ist im Standard strenger: Beim Abgleich einer E-Rechnung mit Bestellzeilen passen nur Zeilen mit gleichem Gesamtbetrag aus Einkaufspreis und Zeilenrabatt. Eine Toleranz wird im Feld „E-Document Matching Difference %“ der Einkaufs- und Kreditoren-Einrichtung gesetzt. Rechnungszeilen, die nicht auf der Bestellung stehen, verhindern das Buchen, weil eine eingehende Rechnung nicht teilweise gebucht werden kann.

• Prozent und absoluten Betrag kombinieren: Ein reiner Prozentwert lässt bei großen Positionen zu viel durch, ein reiner Betrag blockiert kleine Positionen unnötig.
• Teil-, Abschlags- und Schlussrechnungen: Bereits berechnete Mengen immer mitzählen, sonst läuft eine Nachberechnung als „wie bestellt“ durch.
• Rechnung vor Wareneingang: In SAP sperrt das System eine solche Rechnung, wenn für den Buchungskreis der Schlüssel DW nicht gepflegt ist. Das ist oft gewollt, sollte aber bewusst entschieden sein.
• Bestellnummer fehlt im Feld: Sie steht oft nur im Freitext, im Mailtext oder im PDF. Gegen offene Bestellungen des Lieferanten suchen, nicht per Muster raten.
• Fracht und Nebenkosten: In SAP wird die Mengenabweichung auch bei geplanten Bezugsnebenkosten geprüft. Ungeplante Nebenkosten brauchen eine eigene Regel.
• Kleindifferenzen: SAP kann Salden unter einer absoluten Grenze automatisch als Aufwand oder Ertrag ausbuchen (Schlüssel BD). Die Grenze gehört in die Verfahrensdokumentation.
• Keine Prüfung ist keine Toleranz: Stehen in SAP alle Grenzen eines Schlüssels auf „Nicht prüfen“, akzeptiert das System jede Abweichung. Das sollte nie unbemerkt so eingestellt sein.

Wie lässt sich die Freigabe nach Betrag und Kostenstelle regeln?

Die Freigabe wird über eine Matrix geregelt, die Betrag, Kostenstelle und Art der Abweichung kombiniert. Eine Rechnung mit Bestellbezug, die alle Prüfungen besteht, braucht in vielen Abläufen keine zweite inhaltliche Freigabe mehr, denn die Entscheidung fiel bereits mit der Bestellung. Rechnungen ohne Bestellbezug gehen an die Verantwortlichen der Kostenstelle, über festgelegten Wertgrenzen zusätzlich an eine zweite Person.

Nach den GoBD muss ein Unternehmen Kontrollen einrichten, ausüben und protokollieren, und die Beschreibung dieses internen Kontrollsystems ist Teil der Verfahrensdokumentation. Die Freigaberegeln gehören deshalb nicht nur in die Software, sondern auch schriftlich in die Verfahrensdokumentation, mit Gültigkeitsdatum. Die Wertgrenzen legen Sie selbst fest, sie hängen von Ihrer Organisation ab.

Was verlangen die GoBD von einem automatisierten Rechnungseingang?

Die GoBD verlangen, dass eingehende Rechnungen im empfangenen Format unveränderbar aufbewahrt werden und dass das Verfahren in einer Verfahrensdokumentation nachvollziehbar beschrieben ist. Grundlage ist das BMF-Schreiben vom 28. November 2019, zuletzt geändert am 14. Juli 2025 wegen der E-Rechnung.

Bei E-Rechnungen genügt es nach der Änderung vom 14. Juli 2025, den strukturierten Teil aufzubewahren. Den PDF-Teil einer ZUGFeRD-Rechnung müssen Sie nur zusätzlich aufbewahren, wenn er steuerlich bedeutsame zusätzliche oder abweichende Angaben enthält, etwa Buchungsvermerke. Die XML-Datei darf nicht durch eine Umwandlung, zum Beispiel in TIFF, verloren gehen. Werden Bilder per Texterkennung angereichert, sind die gewonnenen Informationen nach Verifikation und Korrektur ebenfalls aufzubewahren.

Für die Automatisierung sind zwei Randziffern besonders wichtig. Nach Rz. 110 erfüllt die Ablage in einem Dateisystem die Unveränderbarkeit regelmäßig nicht, wenn keine zusätzlichen Maßnahmen getroffen werden. Nach Rz. 111 sind auch Änderungen an Einstellungen und an der Parametrisierung der Software aufzuzeichnen. Wer also eine Toleranz, eine Freigabegrenze oder eine Prüfregel ändert, muss das protokollieren.

Die Verfahrensdokumentation beschreibt nach Rz. 151 bis 154 Inhalt, Aufbau, Ablauf und Ergebnisse des Verfahrens, in der Regel mit allgemeiner Beschreibung, Anwender-, System- und Betriebsdokumentation. Sie muss dem tatsächlich eingesetzten Verfahren entsprechen, auch in der Programmversion, und Änderungen müssen versioniert nachvollziehbar sein. Umsatzsteuerlich gilt zusätzlich die Aufbewahrung von acht Jahren nach § 14b Abs. 1 UStG.

Das BMF stellt klar, dass eine Archivierung außerhalb eines GoBD-konformen Systems allein noch kein umsatzsteuerlicher Verstoß ist. Für andere Zwecke gelten die GoBD trotzdem. Den Aufbewahrungsort und die Fristen stimmen Sie mit Ihrer Steuerberatung ab.

Wie läuft die Übergabe an SAP S/4HANA, Business Central, DATEV und Abacus?

Die Übergabe hängt davon ab, was das Zielsystem selbst prüft und in welcher Form es Belege annimmt. Die Tabelle zeigt, was die Hersteller dokumentieren und wo eine vorgeschaltete Automatisierung ansetzt. Wir arbeiten herstellerunabhängig mit den Systemen, die bei Ihnen laufen.

Für SAP S/4HANA ist die Rechnungsprüfung mit Toleranzschlüsseln der Kern: Eine vorgeschaltete Prüfung findet Lieferant und Bestellnummer, sortiert Klärfälle vor und übergibt saubere Belege, die SAP dann mit den eigenen Toleranzen prüft. An Microsoft Dynamics 365 Business Central nimmt das E-Document-Framework E-Rechnungen an, ordnet den Lieferanten in fester Reihenfolge über GLN, USt-IdNr., Teilnehmerkennung und Name zu und erkennt Dubletten über Lieferant, externe Belegnummer und Datum. Die Zeilenzuordnung per Copilot wird laut Microsoft abgekündigt und durch den Payables Agent ersetzt.

Für DATEV wird ein Buchungsstapel im DATEV-Format erzeugt, laut DATEV am besten eine Datei je Buchungsperiode. Das Belegfeld 1 dient als Schlüssel für den Ausgleich offener Posten, die Postensperre schließt eine Rechnung aus dem Zahlungsvorschlag aus, der Beleglink verweist auf den Beleg. Das Feld Festschreibung verdient Aufmerksamkeit: Bleibt es leer, wird automatisch festgeschrieben, steht in einem Buchungssatz eine 1, wird der ganze Stapel nach dem Import festgeschrieben. Für Abacus beschreibt der Hersteller Belegerfassung, strukturierten Rechnungsempfang und eine Belegfreigabe mit individuellen Workflows in MyAbacus. Als Schnittstellen dokumentiert der Abacus API Hub REST-APIs, ODBC/JDBC und AbaConnect.

Wann reicht Standard-Software und wann lohnt Automatisierung am ERP?

Standard-Software reicht, wenn ein ERP alle Rechnungen annimmt, die Formate abdeckt und Ihre Prüfregeln mit Bordmitteln abbildet. Automatisierung am ERP lohnt sich, wenn Kanäle, Gesellschaften oder Prüfregeln über das hinausgehen, was ein einzelnes System von Haus aus kann. Die Tabelle hilft bei der Einordnung.

Ablauf in 6 Schritten

1. 01
   Prozessgespräch

   Wir gehen Ihren heutigen Rechnungseingang durch: Kanäle, Formate, Gesellschaften, Zielsysteme, Freigaben und die häufigsten Klärfälle.

2. 02
   Prüfregeln festlegen

   Gemeinsam mit Ihrem Team und Ihrer Steuerberatung legen wir Reihenfolge, Toleranzen, Dublettenschlüssel, Bankdatenregel und Freigabematrix schriftlich fest.

3. 03
   Automatisierungs-Sprint

   Ein Ablauf entsteht als Prototyp auf Ihren echten Belegen in Ihrer Testumgebung, angebunden an Ihr ERP über dessen Schnittstellen.

4. 04
   Abnahme an echten Fällen

   Ihr Team prüft die Ergebnisse gegen bekannte Rechnungen, auch gegen absichtlich fehlerhafte. Jede Abweichung muss als Klärfall auftauchen.

5. 05
   Verfahrensdokumentation

   Prüfregeln, Freigaben, Aufbewahrung und Protokollierung werden beschrieben und versioniert, passend zur eingesetzten Programmversion.

6. 06
   Betrieb

   Der Eingang läuft on-premise, in einer Private Cloud in Deutschland oder in einer EU-Region der Public Cloud. Regeländerungen werden protokolliert.

Häufige Fragen