If your SaaS already does B2B billing for customers in Europe, sooner or later one of them will ask: "Can you send my invoices through Peppol?"

Belgium has required structured domestic B2B e-invoicing since 1 January 2026. Germany has required businesses to be able to receive e-invoices since 1 January 2025, with issuing obligations phased in from 2027 to 2028. France starts its B2B e-invoicing rollout from 1 September 2026 through approved platforms. The EU ViDA package brings digital reporting for intra-EU B2B transactions from 1 July 2030.

The exact rails differ by country. Belgium is Peppol-first. Germany and France are not simply "Peppol only". But the direction is clear: structured e-invoicing is becoming part of the default B2B stack.

Your team has two options. Build it yourself — UBL templates, country variants, Peppol Access Point integration, retry semantics, status webhooks, compliance drift, the works. Or treat Peppol as infrastructure you call out to, the way you treat your card processor or your transactional email.

This is the second path: how to add Peppol to a SaaS product so that your devs stay focused on your product and Peppol becomes an API integration plus a webhook handler.

Why "build it yourself" turns into a tax

Peppol looks deceptively small. It's just an XML format, right?

It isn't. The standard you usually need to emit is UBL 2.1 conforming to Peppol BIS Billing 3.0, with country-specific rules layered on top. The XML has hundreds of optional fields and a non-trivial validation tree. You have to:

• Generate UBL from your invoice data shape. Your model is not UBL's model, so there is mapping work.
• Validate before sending, or the Access Point rejects the document.
• Look up the recipient's Peppol identifier in the Peppol Directory.
• Submit through a certified Peppol Access Point. You do not talk to recipients directly; you talk to an AP that talks to their AP.
• Handle async delivery. "Accepted by Access Point" is not the same as "delivered to recipient".
• Track failures. A recipient can reject a document later, and your tenant needs to see that state.

For a SaaS where invoicing is a feature and not the product, that is a tax. The framing I keep hearing from devs at billing, healthcare, and ERP SaaS companies is the same: Peppol is important, but it is not the core business.

First decision: who is the sender?

Before writing any code, draw this line. There are two different SaaS shapes that people often mix together.

Shape A: your SaaS sends invoices as your own legal entity.

Example: you run a B2B SaaS and invoice your customers. You have one verified sender identity. This is the simple integration path: one API key, one onboarding flow, one webhook endpoint, many recipients.

Shape B: your SaaS sends invoices on behalf of your customers.

Example: a healthcare, ERP, or marketplace SaaS where each customer is its own legal entity and needs to send invoices under its own Peppol participant identifier. That is a platform/delegated-sender model. It needs KYB, authorization, sender selection, audit trails, and often country-specific verification.

Do not fake Shape B by stuffing a tenant's Peppol ID into a random from field unless your provider explicitly supports delegated sender selection. A good provider should expose a real sender model, usually something like a legal entity ID or sub-account ID, plus authorization gates.

getpeppr's public API today is designed around the verified-account sender model. We are actively working through the delegated-sender pattern with platform customers, but this is not a "just pass from.peppolId and you're done" feature. If that is your use case, talk to us before making customer promises.

What your platform owns vs. what you delegate

Your platform should still own the product-specific parts:

• Your tenant/account model
• Your invoice rows, line items, tax decisions, and UI
• Billing-side metering for how many Peppol sends happen
• The UX where a user sees "queued", "sent", "accepted", "refused", or "failed"
• For delegated-sender use cases: consent, KYB, and authorization UX for each sender

You delegate the Peppol-specific machinery:

• UBL generation from a sane JSON shape
• Validation against Peppol BIS 3.0 and relevant business rules
• Access Point transmission
• Peppol Directory lookups
• Status webhooks
• Compliance updates as mandates roll out

The rest of this article uses getpeppr as the provider because that's what we ship, but the principle applies to any decent Peppol-as-a-service API: keep tenancy and product logic in your platform, push Peppol-specific work out.

The TypeScript path, end to end

This is what a clean current getpeppr integration looks like for the verified-sender model.

1. Install and initialise

npm install @getpeppr/sdk

import { Peppol } from "@getpeppr/sdk";

export const peppol = new Peppol({
  apiKey: process.env.GETPEPPR_API_KEY!, // sandbox or production key
});

The sender identity is configured through getpeppr onboarding and tied to the account/API key. In production, that sender needs a verified Peppol identity before documents can be sent.

2. Send an invoice

