Germany's E-Rechnung Mandate: Issuing Structured Invoices From Your Own Systems by 1 January 2027

From 1 January 2027, a German business whose turnover in 2026 was above €800,000 can no longer send a paper or PDF invoice to another German business. The invoice has to be a structured e-invoice: a data file built to the European standard EN 16931. From 1 January 2028 the threshold disappears and the rule applies to every business, apart from a few narrow exceptions.

For a small firm this arrives as a software update. For a company whose invoices come out of its own billing system, an industry package or an ERP customised over fifteen years, it is a software project, and there are about thirteen weeks left. This article is for the second group.

What the Law Says

The definition sits in § 14 UStG: an invoice "die in einem strukturierten elektronischen Format ausgestellt, übermittelt und empfangen wird und eine elektronische Verarbeitung ermöglicht". The format has to conform to the European standard under Directive 2014/55/EU (in practice, EN 16931), or be agreed between the parties, provided the required data can be extracted correctly and completely into a form compatible with that standard. A PDF does not qualify, however tidy it looks.

The obligation covers supplies to another business where both sides are established in Germany. The transition is in § 27 Abs. 38 UStG:

• Supplies made in 2025 and 2026 may still be invoiced on paper, or in another electronic format if the customer agrees, as long as the invoice goes out by 31 December 2026.
• Supplies made in 2027 get the same allowance until 31 December 2027, but only if the issuer's total turnover in the previous calendar year was not more than €800,000.
• EDI that does not meet the standard may continue for supplies made in 2027, with the customer's agreement, whatever your size.

Three details matter more than they look.

The threshold is measured on last year's turnover. Your 2027 position depends on your 2026 figure, which nobody will know precisely until the books close. If you are anywhere near €800,000, build as if you are above it.

The allowance ends on a send date. Read literally, the first transitional rule stops covering paper and PDF on 31 December 2026, even for work done in 2026. If you are above the threshold and bill in arrears, the invoice you send in the first week of January for December's work already has to be structured. Confirm this with your tax adviser, but do not plan a go-live for mid-January.

Some invoices stay out of scope: consumer invoices, cross-border invoices, small-amount invoices up to €250 gross, tickets that count as invoices, invoices from Kleinunternehmer, and supplies exempt under § 4 Nr. 8 to 29 UStG.

We are not aware of any bill to move these dates. Plan as though they hold.

Receiving Has Applied Since 2025. Issuing Is the New Part.

Since 1 January 2025, every German business has had to be able to receive e-invoices. The Federal Ministry of Finance's FAQ on e-invoicing is blunt about what that takes: "Für den Empfang einer elektronischen Rechnung genügt bereits ein E-Mail-Postfach." An inbox is enough.

Note one line in § 14 itself: where the e-invoice obligation applies, the recipient's consent is not required. A German business customer cannot refuse your structured invoice.

Issuing is a different problem. When you receive, a tool reads someone else's file. When you issue, your system is the author: if the data is wrong at source, nobody later in the chain can repair it, and an invoice that fails your customer's validation sits unpaid.

Who Gets This in an Update

Plainly: if you are a small firm invoicing out of DATEV, lexoffice, sevDesk or a similar package, your vendor ships the format. Check your master data (VAT ID, customer addresses, bank details), switch the feature on and send a test invoice. You do not need a project, and you do not need a software company.

Much the same applies to a mainstream ERP still close to standard: the vendor or your partner supplies the output, and the work is configuration and testing.

The rest of this article is for companies whose invoices come from code they own, or code nobody maintains any more:

• billing engines in subscription platforms, marketplaces and utilities, which issue invoices programmatically at volume;
• industry software for wholesale, construction, logistics or field service, where the vendor is small, slow or gone;
• ERPs whose invoice output was rewritten years ago as custom print programs, report templates or a month-end mail merge.

The Formats: EN 16931, XRechnung and ZUGFeRD

EN 16931 is the European standard. It defines the semantic model of an invoice (the fields, what they mean, which are mandatory, and the business rules between them) and binds it to two XML syntaxes, UBL 2.1 and UN/CEFACT CII.

XRechnung is the German specification on top of EN 16931, maintained by KoSIT: pure XML in either syntax, required by public authorities and equally valid between businesses. According to KoSIT's XRechnung page, version 3.0 has been in force since 1 February 2024 and stays in force until at least 31 July 2027. A preliminary version of 4.0 was published in September 2026, with the final release expected in spring 2027. You will go live on 3.0 and upgrade within your first year.

ZUGFeRD is a hybrid: a PDF/A-3 file with CII XML embedded in it. People read the PDF; machines read the XML. In France the same format is called Factur-X, and the two are technically identical. FeRD published version 2.5.2 on 4 August 2026. ZUGFeRD comes in profiles (MINIMUM, BASIC WL, BASIC, EN 16931, EXTENDED), and the ministry's FAQ accepts ZUGFeRD from version 2.0.1 "mit Ausnahme der Profile MINIMUM und BASIC-WL".

In a hybrid invoice the XML counts. The FAQ calls the structured part the "führender Teil", the leading part. If your PDF and your XML disagree, the PDF is wrong.

For most German B2B issuers the sensible default is ZUGFeRD in the EN 16931 profile, so customers who still read invoices by eye can carry on, plus XRechnung for public authorities and anyone who asks. Both should come from one internal invoice object, not two code paths.

