E-invoicing from Dynamics 365 Sales: ZUGFeRD and XRechnung

If you invoice out of Dynamics 365 Sales today, the process is probably Word template, PDF, email. For VAT that’s worked so far. From 1 January 2027, many invoices to other German businesses have to be e-invoices, meaning structured data that conforms to EN 16931. That covers every invoice for 2026 work that goes out in 2027, whatever your turnover, and invoices for 2027 work if your 2026 turnover was above EUR 800,000. A PDF doesn’t count, so e-invoicing from Dynamics 365 Sales starts with the data on the invoice record. This post covers what Microsoft ships, which format and profile you need, five places where implementations fail and which route fits. If you bill projects in Dynamics 365 Project Operations, read our post on e-invoicing for Dynamics 365 Project Operations.

What the 2027 obligation requires

The legal basis is the Wachstumschancengesetz of March 2024, which changed the invoicing rules in § 14 and added the transition rules in § 27 (38) of the German VAT Act (UStG). Receiving has been compulsory for every business established in Germany since 1 January 2025, with no transition and no exception (Federal Ministry of Finance letter of 15 October 2024, paragraphs 40 and 62, and the Ministry’s FAQ, question 12). Issuing phases in:

• Supplies made in 2025 and 2026 may still be invoiced on paper, or as a PDF if the recipient agrees, if the invoice is issued by 31 December 2026 (§ 27 (38) no. 1; paragraph 63).
• For supplies made in 2027, that stays allowed until the end of 2027 only for businesses whose total turnover in 2026 was no more than EUR 800,000 (no. 2; paragraph 64). EDI with the recipient’s consent stays allowed for everyone (no. 3; paragraph 65).
• From 1 January 2028 every invoice between domestic businesses has to be an e-invoice, apart from the exceptions below.

So December 2026 work invoiced in January 2027 needs an e-invoice by the wording of the law, whatever your turnover. The Ministry also accepts EDI with consent for it until the end of 2027 (paragraph 65).

The duty applies between parties both established in Germany; a German VAT registration alone doesn’t make a foreign business domestic (the Ministry’s FAQ, question 3). In a VAT group (Organschaft), the EUR 800,000 test uses the turnover of the whole group (paragraph 64). Outside the duty, among others: invoices up to EUR 250 gross (not for reverse-charge supplies, § 33 UStDV), tickets, invoices from small businesses under the Kleinunternehmer scheme (§ 34a UStDV), invoices to consumers, and supplies exempt under § 4 numbers 8 to 29. Any EN 16931 format is permitted. In Germany that mostly means XRechnung, and ZUGFeRD from version 2.0.1 except the MINIMUM and BASIC-WL profiles; other EN 16931 formats such as Peppol BIS Billing also qualify (paragraphs 25 and 26). As of September 2026, the dates in § 27 (38) haven’t changed.

E-invoicing from Dynamics 365 Sales: what Microsoft ships

Microsoft doesn’t ship a finished solution for e-invoicing from Dynamics 365 Sales, and the partner market covers it only in part. It also depends which Dynamics you mean. Dynamics 365 Sales has no e-invoicing function: its invoice documentation describes sending the invoice by email with a Word document attached. 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 the partner market, mostly template-based document tools that emit XML from a Word-authored template and bundle it with the PDF. Ask the vendor whether the tool checks the file against EN 16931 and the XRechnung rules before it goes out, or whether that check stays with you.

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 EN 16931 profile, formerly COMFORT, is usually the right one; for VAT purposes every profile except MINIMUM and BASIC-WL qualifies. 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 a buyer reference in BT-10, where public buyers ask for their Leitweg-ID, the routing identifier an authority gives its suppliers. Version 3.0.2 is current. A preview of XRechnung 4.0 dated 15 September 2026 is out, and xeinkauf.de expects the final version in spring 2027.

