In short and in plain language
This is about new rules for electronic invoices between firms.
The article explains what these rules mean for your shop. It shows the path of an invoice from the order to the archive.
Key questions are: What kind of invoice does the shop create? How does it get into the accounts? How is it stored?
We check the invoice path in your shop. We install needed updates in a planned time slot.
Two clocks are running on invoicing in a German shop, and only one of them still has a transition period. Issuing may continue on paper, and with the recipient's consent in another electronic format, for the time being – but for supplies from 1 January 2027 only if the issuer's prior-year total turnover was no more than 800,000 euros (Section 27 (38) UStG, German VAT Act). For receiving, no such period exists. This article follows the path from the order in the shop to the archive: which format is produced, how the document reaches accounting, what a test system actually verifies and what happens to retention.
Key takeaways
- For supplies from 1 January 2027, paper remains permitted only if prior-year total turnover was no more than 800,000 euros (Section 27 (38) UStG). The figure that decides this is the 2026 turnover.
- An e-invoice is a structured document, not a file with a layout: issued, transmitted and received in a structured electronic format that allows electronic processing (Section 14 (1) UStG).
- Permitted are the XRechnung standard and, under certain conditions, ZUGFeRD from version 2.0.1 without the MINIMUM and BASIC-WL profiles; the basis is the EN 16931 series with XML as the data format (Federal Ministry of Finance).
- Receiving allows no delay: domestic businesses must create the technical conditions for it, and issuing does not require the recipient's consent (Federal Ministry of Finance letter of 15 October 2025).
- Retention runs for eight years (Section 14b (1) UStG), and the structured part must remain intact in its original form (Federal Ministry of Finance) – what gets backed up is the file, not the printout.
Two deadlines, two obligations
German VAT law defines the structured document in its own terms: an electronic invoice is an invoice issued, transmitted and received in a structured electronic format that allows electronic processing (Section 14 (1) UStG). A PDF attached to an email does not qualify; it is an ordinary invoice in an electronic format, technically a picture of an invoice. The difference is not cosmetic: the structured document can be read in, checked and posted without an intermediate step, whereas the PDF needs eyes or text recognition.
The obligation to issue applies to supplies between domestic businesses. As a transitional measure, an invoice may still be transmitted on paper and, subject to the recipient's consent, in another electronic format until 31 December 2026; for supplies from 1 January 2027 that only holds if the issuer's total turnover in the preceding calendar year was no more than 800,000 euros (Section 27 (38) UStG). A third transition covers electronic data interchange: EDI runs with the recipient's consent until 31 December 2027, regardless of turnover. For shop planning this means the decisive figure is the 2026 turnover, and it is only final long after the switch-over should have been prepared.
The cut-off date hangs on last year's turnover
What an e-invoice technically is
The basis is not a German invention. Directive 2014/55/EU calls for a common European standard for the semantic data model of the core elements of an electronic invoice; CEN implemented it technically with the EN 16931 series, which prescribes the structured data format XML (Federal Ministry of Finance letter of 15 October 2025). Everything that counts as an e-invoice is therefore an XML document with defined fields – invoice number, supply date, tax rates, amounts, address data – and not a layout.
Two national formats meet that requirement in practice: the XRechnung standard as pure XML, and the hybrid ZUGFeRD format from version 2.0.1, excluding the MINIMUM and BASIC-WL profiles (Federal Ministry of Finance letter of 15 October 2025). Hybrid means a PDF file carries the XML embedded inside it. People see the familiar page, accounting reads the structured part. For a shop that has been sending invoices as PDFs, that is often the shorter route – delivery by email stays as it is, the content becomes machine-readable.
| Document | What it contains | As an outgoing B2B invoice from 2027 |
|---|---|---|
| Paper invoice | Print without a data model | Only below the turnover limit, at the latest until the end of 2027 (Section 27 UStG) |
| PDF email attachment | Layout without a data model | Ordinary invoice, does not replace the e-invoice |
| XRechnung | XML per EN 16931 | Permitted format (Federal Ministry of Finance) |
| ZUGFeRD from 2.0.1 | PDF with embedded XML | Permitted, without the MINIMUM and BASIC-WL profiles (Federal Ministry of Finance) |
| EDI message | Agreed format | Transition until the end of 2027 with consent (Section 27 UStG) |
The table answers the question of format, not the question of route. A shop that produces valid XML but sends it to an address nobody ever looks into has met the obligation on paper and still brought operations to a halt. That is why a switch-over starts with a survey of the whole route, not with the choice of a format.
What the shop has to be able to do
The shop is rarely the only system in this chain. It either produces the document itself or supplies the data another system turns into one. Both designs occur, and both need the same checks: the mandatory details have to sit in the structured part, not only in the visible layout. An amount that is printed in the PDF but empty in the XML shows up when the file is read in – as a rule at the recipient's end, rarely before.
Structured export
The shop produces XRechnung or ZUGFeRD from version 2.0.1, not just a PDF that looks the same. What counts is whether the fields defined by EN 16931 are filled.
Complete master data
Recipient, tax rates, payment terms and the VAT details belong in the data model. A free-text field is no substitute for them.
Number ranges without gaps
Invoice and credit-note numbers continue unbroken even when documents start coming from a different branch of the system. Duplicate numbers typically surface only during an audit.
Dispatch with evidence
The sending path logs delivery and failure. An invoice stuck in the queue is otherwise invisible from inside the shop.
Handover to accounting
The export runs on schedule and reports when it fails. Without that report, a failed run looks exactly like a day without invoices.
Retention of the original
The structured part is stored so that it remains intact in its original form (Federal Ministry of Finance). What is kept is the file that was produced.
These six points can be checked one by one, and that is exactly how they belong in the preparation: as a list with ticks, not as a feeling. Anyone surveying the invoicing route for the first time tends to find more than the format question – outdated extensions, duplicate number ranges, an export that has been writing empty files for months. We build this survey into Shopware maintenance as a fixed step ahead of the switch-over date.
The invoice path through the systems
Four stations are enough to describe the route: the order arises in the shop, an invoice document is produced from it, the document goes to the recipient and to accounting, and it ends up in the archive. Something can be lost at each handover, and each handover can be measured. Writing the four stations down once also produces the check list for the test system.
The practical entry point is a single sample invoice. It is produced in the test system, saved as a file and inspected – not in the shop's preview window, but as a raw file. Anyone looking into an EN 16931 XML for the first time recognises the mandatory fields immediately; they carry self-explanatory names.
<!-- Extract from an EN 16931 invoice, shortened -->
<Invoice>
<ID>2027-000148</ID>
<IssueDate>2027-01-08</IssueDate>
<InvoiceTypeCode>380</InvoiceTypeCode>
<DocumentCurrencyCode>EUR</DocumentCurrencyCode>
<AccountingSupplierParty>
<Party>
<PartyName><Name>Beispielbetrieb</Name></PartyName>
</Party>
</AccountingSupplierParty>
<TaxTotal>
<TaxAmount currencyID="EUR">38.00</TaxAmount>
</TaxTotal>
<LegalMonetaryTotal>
<PayableAmount currencyID="EUR">238.00</PayableAmount>
</LegalMonetaryTotal>
</Invoice>The field names are unwieldy, the check is not: invoice number, date, currency, tax amount and payable amount each appear as their own element and can be held against the document in the shop. If an amount differs, the fault lies in the generation and not with the recipient. That comparison later replaces the guesswork when an invoice comes back.
The second comparison concerns dispatch and handover. Both usually run as a background job: a run that produces, exports or sends documents overnight. If it fails, nothing announces it by itself. That is why the invoice run belongs in the same monitoring as the shop's other cron jobs and imports.
Receiving is the obligation already in force
There is a transition period for issuing, but not for receiving. Domestic businesses must create the technical conditions for receiving an e-invoice; anyone technically unable to do so, or refusing to accept one, has no entitlement to an alternative ordinary invoice from the issuer (Federal Ministry of Finance letter of 15 October 2025). For a shop operator that means: even a business still allowed to issue on paper is already receiving structured incoming invoices from suppliers and service providers.
A second point is often overlooked in practice: issuing an e-invoice to another domestic business does not require the recipient's consent (Federal Ministry of Finance letter of 15 October 2025). A supplier can therefore switch without asking first. A business with no route for receiving collects XML files in a mailbox nobody opens – and finds the documents only once accounting starts missing them.
An address somebody actually reads
Taking stock before the switch-over
Before the first change comes a survey of what happens today. It costs a few hours and saves several rounds of guesswork later. Two questions carry the survey: where does the invoice data come from, and who processes it afterwards? Everything else – format, sending route, filing – follows from the answers to those two.
The survey belongs in the same file as the shop's other mandatory information. A shop that already maintains terms, withdrawal instructions and price details on a regular basis has the rhythm for it; the details on the invoice are then one more item on the same list.
- Which system produces the outgoing invoice today: the shop, the ERP system or a connected billing system?
- Which format leaves the building – paper, PDF, XML, or several routes at once?
- Are recipient, tax rates and payment terms filled in the data model or only printed in the layout?
- Which route does the document take out, and where exactly is delivery logged?
- How does the invoice reach accounting: export, interface or a collected folder?
- Which address accepts incoming invoices, and who looks into it on a fixed schedule?
- Where does the invoice sit afterwards, how long does it stay readable there, and who can prove it?
The test system decides, not the announcement
A format switch is hard to judge on the live system, because every test run there produces a real invoice. The place for it is a staging environment with a copy of production data where documents may be created without consequences. What matters is that dispatch from there goes nowhere: a test system sending real invoices to real customers is the more expensive mistake.
Testing happens in three steps. First generation: does a structured file appear at all, and does it carry the mandatory fields? Second content: do amounts, tax rates and address data match the order? Third handover: does the file arrive where it is processed, and is a failure reported? Only when all three steps have evidence behind them is the switch-over more than an intention.
The testing itself belongs in a fixed frame. A switch-over squeezed in between two orders leaves no evidence and no way back. Put it into a maintenance window with an announcement and a rollback point instead, and you end up with a date, a list of verified points and a state you can roll back to.
Retention: eight years, structured part
The retention period is set by law and is independent of the format: a business must keep a copy of the invoices it has issued as well as all invoices it has received for eight years (Section 14b (1) UStG); the period starts at the end of the calendar year in which the invoice was issued. For an e-invoice there is an additional requirement as to form: at least the structured part must be kept so that it remains intact in its original form (Federal Ministry of Finance letter of 15 October 2025).
In practice that means the XML file itself is preserved, not a printout of it and not a freshly rendered preview. A shop that only renders documents from the database on demand has, strictly speaking, filed no original. That distinction later decides whether a backup holds up when it matters – the same question as with retention of personal data, only with a different period.
Two pieces of evidence are enough: that the file sits where it is supposed to sit, and that its content has not changed since it was written. A checksum per document costs almost no compute time and answers the second question later without discussion. The first question is answered by reconciling document numbers against the database – gaps show up there faster than in a spot check.
The schedule up to January
A business that has to issue structured invoices in January 2027 has barely a quarter left, and peak season sits inside it. A realistic sequence puts the survey into October, the switch-over in the test system into November and the go-live into a maintenance window in December or the first week of January – before the first invoice of the new year, not after it.
Peak season falls between November and January, and many shops run a change freeze during it. Pushing the switch-over behind that leaves three weeks for a task that raises questions. The same round is a good moment to look at forgotten test sites and stale subdomains: an old test site still producing and sending real invoices stops being a side issue once the format changes.
Ist ein Unternehmer technisch nicht in der Lage, eine E-Rechnung empfangen zu können, bzw. verweigert er die Annahme, hat er kein Anrecht auf eine alternative Ausstellung einer sonstigen Rechnung durch den Rechnungsaussteller.
After the switch-over: running operations
The first structured document does not close the task, it moves it. Formats are revised, extensions updated, tax rates changed, and every one of those changes touches the invoice run. An update that quietly switches invoice generation to a different profile tends to surface at the recipient's end first when nobody is checking.
That is why invoice dispatch belongs in the same routine as security updates and backups after the switch-over: a regular look at the most recently produced files, an alert on failures and a note on which extension is involved. Keeping extension licence expiry dates in view means not losing access in the middle of January to the very update that fixes a format error.
What belongs in the maintenance plan
Sources and legal basis
Related Articles
Shopware Updates: Safe Deployment
Plan and deploy Shopware updates safely: staging environment, regression testing, rollback plans and plugin compatibility for live operations.
Shop Server Logs: How Long IP Addresses May Be Stored
How long may IP addresses stay in server logs? What the GDPR requires, what the five weeks from the BfDI mean, and how rotation, truncation and backups fit in.
WordPress security updates: what old branches still get
WordPress 7.1.2 closed a critical flaw and the fix was backported to 4.7 as a courtesy. What older branches receive, what they do not, and when to move up.