Stripe Billing Sends PDFs. From 2027 That Is Not an Invoice in Germany

Stripe Invoicing and Stripe Billing produce a PDF. Stripe's own documentation states plainly that the two products cannot create or send electronic invoices without an additional e-invoicing app, and points customers at App Marketplace partners instead. For a domestic German B2B sale, that PDF stops satisfying the issuing obligation on 1 January 2027 for larger sellers and on 1 January 2028 for everyone else.

Most articles on this subject are written by tax advisors or by vendors selling a format converter. This one is written from the build side. The question it answers is not "what does the law say" but what an engineering team actually has to construct around a payment processor, and which parts can be bought. It is an engineering guide, not tax advice, and your tax advisor still owns the tax positions.

What actually changes, and when

The deadlines that matter to a software team are not one date but a matrix. Receiving became compulsory before issuing did, and every neighbouring country solved the transport problem differently.

Read the France row again next to the Germany row. Germany mandates a format and leaves the channel to the parties, so email is a legitimate delivery mechanism. France mandates a network. If your roadmap treats "e-invoicing" as one feature, it is already mis-scoped: format, transport and reporting are three independent axes that each country sets separately.

What stays out of scope

• B2C. Consumer invoices are untouched by the German mandate.
• Small amounts. Invoices up to EUR 250 gross, and transport tickets, may stay unstructured.
• Certain tax-exempt supplies under the exemption catalogue in the German VAT Act.

For a typical B2B SaaS the EUR 250 carve-out is a trap rather than a relief. A EUR 49 monthly seat plan sits below it, an annual contract does not, and self-serve upgrades move a customer across the line mid-year. Encoding "is this invoice in scope" as a rule the billing system evaluates per document beats encoding it as a policy in a wiki.

Why a PDF is not an e-invoice

EN 16931 does not describe a document. It describes a semantic data model: a list of business terms such as seller VAT identifier, invoice line net amount, VAT category code and payment due date, each with a defined cardinality and a set of business rules that must hold. A file is an e-invoice when it carries that model in one of two permitted XML syntaxes, UBL or UN/CEFACT CII, and passes the rules.

A PDF carries pixels and, at best, a text layer. A machine cannot reliably know whether "19%" on line four is a tax rate, a discount or part of a product name. That is the whole distinction. "Machine-readable" in the legal sense means the receiving system can extract every mandatory field deterministically, without heuristics and without an LLM guessing.

Two implementation details cost teams a release each when they surface late. First, not every ZUGFeRD profile qualifies: the MINIMUM and BASIC WL profiles carry no invoice lines and therefore do not meet the German requirement, so a library default of MINIMUM ships a file that looks compliant and is not. Second, in a hybrid file the structured part is the binding original. If the XML says EUR 1,190.00 and the rendered PDF says EUR 1,180.00, the XML wins and your customer's system books the XML. Rendering the PDF from the same data structure that produced the XML, rather than from a parallel template, is the only reliable way to prevent that class of defect.

Does the German mandate apply to an Austrian, Swiss or US SaaS?

Usually not, and this is the single most misread point in the whole topic.

The German issuing obligation applies to a supply between two businesses that are both established in Germany, where establishment means a seat, place of management, or a VAT fixed establishment there. An Austrian GmbH with no German fixed establishment invoicing a Berlin customer is outside the issuing mandate. The supply is typically a reverse-charge service anyway, with the German customer accounting for the VAT.

Three qualifications keep that from being a reason to do nothing:

1. A German entity or fixed establishment pulls you in. Many foreign groups have one and forget that the billing entity, not the parent, is what counts.
2. Receiving is separate from issuing. If you have a German entity, it must already be able to ingest structured supplier invoices, which is an accounts-payable and integration problem rather than a billing one.
3. Your customers will ask regardless. Once a German buyer's accounts payable runs on structured intake, a PDF from a foreign vendor becomes the exception that a human handles, chases and pays late. Being unstructured is a commercial cost long before it is a legal one.

The same logic applies in reverse if you sell into France or Belgium, where the requirement is a network membership rather than a file format. Many of our clients bill from Austria into Germany and beyond, which is exactly the shape where the legal answer and the practical answer diverge. We wrote about the wider version of this pattern in how GDPR and the AI Act stack for a DACH SaaS.

