E-Rechnungspflicht 2027 mit altem NAV oder Business Central: der realistische Fahrplan

Der Rechnungslauf im NAV 2016 läuft seit Jahren fehlerfrei. Jeden Monat, ohne Drama. Ab dem 1. Januar 2027 ist er trotzdem nicht mehr gesetzeskonform, jedenfalls dann, wenn das Unternehmen unter die E-Rechnungspflicht fällt und weiterhin PDFs verschickt.

Genau diese Kombination sehe ich in Projekten immer wieder: Das System ist stabil, tief angepasst, niemand will es anfassen. Der Betrieb läuft weiter und genau das ist das Problem. Denn die Pflicht kommt unabhängig davon, ob das System dafür bereit ist.

1. Die Rechtslage in drei Minuten

Die E-Rechnungspflicht für inländische B2B-Umsätze wird stufenweise eingeführt:

Stichtag	Was gilt
seit 1. Januar 2025	Alle inländischen Unternehmen müssen E-Rechnungen empfangen können
ab 1. Januar 2027	Unternehmen mit mehr als 800.000 € Umsatz im Vorjahr müssen E-Rechnungen ausstellen
ab 1. Januar 2028	Die Ausstellungspflicht gilt für alle inländischen Unternehmen

Als E-Rechnung gilt dabei nur ein strukturiertes elektronisches Format nach der europäischen Norm EN 16931. In Deutschland vor allem XRechnung und ZUGFeRD ab Version 2.0. Ein PDF per E-Mail ist keine E-Rechnung, sondern eine “sonstige Rechnung” und erfüllt die Ausstellungspflicht nicht.

Zwei Punkte werden dabei häufig übersehen. Erstens: Die Empfangspflicht gilt bereits seit 2025, auch für Unternehmen, die selbst noch gar nicht ausstellen müssen. Wenn ein Lieferant heute eine XRechnung schickt, muss sie verarbeitet werden können. Zweitens: Die 800.000-€-Grenze bezieht sich auf den Umsatz des Vorjahres, also 2026. Wer darüber liegt, hat ab dem ersten Arbeitstag 2027 keine Übergangsfrist mehr.

2. Warum altes NAV und ältere BC-Versionen das Problem nicht lösen

Microsoft hat die E-Rechnungs-Funktionalität als E-Documents-Framework in Business Central, mit Unterstützung für XRechnung, ZUGFeRD und Peppol in der deutschen Lokalisierung integriert. Allerdings erscheinen diese Funktionen ausschließlich für aktuelle Business-Central-Versionen.

Für die Systeme, um die es hier geht, bedeutet das konkret:

• Dynamics NAV (2009 bis 2018): Alle Versionen sind aus dem Mainstream-Support. Es erscheinen keine funktionalen Erweiterungen mehr. Die E-Rechnungs-Funktionen werden für NAV nie nachgeliefert.
• Ältere Business-Central-Versionen OnPrem (etwa BC 14): Auch hier gilt: kein E-Documents-Framework, keine deutsche E-Rechnungs-Lokalisierung. Wer auf einer Version ohne aktuellen Update-Pfad sitzt, steht praktisch an derselben Stelle wie ein NAV-Kunde.

Es fehlt in diesen Systemen nicht nur “ein Format”. Es fehlen gleich mehrere Bausteine, die Erzeugung des strukturierten XML nach EN 16931 beim Rechnungsausgang, das Einlesen, Validieren und Zuordnen eingehender XRechnungen und ZUGFeRD-Dateien, die Verknüpfung mit den vorhandenen Buchungsprozessen und das alles abgestimmt auf die individuellen Anpassungen, die in gewachsenen NAV-Systemen praktisch immer vorhanden sind.

Genau deshalb ist “wir warten auf ein Update” keine Strategie. Das Update kommt nicht.

3. Die drei Wege im Vergleich

Für Unternehmen mit altem NAV oder älterem BC gibt es drei realistische Wege. Keiner davon ist pauschal richtig. Die Entscheidung hängt von der Restlaufzeit des Systems, dem Anpassungsgrad, dem Budget und dem verbleibenden Zeitfenster ab.