ZUGFeRD 2.5.2 came out in August 2026 and has applied since 1 September 2026; it matches Factur-X 1.09.2. FeRD describes it as a corrigendum that mainly fixes inconsistencies in the EXTENDED profile. In BASIC-WL, BASIC and EN 16931, rule BR-CO-27 is now called CII-SR-470, and the rule itself is unchanged.

Five places e-invoicing from Dynamics 365 Sales fails

Forward this part to your finance team.

1. Tax category and exemption reason

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 (for AE, the buyer VAT id or legal registration number), 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

The failure: the final invoice shows the full price and the full VAT without deducting the down payments already invoiced with VAT, so the VAT on them is owed a second time (§ 14c (1) UStG; section 14.8 (10) of the VAT Application Decree, UStAE). What is required: the part payments received before the supply and the VAT on them are deducted (§ 14 (5) sentence 2 UStG). In EN 16931 that means the prepaid gross amount in BT-113, a BG-3 reference to the preceding invoice, and the amount due in BT-115, the gross total less BT-113 (BR-CO-16). The Ministry of Finance says a final invoice can’t yet be fully expressed in the structured data and suggests a Restrechnung for the remaining amount instead (paragraph 48; UStAE 14.8 (11)). It also accepts the deductions in an unstructured attachment inside the e-invoice if the structured part refers to it expressly, after 31 December 2027 too (its FAQ, question 7b). A breakdown sent separately doesn’t count.

3. Credit notes and cancellations

The failure: a cancellation goes out as an ordinary invoice (type 380) with negative amounts and no link to the original. What is required: a distinct type code (381 credit note or 384 corrected invoice) and a BG-3 reference to the cancelled document. Where the e-invoice duty applies, an e-invoice has to be corrected with an e-invoice, “using the appropriate invoice type” (section 14.11 (1) sentence 7 UStAE, added by the letter of 15 October 2025). If a supply may still be invoiced without an e-invoice under the transition rules, its correction can be made without one too (sentence 9 of the same section; the Ministry’s FAQ, question 7b). In the German VAT Act, a Gutschrift is an invoice your customer issues for you (self-billing, § 14 (2) sentence 5 UStG). A credit note that cancels or corrects your own invoice doesn’t count as one (section 14.3 (2) sentence 5 UStAE), so German teams call it a Stornorechnung or Rechnungskorrektur.

4. Leitweg-ID and the BR-DE rules

The failure: an XRechnung to a municipality goes out with no Leitweg-ID in BT-10, no seller contact or no buyer electronic address in BT-49, and the public buyer rejects it before anyone reads it. What is required: 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). Since XRechnung 3.0, the buyer’s electronic address in BT-49 is required too (PEPPOL-EN16931-R010).

5. Validation before sending

The failure: XML generated, sent, and two weeks later the recipient reports a Schematron error. What is required: check the file against the schema and the business rules (EN 16931, plus the KoSIT Schematron for XRechnung) before it goes out, check a ZUGFeRD PDF for PDF/A-3b, for example with veraPDF, and don’t send a file that fails. A syntax error is a format error: the file counts as an “other invoice” and doesn’t meet the e-invoice duty (letter of 15 October 2025, paragraph 6a). A business-rule error on a mandatory VAT detail makes the invoice improper for VAT. Other rule errors, such as a missing BT-10, don’t matter for VAT, though public buyers still require the Leitweg-ID there (paragraphs 6b and 35a). The Ministry suggests keeping the validation report as evidence.

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

We’ve built invoicing in Dynamics 365 Sales for years, and the WBS Invoice Accelerator for Dynamics 365 came out of that work. It’s been in production at WBS since September 2026. It extends Microsoft’s own apps, Dynamics 365 Sales and Project Operations, and works on their standard invoice record in your Dataverse environment, so there’s no second invoicing system and nothing to sync. The full accelerator adds a visual invoice editor on the invoice form, brand profiles for each brand you bill under, invoice types from down payment to final invoice and sequential number ranges per brand and invoice type. It also handles foreign-currency invoices, prints a PDF with the same layout as the screen and blocks deleting issued invoices. The e-invoice module creates a ZUGFeRD or an XRechnung file from the invoice record, and every full licence includes it. If you’d rather keep your current invoice form, the e-invoice add-on puts the e-invoice buttons on the Sales invoice form your team already uses. Dynamics 365 Finance and Business Central have their own e-invoicing features, and the accelerator isn’t meant for them.

