E‑Rechnung aus dem Altsystem

Ab dem 1. Januar 2027 müssen Unternehmen, deren Vorjahresumsatz 800.000 € überstieg, Rechnungen an andere Unternehmen im Inland als E-Rechnung ausstellen; ab 2028 gilt das für alle.^[1] Viele von ihnen fakturieren aus einem System, das der Hersteller nicht mehr weiterentwickelt: Für Dynamics NAV 2018 endet der erweiterte Support am 11. Januar 2028,^[2] für SAP ERP 6.0 die Standardwartung Ende 2027.^[3] Die übliche Antwort heißt Migration. Dieser Leitfaden beantwortet eine andere Frage: Die Rechnungsdaten liegen längst im System — wie kommen sie heraus?

Warum das Format das kleinere Problem ist

Eine E-Rechnung im Sinne des Gesetzes ist eine Rechnung in einem strukturierten elektronischen Format nach der europäischen Norm EN 16931 — in Deutschland meist XRechnung oder ZUGFeRD ab Version 2.0.1, ohne die Profile MINIMUM und BASIC-WL.^[4] Das klingt nach einem Softwareproblem, und so wird es meistens auch verkauft.

Tatsächlich ist der Inhalt einer E-Rechnung fast vollständig durch das Umsatzsteuergesetz vorgegeben, und zwar nicht erst seit gestern. § 14 Abs. 4 UStG verlangt Namen und Anschrift beider Parteien, Steuernummer oder USt-IdNr., Ausstellungsdatum, Rechnungsnummer, Menge und Art der Leistung, den Leistungszeitpunkt, das nach Steuersätzen aufgeschlüsselte Entgelt, Steuersatz und Steuerbetrag.^[5] Jedes System, das eine ordnungsgemäße Rechnung druckt, hat diese Angaben.

Die E-Rechnung verlangt sie nur in anderer Form: nicht als Seite, sondern als Datensatz mit festen Feldern. Die Rechnungsnummer steht im Feld BT-1, die Nettosumme in BT-109, jede Mengeneinheit als Code aus einer internationalen Liste. Das ist eine Übersetzung, kein neues Wissen — und für eine Übersetzung muss man das Quellsystem nicht umbauen. Man muss nur an seine Daten kommen.

Die vier Wege aus dem Altsystem

Ein ERP gibt Rechnungsdaten auf vier Arten nach außen, und fast jedes Altsystem beherrscht mindestens eine davon. Sie unterscheiden sich darin, was sie am System voraussetzen — und darin, wie sie scheitern.

1. Die Exportliste

Jedes ERP kann Listen ausgeben — als CSV, als Excel-Datei, als Text mit Trennzeichen. Meist gibt es bereits einen Bericht über gebuchte Rechnungen, oft mit einer Zeile je Position. Das ist der häufigste Weg und in der Regel der einfachste.

Voraussetzung: Der Bericht enthält alle nötigen Angaben. Fehlt eine Spalte, ist das eine Anpassung am Bericht, nicht an der Buchungslogik. Typische Fallen: der Zeichensatz (viele Altsysteme schreiben Windows-1252, nicht UTF-8), das Dezimalkomma, Vorspann- und Summenzeilen — und ein Trennzeichen im Freitext. Steht in einer Positionsbezeichnung „Consulting, on site“ und das Komma trennt die Spalten, verschiebt sich alles dahinter um eine Spalte. Der Beleg bleibt formal gültig und trägt den Steuersatz im Preisfeld. Das Beispiel ist nicht ausgedacht: Es ist beim Bau unserer eigenen Anbindung genau so aufgetreten.

2. Der Druckstrom

Wo sich kein Export mehr einrichten lässt — weil niemand mehr eine Entwicklungsumgebung für das System hat oder der Wartungsvertrag ausgelaufen ist —, bleibt fast immer eines: Das System kann die Rechnung drucken. Viele Altsysteme können diesen Ausdruck statt auf Papier in eine Datei schreiben, gerade solche mit textbasierten Formularen. Daraus lässt sich die Rechnung zurücklesen.