async function sendInvoice(invoice: YourInvoice) {
  return peppol.invoices.send({
    number: invoice.number,
    date: invoice.date,
    dueDate: invoice.dueDate,
    currency: invoice.currency ?? "EUR",
    buyerReference: invoice.buyerReference ?? invoice.recipient.reference,
    to: {
      name: invoice.recipient.legalName,
      peppolId: invoice.recipient.peppolId,
      street: invoice.recipient.street,
      city: invoice.recipient.city,
      postalCode: invoice.recipient.postalCode,
      country: invoice.recipient.country,
      vatNumber: invoice.recipient.vatNumber,
    },
    lines: invoice.lines.map((line) => ({
      description: line.description,
      quantity: line.quantity,
      unitPrice: line.unitPrice,
      vatRate: line.vatRate,
    })),
  });
}

The important boundary: your product maps your invoice model to a provider JSON shape. Your product does not generate UBL XML directly.

3. Receive status updates

The Peppol pipeline is asynchronous. You do not want your UI to rely on a single success/failure boolean from send(). You want a local invoice state and a webhook handler.

Current getpeppr webhook events include invoice.sent, invoice.accepted, invoice.refused, invoice.error, invoice.registered, invoice.received, invoice.paid, and test.ping.

import express from "express";
import { webhooks } from "@getpeppr/sdk";

app.post(
  "/webhooks/getpeppr",
  express.raw({ type: "*/*" }),
  async (req, res) => {
    try {
      const event = await webhooks.constructEvent(
        req.body.toString("utf8"),
        req.headers["getpeppr-signature"] as string,
        process.env.GETPEPPR_WEBHOOK_SECRET!,
      );

      switch (event.type) {
        case "invoice.sent":
        case "invoice.accepted":
          markDeliveredInYourApp(event.data.invoiceId);
          break;

        case "invoice.refused":
        case "invoice.error":
          flagForReview(event.data.invoiceId, event);
          break;

        case "invoice.paid":
          markPaid(event.data.invoiceId);
          break;
      }

      res.sendStatus(200);
    } catch {
      res.sendStatus(400);
    }
  },
);

The signature header is Getpeppr-Signature. Verify it on every request. Webhook URLs are public; they will be poked.

4. Validate offline before wiring the live API

The @getpeppr/cli package lets you generate, validate, and convert invoices locally.

npx @getpeppr/cli init my-invoice.json
npx @getpeppr/cli validate my-invoice.json
npx @getpeppr/cli convert my-invoice.json --validate -o invoice.xml

This is useful before you connect your production invoice rows to a live Peppol send. Start with a representative sample: one normal invoice, one VAT exemption, one credit note, and one cross-border example.

If your SaaS needs delegated sending

If each of your customers needs to send under their own Peppol ID, ask your provider these questions before you commit to a rollout:

• How do I create and verify a sender legal entity?
• Is sender selection explicit in the API, or is it inferred from the API key?
• How do you handle consent and KYB for each sender?
• Can one platform account manage many sender legal entities?
• Are sender events and invoice events scoped clearly enough for my tenant model?
• What happens if a sender verification fails after the customer already started onboarding?
• Which countries are actually supported for KYB today, not just "on the Peppol network"?

This distinction matters. Sending an invoice to a Peppol participant is one capability. Letting a SaaS platform onboard hundreds of legal senders is another.

What works country by country

Be explicit in customer conversations. "Peppol support" and "local e-invoicing compliance" are not always the same thing.

If you are scoping a customer migration, ask for two or three real invoice examples and the countries involved before estimating the work. The edge cases live in the invoice samples.

Migrating from in-house XML

If you already have an in-house UBL builder and an Access Point arrangement that you want to retire, keep the migration boring:

1. Map your invoice model to the provider's JSON shape. Unit-test the mapper against representative invoices.
2. Run offline validation and XML conversion in CI for a small fixture set.
3. Send through sandbox first and compare the resulting XML with your current pipeline.
4. Move read-only status display first, then flip sends for one low-volume customer.
5. Keep the old path warm until you have enough successful production evidence to remove it safely.

You are not trying to make Peppol exciting. You are trying to make it disappear into infrastructure.

Next steps

If you are sizing this work for your SaaS:

• Read the Belgium developer playbook for mandate context.
• Spin up a sandbox key at getpeppr.dev and push a fake invoice through.
• Validate one of your real invoices offline: npx @getpeppr/cli validate your-invoice.json.
• If you are a platform that needs delegated sending for many customer legal entities, send us the countries and two or three real invoice examples. That is the fastest way to find the real integration shape.

No sales theatre. Just the actual invoice shape, the sender model, and the countries involved.

— Zero Loop Labs