From 1 January 2027, an issuer with prior-year turnover above EUR 800,000 must send invoices for domestic B2B supplies made from that date as structured e-invoices (XRechnung or ZUGFeRD 2.0.1 and later), not plain PDFs. Smaller issuers follow a year later. We'd buy delivery and validation, build only the mapping from your billing data to the format's fields, and name an owner this week. Receiving has been mandatory since January 2025.
Does the 1 January 2027 date apply to your SaaS?
Who must issue an e-invoice from 2027, and who from 2028
The Federal Ministry of Finance's (BMF) FAQ on the E-Rechnung, last updated 29 October 2026, says all issuers can use a plain invoice until 31 December 2026. Issuers whose turnover in the previous calendar year was EUR 800,000 or less keep that option until 31 December 2027 (a PDF by email needs the customer's consent). After that, everyone issues e-invoices. Section 27(38) of the UStG, the German VAT act, says the same, and it keys on the date of the supply, not the invoice.
Whose turnover counts? The issuer's, for the prior year. A SaaS that crossed EUR 800,000 in 2026 is in for 2027 supplies.
Receiving is separate and already live. Every business has had to be able to receive an e-invoice since 1 January 2025, and an email inbox is enough. Small businesses still have to be able to receive.
If you sell from outside Germany
The BMF defines a domestic business by where it has its seat, its management, or an establishment that takes part in the turnover. If you meet one of those in Germany, you're in. If you don't, or you issue invoices in your customers' names, confirm your case with a German tax adviser before you decide anything else.
B2C sales, invoices up to EUR 250 gross, many tax-exempt supplies and small-business issuers are out of the obligation.
What does "e-invoice" mean for the invoice your product sends?
An e-invoice is issued, sent and received in a structured electronic format that allows automatic processing. A PDF alone is what the BMF calls a "sonstige Rechnung", an other invoice, and it stops being enough after the transition.
The BMF says XRechnung and ZUGFeRD from version 2.0.1 satisfy the VAT rules, except the MINIMUM and BASIC-WL profiles of ZUGFeRD. You can also agree another format with your customer if the data can be extracted correctly and completely.
ZUGFeRD is a PDF with XML embedded. XRechnung is XML only. In both, the XML is now the leading part, so what the customer's system reads is what counts, not what the PDF shows.
Three rules shape the engineering:
- Every VAT-mandatory field has to sit in the structured part. A reference to an unstructured attachment doesn't count, though extra detail may travel as an embedded attachment.
- Corrections, including credit notes, must be e-invoices too.
- You archive for eight years, at least the structured part, unaltered.
Validation against the official schema is sensible but not a condition for tax recognition. Delivery has no prescribed channel: email, an interface or a portal download all work, and Peppol (a delivery network for e-invoices) isn't required.
The BMF's view is that missing the duty isn't a regulatory offence. Input VAT deduction at the customer can be affected, though the BMF notes relief in practice, and the customer has a civil claim to a correct e-invoice. For your German customers, that's a support ticket and a delayed payment, which is reason enough.
What must ship before 1 January, in order
- Map your billing data to the EN 16931 fields, the EU standard behind XRechnung and ZUGFeRD. Start here, because every gap is a missing field in your own data.
- Give each invoice line a structured description. A free-text plan name like "Team plan" may not let the tax office determine the service, which is the BMF's test for the structured part.
- Emit credit notes and corrections as e-invoices, from the same code path.
- Add a validation step before anything is sent.
- Pick a delivery channel and store a receiving address per customer.
- Archive the structured file with the invoice record.
- If you also buy from German suppliers, make sure someone reads the inbox.
Step 3 has the least settled rules. The BMF says the correction types aren't fixed in the standard yet, so for now any practicable correction with a suitable invoice type is accepted. Pick one and write it down.
Build or buy: where is the line?
Stay on your billing tool and add a partner
Stripe's documentation says Stripe Invoicing creates invoice records and exposes them through its API and webhooks, but doesn't generate or transmit legally compliant e-invoice files on its own. Its options are an app from the Stripe App Marketplace (Billit is its preferred partner) or your own webhook integration on invoice.created. If you're still choosing a billing tool, check who is the seller on a Stripe or Paddle invoice first, because the seller is the issuer who has to send the e-invoice.
Buy a provider API for generation, validation and delivery
You send your invoice data, the provider returns a valid file and delivers it. Peppol is optional in Germany, so you don't need an access point just for the mandate, unless a customer asks for it. On a January 2025 Hacker News thread about Peppol, one commenter put the basic yearly membership at EUR 2,000 and others objected to per-invoice fees; another said an access point checks that intermediate values are calculated and rounded correctly, not just the schema. Those are commenter reports, not price lists. Ask two or three providers for a quote against your monthly invoice count.
Build generation yourself
Mustang is an open-source Java library under the Apache 2.0 licence that reads, writes and validates ZUGFeRD, Factur-X and XRechnung. Release 2.26.0 supports XRechnung 3.0.2, the version KoSIT currently publishes, and ZUGFeRD 2.5.0. KoSIT publishes an open-source validator and a test suite repository, so you can test without a vendor.
You still own the mapping and the corrections flow, and you own the library upgrade when the standard moves. If a contractor builds it, settle who maintains it first; our guide to a software maintenance contract covers that, and what a European software team costs helps size the job.
| Starting point | What it gives you |
|---|---|
| Stripe e-invoicing docs | Webhook and partner pattern |
| Mustang project | Open-source writer and validator |
| KoSIT XRechnung FAQ | Official validator and test suite |
Our call: buy transport and validation, because that's plumbing with no product value. Build the mapping, because it's your data model and no vendor can see it for you.
Worked example: a 14-person SaaS with EUR 2.4M turnover
Illustrative: the SaaS invoices German GmbH customers monthly, with EUR 2.4M turnover in 2026.
- Does it reach us? 2026 turnover is above EUR 800,000, so supplies from 1 January 2027 need e-invoices. A 400,000 EUR issuer could still send plain invoices through 2027.
- Is the data there? The invoice carries only a free-text plan name, so the line needs structured content, and attaching the PDF doesn't fix it.
- What about downgrades? A credit note after a plan downgrade goes through the same path.
The outcome: keep the billing tool, add a webhook that maps each invoice to the provider's API or to Mustang, and fix the line data and the credit-note path first. That's mapping work, and it's the part that takes calendar time.
What this means for your January plan
The deadline is close, so the owner comes this week and the build-or-buy call before mid-December. Here's what we'd do.
- Name one engineer as owner this week. Finance reads the output, but engineering owns the data.
- Decide build or buy before mid-December. If you buy, ask for quotes with your monthly invoice count in hand.
- Send test e-invoices to two German customers and ask them to open them in their systems.
- Book an hour with a German tax adviser to confirm scope, and to check the BMF's latest detailed letter, since the FAQ refers to letters of October 2024, 2025 and 2026. A reporting system for B2B invoices is planned for a later date, so don't build for it yet.
If your January list has other EU deadlines, the EU Data Act January 2027 deadline is another one for SaaS providers. Our EU contracting and compliance guides cover the contract questions that follow.
FAQ
Is a PDF still valid as an invoice in 2027?
Not for an issuer with prior-year turnover above EUR 800,000. From 1 January 2027 a PDF is a "sonstige Rechnung", not an e-invoice. Issuers at or under that threshold can keep using one until 31 December 2027 (a PDF by email needs the customer's consent). A ZUGFeRD file is a PDF with XML inside, and the XML is what counts.
Does Germany require Peppol?
No. The BMF prescribes no delivery channel, and email, an interface or a portal download are all allowed. Peppol is one option, not a requirement.
What is the difference between XRechnung and ZUGFeRD?
XRechnung is XML only, so the recipient needs a viewer. ZUGFeRD is a PDF with XML embedded, and the XML is the leading part. The BMF accepts ZUGFeRD from 2.0.1, except the MINIMUM and BASIC-WL profiles.
Is there a penalty for not issuing an e-invoice?
The BMF's view is that it isn't a regulatory offence. Input VAT deduction at the customer can be affected, though the BMF notes relief in practice, and the customer has a civil claim to a correct e-invoice.
Do we have to receive e-invoices already?
Yes, since 1 January 2025. A working email inbox is enough, and even small businesses must be able to receive.