Das funktioniert, weil ein Rechnungsformular ein festes Raster hat. Die Rechnungsnummer steht in der Zeile, die mit „Rechnung Nr.“ beginnt, der Betrag einer Position ab einer bestimmten Spalte. Kopfdaten wie Käufer und Datum stehen einmal oben und gelten für alle Positionen darunter; die Summen stehen darunter, und eine mehrseitige Rechnung wiederholt den Kopf auf jeder Seite.

Voraussetzung: ein Rechnungsformular, das sich als Text abgreifen lässt. Am System selbst ändert sich nichts. Die Falle: Ändert jemand das Formular, verrutscht das Raster. Eine Positionszeile, die nicht mehr erkannt wird, ist dann nicht falsch, sondern weg — und die Rechnung ist trotzdem formal gültig, nur um eine Position ärmer. Wie man das bemerkt, steht weiter unten; es ist die wichtigste Frage dieses Wegs.

3. Die Datenbanksicht

Der sauberste Weg führt direkt an die Tabellen: eine Sicht (View) in der Datenbank des ERP, die gebuchte Rechnungen mit ihren Positionen liefert — bei Dynamics NAV etwa aus den Tabellen der gebuchten Verkaufsrechnungen (Sales Invoice Header und Sales Invoice Line). Die Werte kommen typisiert an: kein Zeichensatz, kein Dezimalkomma, kein Raster.

Voraussetzung: lesender Zugriff auf die Datenbank und jemand, der das Schema kennt. Deshalb ist es der seltenste Weg. Viele IT-Abteilungen geben diesen Zugriff aus gutem Grund nicht her, und bei gehosteten Systemen ist er oft gar nicht vorgesehen. Das Kennwort gehört dabei nicht in die Konfiguration, sondern in die Umgebung des Dienstes, der liest. Die Falle: Eine Sicht liefert, was in den Tabellen steht, nicht, was der Kunde als Rechnung bekommen hat. Gutschriften etwa liegen in NAV in eigenen Tabellen; welche Datensätze als Rechnung hinausgehen, muss die Sicht ausdrücklich festlegen.

4. Die Schnittstelle des Herstellers — bei SAP das IDoc

Manche Systeme bringen einen Ausgang für elektronische Belege bereits mit. Bei SAP ist das das IDoc: ECC 6.0 ebenso wie S/4HANA kann eine Faktura als INVOIC02 über einen Dateiport ausgeben. Eingerichtet wird das mit drei Transaktionen — WE21 für den Port, WE20 für die Partnervereinbarung, NACE für die Nachrichtenart der Faktura. Danach liegt zu jeder freigegebenen Rechnung eine Datei im Verzeichnis. Das ist Customizing im Standard, kein neues Produkt. Einzelheiten und die Lagen, in denen SAP DRC die bessere Wahl ist, stehen auf der Seite SAP ohne BTP: der IDoc-Weg.

Die Falle: Der Aufbau eines INVOIC02 liegt fest, die Belegung der Qualifier nicht. Welcher Code das Rechnungsdatum trägt und welcher die Fälligkeit, welcher die Netto- und welcher die Bruttosumme, hängt am Customizing des einzelnen Systems — und die öffentlichen Quellen widersprechen sich dabei. Abgelesen wird es am echten Beleg (WE02) und in der IDoc-Dokumentation des Systems (WE60), nicht aus einer Tabelle im Internet.

Und der überwachte Ordner?

Oft genannt, aber kein fünfter Weg. Ein überwachter Ordner — auf einem Netzlaufwerk oder per SFTP — ist die Art, wie Export, Druckdatei oder IDoc zur Verarbeitung gelangen; er erspart, dass jemand Dateien von Hand verschiebt. Wichtig ist daran eine Kleinigkeit: Verarbeitete Dateien werden verschoben, nicht gelöscht. Ohne die Quelldatei lässt sich ein Lauf nicht wiederholen, und genau das braucht man am Tag der ersten Panne.

