EN 16931 in NAV-Altsystemen sauber mappen: Steuerschlüssel, Einheitencodes und Leitweg-ID

Woran die Arbeit tatsächlich hängt

Ein XMLPort in C/SIDE ist schnell zusammengeklickt, das ist ein Nachmittag Arbeit, wenn überhaupt. Trotzdem wird die E-Rechnung in Projekten regelmäßig zur Monatsaufgabe, und der Grund liegt nicht im XML.

Die Antwort: Das XML ist die Hülle. Die Arbeit steckt darin, aus dreißig Jahre gewachsenen Buchungsgruppen, frei getippten Einheitenkürzeln und historisch gewachsenen Zahlungsbedingungen die genormten Codes zu erzeugen, die die EN 16931 verlangt — und zwar so, dass jede einzelne Rechnung durch die Prüfregeln kommt, nicht nur die schöne Musterrechnung.

Dieser Artikel beschreibt, welche Codelisten das sind, wo NAV-Installationen typischerweise klemmen und was Sie selbst prüfen können, bevor Sie jemanden beauftragen.

Die Codelisten, um die es geht

Die Norm arbeitet nicht mit Klartext, sondern mit internationalen Codelisten. Die fünf, die Sie in jeder Ausgangsrechnung brauchen:

Dazu ISO 4217 für die Währung, ISO 3166 für Ländercodes und die EAS-Liste für elektronische Adressen, wenn Sie über Peppol versenden.

Keiner dieser Codes steht in Ihrer NAV-Datenbank. Alle müssen erzeugt werden.

Stolperstein 1: Steuerkategorie ist nicht ableitbar

In NAV entsteht die Umsatzsteuer aus der Kombination von MwSt-Geschäftsbuchungsgruppe und MwSt-Produktbuchungsgruppe. Aus dieser Kombination ergibt sich ein Prozentsatz, und mehr weiß das System nicht.

Die Norm will aber etwas anderes wissen. Nicht die Höhe des Satzes zählt, sondern der Rechtsgrund dahinter. Ein Steuersatz von 0 % kann drei völlig verschiedene Sachverhalte bedeuten:

Alle vier haben in NAV denselben Prozentsatz. Der Unterschied lässt sich nicht aus der Zahl ableiten, sondern nur aus der fachlichen Bedeutung der Buchungsgruppenkombination. Das heißt: Sie brauchen eine Zuordnungstabelle, die jede in Ihrem Haus verwendete Kombination auf einen Kategoriecode abbildet. Diese Tabelle muss ein Mensch mit Kenntnis Ihrer Buchhaltung ausfüllen — automatisch geht es nicht.

Bei den Kategorien AE, K, G und E kommt hinzu, dass die Norm einen Befreiungsgrund verlangt: entweder als VATEX-Code oder als Freitext. Fehlt er, weist die Prüfung die Rechnung ab.

Für Betriebe im Rohstoffhandel, in der Kreislaufwirtschaft oder im Metallschrott ist das kein Randthema. Wer regelmäßig nach § 13b abrechnet, hat die Fallunterscheidung in jeder zweiten Rechnung.

Stolperstein 2: Mengeneinheiten sind Freitext

In NAV ist der Einheitencode ein Textfeld mit zehn Zeichen. Über die Jahre steht darin, was jemand gerade getippt hat: STK, Stk, STÜCK, ST, PCS. Für die interne Verarbeitung war das nie ein Problem, weil das Feld ohnehin nur gedruckt wurde.

Die Norm verlangt an dieser Stelle einen Code aus UN/ECE Rec. 20/21. STK steht dort nicht. H87 steht dort.

Also: Zuordnungstabelle, einmal aufgebaut, dann gepflegt. Der Aufwand ist überschaubar, wenn Sie zwanzig Einheiten haben, und unangenehm, wenn Ihre Artikelstammdaten aus drei Firmenübernahmen zusammengewachsen sind. Prüfen Sie das früh — es ist eine der wenigen Zahlen, die den Projektaufwand deutlich verschieben können.

Ein Sonderfall, der oft übersehen wird: Positionen ohne Menge — Frachtpauschalen, Zuschläge, Rundungspositionen. Die Norm will auch dort eine Einheit. Üblicherweise C62 (Stück, dimensionslos) oder eine Abbildung als Zu- und Abschlag auf Dokumentebene.

