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

E-invoicing from Dynamics 365 Sales: ZUGFeRD and XRechnung

Zachary Woods 15 Sep 2026 10 min read
Share

If you invoice out of Dynamics 365 Sales today, the process is almost certainly Word template, PDF, email. For VAT purposes that has been fine. From 1 January 2027 it stops being fine for a large share of German businesses: anyone whose 2026 turnover exceeds EUR 800,000 has to issue invoices to other domestic businesses as structured data conforming to EN 16931. A PDF, however neat, no longer counts, so e-invoicing from Dynamics 365 Sales becomes a data problem rather than a document one. Three questions follow. Is there a finished solution for Dynamics? Which version and profile, and what has to be configured? If not, which route, at what effort?

What the 2027 obligation requires

The legal basis is the Wachstumschancengesetz of March 2024, which rewrote § 14 and added § 27 (38) of the German VAT Act. Receiving has been compulsory for every business established in Germany since 1 January 2025, no transition, no exception (Federal Ministry of Finance letter of 15 October 2024, paragraphs 40 and 62). From 1 January 2027 the E-Rechnungspflicht, the German issuing duty, applies to businesses whose prior-year turnover exceeded EUR 800,000 (paragraph 64). From 1 January 2028 it covers everyone.

The duty applies between parties both established in Germany. Where a VAT group (Organschaft) exists, the turnover of the whole group counts against the EUR 800,000 threshold, not the individual entity’s (paragraph 64). Outside the duty: invoices up to EUR 250, the small-business scheme (§ 34a UStDV), invoices to consumers, and supplies exempt under § 4 numbers 8 to 29. Any EN 16931 format is permitted; in Germany that means XRechnung and ZUGFeRD from version 2.0.1, excluding MINIMUM and BASIC WL (paragraphs 25 and 26). Nothing was postponed in 2026; the issuing duty starts on 1 January 2027.

E-invoicing from Dynamics 365 Sales: what Microsoft ships and what it does not

The short answer: nothing from Microsoft, something from the partner market, and it depends which Dynamics you mean. Dynamics 365 Sales has no switch for this. Its invoice documentation describes emailing the invoice with a Word document attached, and that is all. Dynamics 365 Finance has Electronic Reporting configurations that produce XRechnung in UBL syntax, and Business Central has the E-Documents framework. Neither exists in a Sales environment on Dataverse.

That leaves document tools such as DocumentsCorePack, which emits XML from a Word-authored template and bundles it with the PDF through a multipart action. The vendor is direct about the limits in its own knowledge base: no schema check, no verification against legal or tax rules, and a recommendation to validate with online tools. You get a file that looks like an e-invoice. Whether it is one is left for you to prove.

ZUGFeRD and XRechnung: formats, profiles, versions

EN 16931 is the European semantic model of an invoice: numbered business terms (BT) and groups (BG) in UN/CEFACT CII or UBL syntax. ZUGFeRD is the hybrid, a readable PDF/A-3 carrying an embedded CII file called factur-x.xml, and for B2B the right profile is EN 16931, formerly COMFORT. XRechnung is the German standard for public-sector buyers, a CIUS of EN 16931 maintained by KoSIT: XML only, tightened by the national BR-DE rules, and requiring the Leitweg-ID, the routing identifier that names the public authority as recipient and which the authority gives to its suppliers. Version 3.0.2 is current.

ZUGFeRD 2.5.2 has superseded the previous release since 1 September 2026. FeRD describes it as a corrigendum: for the EN 16931 profile the only change is a rule rename, BR-CO-27 becoming CII-SR-470, with no functional effect.

Five places e-invoicing from Dynamics 365 Sales fails

Forward this part to your finance team.

1. Tax categories instead of percentages

The failure: the rate record holds only a percentage, so a reverse-charge construction supply under § 13b comes out as category S at 0 percent. What is required: a UNCL5305 category code on every rate (S, Z, E, AE, K, G or O), the buyer VAT id in BT-48 for K and AE, and for E, AE, K, G and O an exemption reason in BT-120 or a VATEX code in BT-121.

2. Prepayments inside the final invoice

What usually goes out is the remaining net amount and nothing else, with no reference to the deposit invoices before it. EN 16931 wants gross prepayments in BT-113, one reference per deposit invoice in BG-3, and the amount due in BT-115, footing against the gross total (BR-CO-16). Even then the standard cannot fully express a German final invoice under § 14 (5). The tax authority’s own suggestion is to issue a Restrechnung, billing only the remaining balance; failing that it tolerates an unstructured attachment with the section 14.8 breakdown in a final invoice issued up to 31 December 2027 (paragraph 48).

3. Credit notes and cancellations

Cancellations are where this breaks most often: the document goes out as an ordinary invoice (type 380) with negative amounts and no link to the original. It needs a distinct type code (381 credit note or 384 corrected invoice) and a BG-3 reference to the cancelled document. Correcting an e-invoice has to be done as an e-invoice, “using the appropriate invoice type”, per section 14.11 of the decree.

4. Leitweg-ID and the BR-DE rules