One EN 16931 model in UN/CEFACT CII feeds two outputs. ZUGFeRD is a hybrid PDF/A-3 in the EN 16931 profile, built on the Factur-X 1.07.3 schema set, which matches ZUGFeRD 2.3.3 and so meets the Ministry’s version rule (paragraph 25). Its PDF uses the accelerator’s own layout and your brand profile; your Word template isn’t used. XRechnung 3.0.2 is plain XML with the buyer reference, the Leitweg-ID for public buyers. There are no other profiles and no UBL output.

The first four failure points are handled in the invoice model, the fifth largely by the checks in the e-invoice service.

• Tax rates carry a UNCL5305 category code and, where no VAT is charged, the reverse-charge note or exemption text.
• A final invoice (Schlussrechnung) deducts the issued down payment, progress and partial invoices of the same sales order. Drafts and cancelled invoices are never deducted. An advance that isn’t marked as paid is still deducted, with a warning. The law speaks of part payments received (pitfall 2), so whether to issue the final invoice before the advance is paid is a question for your tax adviser.
• The PDF lists each deduction with net and VAT, then the VAT contained in the deductions. The e-invoice carries BT-113, one BG-3 reference (CII has room for one) and a note in the structured data that lists each deduction with net, VAT and gross.
• An incomplete or ambiguous deduction, such as an advance without a number or with a cancellation that isn’t issued yet, stops the e-invoice and the PDF export, and the message names the invoice.
• VAT is calculated after line and invoice-wide discounts, and the PDF and the XML show the same totals. An invoice-wide discount goes into the e-invoice only when the invoice has a single VAT rate.
• Credit notes and cancellation invoices go out as type 381 with positive amounts and a BG-3 reference to the original invoice; every other invoice type, partial and progress invoices included, goes out as type 380. The app’s German label for the credit note is Gutschrift, and it always corrects an invoice you issued. Self-billing isn’t part of the product.
• An XRechnung isn’t generated if any of these is missing: a buyer reference (the Leitweg-ID for public buyers), a seller contact with name, phone and email, an IBAN, city and post code for seller and buyer, the seller’s VAT id or tax number, or the buyer’s email address.

Nothing is generated until the service has checked the invoice against the EN 16931 business rules and the official EN 16931 Schematron, and an XRechnung also against the German BR-DE rules in the KoSIT Schematron. If any check finds an error, no file is created. In our testing we also check the XML against the schema, run the official KoSIT validator with the XRechnung 3.0.2 configuration and check the ZUGFeRD PDF with veraPDF for PDF/A-3b. You can check your own file the same way with our free e-invoice validator.

With the add-on, the invoice form gets three e-invoice buttons: Check e-invoice, ZUGFeRD and XRechnung. The check runs the same rules as the other two without creating a file, so accounting can correct the record before the invoice goes out. A generated file is stored as a note on the invoice with a short check summary: the result, the checks that ran and the number of warnings. An issue record keeps the number, format, time, user and a SHA-256 hash of the file, and the accelerator blocks changing the stored file or deleting it. Each invoice gets one e-invoice format, and asking again returns the stored original. Your workflows and your quote and order templates stay as they are, and no Dynamics 365 version upgrade is needed.

The file is created by a small Azure service that reads the invoice with a read-only identity. WBS runs it for you as an Azure Function in Germany (Azure region Germany West Central, Frankfurt) and processes the invoice data on your behalf under a data processing agreement. The service keeps no invoices, and its logs hold technical data such as which invoice failed and why. Sending stays in your hands, through the channel each customer has agreed with you. Peppol isn’t included, and the accelerator doesn’t read incoming e-invoices.