Stolperstein 3: Summenkonsistenz

Die häufigste Ursache, warum ein selbstgebauter Datensatz die Prüfung nicht besteht, ist eine Rundungsdifferenz von einem Cent. Falsche Codes fallen seltener auf, als man erwarten würde.

Die EN 16931 enthält Geschäftsregeln (BR-CO-…), die verlangen, dass die Summen rechnerisch aufgehen: Die Summe der Positionsnettobeträge muss dem Nettogesamtbetrag entsprechen, die Steuerbeträge je Kategorie müssen zur Bemessungsgrundlage passen, und der Zahlbetrag muss aus Brutto minus bereits Gezahltem hervorgehen.

NAV rechnet intern anders, als die Norm es erwartet — insbesondere bei zeilenweiser Rabattierung, bei Rechnungsrabatten auf Belegebene und bei der Rundungsmethode je Mandant. Das lässt sich lösen, aber es muss bewusst gelöst werden. Wer die Beträge einfach aus den Feldern übernimmt, die auf dem Ausdruck stehen, bekommt bei jeder dritten Rechnung eine Abweisung.

Das ist auch der Grund, warum der Datensatz aus den Belegdaten entstehen sollte und nicht aus dem Rechnungsbericht: Auf dem Ausdruck stehen gerundete Anzeigewerte, in den Posten stehen die Rechenwerte.

Stolperstein 4: Leitweg-ID — nur B2G, aber dann zwingend

Die Leitweg-ID ist die Adressierungskennung öffentlicher Auftraggeber. Sie geht in das Normfeld BT-10 (Käuferreferenz) und hat die Form Grobadressierung-Feinadressierung-Prüfziffer, etwa 04011000-1234512345-06.

Wenn Sie an mehrere Dienststellen desselben Auftraggebers fakturieren, kann es je Dienststelle eine eigene ID geben. Dann braucht es die Zuordnung auf Ebene der Lieferadresse oder ein Auftragsfeld — planen Sie das ein, bevor die erste Rechnung zurückkommt.

Die Pflichtfelder, die in NAV-Installationen am häufigsten fehlen

Aus unseren Bestandsaufnahmen, sortiert nach Häufigkeit:

Keiner dieser Punkte ist schwierig. Alle zusammen sind der Grund, warum wir am Anfang eines Projekts eine Stammdaten-Ampel erstellen, bevor irgendjemand Code schreibt.

Was Sie selbst prüfen können

Vier Auswertungen, die Sie ohne Hilfe fahren können und die die Hälfte der späteren Überraschungen vorwegnehmen:

Wenn Sie diese vier Zahlen haben, lässt sich der Aufwand einer Umsetzung seriös schätzen. Ohne diese Angaben schätzt jeder ins Blaue, wir eingeschlossen.

Was ein Konvertierungsdienst leisten kann und was nicht

Der häufigste Gegenvorschlag lautet: Wir schicken das PDF an einen Konvertierungsdienst, der macht daraus eine E-Rechnung.

Das funktioniert für einfache Rechnungen. Es funktioniert nicht, sobald die Norm etwas verlangt, was auf dem Ausdruck nicht steht — und das ist bei den Steuerkategorien fast immer der Fall. Ob eine 0-%-Position ein Reverse-Charge-Fall oder eine Ausfuhr ist, kann kein Dienst aus dem PDF ablesen. Er kann es nur aus Ihren Buchungsdaten erfahren.

Deshalb entsteht der Datensatz dort, wo die Daten liegen: in Ihrem System. Wie das für NAV 2013 bis BC 14 ohne Versionswechsel umgesetzt wird, beschreiben wir hier: E-Rechnungs-Modul im freien Objektbereich Ihrer NAV-Lizenz.

Für die vorgelagerten Fragen — wer ab wann versenden muss und welches Format Sie brauchen — siehe E-Rechnungspflicht 2027 für NAV- und BC-Anwender und ZUGFeRD oder XRechnung.

---

Stand: August 2026. Codelisten nach EN 16931 sowie den Veröffentlichungen von UN/CEFACT und KoSIT in der jeweils geltenden Fassung; mit der Normrevision EN 16931-1:2026 sind Änderungen zu erwarten. Dieser Text ist keine Steuerberatung. Dynamics, Business Central und NAV sind Marken der Microsoft Corporation.