• Contact us: office@woods.consulting
Book a meeting
Dynamics 365

E-Rechnung aus Dynamics 365 Sales: ZUGFeRD und XRechnung 2027

Zachary Woods 15 Sep. 2026 9 min read
Share

Wer heute aus Dynamics 365 Sales fakturiert, erzeugt die Rechnung fast immer so: Word-Vorlage, PDF, E-Mail. Umsatzsteuerlich war das bisher in Ordnung. Ab dem 1. Januar 2027 ist es das für viele Unternehmen nicht mehr: Wer 2026 mehr als 800.000 Euro Umsatz macht, muss Rechnungen an andere inländische Unternehmen strukturiert nach EN 16931 ausstellen. Ein PDF, so sauber es aussieht, zählt dann nicht mehr. Drei Fragen stellen sich dabei immer: Gibt es das für Dynamics fertig? Welche Version, welches Profil, was ist einzurichten? Und sonst: welcher Weg, mit welchem Aufwand? Dieser Beitrag beantwortet die drei Fragen zur E-Rechnung aus Dynamics 365 Sales und zeigt fünf Stellen, an denen Umsetzungen scheitern.

Was die E-Rechnungspflicht ab 2027 verlangt

Grundlage ist das Wachstumschancengesetz vom März 2024 (§ 14 und § 27 Abs. 38 UStG). Seit dem 1. Januar 2025 muss jedes inländische Unternehmen E-Rechnungen empfangen können (BMF-Schreiben vom 15. Oktober 2024, Rz. 40, 62). Ab dem 1. Januar 2027 müssen Unternehmen mit mehr als 800.000 Euro Vorjahresumsatz ihre Rechnungen an andere inländische Unternehmen als E-Rechnung ausstellen (Rz. 64), ab dem 1. Januar 2028 alle.

Ausgenommen sind Kleinbetragsrechnungen bis 250 Euro, Rechnungen von Kleinunternehmern (§ 34a UStDV), Rechnungen an Privatkunden und Umsätze nach § 4 Nr. 8 bis 29 UStG. Zulässig sind alle Formate nach EN 16931, in Deutschland vor allem XRechnung und ZUGFeRD ab Version 2.0.1 ohne die Profile MINIMUM und BASIC WL (Rz. 25, 26). Eine Verschiebung gab es 2026 nicht; bis zum Stichtag bleiben gut drei Monate.

E-Rechnung aus Dynamics 365 Sales: was Microsoft mitbringt und was nicht

Die kurze Antwort: von Microsoft nicht, aus dem Partnermarkt teilweise, und es kommt darauf an, welches Dynamics gemeint ist. Dynamics 365 Sales hat keinen Schalter dafür. Die Rechnungsdokumentation kennt den Versand per E-Mail mit Word-Anhang, mehr nicht. Dynamics 365 Finance und Business Central haben eigene E-Rechnungsfunktionen, die es in einer Sales-Umgebung nicht gibt.

Bleiben Vorlagenwerkzeuge wie DocumentsCorePack: XML aus einer Word-Vorlage, per „Multipart“ mit dem PDF gebündelt. Der Hersteller schreibt selbst, dass keine Schemaprüfung stattfindet, keine Prüfung gegen ein E-Rechnungsformat und keine steuerliche Validierung. Das Werkzeug erzeugt also eine Datei, die wie eine E-Rechnung aussieht; ob sie eine ist, prüft es nicht, der Hersteller verweist dafür auf Online-Validatoren.

ZUGFeRD und XRechnung: Formate, Profile, Versionen

EN 16931 ist das europäische Datenmodell der Rechnung: nummerierte Informationselemente (BT) und Gruppen (BG) in der Syntax UN/CEFACT CII oder UBL. ZUGFeRD ist hybrid: ein lesbares PDF/A-3 mit eingebetteter CII-Datei „factur-x.xml“. Für B2B ist das Profil EN 16931 (früher COMFORT) das richtige. XRechnung ist der deutsche Standard für die öffentliche Hand, eine von der KoSIT gepflegte CIUS zur EN 16931: reines XML ohne PDF, ergänzt um die nationalen Regeln BR-DE-1 bis BR-DE-28 und die Leitweg-ID als Pflichtangabe. Aktuell ist Version 3.0.2.

ZUGFeRD 2.5.2 erschien im August 2026 und löst laut FeRD ab dem 1. September 2026 die Vorversion ab. Für das Profil EN 16931 betreffen die Änderungen seit der 2.3-Generation nach Angaben des FeRD vor allem Codelisten und Prüfartefakte.

Fünf Stellen, an denen E-Rechnungen aus Dynamics scheitern

Diesen Teil können Sie an die Buchhaltung weiterleiten.

1. Steuerkategorien statt Prozentsätze

