Peppol E-Invoicing for Stripe Billing and Invoicing

How do you send a Peppol invoice from Stripe?

Stripe finalises the invoice and fires a webhook. A bridge reads that event, maps the Stripe invoice into the structured format the network carries, adds the identifiers and tax codes Stripe does not hold, and hands it to a certified Peppol Access Point for delivery.

Stripe does not speak Peppol, and nothing inside Stripe produces a network invoice on its own. That is not a criticism of the product: Stripe is built to charge a customer and to show them a bill, and it does both well. Peppol is built to hand a machine-readable document from your finance system to your customer's finance system with no human in between. The two jobs meet at the point where a Stripe invoice becomes final, and the gap between them is a mapping job with a small number of well-defined pieces.

The rest of this page walks through those pieces in order: what a Stripe invoice already contains, what the European standard as Peppol implements it requires on top of that, how the webhook bridge fills the gap, which identifiers and tax details have to be supplied from outside Stripe, and what status comes back once the document is on the network. If you want the format itself explained first, what a UBL invoice is is the shorter read, and how the Peppol network works covers the delivery side.

What a Stripe invoice already contains

More than people expect, and it is worth being precise about it, because the mapping work is only the difference between this list and the next one. A finalised Stripe invoice carries the customer it belongs to — name, email address and billing address — and a set of line items, each with a description, a quantity, a unit amount and a currency. It carries a subtotal, any discounts, whatever tax was calculated, the total, and how much of that total has been paid. It carries an invoice number, drawn from a sequence Stripe keeps per customer, a creation date and a due date. And it carries a status: draft while you are still editing it, open once it is issued, then paid, void or uncollectible.

It also carries two things that matter more than they look. The first is finality. A draft invoice can still change; a finalised one cannot, and finalisation is the moment the number is assigned. That is the only safe moment to build a network document from it, because a compliance document that disagrees with the invoice it came from is worse than no document at all. The second is metadata: arbitrary key-value pairs you can attach to a customer or an invoice. Nothing in Stripe reads them, which is exactly why they are the natural home for the handful of e-invoicing facts Stripe has no field for.

What a Stripe invoice does not contain is a compliance document. The hosted invoice page and the rendered PDF are presentations of the data for a human to look at. A tax authority or a buyer's accounts-payable system asks for something different: the same facts as structured data, in a format defined by someone other than your supplier, so that it can be validated and posted without being read.

What the European standard requires that a Stripe invoice does not carry

The European semantic standard for electronic invoicing, EN 16931, defines the meaning of every field an invoice must carry; Peppol BIS Billing 3.0 is the profile that says how to express those fields in UBL and adds rules of its own. The gap between a Stripe invoice and a compliant one is not about the amounts, which Stripe already has right. It is about identity, coding and structure.

Two of those rows cause most of the failures in practice. The first is the electronic address, because it is the one field with no plausible substitute: an email address will not route a document, and a network delivery cannot be attempted without a participant identifier and the scheme it belongs to. The second is the tax coding. An exempt supply and a zero-rated supply produce the same number on a Stripe invoice and are different categories under the standard, with an exemption reason required for one and not the other. A validator will refuse the difference even though the arithmetic is identical.

The last row is the one that surprises subscription businesses. In most e-invoicing flows the invoice arrives before the money moves; with Stripe the money has usually moved first. The document still has to be honest about that, or your customer's accounts-payable system opens a payable for an amount that has already left their card. Stating the payment status correctly at the moment of sending is not a detail — it is the difference between a clean posting and a support ticket.

One thing worth saying plainly, because it is a real limit rather than a feature: the standard's rules are about structure, not about intent. Nothing in a validator can tell you that you applied the wrong VAT rate, only that the rate you applied is coded in a way it recognises and reconciles with the totals you stated. Rates and liability remain a matter for your tax adviser and the authority in the country concerned; the formatting, the coding and the delivery are the parts this page is about.

How the webhook bridge fills the gap

A webhook is Stripe calling you rather than you polling Stripe. You register an endpoint, choose the events you care about, and Stripe posts a signed payload to that endpoint each time one occurs. For e-invoicing the event that matters is the one raised when an invoice is finalised, because that is the first moment the invoice is immutable and has its number. Events for payment succeeding, payment failing and the invoice being voided matter afterwards, for the status of a document already sent.

The bridge is the code between that endpoint and our send API, and it does four things. It resolves the parties, turning your Stripe account into a seller with a VAT identifier and a registered address, and the Stripe customer into a buyer with a network address. It maps the lines, giving each one a coded unit of measure and a tax category alongside the description and amount Stripe already supplies. It assembles the document in UBL, with the type code and specification identifier the profile requires. And it hands the result over for validation and transmission.

From that point the work is ours. Every document is validated against EN 16931 and the Peppol BIS Billing 3.0 rules before transmission, so a mapping mistake surfaces as a named rule failure on our side rather than as a rejection from your customer's system days later. Transport is AS4, encrypted and digitally signed. GoRoute is an OpenPeppol-certified Access Point and SMP provider under Peppol ID POP000991, which in plain terms means we are approved to send and receive on the network on your behalf and we run the directory entry that lets other participants find your address.