What Stripe gives you, and what it does not

Stripe is very good at the parts it owns. The gap is specific, and worth naming precisely rather than turning into a complaint about the platform.

Nothing in that table argues against Stripe. It argues against the assumption that the payment processor is the system of record for compliance. Payments and invoicing are two products that happen to share a database.

The format is the smallest part: four systems a converter does not build for you

1. Tax determination that maps to EN 16931 fields

Your billing engine already decides between standard rate, reduced rate, reverse charge, intra-Community supply and One Stop Shop treatment. EN 16931 requires that decision to be expressed as a coded VAT category, a rate, a taxable base and, for anything not taxed at the standard rate, a machine-readable exemption reason. A converter receives whatever your system hands it. If the upstream decision is a free-text note saying "reverse charge", the output is a structurally valid invoice carrying a wrong tax position, which is the worst of both outcomes: it passes validation and fails an audit.

2. Buyer master data and routing identifiers

A structured invoice needs a real buyer: legal name, registered address, VAT identification number, and for many enterprise and public buyers a routing identifier such as a Leitweg-ID or a Peppol participant ID. Self-serve signup forms collect none of that reliably. Teams discover on go-live that a large share of their B2B customer records hold a personal name in the company field and an unvalidated VAT ID. Validating VAT identifiers at checkout, and treating the routing identifier as a required field for enterprise plans, is a two-week change if you do it now and a data-migration project if you do it in December 2026.

3. An unalterable archive of the structured original

The XML is the legal original, so the XML is what must be retained, unchanged and machine-readable, for the statutory period. Invoices issued or received from 2025 onward carry an eight-year retention period in Germany. "It is in Stripe" is not an archive: it is a third-party API whose lifecycle you do not control. A workable pattern is object storage with versioning and an object-lock retention policy, a content hash recorded at write time, and an index that maps invoice number to storage key. Alongside it you need a written process description covering how invoices are created, validated, sent, stored and corrected. Auditors read that document before they read your code.

4. The correction lifecycle

This is where subscription products differ from one-off sellers, and where most of the engineering effort actually lands. Proration, mid-cycle plan changes, dunning retries, partial refunds, credits and currency changes all generate financial events that have to become correction documents rather than edits. Under immutability rules you cancel and reissue; you do not overwrite. A refund is not automatically a credit note, and a voided draft is not the same as a cancelled invoice. Writing that mapping down as a state machine, with one row per Stripe event type, is the single highest-value artefact this project produces.

The 2025 BMF letter turned validation into a pipeline requirement

The German finance ministry's second application letter, dated 15 October 2025, sorts e-invoice defects into three classes. For an engineering team this reads less like tax guidance and more like a specification for a validation gate.

The engineering implication is direct. Validate every document against the EN 16931 business rules before it is sent, fail closed on format and business-rule errors, and route content errors to a human queue because no validator can catch them. Treating validation as an outbound gate rather than a monitoring dashboard is the difference between a defect caught in a queue and a defect discovered by a customer's tax department. It is the same discipline we apply in a software quality assurance engagement: the check belongs in the path, not next to it.

"Teams budget for the XML and get surprised by the archive and the credit notes. The format is a library call. The correction lifecycle is a state machine somebody has to own for the next eight years."

A reference architecture for a Stripe-based billing stack

1. Billing events. Consume Stripe webhooks into your own durable event log. Never treat the processor as your source of truth for accounting records.
2. Invoice data model. Project those events into a normalised invoice entity that holds every EN 16931 mandatory term explicitly, including buyer identifiers and coded tax treatment. This model, not the PDF, is your real deliverable.
3. Numbering and immutability. Assign the invoice number at the moment the document becomes final, from a single writer, and make the record append-only from then on.
4. Rendering. Generate the XML and the human-readable rendition from the same model in one step, so they cannot diverge.
5. Validation gate. Run schema plus business-rule validation. Block on failure. Record the validation result with the document.
6. Transport. Select the channel per destination: email attachment for Germany, a Peppol access point for Belgium and the Nordics, an accredited platform for France. Keep transport behind an interface so a new country is a new adapter, not a new codebase.
7. Archive and reconciliation. Write the structured original to locked storage with a hash, then reconcile the archive against the ledger on a schedule. An archive nobody reconciles is an assumption, not a control.