Der Fehler: Am Steuersatz ist nur die Prozentzahl gepflegt, und eine Bauleistung nach § 13b UStG landet als Kategorie S mit 0 % im XML. Richtig: Jeder Steuersatz trägt einen Kategoriecode nach UNCL5305 (S, Z, E, AE, K, G oder O). Bei K steht die USt-IdNr. des Käufers in BT-48, bei AE die USt-IdNr. oder eine Registernummer des Käufers; bei E, AE, K, G und O gehört ein Befreiungsgrund in BT-120 oder als VATEX-Code in BT-121.

2. Anzahlungen in der Schlussrechnung

Der Fehler: Die Schlussrechnung weist nur den Restbetrag netto aus, ohne Bezug auf die Anzahlungsrechnungen. Richtig: Anzahlungen brutto in BT-113, je Anzahlungsrechnung ein Verweis in BG-3, der fällige Betrag in BT-115; die Summe geht gegen den Bruttobetrag auf (BR-CO-16). Für jede Lösung gilt: EN 16931 bildet die Endrechnung nach § 14 Abs. 5 UStG noch nicht vollständig ab. Bis Ende 2027 duldet das BMF deshalb einen unstrukturierten Anhang mit der Zusammenstellung nach Abschnitt 14.8 UStAE (Rz. 48).

3. Gutschrift und Storno

Der Fehler: Die Stornorechnung geht als gewöhnliche Rechnung (Typ 380) ohne Bezug auf das Original hinaus, nur mit negativen Beträgen. Richtig: ein eigener Rechnungstyp (381 Gutschrift oder 384 Rechnungskorrektur) und in BG-3 der Verweis auf die stornierte Rechnung; wir geben Storno und Gutschrift als 381 mit positiven Beträgen aus. Die Berichtigung einer E-Rechnung muss selbst eine E-Rechnung sein, „unter Verwendung des entsprechenden Rechnungstyps“ (Abschnitt 14.11 UStAE).

4. Leitweg-ID und BR-DE bei öffentlichen Auftraggebern

Der Fehler: eine XRechnung an eine Kommune ohne Leitweg-ID in BT-10, ohne Verkäuferkontakt mit Telefon und E-Mail, ohne elektronische Käuferadresse in BT-49. Richtig: BR-DE-1 verlangt Zahlungsangaben (BG-16), BR-DE-2 mit BR-DE-5 bis 7 einen Verkäuferkontakt mit Name, Telefon und E-Mail, BR-DE-3, 4, 8 und 9 Ort und PLZ von Verkäufer und Käufer, BR-DE-15 die Käuferreferenz (Leitweg-ID, BT-10), BR-DE-16 USt-IdNr. oder Steuernummer.

5. Validierung vor dem Versand, nicht nach der Reklamation

Der Fehler: XML erzeugt, verschickt, zwei Wochen später meldet der Empfänger einen Schematron-Fehler. Richtig: Vor dem Versand laufen die Geschäftsregeln (EN 16931 und KoSIT-Schematron), die Struktur wird gegen das Schema abgesichert, und die PDF/A-3b-Konformität wird mit veraPDF nachgewiesen; was durchfällt, geht nicht raus. Eine Datei mit Formatfehler ist nur eine „sonstige Rechnung“ (BMF-Schreiben vom 15. Oktober 2025, Rz. 6a).

Wo wir ins Spiel kommen: ZUGFeRD und XRechnung aus der Rechnung selbst

Wir bauen seit Jahren für unsere Kunden die Rechnungsstellung in Dynamics 365 Sales. Daraus ist der WBS Invoice Accelerator entstanden, eine verwaltete Lösung mit sieben deutschen Rechnungsarten, Nummernkreisen und einer Löschsperre nach GoBD.

Aus der Rechnung entsteht ein EN-16931-Datenmodell in UN/CEFACT CII. Daraus erzeugen wir ZUGFeRD als hybrides PDF/A-3b im Profil EN 16931 auf dem Schemasatz Factur-X 1.07.3 (ZUGFeRD-2.3-Generation) sowie XRechnung 3.0.2 als XML mit Leitweg-ID. Andere Profile gibt es nicht.

Die ersten vier Stellen sitzen im Modell, die fünfte im Dienst. Steuersätze tragen Kategoriecode und Befreiungstext. Schlussrechnungen liefern BT-113, BG-3 und BT-115 aus den verknüpften Anzahlungsrechnungen. Gutschrift und Storno gehen als Typ 381 mit positiven Beträgen und Referenz hinaus. Eine XRechnung ohne Leitweg-ID, Kontakt oder Käuferadresse wird gar nicht erst erzeugt. Vor jeder Ausgabe laufen das EN-16931-Regelwerk samt BR-DE und die Schematron-Prüfungen; bei einem Fehler kommt ein Prüfbericht statt einer Datei. Schemakonformität des XML und PDF/A-3b prüfen wir bei jeder neuen Version: veraPDF 1.30.2 und der KoSIT-Validator 1.6.2 melden keine Fehler.