Public-sector buyers reject these before a human sees them: an XRechnung to a municipality with no Leitweg-ID in BT-10, no seller contact, no buyer electronic address in BT-49. The German rules ask for payment details (BR-DE-1), a seller contact with name, phone and email (BR-DE-2, 5 to 7), city and post code for both parties (BR-DE-3, 4, 8, 9), the buyer reference (BR-DE-15), and a VAT id or tax number (BR-DE-16).

5. Validation before sending

This one is normally found by the recipient: XML generated, sent, and two weeks later a Schematron error comes back. What is required: the business rules (EN 16931 plus the KoSIT Schematron) run before dispatch, the structure is checked against the schema, PDF/A-3b is evidenced with veraPDF, and anything that fails never leaves the building. A file with a format error counts as an “other invoice” and does not discharge the obligation (letter of 15 October 2025, paragraph 6a).

Where we come in: ZUGFeRD and XRechnung from the invoice itself

We have built invoicing in Dynamics 365 Sales for years. The WBS Invoice Accelerator came out of that work: a managed solution with the seven German invoice types, number ranges and a deletion lock for retention rules.

One EN 16931 model in UN/CEFACT CII feeds two outputs. ZUGFeRD is a hybrid PDF/A-3, checked as PDF/A-3b with veraPDF on every build, in the EN 16931 profile on the Factur-X 1.07.3 schema set: the ZUGFeRD 2.3 generation, which the Ministry of Finance letter accepts as an e-invoice from 2.0.1 upward (paragraph 25). The 2.5.2 code lists and the August 2026 KoSIT configuration are on our upgrade list. XRechnung 3.0.2 is XML with the Leitweg-ID. No other profiles.

The first four failure points sit in the model, the fifth in the service.

  • Tax rates carry a UNCL5305 category code and an exemption text.
  • Final invoices produce BT-113, BG-3 and BT-115 from the linked deposit invoices.
  • Credit notes and cancellations go out as type 381 with positive amounts and a reference.
  • An XRechnung missing its Leitweg-ID, seller contact or buyer address is never generated.

Nothing is generated until the EN 16931 rules including BR-DE and the Schematron checks have run; a failure returns a validation report instead of a file. On every new version we check the XML against the schema and the hybrid with veraPDF 1.30.2, and the official KoSIT validator reports no errors against the XRechnung 3.0.2 configuration.

No Dynamics 365 version upgrade is needed. The managed solution is imported into Dataverse (it requires WBS Main), the licence goes in as an offline key in an environment variable, and per environment the renderer is enabled with a service address, a key and an application user. An issued invoice then carries a “Generate e-invoice” button for ZUGFeRD or XRechnung, and the file lands as a note on the invoice. The renderer is an Azure service we operate in the EU with a read-only identity; it stores no credentials for your environment. Sending and Peppol are not included.

Status today: built, validated against KoSIT and veraPDF, and in July 2026 generated end to end by the render service from records in our own development environment, final invoice with deposits included. Productization is the work that remains; a pilot on customer data and production hosting are ahead.

Three routes, and how a pilot runs

The template route (a DocumentsCorePack multipart action) is the fastest start and costs no extra licence if the tool is already in place. In exchange, conformance, tax logic and validation stay with you, and the effort lands in a template per invoice type plus a test pass after every standard change. A partner add-on such as audius:ZUGFeRD, which audius positions alongside its audius:Report document add-on, takes the format work off your hands; get its handling of final invoices, credit notes and validation confirmed in writing before you buy. The third route is ours, the e-invoice built from the invoice model rather than from a template, starting as a pilot:

  1. A scoping call on buyer mix, the turnover threshold, invoice volume and layout.
  2. A schema comparison in your development environment. Without it any estimate is a guess.
  3. Build and configuration there.
  4. A pilot in test with 10 to 20 real invoices across every type you use, including a final invoice with deposits and a credit note, each one through veraPDF and the KoSIT validator.
  5. Promotion through development, test and production, with buffer before the deadline.

Plan for a few weeks up to a quarter, depending on the invoice types and the state of your master data. The number only becomes firm after the schema comparison. Whatever the route, prepare the same things:

  • Per-entity master data: legal name, address, VAT id, tax number, register number, IBAN and BIC, plus a named contact with phone and email for XRechnung.
  • A tax category on every rate, with a reason and exemption text for each 0 percent variant (reverse charge, intra-community, exempt, export).
  • Leitweg-IDs for every public-sector buyer, or a decision that you are B2B and ZUGFeRD only.
  • Buyer records with country, post code, city, an invoice-receipt email address for BT-49, and the buyer VAT id where reverse charge applies.
  • A named owner in finance for the pilot.

Next step

Check the master data behind points 1 and 4 first. That is half the work whichever route you choose. If you want the three questions answered for your own environment, talk to us about e-invoicing from Dynamics 365 Sales and we will plan the pilot with you. Or call +49 931 8709 89 77.

Related reading: the WBS Invoice Accelerator, and our Dynamics 365 Sales practice.

Sources

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