In short and in plain language
This post explains what new rules for invoices mean for your shop.
It shows how a file to look at differs from data a program can read.
It follows the path of an invoice from the sale to the archive. At each step it shows what you can check. This also covers invoices that come in to you.
The post does not replace advice on tax.
We build shops that also create data for programs after each sale.
On 1 January 2027 the first transition period of the German e-invoicing obligation for business-to-business trade comes to an end. Until 31 December 2026, Section 27 (38) of the German VAT Act still allows an invoice to be sent on paper or — subject to the recipient's consent — in any electronic format; after that, the relief only applies to companies whose turnover in the previous calendar year did not exceed EUR 800,000. For an online shop this is not an accounting question but a question about your own system: what format does the shop produce after an order today, where does the file go, and what happens when an invoice arrives as a structured record? The answer is rarely visible in the shop interface. It sits in the invoice template, in the delivery route of the order confirmation and in the fields the checkout asks for at all. According to a survey by the German digital association Bitkom, shortly before the receiving obligation took effect only 45 per cent of companies in Germany were able to accept an e-invoice — the technical side reliably lags behind the legal one. This article follows the invoice from checkout to archive and names what has to change at every stop. It explains the legal position for work on a shop and a website and does not replace tax advice in an individual case.
Key points at a glance
- An electronic invoice is a document in a structured electronic format that allows electronic processing (Section 14 (1) UStG). A PDF attached to the order confirmation is therefore an other invoice, not a structured record.
- Until 31 December 2026 paper or another electronic format remains permitted with the recipient's consent (Section 27 (38) UStG). From 2027 that relief only carries up to a previous-year turnover of EUR 800,000.
- Electronic data interchange via EDI remains possible with the recipient's consent until 31 December 2027 (Section 27 (38) UStG) — the deadline that matters for shops connected to a large customer's purchasing system.
- The obligation to receive is already in force. Anyone unable to accept an e-invoice, or refusing to accept one, has no claim to an alternative other invoice (Federal Ministry of Finance circular of 15 October 2025).
- Invoices up to EUR 250 may still be sent as an other invoice (Section 33 UStDV). For a shop with small baskets this is the most important exception.
- Invoices must be kept for eight years (Section 14b UStG), and for an e-invoice at least the structured part must remain intact (Federal Ministry of Finance circular of 15 October 2025). A printout is not an archive.
What the law calls an e-invoice — and what only looks like one
The distinction everything turns on sits in a single sentence of the German VAT Act: an electronic invoice is an invoice issued, transmitted and received in a structured electronic format that allows electronic processing (Section 14 (1) UStG). Everything else — paper as much as any other electronic format — is an other invoice (Section 14 (1) UStG). That puts exactly the file most shops send after a purchase on the wrong side: the Federal Ministry of Finance expressly counts all unstructured electronic files, for example PDF files without embedded data records, as other invoices. An invoice is therefore not electronic in the sense of the law merely because it arrives by email. What counts is whether an accounting system can take over the amount, the tax rate and the line items without retyping.
Behind this sits the European standard series EN 16931, with which the European Committee for Standardization implemented Directive 2014/55/EU; it prescribes the use of the structured data format XML (Federal Ministry of Finance circular of 15 October 2025). In Germany the XRechnung standard and — under certain conditions — the ZUGFeRD format meet that requirement. For work on the shop this means the task is not a new invoice layout but a second file alongside the document the customer looks at. Setting up that separation early avoids rebuilding twice. How deeply the distinction between business and private customers reaches into pricing is shown in the article on customer groups and net prices in a B2B shop.
The PDF attachment is the most common misconception
Who is affected from 2027 — and who has time until the end of 2027
The transition rule in Section 27 (38) UStG stages the obligation in three steps, and it distinguishes by the issuer's turnover rather than by the size of the shop. For supplies carried out up to 31 December 2026 the invoice may still be sent on paper or — subject to the recipient's consent — in an electronic format that does not meet the definition. For supplies from 1 January 2027 the same relief only remains if the issuer's total turnover in the preceding calendar year did not exceed EUR 800,000. Anyone above that issues structured invoices from the first supply of 2027. The decisive figure is the previous calendar year, not current turnover — so the outcome is already settled with the 2026 annual accounts.
A third stage concerns electronic data interchange. Where the invoice was transmitted via EDI, it remains permissible in a diverging format with the recipient's consent until 31 December 2027 (Section 27 (38) UStG). That affects the classic web shop less than cases where a shop is connected to a larger customer's purchasing system and orders run through an existing interface. The direction of view matters: these deadlines only concern issuing. Receiving has been mandatory since 1 January 2025 without any transition period, and anyone who has not prepared for it notices with the first supplier invoice. Which services belong together here is set out under services.
Turnover up to EUR 800,000
For supplies from 2027, paper or another electronic format remains permitted with the recipient's consent until the end of 2027 (Section 27 (38) UStG). That consent should be documented, otherwise the basis is missing in a dispute.
Turnover above that
Structured invoices are issued from the first supply of 2027. The rebuild needs lead time because master data, number ranges and the delivery route are all affected at once.
EDI connections
With the recipient's consent, EDI continues until the end of 2027 (Section 27 (38) UStG). After that the data stream has to meet the standard — the connection stays, the format changes.
- Total turnover of the previous year within the meaning of Section 19 (2) UStG, not turnover of the current year
- Share of sales to other businesses for their business — only there does the obligation apply
- Whether invoices currently travel via EDI or through an interface into a customer's purchasing system
- Whether the recipient is based in Germany, because the obligation covers domestic business-to-business supplies
- Whether your baskets regularly stay below the small-amount threshold of EUR 250 (Section 33 UStDV)
What your shop actually produces today
Taking stock does not start at the tax adviser's desk but in the checkout flow. Three questions are enough for a first finding: does the shop create the invoice itself or does it hand the order to an inventory or accounting system? Which file leaves the system — a PDF rendered from a template, an HTML email body or a data record? And is the invoice available for download in the customer account or only in the outbox? In many installations the shop software creates the document itself and attaches it to the confirmation email. That is exactly the lever: converting the document into a hybrid format at that one point changes neither layout nor delivery route. What an online shop has to deliver here depends less on the shop platform than on the question of who assigns the invoice numbers.
In installations built on WordPress with a shop extension, invoice generation often sits in a separate add-on whose templates have grown over the years. There is regularly a second invoice route for special cases — prepayment, partial delivery, credit note — that gets forgotten during the rebuild and then remains the only one still producing plain PDF files. A complete list of every document type the system can produce is therefore the first real working step. It is also the basis for testing: every document type has to be generated once, opened and read back in by machine before the deadline counts.
| Feature | Other invoice | E-invoice |
|---|---|---|
| Form | Paper or unstructured file | Structured electronic format to EN 16931 |
| Legal basis | Section 14 (1) UStG (other invoice) | Section 14 (1) UStG (electronic invoice) |
| Recipient's consent | Required for electronic transmission | Not required between domestic businesses |
| Processing at the recipient | Visual check, retyping or text recognition | Direct import without a media break |
| Typical file | PDF without embedded data records | XML or a hybrid format with an XML part |
| Created in the shop by | Invoice template in the shop system | Invoice template plus record generation |
| From 2027 above EUR 800,000 turnover | No longer permitted for domestic B2B supplies | Mandatory |
| Retention | Keep the file readable for eight years | Structured part intact for eight years |
The route an invoice takes after the order
After checkout the same thing happens in most shops: the customer receives a confirmation, the system reserves an invoice number, and somewhere between payment and dispatch the document is created. Which of these stations produces the invoice decides where the structured record has to be created. If the document hangs off the payment status, so does the record — and every new payment method brings a new trigger with it. Which routes are common and where they trip people up is described in the article on payment methods in an online shop. For the changeover what matters most is that there is exactly one place where an invoice comes into being. Two parallel generators are the surest route to two different invoice numbers for the same transaction.
The second part of the route is transmission, and here the law is more open than many assume: e-invoices may be transmitted by email, by download from an internet portal, via EDI, by providing the data through an electronic interface or through shared access to a central storage location (Federal Ministry of Finance circular of 15 October 2025). A customer account with a download is therefore expressly among the permitted routes. The condition is that the file sits there reliably and stays retrievable — which is a question of web hosting and backups rather than of shop software.
The delivery route is freer than the format
- Checkout: the shop records the transaction and takes the billing address from the customer account
- Customer type check: business customer with a VAT identification number, or private customer
- Define the trigger: payment received, dispatch or partial delivery creates the document
- Generation: the structured record and the human-readable view are created in the same step
- Transmission: attached to the email, filed in the customer account or handed to an interface
- Filing: the structured part goes into the archive unchanged, before anyone opens it
Incoming invoices: the obligation that is already running
The issuing side has a deadline, the receiving side does not. Domestic businesses have to create the technical conditions for receiving an e-invoice (Federal Ministry of Finance circular of 15 October 2025) — regardless of whether they issue structured invoices themselves. The consequence of neglecting it is stated even more plainly: if a business is technically unable to receive an e-invoice, or refuses to accept one, it has no claim to an alternative other invoice from the issuer. For running a shop that means one thing above all: the inbox where supplier invoices arrive belongs in the inventory just as much as invoice output. In ongoing website care this is the point that is documented least often.
In practice, being able to receive means an address that accepts XML attachments, a storage location where the file lands unchanged, and a way to produce a readable view from the record. The last part is necessary because the structured format serves machine processing in the first place and is not suited to a visual check by the human eye. Anyone who wants to verify an invoice therefore needs a rendering — with a hybrid format the file brings it along. How closely mandatory details and machine readability are otherwise linked is shown in the article on mandatory information under GPSR and ProdSG.
Point of acceptance
An address that does not filter XML attachments, and someone responsible for reading it. A separate mailbox purely for e-invoices is not required (Federal Ministry of Finance circular of 15 October 2025).
Unaltered filing
The structured part goes into the archive in its original form before anyone opens, renames or converts it. After that, integrity can no longer be demonstrated.
Readable view
It must be possible to render the record, otherwise no substantive check is possible. With hybrid formats the view is part of the same file.
A dedicated mailbox is not required
Customer account, master data and mandatory details
A structured record is less forgiving than a PDF: what is missing is visibly missing, because the receiving system expects the field. That moves the customer account to the centre. The billing address has to be complete, the company name has to appear in the form in which it is entered in the commercial register, and for business customers the VAT identification number belongs in a field of its own rather than in a comment box. An order without those details later produces an invoice that is formally incomplete — and nobody notices when it is sent, only at the recipient. Anyone who knows the same care from other mandatory details will find the comparison in the article on mandatory details in an online property listing.
Two fields cause most of the rework in practice. The first is the distinction between private and business customer: without it there is no way to decide whether a structured invoice is required at all, because the obligation covers supplies to another business for that business. The second is the routing or reference identifier that some recipients need in order to allocate the invoice. Both belong in the checkout as fields, not as a free-text line. That an extra mandatory field can raise the abandonment rate is a genuine conflict of aims — it can be defused by showing the question only after the customer has selected “business customer”. The trade-off is similar for a digital menu with allergen information, where mandatory details and usability compete for the same space.
- Full name and full address of the supplying business and of the recipient
- Tax number or VAT identification number of the issuer
- Date of issue and a sequential invoice number assigned only once
- Quantity and type of the goods supplied, or the scope and type of the service
- Date of the supply or service, kept separate from the invoice date
- Consideration broken down by tax rate, plus the tax amount attributable to it
- For business customers, the recipient's VAT identification number in a field of its own
Retention: eight years on the structured part
Under Section 14b UStG, invoices issued and received must be kept for eight years, and the period starts at the end of the calendar year in which the invoice was issued. An invoice from January 2027 therefore has to remain accessible until the end of 2035. For filing this means more than a folder structure: for an e-invoice at least the structured part has to be kept so that it is available intact in its original form (Federal Ministry of Finance circular of 15 October 2025). A newly generated PDF, an export from the accounting system or a printout does not meet that. Whether the archive survives an outage only shows in an emergency — the article on testing backups and restores describes how to check that beforehand.
Eight years is longer than most contracts for shop software and support run. Retention therefore becomes a contractual question rather than a settings question: who owns the archive files, in what format are they handed over on a change of provider, and how long does access remain available after the cooperation ends? Anyone reviewing terms and notice periods anyway will find the structure in the article on website contracts, terms and notice periods. An archive copy that only exists inside the shop system is not retention but a bet on that system's continued existence.
A printout is not an archive
How to approach the changeover step by step
The order that works starts with a list rather than with software. First step: which document types does the system produce today, and which of them go to business customers? Second step: what was last year's turnover, and which deadline does that give you under Section 27 (38) UStG? Third step: which fields are missing in the customer account so that a complete record can be produced? Only then comes the question of the format and the module that creates it. An online shop that has been through these steps usually needs less time for the changeover itself than for taking stock beforehand.
That leaves testing, and it is the part you cannot skip. One test invoice per document type, produced in the live system, sent to a real recipient and read back in there — that is the only evidence that counts before the deadline. According to the Bitkom survey, 55 per cent of companies were already using e-invoicing for outgoing invoices, and among receiving formats EDI formats were the most widespread at 71 per cent; a recipient able to check your file is therefore usually available already. If you want the changeover accompanied in an existing system, ongoing website care is the framework for it; for a first assessment the contact form is enough.
Sources and studies
Related Articles
Wine, spirits, e-cigarettes: age checks in your webshop
What the German Youth Protection Act requires when shipping alcohol, tobacco and e-cigarettes, and how a shop checks per product, at checkout and on delivery.
Selling to EU consumers: threshold, OSS and VAT rates
Above 10,000 euros of distance sales to other EU countries, the VAT of the delivery country applies. What the shop needs: rates, prices, checkout, OSS report.
Restaurant website: menu, allergens, ordering
The menu as a page instead of a PDF: declaring allergens under Annex II, stating total prices correctly and building an ordering path that holds up.