What Has to Change in Your System

The invoice becomes data, not a layout

Many older systems build the invoice at print time: text concatenated into a template, totals summed inside the report, the VAT note a hard-coded paragraph. None of that survives EN 16931. You need a stored invoice object holding every field, with the XML and the PDF both rendered from it.

The fields that are usually missing or wrong:

• Party data. Structured addresses with ISO country codes, and a VAT ID or tax number. Free-text address blocks have to be split.
• Date of supply or service period, held as data rather than as a sentence in the header.
• Units. Each quantity needs a code from UN/ECE Recommendation 20 (H87 for piece, KGM for kilogram, DAY for day). "Stk." and "pauschal" have to be mapped.
• VAT. Every line carries a VAT category and rate. The invoice carries one VAT breakdown per combination of category and rate, and the totals must add up exactly at two decimals. Systems that round VAT per line fail here.
• Exemption and reverse charge wording. The sentence at the bottom of the PDF becomes a VAT category code plus an exemption reason.
• Payment. Payment means, IBAN and terms in structured form.
• References. The order number or buyer reference your customer's accounts payable team matches against. If you never stored it, start capturing it now.

Text-only lines ("delivery as agreed") are a common snag. In a structured invoice a line is a billable line, so that text belongs in a note.

Corrections, credit notes and self-billing

The FAQ is explicit: where the e-invoice obligation applies, a correction also has to be an e-invoice, using the invoice type for a correction. In EN 16931 it points back to the preceding invoice by number and issue date, so your system has to keep that link as data.

Watch the vocabulary. In German VAT law a "Gutschrift" is a self-billed invoice, issued by the customer by prior agreement (§ 14 Abs. 2 UStG). What an English speaker calls a credit note (a price reduction or a cancellation) is a correction. Many systems use one document type for both. Separate them before you map them, and if you self-bill suppliers, treat those documents as invoices your system issues.

A final invoice may list earlier partial payments in an attachment, provided the structured part refers to it; the FAQ confirms this continues after 2027.

Validation before anything leaves

KoSIT publishes an open source validator that checks XML against schemas and Schematron rules, with a public configuration for XRechnung. It runs from the command line, as an HTTP daemon or as a library. Put it in the sending path: every invoice is validated before it goes out, and a failure lands in a queue a named person owns, saying which field broke which rule.

For ZUGFeRD, validate the embedded XML against your profile's rules, check the PDF/A-3 container separately, and confirm the PDF shows the same totals as the XML.

Transmission

The law, says the FAQ, "sieht keinen bestimmten Weg vor": it prescribes no channel. Email with the file attached is fine. So is an API, a download portal, shared storage inside a group, or (the ministry's own example) a USB stick. Peppol is not required for domestic B2B in Germany.

The engineering work is per customer: an invoice address, a preferred format, and a record of what was sent where. A retry after a failed send carries the same document with the same invoice number. Two numbers for one supply is a tax problem, not a software one.

Archiving

At least the structured part has to be kept "unversehrt in seiner ursprünglichen Form", intact in its original form, and § 14b UStG sets retention at eight years from the end of the year of issue. Store the exact bytes you sent, with a hash. Do not plan to regenerate invoices from the database later: by then the data and the code have moved on. The same goes for e-invoices you receive.

A Plan for October to December 2026

Thirteen weeks is enough for a focused build if the source data is in reasonable shape. It is not enough to replace the billing system.

Weeks 1 and 2: inventory and decisions. List every place an invoice is produced, including manual credit notes, project final invoices and the spreadsheet for one large customer. Check 2026 turnover against the threshold. Pick the default format, and decide whether you build the generator or send invoice data to an e-invoicing provider's API.

Weeks 2 to 4: data gap analysis. Map three months of real invoices field by field to EN 16931. Mark what is missing, what must become a code, and what is calculated differently. This is where the real size of the project shows.

Weeks 4 to 9: build. The invoice object, the mapping, XML and PDF/A-3 rendering, the validator in the sending path, the failure queue and the archive. In parallel, someone cleans master data and collects invoice addresses from customers.

Weeks 9 to 11: replay and pilot. Run the last three months of invoices through the new generator and validate every one. Then pilot with a few willing customers and ask whether their systems read the files.

Weeks 11 to 13: freeze and runbook. Freeze changes in December. Write down who owns the failure queue, how a correction is issued, and what happens when a customer rejects an invoice. January invoices for December work are already in scope.

January 2027. Go live, and watch the queue daily through the first month end and the first VAT return.

Through 2027. Plan the XRechnung 4.0 upgrade before 3.0 stops being valid, and bring any group companies below the threshold across before 1 January 2028.

If you start late, cut the automation, not the validity of the output: automate the high-volume invoice types first and send rare documents through an e-invoicing tool by hand for a few weeks.

Where to Get Help

We build the connection between the system that produces your invoices and the format the law requires: data model changes, mapping, validation, transmission and archive, in your codebase and alongside your team. Our e-invoicing integration service describes how those projects run; if the mandate lands in the middle of an ERP change, see ERP modernization. The wider calendar is in our 2026 EU digital compliance guide.

We are engineers rather than tax advisers: scoping questions belong with your Steuerberater, and we build to their answer. Tell us what produces your invoices today and roughly how many go out each month: write to office@c9group.dev.