The honest part of this design is where the judgement sits. The transport is solved and the validation is solved; the mapping is where your business rules live, and no integration can guess them for you. Which of your Stripe products is a service and which is a licence, whether a customer in another member state is reverse-charged, what unit a metered line is measured in — these are decisions, made once, and then applied to every invoice afterwards. Getting them wrong is cheap to find and cheap to fix if you test before you send.

That is what the sandbox is for. Our free developer sandbox is connected to the Peppol test network with deterministic test receivers, so you can push a real finalised Stripe invoice through the whole path — map, validate, send, receive the lifecycle events — and read exactly what comes back, before a single document reaches a customer. The API services page sets out the interface itself, and the API documentation has the request and response shapes.

Which identifiers and tax details have to be added

Start with the seller, because it is the easy half. Your own VAT identifier, your legal registration number, your registered address including the country code, and your own network participant identifier are properties of your company rather than of any one invoice. They are configured once on the sending account and then appear on every document. If your Stripe account bills from more than one legal entity, that is the one case where the seller side needs a mapping too, because the identifiers follow the entity and not the Stripe account.

The buyer is the harder half, and it comes down to one field. A network address is not an email address: it is an identifier plus the scheme that identifier belongs to, and the pair has to be registered on the network before anything can be delivered to it. Stripe has nowhere to put it, so it has to come from somewhere you control — your own customer master if you have one, or Stripe customer metadata if you do not. Whichever you choose, collect it at the point where you already ask a business customer for their VAT number, because asking again later is a conversation nobody enjoys.

Belgium is worth a paragraph of its own, and not only because it is where most readers of this page are. Belgian business-to-business e-invoicing has been mandatory between VAT-registered businesses since 1 January 2026, the three-month tolerance period ended on 31 March 2026, and the rules have been fully enforced since 1 April 2026. The identifier a Belgian participant is registered under is the ten-digit enterprise number from the Crossroads Bank for Enterprises, under Peppol scheme 0208 — not the VAT scheme. And since the old Hermes service was decommissioned at the end of 2025, a Belgian buyer is no longer reachable by default: they must have appointed a service provider. If a Belgian recipient will not resolve, that is usually the reason rather than a mistyped identifier. Our Belgium e-invoicing page covers the mandate, the penalties and the platform in full.

On the tax side, three things have to be decided per line rather than per invoice. The category: standard-rated, zero-rated, exempt, reverse charge, or outside scope. The rate that goes with it, which the standard expects even when it is zero. And, where the category is anything other than standard-rated, a reason, because a document that says no tax was charged without saying why is incomplete. Stripe Tax will tell you the amount; the category and the reason are yours to map, usually from the product and the relationship between the two parties.

The rest is arithmetic that has to reconcile. Line net amounts must sum to the invoice net total, the tax breakdown must sum to the tax total, and the amount due must be the total less what has already been paid. Stripe holds all of those numbers in minor units, which removes most rounding arguments before they start, and the validator checks the sums rather than trusting them.

What comes back after the invoice is sent

The network answers, which is the largest practical difference between sending an e-invoice and emailing a PDF. There are two layers to the answer, and confusing them is the commonest reason a finance team thinks an invoice is stuck when it is not.

The transport layer is the AS4 exchange itself. When the receiving access point takes the document, it returns a signed receipt. That receipt is evidence of handover: it proves the document was accepted by the infrastructure serving your customer, and it is what you keep if delivery is ever disputed. It does not prove that a human at your customer has looked at the invoice, and it is not an acceptance of the amount.

The business layer sits above it. Where a recipient sends one, a message-level response names what failed — a rule the document broke, or an identifier that did not resolve. That is a different kind of answer from a receipt, and it is the one that tells you to fix something. Not every recipient sends one, which is worth knowing in advance rather than discovering during a month-end.

On your side, both layers arrive as webhooks, so the traffic runs in each direction as events rather than as polling. GoRoute posts document.received, document.validated, document.sent, document.failed and document.delivered events with HMAC-signed payloads, retried with exponential backoff and dead-lettered if your endpoint stays unreachable. Correlate them on the message identifier, and carry the Stripe invoice identifier through as your own reference, so that a document in one system can always be found in the other.

Keep the two status models apart in your own head and in your own data. Stripe's invoice status answers a question about money: has this been paid. The Peppol status answers a question about delivery: did the document arrive and was it well-formed. An invoice can be paid and undelivered, or delivered and unpaid, and neither state is an error. A dashboard that collapses them into one field will eventually tell somebody something untrue.

Finally, the after-the-fact events. A Stripe invoice that is voided or refunded after the document has gone out cannot be unsent, because a delivered invoice belongs to the recipient's records as much as to yours. The correction is a credit note, sent the same way, referencing the original. Deciding how your billing system raises one — and making sure it does so rather than silently editing history — is part of the integration, not an afterthought to it.