E-invoicing: ZUGFeRD and XRechnung from your ERP
From 1 January 2027, German companies with more than 800,000 € in prior-year turnover must issue their B2B invoices as structured e-invoices. We shape shop, ERP and accounting so that this becomes an automatic document flow instead of a manual compliance exercise.
01/01/2025
Obligation to receive (Sec. 14 UStG)
01/01/2027
Issue above 800,000 € turnover
01/01/2028
Issue for all B2B transactions
8 years
Retention (Sec. 14b UStG)
Setup fixed price · net plus VAT
- Structured invoice to EN 16931 instead of a PDF attachment
- XRechnung, ZUGFeRD 2.x or both in parallel from the same record
- Mandatory fields filled from ERP and shop instead of added by hand
- Handover to financial accounting without double entry
The entry price applies to a clearly delimited document route, for example generating ZUGFeRD invoices from an inventory system and handing them over to accounting. If incoming invoice processing, a Peppol connection, credit notes and cancellations or multiple entities are added, the fixed price rises accordingly. Extensions are billed via the project day at 990 € net or the hourly rate at 119 € net. The full rationale is on the pricing overview. All prices net plus VAT.
The e-invoicing mandate is not an accounting topic, it is an interface topic. The rules apply to a document whose contents come together from three systems: customer and tax data from the ERP, line items and conditions from the order, payment information from the shop or the payment provider. Wherever these data are merged by hand today, a bottleneck appears from 2027 onwards. Wherever they travel through clean interfaces, the e-invoice is merely one more output format.
From order to structured e-invoice
What the law actually requires
The German Growth Opportunities Act redefined the concept of an invoice in VAT law. Since then, an e-invoice is only an invoice that is issued, transmitted and received in a structured electronic format and enables electronic processing (Sec. 14 UStG). A PDF sent by email is therefore no longer an e-invoice but an 'other invoice'. This distinction is the core of the whole topic: it is not about the transmission channel but about the machine-readable structure of the data.
Since 1 January 2025, all German companies have had to be able to receive e-invoices in the B2B context — regardless of size or turnover. Staggered transition periods apply to issuing. Until the end of 2026, invoices may still be issued on paper or as PDFs if the recipient agrees. From 1 January 2027 this option disappears for companies with more than 800,000 € in prior-year turnover, and from 1 January 2028 for all remaining German companies (Sec. 27 (38) UStG). From 2028, existing EDI procedures must also meet the requirements of the standard.
Invoices to consumers, small-amount invoices up to 250 € (Sec. 33 UStDV) and travel tickets (Sec. 34 UStDV) are not affected. Anyone serving both B2B and B2C from the same shop nevertheless needs a clean separation in the data model — otherwise a manual glance ends up deciding which document gets which format. Precisely this case distinction belongs in the interface, not in the daily routine of the accounting team.
- 1
Since 01/01/2025: obligation to receive
Every German company must be able to accept and process e-invoices. An email inbox is sufficient as an access channel but does not replace structured downstream processing.
- 2
Until 31/12/2026: transition period
Paper and PDF invoices remain permissible provided the recipient agrees. This phase is the window for the technical changeover — after that it becomes a compliance task under time pressure.
- 3
From 01/01/2027: obligation to issue above 800,000 €
Companies whose prior-year turnover exceeds 800,000 € must issue their domestic B2B invoices as e-invoices. The threshold refers to total turnover in the preceding calendar year.
- 4
From 01/01/2028: mandatory for everyone
The obligation to issue applies to all domestic B2B transactions regardless of turnover. EDI procedures must then also deliver a format that complies with EN 16931.
- 5
From 2030: European reporting duties
The EU package on VAT in the Digital Age provides for digital reporting duties for cross-border transactions from July 2030 (Directive (EU) 2025/516). Anyone invoicing in a structured way today already has the data basis for it.
XRechnung, ZUGFeRD and what does not count
Both permitted formats are based on the same European standard EN 16931, which defines what information an invoice must contain and how it is named. XRechnung is a purely structured XML file without a visual component; it is widespread in the public sector and has been used there for years. ZUGFeRD from version 2.0.1 is a hybrid format: a PDF/A-3 document with the same data embedded as XML. People see a familiar invoice image, machines read the structure. Both routes are permissible — which one fits better depends on your recipients (German Federal Ministry of Finance letter of 15 October 2024).
| Criterion | XRechnung (XML) | ZUGFeRD 2.x (hybrid) | PDF by email |
|---|---|---|---|
| Meets the e-invoicing obligation | included | Yes, from profile EN 16931 | not included |
| Human readable | Only after visualisation | Yes, PDF view included | included |
| Machine processable | Fully | Fully via the embedded XML | Only via text recognition |
| Typical use | Public authorities, large B2B recipients | Mixed recipient groups in mid-sized companies | Being phased out in domestic B2B |
| Effort in a shop and ERP setting | Mapping onto an XML schema | Mapping plus PDF generation | No mapping, but manual rework |
| Risk on rejection | Schema validation reports errors immediately | Schema validation reports errors immediately | Errors only surface in accounting |
Not every ZUGFeRD profile meets the requirements
What has to happen in the ERP
Most ERP and inventory systems can now produce an e-invoice format. The effort rarely lies in the export itself but in the data quality before it. A structured invoice is unforgiving: if a mandatory field is missing, the document is rejected — not with a polite query but with a schema error. In our project practice these six points determine whether the changeover runs smoothly (project experience).
Complete master data
VAT identification number, full address, bank details and the recipient's electronic address belong in the customer master data model — not in a comment field.
Tax categories per line item
Every invoice line needs an unambiguous tax category: standard rate, reduced rate, exempt, reverse charge or intra-Community supply. A mere percentage does not satisfy the standard.
Buyer reference and order reference
Many recipients require a buyer reference or order number in order to assign the invoice automatically. These values have to be passed through from the shop order into the invoice document.
Consistent amounts
Line totals, tax amounts and the invoice total have to add up. Rounding differences from gross-to-net conversion are one of the most common reasons for rejection.
Credit notes and cancellations
Correction documents need the same structured route as the original invoice, including a reference to the corrected invoice. A manually created cancellation PDF breaks the chain.
Archiving the original
What must be retained is the structured record, not just the visual rendering. Invoices must be archived in an audit-proof manner for eight years (Sec. 14b UStG).
What has to happen in the shop
In most cases the shop is not the invoicing system — but it is the source of a considerable share of the mandatory information. Anyone who does not distinguish cleanly between business and private customers at checkout, or captures the VAT identification number as free text only, merely shifts the problem into accounting. These points therefore belong in the shop configuration before the document route is switched over.
- Distinguish the customer type at checkout: business and private customers need different document routes. The decision has to be attached to the record, not guessed from the invoice amount.
- Capture the VAT identification number in a structured field and validate it instead of writing it into a comment box. Only then can reverse charge be derived reliably.
- Maintain buyer reference and order number as dedicated fields and pass them into the invoice document via the interface.
- Transfer the delivery date or service period, because this value is expected in the structured invoice and cannot always be derived from the invoice date.
- Pass payment method and payment status on to the document route so that already-paid invoices are flagged correctly — see the page on payment integration.
- Stop treating the invoice PDF as the original: the structured record is the original, the visual component is an addition.
Do you know whether your documents would already be compliant?
We check a real sample invoice from your system against the standard and tell you which fields are missing and where they have to come from.
Transmission routes: how the invoice arrives
The law does not prescribe a particular transmission procedure. Anything that carries the structured record unchanged to the recipient is permissible. In practice three routes have become established, and they differ considerably in effort and degree of automation. Which route fits depends less on your own technology than on your recipients — larger customers and public authorities often dictate the channel.
Email with attachment
The simplest route: the XML or hybrid file is sent as an attachment. A dedicated inbox is enough to receive them. The downsides are the missing delivery confirmation and weak automation on the incoming side.
Peppol network
A standardised network with a unique recipient address and proof of delivery. Sensible if you supply many business customers or public authorities and want to automate dispatch end to end.
Recipient portal or API
Large trading partners run their own supplier portals or interfaces. These routes can be bundled through a middleware so that each channel does not create its own special logic inside the ERP.
Learn moreHow a changeover project runs
Inventory of document routes
We record which document types are created today — invoices, credit notes, cancellations, prepayments, collective invoices — and which system each of them comes from. There are often more routes than the org chart suggests.
Field-by-field comparison against the standard
Using a real sample invoice we check field by field which mandatory entries exist, which are missing and which source they have to come from. The result is a concrete gap list rather than a general recommendation.
Fixing data quality in shop and ERP
Missing master data, ambiguous tax categories and missing references are corrected before the technical changeover starts. This step determines the success of the entire project.
Mapping and format generation
We map the standard onto your data model and produce XRechnung, ZUGFeRD or both from the same record. The output is validated against the schema before any document leaves the building.
Test run with real recipients
Before going live we send test documents to selected customers or portals and evaluate the responses. Only once that round runs cleanly do we switch over.
Handover to accounting and archiving
The generated documents flow into financial accounting in structured form — for example via the DATEV integration — and are archived in an audit-proof way. After that, e-invoicing is a normal part of day-to-day business.
Typical pitfalls from project practice
The most common mistake is assuming that enabling an export function settles the matter. In reality the work only starts there. A second classic is rounding differences: shops frequently calculate with gross prices, ERP systems with net prices. If both sides round differently, the invoice total deviates by a few cents from the sum of the line items — and validation rejects the document. Such differences can only be resolved cleanly in one place, namely in the interface.
A third point concerns attachments. Delivery notes, timesheets or test certificates that are sent along as additional PDF pages today belong in the structured world either as an embedded attachment inside the document or in a separate process. Anyone who simply drops them loses information on which the customer bases their approval. Finally, many companies underestimate the incoming side: the obligation to receive already applies, but an inbox into which structured files drop without anyone processing them satisfies the letter of the law while saving not a single minute of work.
Why the changeover becomes an automation project
The obligation forces structured data — and structured data is exactly the precondition for automating the entire document flow. If you have to make the change anyway, you can combine it with connecting financial accounting, payment reconciliation and archiving. The additional effort for that is considerably smaller than running two separate projects.
- One data model for outgoing invoices, accounting and the archive
- Payment assignment based on the same references
- Fewer queries because documents arrive complete
The essentials on the e-invoicing mandate
- All German companies have had to be able to receive e-invoices since 1 January 2025 (Sec. 14 UStG).
- Companies with more than 800,000 € in prior-year turnover must issue them from 1 January 2027, all others from 1 January 2028 (Sec. 27 (38) UStG).
- Permitted formats are structured formats to EN 16931, in particular XRechnung and ZUGFeRD from the EN 16931 profile; the MINIMUM and BASIC WITHOUT VAT profiles are not sufficient (Federal Ministry of Finance letter of 15 October 2024).
- A PDF in an email attachment no longer counts as an e-invoice but as an 'other invoice'.
- The effort almost always lies in the data quality of shop and ERP, not in the export itself.
- Setup fixed price from 1,490 € net per document route, extensions at the project day of 990 € net — details on the pricing overview.