Welcher Weg für welches System

Die Reihenfolge der Wahl ist einfach: zuerst, was das System ohne Änderung schon ausgibt; bei gleicher Verfügbarkeit der Weg mit den typisierten Daten. Ein Export, der bereits läuft, schlägt eine Datenbanksicht, die erst genehmigt werden muss. Der Druckstrom ist der Weg für Systeme, an denen nichts mehr geändert werden kann oder darf.

Die eigentliche Arbeit: die Zuordnung

Welcher Weg es auch wird: Am Ende steht eine Tabelle von Werten, die auf die Felder der Norm verteilt werden müssen. Die Spalte „Beleg-Nr.“ auf BT-1, das Datum auf BT-2 im richtigen Format, die Einheit „STK“ auf den Code C62 und „STD“ auf HUR, ein Steuersatz von 0 % je nach Fall auf die Kategorie K für eine innergemeinschaftliche Lieferung oder AE für die Steuerschuldnerschaft des Leistungsempfängers.

Diese Zuordnung sollte eine Datei sein, kein Programm. Der Unterschied ist nicht akademisch: Eine Datei kann jemand lesen, prüfen und beim nächsten Formatwechsel ändern, ohne Code anzufassen. Sobald eine Zuordnung Rechenausdrücke, Bedingungen oder Schleifen braucht, ist sie ein Programm — und dann gehört sie dorthin, wo Programme geprüft werden, nicht in die Einrichtung eines einzelnen Kunden.

Wie viel Arbeit das ist, lässt sich beziffern. In unserer eigenen Anbindung erzeugt ein Werkzeug aus einer unbekannten Exportdatei den Entwurf der Zuordnung: Es erkennt Zeichensatz, Trennzeichen, Vorspannzeilen, Zahlen- und Datumsformat und ordnet die Spalten nach ihren Namen zu, deutsch wie englisch. An zwei Beispielen aus verschiedenen Systemen traf es 20 von 22 und 18 von 18 Spalten; der Rest ist Handarbeit von Minuten. Was danach Zeit kostet, ist fast nie die Technik, sondern die Klärung dessen, was im Ausdruck fehlt.

Was im Ausdruck fehlt

§ 14 UStG deckt den größten Teil ab, aber nicht alles, was eine XRechnung verlangt. Drei Lücken treten bei Altsystemen fast immer auf, und alle drei liegen im Stammsatz, nicht im einzelnen Beleg:

• Kontaktdaten des Verkäufers. Die XRechnung verlangt einen Ansprechpartner mit Telefonnummer und E-Mail-Adresse (Regeln BR-DE-2 und BR-DE-5 bis BR-DE-7). Auf Papierrechnungen steht das oft nur verstreut im Briefkopf oder gar nicht. Einmal hinterlegt, gilt die Angabe für alle Belege.
• Die Käuferreferenz. Das Feld BT-10 ist in der XRechnung Pflicht (BR-DE-15). Bei öffentlichen Auftraggebern gehört die Leitweg-ID hinein, bei Unternehmen meist eine Bestell- oder Kundennummer. Woher sie kommt, muss einmal festgelegt werden.
• Codes statt Wörter. Mengeneinheiten nach UN/ECE-Empfehlung 20 (Stück ist C62, Stunde HUR) und Steuerkategorien statt Freitext. Jedes Altsystem hat dafür eigene Kürzel; die Übersetzung ist eine Nachschlagetabelle, die einmal gepflegt wird.

Dazu kommt eine praktische Frage: wohin die Rechnung geht. Die Rechnungsadresse des Käufers, meist ein E-Mail-Postfach, ist in vielen Altsystemen nirgends gepflegt, weil bisher die Post zugestellt hat. Keine dieser Lücken braucht ein neues ERP. Alle lassen sich vor dem Stichtag schließen — am besten, bevor die erste echte Rechnung den neuen Weg nimmt. Was jede Regel bedeutet, steht in unseren Prüfregeln mit steuerlicher Einordnung.