Weg	Was passiert	Passt, wenn …	Zu beachten
Nachrüsten	XRechnung/ZUGFeRD-Fähigkeit wird direkt im Altsystem über ein ISV-Add-on oder eine Eigenentwicklung (C/AL bzw. AL) ergänzt	das System noch mehrere Jahre laufen soll und die Rechnungsprozesse überschaubar sind	Add-ons für alte NAV-Versionen werden seltener; Eigenentwicklung braucht jemanden, der C/AL und die EN-16931-Formate beherrscht
Anbinden	Ein externer Konvertierungs- oder Portaldienst übernimmt Erzeugung und Empfang; das Altsystem liefert und empfängt Daten über eine Schnittstelle	möglichst wenig am Altsystem geändert werden soll	laufende Kosten pro Rechnung/Monat; die Schnittstelle selbst muss sauber in die bestehenden Prozesse integriert werden. Hier liegt der eigentliche Aufwand
Migrieren	Wechsel auf ein aktuelles Business Central, das die E-Rechnung nativ beherrscht	die Ablösung ohnehin absehbar ist und die Pflicht der Anlass sein soll, sie geordnet anzugehen	der aufwendigste, aber nachhaltigste Weg; bei stark angepassten Systemen mehrere Monate Vorlauf und der Betrieb muss währenddessen weiterlaufen

Wichtig ist die ehrliche Reihenfolge. Erst verstehen, was das eigene System wirklich tut, dann den Weg wählen. In der Praxis scheitern Umstellungen selten am Format, sie scheitern daran, dass individuelle Anpassungen, Sonderprozesse und Schnittstellen erst mitten im Projekt sichtbar werden.

4. Warum die Bestandsaufnahme vor der Entscheidung kommt

Bevor ich in solchen Situationen eine Empfehlung ausspreche, mache ich immer zuerst eine strukturierte Bestandsaufnahme. Nicht weil es vorgeschrieben ist, sondern weil ohne sie fast jede Weg-Entscheidung auf Vermutungen basiert.

Ein Readiness-Check für die E-Rechnung beantwortet konkret:

• Rechnungsausgang: Welche Belegarten werden erzeugt, aus welchen Prozessen, mit welchen individuellen Anpassungen an Rechnungslayout und Buchungslogik?
• Rechnungseingang: Wie kommen Eingangsrechnungen heute ins System, und was müsste passieren, damit eine XRechnung nicht nur abgelegt, sondern verarbeitet wird?
• Schnittstellen: Welche vor- und nachgelagerten Systeme hängen an den Rechnungsprozessen, Dokumentenarchiv, DATEV-Export, Portale, Branchenlösungen?
• Systemzustand: Version, Anpassungsgrad, Datenqualität, vorhandenes Know-how – und damit: Welcher der drei Wege ist realistisch, was kostet er, wie lange dauert er?

Was nach der Analyse anders ist: Aus einem diffusen “wir müssen da irgendwann ran” wird eine konkrete, priorisierte Entscheidungsgrundlage mit Aufwandsrahmen und Zeitplan. Ohne diese Grundlage werden solche Projekte regelmäßig teurer und später fertig als geplant.

5. Die Zeitachse rückwärts gerechnet

Wer ab dem 1. Januar 2027 ausstellungspflichtig ist und den Migrationsweg geht, sollte rückwärts rechnen: Produktivstart spätestens im vierten Quartal 2026, davor Testphase mit echten Geschäftsfällen, davor Umsetzung, davor Konzeption und Bestandsaufnahme. Bei einem gewachsenen System mit Eigenentwicklungen bedeutet das: Die Planung muss 2026 beginnen – nicht “irgendwann 2026”, sondern in der ersten Jahreshälfte.

Auch Nachrüstung und Anbindung sind keine Wochenendprojekte. Die reine Formaterzeugung ist der kleinste Teil. Getestet werden müssen die realen Fälle: Sammelrechnungen, Gutschriften, Sonderkonditionen, Fremdwährungen, die zehn Prozent Belege, die schon heute manuell nachbearbeitet werden.

Und selbst wer erst ab 2028 ausstellen muss, hat mit der Empfangsseite bereits heute eine offene Pflicht. Die Frage ist also nicht, ob man das Thema angeht, sondern ob man es geordnet angeht oder unter Zeitdruck.

Unterstützung bei der E-Rechnung mit NAV und Business Central