Three routes, and how an implementation runs

The template route, an XML action in a template-based document tool, 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 for ZUGFeRD 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 data in Dynamics 365, with an implementation we run together with your team. Most of the effort goes into the billing process around the XML. Corrections made in Word or the PDF before sending have to move into the record, house rules for deducting advances become system rules, and the service date becomes a mandatory field. Expect some of that to need a second pass after go-live. We’ve implemented Dynamics 365 in many client projects and built the accelerator ourselves, so we deliver the solution and implement it with you in these steps:

1. An assessment of your real invoices and processes, one invoice type at a time, showing where record, document and daily practice drift apart.
2. Process changes with your accounting team and tax adviser: how unpaid advances are handled, how corrections and cancellations are made, who enters the service date and who approves what.
3. Customising where your business needs it: if your billing differs from the standard, we adapt fields, rules and screens.
4. Setup in your test environment, and master data: seller data, a VAT category per tax rate, countries, VAT ids and Leitweg-IDs, each with a named owner.
5. Acceptance in your test environment with your real invoices across every type you use, including a final invoice with deposits and a credit note, each XRechnung through the KoSIT validator and each ZUGFeRD file through veraPDF.
6. Go-live: the import into production through your usual release process, and a short guide for accounting.
7. Support in operation: the first questions from recipients, special cases, and updates when the standards change.

The scope depends on your invoice types and the state of your master data. It’s settled after the assessment, and so is the fixed price for the implementation. 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, and for each rate without VAT (reverse charge, intra-community supply, exempt, export) the reverse-charge note or exemption text.
• Leitweg-IDs for every public-sector buyer, or a decision that you’re 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.
• The service date or period on every invoice, entered in its own field instead of a sentence in the cover text.
• A named owner in finance who signs off the result.

Next step

Check the master data behind points 1 and 4 first. You’ll need it whichever route you choose. The product page shows how ZUGFeRD and XRechnung work on the Dynamics 365 Sales invoice form. If you want to know which route fits your own Dynamics 365 Sales environment, send us ten invoices from last year, at least one of each invoice type you use. Redacted copies are fine. We’ll agree a secure way to share them and tell you which processes change and what needs doing. Talk to us about e-invoicing from Dynamics 365 Sales, or call +49 931 8709 89 77.

Related reading: the WBS Invoice Accelerator for Dynamics 365, our post on e-invoicing for Dynamics 365 Project Operations, and our Dynamics 365 Sales practice.

Sources

• § 14 UStG (German VAT Act), gesetze-im-internet.de
• § 27 UStG (subsection 38, transition rules), gesetze-im-internet.de
• § 33 UStDV (invoices up to EUR 250), gesetze-im-internet.de
• § 34a UStDV (small-business scheme), gesetze-im-internet.de
• § 14c UStG (incorrectly stated tax), gesetze-im-internet.de
• VAT Application Decree (UStAE), consolidated version (PDF)
• Federal Ministry of Finance: e-invoicing FAQ
• Ministry of Finance letter of 15 October 2025 (PDF)
• Ministry of Finance letter of 15 October 2024 (PDF mirror)
• IHK Dresden: e-invoicing overview and dates
• IHK Cologne: summary of the 15 October 2025 letter
• FeRD: ZUGFeRD 2.5.2
• FeRD: ZUGFeRD 2.3.3 (Factur-X 1.07.3)
• xeinkauf.de: XRechnung bugfix release, summer 2026
• xeinkauf.de: EN 16931 status and the outlook for XRechnung 4.0
• KoSIT: XRechnung Schematron (the BR-DE rules)
• KoSIT validator, releases
• KoSIT validator configuration for XRechnung, releases
• veraPDF
• Microsoft Learn: create or edit invoices (Dynamics 365 Sales)
• Microsoft Learn: customer electronic invoices for Germany (Dynamics 365 Finance)
• Microsoft Learn: electronic invoicing in Germany (Business Central)