--- title: "Stripe Billing and the 2027 E-Invoicing Mandate" canonical: https://wavect.io/blog/stripe-billing-e-invoicing-2027/ language: en description: "Stripe Billing sends PDFs, not EN 16931 e-invoices. What a B2B SaaS must build before Germany's 2027 mandate: data model, validation, archive, corrections." image: "https://wavect.io/img/blog/headers/header_stripe-billing-e-invoicing-2027.png" --- [**Back**](/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/team/kevin-riedl/) [Kevin Riedl](/team/kevin-riedl/) https://linkedin.com/in/wsdt 13 min read · 4 Aug 2026 Last reviewed August 4, 2026 [**Next**](/blog/validate-b2b-saas-idea-dach/) # Stripe Billing Sends PDFs. From 2027 That Is Not an Invoice in Germany TL;DR Stripe Invoicing and Stripe Billing generate PDFs, and Stripe's own documentation says they cannot create or send electronic invoices without an additional app. For domestic German B2B supplies, a PDF stops satisfying the issuing obligation on 1 January 2027 for sellers above EUR 800,000 turnover in 2026 and on 1 January 2028 for everyone else, while the obligation to receive EN 16931 invoices has applied since 1 January 2025. Converting to ZUGFeRD or XRechnung is a buyable step. The engineering work sits elsewhere: tax determination mapped to EN 16931 category codes, validated buyer master data and routing identifiers, an unalterable archive of the structured original for the eight-year retention period, and a correction lifecycle that cancels instead of deletes. The German mandate covers supplies where both parties are established in Germany, so an Austrian or Swiss seller without a German establishment is outside the issuing duty, though German buyers increasingly expect structured invoices anyway. Germany prescribes the format and leaves the channel free, whereas France requires an accredited platform and Belgium builds on Peppol, so transport belongs behind an interface. 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. **Answer first:** The file format is the cheapest part of the problem. Converting a Stripe invoice into ZUGFeRD or XRechnung is a solved, buyable step. What no converter buys you is correct tax determination mapped to EN 16931 fields, clean buyer master data, an unalterable archive of the structured original, and a correction lifecycle that cancels instead of deletes. Budget for those four systems, not for the XML. ## 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. | Jurisdiction | Date | What changes for a billing system | | --- | --- | --- | | Germany | 1 Jan 2025 | Every domestic business must be able to **receive and process** an EN 16931 e-invoice. No transition period, no recipient veto. | | Germany | until 31 Dec 2026 | Paper stays allowed. A PDF stays allowed only with the recipient's agreement. | | Germany | 1 Jan 2027 | Sellers with more than EUR 800,000 total turnover in 2026 must **issue** structured e-invoices for domestic B2B. | | Germany | 1 Jan 2028 | The turnover exemption ends. Every domestic B2B invoice above the small-amount threshold must be structured. | | Austria | today | Structured e-invoices are required towards central government. The EU Commission's country factsheet records **no B2B mandate** and none scheduled. | | France | Sep 2026 onward | Reception for all businesses, then phased issuance. Invoices must travel through an accredited private platform, not straight to the buyer. | | Belgium | 1 Jan 2026 | Domestic B2B e-invoicing, built on the Peppol network. | | EU (ViDA) | 1 Jul 2030 | EN 16931 e-invoicing and digital reporting for intra-Community B2B transactions. | 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](/glossary/llm/) guessing. | Format | What it is | When a SaaS should pick it | | --- | --- | --- | | XRechnung | Pure XML, a German national restriction of EN 16931. No human-readable layer. | Public sector buyers, and enterprise buyers whose accounts payable system asked for it by name. | | ZUGFeRD / Factur-X | A PDF/A-3 with the CII XML embedded inside it. One file, two audiences. | The pragmatic default for a self-serve B2B product, because the human recipient still sees an invoice. | | Peppol BIS Billing 3.0 | A UBL profile plus a delivery network with addressing and receipts. | Selling into Belgium, the Nordics, Singapore, Australia, or any buyer who gives you a Peppol participant ID. | 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](/blog/gdpr-ai-act-stacking-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. | Capability | Stripe today | What a 2027-ready stack needs | | --- | --- | --- | | Invoice document | Hosted PDF and HTML page | EN 16931 XML, either standalone or embedded in the PDF | | Structured e-invoice | Not generated natively; App Marketplace partners fill the gap | A generator you control, validated before it leaves the building | | Tax determination | Stripe Tax computes rates and handles registrations | The computed result mapped onto EN 16931 VAT category codes and exemption reasons | | Numbering | Sequential per account, configurable prefixes | Numbering that survives credit notes, retries and multi-entity setups, with gaps you can explain | | Corrections | Void, credit note, refund | A documented mapping from each Stripe event to a legally correct correction document | | Retention | API access to invoice objects | An unalterable archive of the structured original for the statutory retention period, under your control | | Transport | Email and hosted link | Email, Peppol or an accredited platform, chosen per destination country | 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](/glossary/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. | Error class | What it means | Consequence | | --- | --- | --- | | Format error | The file is syntactically invalid, or mandatory fields cannot be extracted completely. | It is not an e-invoice at all. It falls back to being an ordinary invoice, which after the deadline means the obligation was not met. | | Business rule error | The syntax holds but an EN 16931 business rule is violated. | Still an e-invoice, but defective and in need of correction. | | Content error | The tax-relevant content is wrong: rate, service description, supply date. | The recipient's input VAT deduction is at risk. | 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](/services/software-quality-assurance/) engagement: the check belongs in the path, not next to it. ![Kevin Riedl](/img/team/kevin.webp) "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](/glossary/technical-debt/) accumulates when the work is rushed against a legal deadline. ## Build, buy or bolt on | Option | Fits when | What it still leaves you | | --- | --- | --- | | Stripe App Marketplace partner | Low invoice volume, one country, standard tax treatment, invoices created in Stripe itself | Master data quality, archive ownership, correction mapping | | E-invoicing SaaS with an API | Several countries, moderate volume, you want format and transport handled together | The mapping layer from your domain model to their schema, plus vendor dependency on a regulated path | | Peppol access point provider | Network-mandate countries, enterprise buyers with participant IDs | Format generation and everything upstream of transport | | Build the invoice layer in-house | Invoicing logic is already a differentiator: usage-based pricing, marketplaces, split payouts, multi-entity groups | Ongoing conformance work as EN 16931 and the national profiles evolve | 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](/software-development-guide/custom-software-vs-off-the-shelf/). Buy the commodity, own the thing your business logic actually touches. When we took the institutional [bond analytics platform](/case-studies/bond-analytics/) 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](/services/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. ## Stripe and e-invoicing FAQ ### Can Stripe send an XRechnung or ZUGFeRD invoice? Not on its own. Stripe's documentation states that Stripe Billing and Stripe Invoicing cannot create or send electronic invoices without integrating an e-invoicing app, and directs customers to App Marketplace partners. Stripe generates a PDF, which is not a structured e-invoice under EN 16931. ### Is a PDF invoice still legal in Germany after 2027? For domestic B2B supplies it stops satisfying the issuing obligation: from 1 January 2027 for sellers with more than EUR 800,000 turnover in 2026, and from 1 January 2028 for all others. Invoices to consumers, invoices up to EUR 250 gross and certain tax-exempt supplies remain outside the mandate. ### Does an Austrian or Swiss company have to issue German e-invoices? The German issuing obligation covers supplies where both parties are established in Germany, meaning a seat, place of management or VAT fixed establishment there. A company without such an establishment is outside it. A German subsidiary or fixed establishment does fall in scope, and German buyers increasingly expect structured invoices regardless of where the seller sits. ### Which format should a B2B SaaS choose? ZUGFeRD, at the EN 16931 profile or higher, is the pragmatic default because one file serves both the machine and the human reader. Use XRechnung where the buyer or the public sector asks for it, and Peppol BIS Billing 3.0 where the buyer gives you a participant identifier or the destination country runs a network mandate. ### Do the MINIMUM and BASIC WL ZUGFeRD profiles count? No. Both omit invoice line data and therefore do not meet the German requirement for a compliant e-invoice. Generate at the BASIC profile or above, and validate the output rather than trusting a library default. ### Is email an acceptable way to deliver an e-invoice in Germany? Yes. Germany mandates the format and leaves the transmission channel to the contracting parties, so an emailed XML or ZUGFeRD file is sufficient. France requires transmission through an accredited platform and Belgium builds on Peppol, so the channel decision belongs to the destination country. ### How long must e-invoices be kept? In Germany, invoices issued or received from 2025 onward carry an eight-year retention period. The structured part is the legally binding original, so the XML must be stored unchanged and machine-readable, supported by a written description of the invoicing process. ### How much engineering effort is this? For a single-country SaaS buying format generation and transport, expect a focused quarter for the invoice model, validation gate, archive and correction mapping. Multi-entity groups, usage-based pricing, marketplaces and poor customer master data each extend that materially. Running your historical invoices through the validation gate as a backtest is the fastest way to size it honestly. ## Final thoughts Stripe is a payment processor with an invoicing convenience feature, not a compliance system of record, and it says so itself. Treat the 2027 deadline as what it is: a forcing function to give your billing domain a real data model, a validation gate, an archive you control and a correction lifecycle somebody owns. Buy the XML and the network. Build the model. Teams that work in that order end up with a billing stack where the next mandate is an adapter change instead of a rewrite. ## Primary sources - [German Federal Ministry of Finance, second application letter on mandatory e-invoicing, 15 October 2025](https://www.bundesfinanzministerium.de/Content/DE/Downloads/BMF_Schreiben/Steuerarten/Umsatzsteuer/Umsatzsteuer-Anwendungserlass/2025-10-15-einfuehrung-obligatorische-e-rechnung.pdf?__blob=publicationFile&v=5) - [German Federal Ministry of Finance, FAQ on mandatory e-invoicing from 1 January 2025](https://www.bundesfinanzministerium.de/Content/DE/FAQ/e-rechnung.html) - [Section 14 of the German VAT Act, invoice issuance and the sequential number requirement](https://www.gesetze-im-internet.de/ustg_1980/__14.html) - [Stripe, mandatory e-invoicing in Germany](https://stripe.com/resources/more/e-invoice-in-germany) - [Stripe, sending e-invoices through App Marketplace partners](https://stripe.com/guides/send-e-invoices-on-stripe-billing-through-app-marketplace-partners) - [FeRD, ZUGFeRD FAQ on versions and profiles](https://www.ferd-net.de/standards/zugferd-faq) - [European Commission eInvoicing country factsheet, Austria](https://ec.europa.eu/digital-building-blocks/sites/display/DIGITAL/eInvoicing+in+Austria) - [European Commission eInvoicing country factsheet, France](https://ec.europa.eu/digital-building-blocks/sites/display/DIGITAL/eInvoicing+in+France) - [European Commission, VAT in the Digital Age](https://taxation-customs.ec.europa.eu/taxation/vat/vat-digital-age-vida_en) ## You may also like.. [**GDPR and AI Act stacking for a DACH SaaS** How overlapping EU regimes land on one product team, and how to sequence the engineering work.](/blog/gdpr-ai-act-stacking-dach-saas/) [**Custom software vs off-the-shelf** The build, buy or hybrid decision applied to a regulated part of your stack.](/software-development-guide/custom-software-vs-off-the-shelf/) AI governance and regulation ## Continue through this cluster Security, policy, compliance and operating controls for responsible AI adoption. [Start with the cornerstone**EU AI Act Cost for a 5-Person Startup**](/blog/eu-ai-act-compliance-cost-startup/) - [Cyber Resilience Act Reporting: 24-Hour Playbook](/blog/cyber-resilience-act-reporting-playbook-2026/) - [EU Product Liability for Software: Evidence Checklist](/blog/eu-product-liability-software-evidence-2026/) - [AI Bill of Materials: CycloneDX vs SPDX](/blog/ai-bill-of-materials-cyclonedx-spdx-2026/) - [LLM Pseudonymization Gateways: Does the Prompt Leave GDPR Scope?](/blog/llm-pseudonymization-gateway-gdpr-2026/) - [Semantica Review 2026: Can It Explain Every AI Agent Decision?](/blog/semantica-ai-agent-decision-provenance/) Inbox, without the noise ## Follow the work that matters to you Get a short email when we publish something new. Follow the whole blog or only the problems you care about. [**Back**](/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/team/kevin-riedl/) [Kevin Riedl](/team/kevin-riedl/) https://linkedin.com/in/wsdt 13 min read · 4 Aug 2026 Last reviewed August 4, 2026 [**Next**](/blog/validate-b2b-saas-idea-dach/) New posts by email × × Get new posts by email A short email when we publish. Free, no tracking. ## Structured Data ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ], "employee": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "founder": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "legalRepresentative": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "name": "Wavect GmbH", "subjectOf": { "@id": "https://wavect.io/verified-claims.json#dataset", "@type": "Dataset", "creator": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.", "inLanguage": "en", "isAccessibleForFree": true, "license": "https://creativecommons.org/licenses/by/4.0/", "name": "Wavect verified publication claims", "url": "https://wavect.io/verified-claims.json" }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/#website", "@type": "WebSite", "inLanguage": [ "en", "de", "es", "zh" ], "name": "Wavect", "potentialAction": { "@type": "SearchAction", "query-input": "required name=search_term_string", "target": { "@type": "EntryPoint", "urlTemplate": "https://wavect.io/search/?q={search_term_string}" } }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/blog/stripe-billing-e-invoicing-2027/#webpage", "@type": "WebPage", "dateModified": "2026-08-04", "inLanguage": "en", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "lastReviewed": "2026-08-04", "url": "https://wavect.io/blog/stripe-billing-e-invoicing-2027/" } ] } ``` ```json { "@context": "https://schema.org", "@type": "BlogPosting", "abstract": "Stripe Invoicing and Stripe Billing generate PDFs, and Stripe's own documentation says they cannot create or send electronic invoices without an additional app. For domestic German B2B supplies, a PDF stops satisfying the issuing obligation on 1 January 2027 for sellers above EUR 800,000 turnover in 2026 and on 1 January 2028 for everyone else, while the obligation to receive EN 16931 invoices has applied since 1 January 2025. Converting to ZUGFeRD or XRechnung is a buyable step. The engineering work sits elsewhere: tax determination mapped to EN 16931 category codes, validated buyer master data and routing identifiers, an unalterable archive of the structured original for the eight-year retention period, and a correction lifecycle that cancels instead of deletes. The German mandate covers supplies where both parties are established in Germany, so an Austrian or Swiss seller without a German establishment is outside the issuing duty, though German buyers increasingly expect structured invoices anyway. Germany prescribes the format and leaves the channel free, whereas France requires an accredited platform and Belgium builds on Peppol, so transport belongs behind an interface.", "articleBody": " Blog overview/Business and regulation/AI governance and regulation Stripe Billing Sends PDFs. From 2027 That Is Not an Invoice in Germany TL;DR Stripe Invoicing and Stripe Billing generate PDFs, and Stripe's own documentation says they cannot create or send electronic invoices without an additional app. For domestic German B2B supplies, a PDF stops satisfying the issuing obligation on 1 January 2027 for sellers above EUR 800,000 turnover in 2026 and on 1 January 2028 for everyone else, while the obligation to receive EN 16931 invoices has applied since 1 January 2025. Converting to ZUGFeRD or XRechnung is a buyable step. The engineering work sits elsewhere: tax determination mapped to EN 16931 category codes, validated buyer master data and routing identifiers, an unalterable archive of the structured original for the eight-year retention period, and a correction lifecycle that cancels instead of deletes. The German mandate covers supplies where both parties are established in Germany, so an Austrian or Swiss seller without a German establishment is outside the issuing duty, though German buyers increasingly expect structured invoices anyway. Germany prescribes the format and leaves the channel free, whereas France requires an accredited platform and Belgium builds on Peppol, so transport belongs behind an interface. 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. Answer first: The file format is the cheapest part of the problem. Converting a Stripe invoice into ZUGFeRD or XRechnung is a solved, buyable step. What no converter buys you is correct tax determination mapped to EN 16931 fields, clean buyer master data, an unalterable archive of the structured original, and a correction lifecycle that cancels instead of deletes. Budget for those four systems, not for the XML. 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. JurisdictionDateWhat changes for a billing system Germany1 Jan 2025Every domestic business must be able to receive and process an EN 16931 e-invoice. No transition period, no recipient veto. Germanyuntil 31 Dec 2026Paper stays allowed. A PDF stays allowed only with the recipient's agreement. Germany1 Jan 2027Sellers with more than EUR 800,000 total turnover in 2026 must issue structured e-invoices for domestic B2B. Germany1 Jan 2028The turnover exemption ends. Every domestic B2B invoice above the small-amount threshold must be structured. AustriatodayStructured e-invoices are required towards central government. The EU Commission's country factsheet records no B2B mandate and none scheduled. FranceSep 2026 onwardReception for all businesses, then phased issuance. Invoices must travel through an accredited private platform, not straight to the buyer. Belgium1 Jan 2026Domestic B2B e-invoicing, built on the Peppol network. EU (ViDA)1 Jul 2030EN 16931 e-invoicing and digital reporting for intra-Community B2B transactions. 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", "articleSection": "Business & Legal", "author": { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/" }, "dateModified": "2026-08-04", "datePublished": "2026-08-04", "description": "Stripe Invoicing and Stripe Billing generate PDFs, and Stripe's own documentation says they cannot create or send electronic invoices without an additional app. For domestic German B2B supplies, a PDF stops satisfying the issuing obligation on 1 January 2027 for sellers above EUR 800,000 turnover in 2026 and on 1 January 2028 for everyone else, while the obligation to receive EN 16931 invoices has applied since 1 January 2025. Converting to ZUGFeRD or XRechnung is a buyable step. The engineering work sits elsewhere: tax determination mapped to EN 16931 category codes, validated buyer master data and routing identifiers, an unalterable archive of the structured original for the eight-year retention period, and a correction lifecycle that cancels instead of deletes. The German mandate covers supplies where both parties are established in Germany, so an Austrian or Swiss seller without a German establishment is outside the issuing duty, though German buyers increasingly expect structured invoices anyway. Germany prescribes the format and leaves the channel free, whereas France requires an accredited platform and Belgium builds on Peppol, so transport belongs behind an interface.", "headline": "Stripe Billing and E-Invoicing 2027", "image": "https://wavect.io/img/blog/headers/header_stripe-billing-e-invoicing-2027.svg", "inLanguage": "en", "keywords": "E-Invoicing, SaaS Billing", "mainEntityOfPage": { "@id": "https://wavect.io/blog/stripe-billing-e-invoicing-2027/", "@type": "WebPage" }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/blog/stripe-billing-e-invoicing-2027/", "wordCount": 4113 } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "item": "https://wavect.io/", "name": "Home", "position": 1 }, { "@type": "ListItem", "item": "https://wavect.io/blog/overview/", "name": "Blog overview", "position": 2 }, { "@type": "ListItem", "item": "https://wavect.io/blog/topics/business-regulation/", "name": "Business and regulation", "position": 3 }, { "@type": "ListItem", "item": "https://wavect.io/blog/clusters/ai-governance/", "name": "AI governance and regulation", "position": 4 }, { "@type": "ListItem", "item": "https://wavect.io/blog/stripe-billing-e-invoicing-2027/", "name": "Stripe Billing and the 2027 E-Invoicing Mandate | ", "position": 5 } ] } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Not on its own. Stripe's documentation states that Stripe Billing and Stripe Invoicing cannot create or send electronic invoices without integrating an e-invoicing app, and directs customers to App Marketplace partners. Stripe generates a PDF, which is not a structured e-invoice under EN 16931." }, "name": "Can Stripe send an XRechnung or ZUGFeRD invoice?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "For domestic B2B supplies it stops satisfying the issuing obligation: from 1 January 2027 for sellers with more than EUR 800,000 turnover in 2026, and from 1 January 2028 for all others. Invoices to consumers, invoices up to EUR 250 gross and certain tax-exempt supplies remain outside the mandate." }, "name": "Is a PDF invoice still legal in Germany after 2027?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "The German issuing obligation covers supplies where both parties are established in Germany, meaning a seat, place of management or VAT fixed establishment there. A company without such an establishment is outside it. A German subsidiary or fixed establishment does fall in scope, and German buyers increasingly expect structured invoices regardless of where the seller sits." }, "name": "Does an Austrian or Swiss company have to issue German e-invoices?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "ZUGFeRD, at the EN 16931 profile or higher, is the pragmatic default because one file serves both the machine and the human reader. Use XRechnung where the buyer or the public sector asks for it, and Peppol BIS Billing 3.0 where the buyer gives you a participant identifier or the destination country runs a network mandate." }, "name": "Which format should a B2B SaaS choose?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "No. Both omit invoice line data and therefore do not meet the German requirement for a compliant e-invoice. Generate at the BASIC profile or above, and validate the output rather than trusting a library default." }, "name": "Do the MINIMUM and BASIC WL ZUGFeRD profiles count?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Yes. Germany mandates the format and leaves the transmission channel to the contracting parties, so an emailed XML or ZUGFeRD file is sufficient. France requires transmission through an accredited platform and Belgium builds on Peppol, so the channel decision belongs to the destination country." }, "name": "Is email an acceptable way to deliver an e-invoice in Germany?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "In Germany, invoices issued or received from 2025 onward carry an eight-year retention period. The structured part is the legally binding original, so the XML must be stored unchanged and machine-readable, supported by a written description of the invoicing process." }, "name": "How long must e-invoices be kept?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "For a single-country SaaS buying format generation and transport, expect a focused quarter for the invoice model, validation gate, archive and correction mapping. Multi-entity groups, usage-based pricing, marketplaces and poor customer master data each extend that materially. Running your historical invoices through the validation gate as a backtest is the fastest way to size it honestly." }, "name": "How much engineering effort is this?" } ] } ```