Ab 2027 muss die Rechnung an Geschäftskunden für viele Unternehmen eine E-Rechnung sein – auch wenn dein ERP noch Dynamics NAV heißt. Die üblichen Antworten darauf sind ein Add-on oder die Migration. Es gibt einen dritten Weg, und er ist erstaunlich kurz.
Für NAV 2016 braucht es genau das: eine neue Codeunit, drei kleine Einhängepunkte in Standardobjekten und ein kostenloses Kommandozeilenwerkzeug. Keine Tabellenänderung, keine neue Lizenz, kein Add-on.
Wie das funktioniert, warum es so schlank geht und wo die Grenzen liegen, steht in diesem Beitrag. Wer schon auf Business Central ist, findet die Einrichtung dort in meiner Anleitung zur E-Rechnung in Business Central.
Kurz zur Orientierung: Der Beitrag richtet sich an Entwickler, Berater und IT-Verantwortliche, die noch NAV betreiben. Die Codeblöcke sind für Entwickler – wer nur verstehen will, ob und wie das geht, kann sie überspringen.
Gebaut und getestet gegen einen Standard-NAV-2016 DE (Build 9.0.44974), geprüft mit den offiziellen Validatoren: KoSIT mit XRechnung 3.0.2 und Mustang mit veraPDF.
Was am Ende herauskommt
Jede gebuchte Inlandsrechnung, die per E-Mail rausgeht oder als PDF gespeichert wird, ist automatisch eine ZUGFeRD-Rechnung: ein ganz normales PDF, in dem die Rechnungsdaten maschinenlesbar stecken.
Wer keine E-Rechnungen verarbeitet, merkt davon nichts. Layout, Druck und Mailversand bleiben, wie sie sind – Outlook und SMTP gleichermaßen.
| Wann | Was passiert |
|---|---|
| Buchen (Inland) | Prüfung aller Pflichtangaben – fehlt etwas, wird nicht gebucht |
| Senden, Speichern als PDF | ZUGFeRD-PDF (PDF/A-3, Profil EN 16931) |
| Öffentliche Auftraggeber | XRechnung als reines XML über das Belegsendeprofil |
| Papierdruck | unverändert |
Vier Bausteine, die schon da waren
Dass das so schlank ging, ist kein Zufall. Vier Dinge passen zusammen – und die meisten davon kennt kaum jemand.
1. NAV 2016 hat die Datenfelder bereits
Microsoft hat in NAV 2016 für PEPPOL die wichtigsten Felder eingeführt, und kaum jemand pflegt sie. Damit war keine einzige Tabellenänderung nötig.
Die Standard-PEPPOL-Codeunits selbst taugen dagegen nicht als Basis: Sie erzeugen PEPPOL BIS 2.x mit Attributen, die XRechnung 3.0 verbietet, und sie fassen die MwSt.-Aufschlüsselung nur nach Kategorie zusammen – 19 % und 7 % landen in einer Gruppe.
| Wofür | Feld |
|---|---|
| Einheit (UN/ECE Rec. 20) | Internationaler Standardcode |
| Steuerkategorie | MwSt.-Buchungsmatrix |
| Befreiungsgrund | MwSt.-Klausel |
| GTIN | Artikel |
| Elektronische Adresse | E-Mail in Firmendaten und Debitor |
2. Ghostscript kann ZUGFeRD
Der schwierigste Teil einer ZUGFeRD-Rechnung ist nicht das XML, sondern das PDF: PDF/A-3, eingebettete Datei mit der richtigen Beziehung, XMP-Metadaten nach Factur-X-Schema, Farbprofil. Ghostscript bringt dafür seit Jahren ein fertiges Skript mit – lib/zugferd.ps. Ein Aufruf genügt:
gswin64c.exe -q -sDEVICE=pdfwrite -dPDFA=3 -dPDFACompatibilityPolicy=2
-sColorConversionStrategy=RGB -sstdout=%stderr
--permit-file-read={temp}/ --permit-file-read={gs}/iccprofiles/
-sZUGFeRDXMLFile={temp}/rechnung.xml
-sZUGFeRDProfile={gs}/iccprofiles/default_rgb.icc
-sZUGFeRDVersion=2p1 -sZUGFeRDConformanceLevel="EN 16931"
-o {temp}/zugferd.pdf {gs}/lib/zugferd.ps {temp}/rechnung.pdfAchte auf -dPDFACompatibilityPolicy=2. Ohne diese Option schreibt Ghostscript im Zweifel ein PDF, das sich PDF/A nennt, es aber nicht ist – und meldet trotzdem Erfolg. Aus C/AL läuft der Aufruf über System.Diagnostics.Process auf dem Service Tier.
3. Das RDLC-PDF ist gutmütig
Das größte Risiko war, ob sich die PDFs des NAV-Report-Renderers sauber nach PDF/A-3 umwandeln lassen. Sie lassen sich: veraPDF hat das Ergebnis mit über 8.700 Prüfungen ohne einen Befund als PDF/A-3b bestätigt.
4. Die Prüfwerkzeuge sind kostenlos
Der KoSIT-Validator nutzt dasselbe Regelwerk wie die Behördenportale, Mustang prüft das fertige PDF samt eingebettetem XML. Ein Testlauf über die typischen Fälle dauert gut eine Minute – statt auf Rückmeldungen von Empfängern zu warten.
Die Architektur
Eine neue Codeunit enthält alles: den gebuchten Beleg laden, alle Pflichtangaben prüfen, die MwSt.-Gruppen nach Kategorie und Satz bilden, das XML schreiben und Ghostscript aufrufen. Das XML entsteht per XmlDocument statt per XMLport, weil sehr viele Elemente bedingt sind. UBL für XRechnung, CII für ZUGFeRD – die Datenlogik dahinter ist für beide dieselbe.
Die Netto-Zeilenbeträge leite ich so her, dass sie mit den gebuchten Beträgen exakt aufgehen: Rechnungsrabatt wieder aufaddieren, Bruttopreise herausrechnen. Dann stimmen alle Summenregeln der EN 16931 schon durch die Konstruktion.
Eingehängt, wo das PDF entsteht
Nicht beim Versand, sondern dort, wo das PDF erzeugt wird. Dadurch gilt es automatisch für Outlook und SMTP, für „Als PDF speichern“ und für „Buchen und per E-Mail senden“. In NAV 2016 sind das genau drei Stellen, jeweils ein Aufruf, markiert mit START/ENDE-Kommentaren.
| Objekt | Stelle |
|---|---|
| Codeunit 452 Report Distribution Management | GenerateReport |
| Codeunit 82 Sales-Post + Print | SaveReportAsPdf |
| Tabelle 9657 Custom Report Selection | PrintCustomReports |
Die Prüfung beim Buchen – ohne Codeunit 80 anzufassen
NAV 2016 hat in Codeunit 80 bereits das Event OnBeforePostSalesDoc. Ein Event-Subscriber in der neuen Codeunit reicht:
[EventSubscriber(Codeunit,80,OnBeforePostSalesDoc)]
LOCAL PROCEDURE CheckBeforePosting(VAR SalesHeader : Record 36);
BEGIN
// nur Inland, nur Rechnung/Gutschrift (Auftrag nur beim Fakturieren)
...
CheckSalesHeader(SalesHeader); // dieselbe Prüfung wie beim Export
END;Das ist wichtiger, als es klingt. Auf einem gebuchten Beleg lassen sich Ländercode oder USt-IdNr. nicht mehr korrigieren. Ohne Prüfung vor dem Buchen wäre so eine Rechnung schlicht nicht mehr versendbar.
Stolpersteine, die kein Handbuch nennt
| Stolperstein | Was dahintersteckt |
|---|---|
| Einheit „Stück“ wird abgelehnt | NAV liefert veraltete Codes wie EA oder 1A mit. Richtig ist H87 für Stück, KMT für Kilometer. Der Validator merkt es, NAV nicht. |
| Leerer Ländercode | In NAV heißt leer „Inland“. In der E-Rechnung ist es ein Fehler – sonst landet ein ausländischer Kunde ohne gepflegten Code als deutsche Adresse in der Rechnung, und kein Validator merkt es. Ich lehne ihn deshalb hart ab. |
| Reverse Charge | Steht in der MwSt.-Matrix mit 19 %, im Beleg aber mit 0 %. Wer Steuerkategorien prüft, muss das unterscheiden. |
| Ghostscript-Profil XRECHNUNG | Schreibt die veraltete Versionskennung 1p2, die Mustang ablehnt. Für ZUGFeRD daher Profil EN 16931 – Behörden bekommen ohnehin die reine XRechnung. |
| Lastschrift | Ein Mandat am Beleg allein heißt nicht, dass eingezogen wird. Zahlungsart 59 nur, wenn auch die Zahlungsform das Lastschrift-Kennzeichen trägt. |
Und eine Erfahrung zur Methode: Zwei unabhängige Code-Reviews haben echte Lücken gefunden, die kein Testbeleg gezeigt hätte – einen Versandweg, der am Einhängepunkt vorbeilief, einen Fehlerpfad, der ein temporäres Berichtslayout für die ganze Sitzung hängen ließ, und einen Sammelversand, bei dem ein PDF mit drei Rechnungen das XML von nur einer bekommen hätte.
Die Grenzen
Das ist eine Übergangslösung bis Business Central, das die Funktion im Standard mitbringt. Bewusst nicht enthalten:
- Codelisten werden nur auf Form geprüft, nicht gegen die vollständigen Listen
- Anzahlungsrechnungen gehen als 380 hinaus, nicht als 386
- Servicebelege sind nicht abgedeckt
- Steuerkategorie O (nicht steuerbar) wird abgelehnt
Ghostscript steht unter AGPL. Unverändert und nur intern auf dem eigenen NAV-Server eingesetzt, sehe ich keine Offenlegungspflicht. Das ist meine Einschätzung, keine Rechtsberatung.
Und das Wichtigste: Getestet ist das gegen einen Standard-NAV-2016. In einem gewachsenen System entscheiden die Individualisierungen, wie viel dazukommt – eigene Rechnungsreports, eigene Versandwege, Mandate aus einem ISV-Produkt. Genau dort liegt der eigentliche Aufwand, nicht in der E-Rechnung selbst.
Fazit
E-Rechnung aus NAV 2016 ist kein Grund, in Panik ein Add-on zu kaufen oder eine Migration zu überstürzen. Die Felder sind da, das schwierigste Stück – das PDF/A-3 – erledigt ein kostenloses Werkzeug, und die offiziellen Validatoren sagen dir sofort, ob es stimmt.
Die eigentliche Arbeit steckt in sauberen Stammdaten und in den Eigenheiten deines Systems.
Gebaut und getestet mit Dynamics NAV 2016 DE (Build 9.0.44974), Ghostscript 10.08.0, KoSIT-Validator 1.6.3 mit XRechnung-Konfiguration 3.0.2 und Mustang 2.26.0. Andere NAV-Versionen haben teils andere Einhängepunkte; die PEPPOL-Felder gibt es ab NAV 2016.
Du hast noch NAV im Einsatz und die E-Rechnung steht vor der Tür? Schreib mir kurz, worum es geht. Ich unterstütze als freiberuflicher Business Central Berater bei Umsetzung, Stammdaten und Test – in NAV wie in Business Central.
Schreibe einen Kommentar