Ein Versionsupdate von Dynamics 365 ist nicht nötig. Die verwaltete Lösung wird auf Dataverse importiert (sie setzt WBS Main voraus), die Lizenz kommt als Offline-Schlüssel in eine Umgebungsvariable, und je Umgebung wird der Renderer freigeschaltet (Dienstadresse, Schlüssel, Anwendungsbenutzer). Danach zeigt die freigegebene Rechnung die Schaltfläche „E-Rechnung erstellen“ (ZUGFeRD oder XRechnung); die Datei liegt anschließend als Notiz an der Rechnung. Der Renderer ist ein von uns betriebener Azure-Dienst in der EU mit rein lesender Identität; Zugangsdaten zu Ihrer Umgebung speichert er nicht. Versand und Peppol sind nicht enthalten.

Stand heute: gebaut, gegen KoSIT und veraPDF validiert und im Juli 2026 vom Azure-Dienst Ende-zu-Ende aus Datensätzen unserer Entwicklungsumgebung erzeugt, Schlussrechnung mit Anzahlung eingeschlossen. Die letzten Schritte zur Produktreife laufen; ein Pilotbetrieb auf Kundendaten und das produktive Hosting stehen noch aus.

Drei Wege zur E-Rechnung und wie eine Pilotphase abläuft

Der Vorlagenweg (DocumentsCorePack-Multipart) ist der schnellste Start und braucht keine zusätzliche Lizenz, wenn DocumentsCorePack schon im Einsatz ist. Dafür bleiben Konformität, die steuerliche Logik (Kategorien, Befreiungen, Anzahlungen) und die Validierung bei Ihnen; der Aufwand steckt in der Vorlage je Rechnungsart und in jedem Prüflauf nach einer Standardänderung. Ein Partner-Add-on wie audius:ZUGFeRD (setzt audius:Report voraus) nimmt Ihnen die Formatarbeit ab; wie es mit Schlussrechnungen, Gutschriften und der Validierung umgeht, sollten Sie sich vor dem Kauf schriftlich bestätigen lassen. Der dritte Weg ist unserer: E-Rechnung aus dem Rechnungsmodell statt aus einer Vorlage, zuerst als Pilotphase. So läuft sie ab:

  1. Ein Abstimmungsgespräch klärt Käuferkreis, Umsatzschwelle, Rechnungsvolumen und Layout.
  2. Schema-Abgleich in Ihrer Entwicklungsumgebung; ohne ihn ist jede Schätzung geraten.
  3. Aufbau und Konfiguration in Ihrer Entwicklungsumgebung.
  4. Pilotphase in der Testumgebung mit 10 bis 20 echten Rechnungen aller genutzten Rechnungsarten, darunter Schlussrechnung mit Anzahlungen und Gutschrift; jede Datei durchläuft veraPDF und den KoSIT-Validator.
  5. Produktivsetzung über Entwicklung, Test und Produktion, mit Puffer vor dem Stichtag.

Als Größenordnung rechnen wir mit wenigen Wochen bis zu einem Quartal, je nach Rechnungsarten und Stammdaten; verbindlich wird es nach dem Schema-Abgleich. Unabhängig vom Weg sollten Sie vorbereiten:

  • Stammdaten je Gesellschaft: Firmierung, Anschrift, USt-IdNr., Steuernummer, Handelsregisternummer, IBAN und BIC, für XRechnung ein Ansprechpartner mit Telefon und E-Mail.
  • Die Steuerkategorie je Steuersatz; jede Variante mit 0 % Steuer mit Grund (Reverse Charge, innergemeinschaftlich, steuerfrei, Ausfuhr) und Befreiungstext.
  • Leitweg-IDs aller öffentlichen Auftraggeber oder die klare Aussage „nur B2B, nur ZUGFeRD“.
  • Käuferstammdaten mit Land, PLZ, Ort und E-Mail des Rechnungseingangs (BT-49), USt-IdNr. des Käufers bei Reverse Charge.
  • Eine benannte Person in der Buchhaltung für die Pilotphase.

Nächster Schritt

Prüfen Sie zuerst die Stammdaten aus den Punkten 1 und 4; das ist die halbe Arbeit. Wenn Sie die drei Fragen für Ihr Dynamics 365 Sales beantwortet haben möchten, sprechen wir kurz darüber und planen dann die Pilotphase. Hier erreichen Sie uns. Oder Sie rufen direkt an: +49 931 8709 89 77.

Quellen

Keep reading

Building something in the Power Platform?

We design and ship the systems behind these posts. Tell us what you are working on.

Book a meeting All posts