Roughly a quarter of that list is buyable off the shelf. The rest is your domain model, and it is where the technical debt accumulates when the work is rushed against a legal deadline.

Build, buy or bolt on

The honest default for most B2B SaaS companies is a hybrid: buy format generation and transport, build the invoice data model, the validation gate and the archive. That split follows the same reasoning as any other custom software versus off-the-shelf decision. Buy the commodity, own the thing your business logic actually touches. When we took the institutional bond analytics platform from zero to enterprise readiness, the same principle held: a regulated output is only as trustworthy as the model that produced it.

Eight failure modes we see in billing pipelines

1. Two sources of truth. The PDF is rendered from a template while the XML is built from the database. They drift within one release.
2. MINIMUM profile by default. A library default produces a file that validates as ZUGFeRD and fails the legal requirement.
3. Rounding at the wrong level. EN 16931 business rules check that line totals, tax subtotals and the document total agree. Rounding per line and per document differently breaks the rules.
4. Mixed VAT rates in one document. A bundle of a 19% licence and a 7% item needs correct tax subtotals per category, not one blended rate.
5. Unvalidated buyer data. Missing VAT identifiers and personal names in company fields, discovered at go-live.
6. Deletion instead of cancellation. A support workflow that removes a wrong invoice destroys the audit trail that immutability requires.
7. Test data in production numbering. A load test that burns 4,000 invoice numbers leaves a gap nobody can explain three years later.
8. No outbound validation. Errors surface in the customer's accounts payable system, which is the most expensive possible detector.

A 90-day plan

1. Weeks 1 to 2, scope. Determine per legal entity whether you are in scope for issuing, and per customer segment whether the small-amount carve-out applies. Produce a one-page decision, not a memo.
2. Weeks 3 to 4, data audit. Measure how many B2B customer records carry a validated VAT identifier, a legal name and a complete address. This number decides your timeline more than any technical choice.
3. Weeks 5 to 7, model and mapping. Define the invoice entity, map every Stripe event type to an invoice or correction document, and map your tax logic to EN 16931 category codes.
4. Weeks 8 to 10, generate and validate. Produce ZUGFeRD from the model, wire the validation gate, and run your last twelve months of invoices through it as a backtest. The failure rate on historical data is your real readiness metric.
5. Weeks 11 to 12, archive and process description. Stand up locked storage with hashing and reconciliation, and write the process documentation while the decisions are fresh.
6. Then, transport per country. Add Peppol or an accredited platform only for the markets that require it.

Twelve weeks assumes someone owns the decisions. Where that owner does not exist, the work stalls at week three, which is a common reason companies bring in a fractional CTO for a bounded regulatory programme instead of hiring for it.

Four myths worth correcting

• "Invoice numbers must be gap-free." German VAT law requires a sequential number assigned once for identification. A gap-free series is not legally required. Gaps do attract audit questions, so document why they exist.
• "A PDF with XML inside is a workaround." ZUGFeRD is a first-class compliant format. The PDF container is not the problem; a PDF without the structured data is.
• "We need Peppol for Germany." Germany prescribes the format, not the channel. Email is sufficient. Peppol becomes necessary because of who you sell to, not because of German law.
• "Our accounting software handles it." It handles the invoices it creates. Invoices created by your product, in your billing engine, on your own numbering series, are yours.

Primary sources

• German Federal Ministry of Finance, second application letter on mandatory e-invoicing, 15 October 2025
• German Federal Ministry of Finance, FAQ on mandatory e-invoicing from 1 January 2025
• Section 14 of the German VAT Act, invoice issuance and the sequential number requirement
• Stripe, mandatory e-invoicing in Germany
• Stripe, sending e-invoices through App Marketplace partners
• FeRD, ZUGFeRD FAQ on versions and profiles
• European Commission eInvoicing country factsheet, Austria
• European Commission eInvoicing country factsheet, France
• European Commission, VAT in the Digital Age