Wie man bemerkt, dass Daten fehlen

Jeder der vier Wege kann Daten verlieren, ohne dass etwas abstürzt. Ein verschobenes Trennzeichen, eine nicht erkannte Formularzeile, eine Sicht mit zu engem Filter, ein falsch belegter Qualifier: In allen Fällen entsteht ein Beleg, der formal gültig ist und inhaltlich falsch. Ein Validator merkt davon nichts. Er prüft, ob die Rechnung in sich stimmt — nicht, ob sie mit dem Altsystem übereinstimmt.

Die Prüfung, die das auffängt, ist der Abgleich gegen die Summen, die das Altsystem selbst ausgibt. Jede ordnungsgemäße Rechnung weist Entgelt und Steuer aus: im Druckstrom steht die Nettosumme unter den Positionen, im IDoc in einem eigenen Segment, im Export oft in einer Fußzeile. Ergeben die neu aufaddierten Positionen diese Summe nicht, fehlt etwas — oder die Zuordnung greift daneben. Dann darf der Beleg nicht hinaus. Dasselbe gilt, wenn die Summe selbst nicht mehr gefunden wird: Dann hat niemand nachgerechnet, und genau das darf nicht aussehen wie bestanden.

Wie leicht so etwas übersehen wird, haben wir an unserer eigenen Anbindung erlebt, vor ihrem ersten Einsatz beim Kunden. Im Druckstrom wurde eine Positionszeile, die nach einer Formularänderung um ein einziges Zeichen verrutscht war, schlicht nicht erkannt. Die Rechnung ging mit 1.360 € statt 1.810 € netto als gültig durch; die gedruckte Summe stand zwei Zeilen tiefer im selben Ausdruck. Und der Summenabgleich, den es für das SAP-IDoc bereits gab, meldete eine Abweichung zwar — hielt den Beleg aber nicht an. Beides ist behoben und durch Gegenproben abgesichert, die zuerst gegen den alten Stand liefen und dort scheiterten.^[6] Wir erzählen das nicht, weil es gut aussieht, sondern weil es die Frage oben beantwortet: Man muss sie jeder Lösung stellen, auch der eigenen.

Was eine solche Schicht nicht löst

• Die Migration. Eine Schicht vor dem Altsystem kauft Zeit; sie ersetzt keine Warenwirtschaft, deren Support endet. Wer ohnehin migriert, plant die E-Rechnung im neuen System — und wählt die Schicht so, dass sie bis dahin trägt.
• Den Empfang. E-Rechnungen empfangen können müssen Unternehmen im Inland schon seit dem 1. Januar 2025. Das ist eine eigene Aufgabe mit eigenen Fehlerquellen: Wer ein hybrides Format bekommt, muss das XML lesen, nicht das PDF. Einen eingegangenen Beleg prüft unser EN-16931-Validator.
• Peppol. Vorgeschrieben ist das Format, nicht der Übertragungsweg. Das BMF-Schreiben nennt E-Mail, den Download über ein Portal, EDI, eine Schnittstelle oder einen gemeinsamen Speicherort; worauf sich die Parteien einigen, ist zivilrechtlich ihre Sache.^[4] Verlangt ein Empfänger Peppol, lässt sich ein Zugangspunkt anbinden. Nötig für die Pflicht ist er nicht.
• Die steuerliche Beurteilung. Ob ein Umsatz der Steuerschuldnerschaft des Leistungsempfängers unterliegt oder steuerfrei ist, entscheidet nicht die Schicht, sondern der Steuerberater. Sie überträgt, was das Altsystem sagt, und prüft es gegen das Regelwerk.
• Texterkennung. Ein PDF ohne eingebettete Daten ist keine Quelle, sondern ein Bild. Wer seine Rechnungen nur noch als PDF hat, braucht einen der vier Wege oben, keine Texterkennung, die Beträge rät.

Häufige Fragen