DEV Community: Zero Lopp Labs

Add Peppol e-invoicing to your SaaS — the easy way to get ahead of the EU mandates

Zero Lopp Labs — Tue, 02 Jun 2026 16:37:57 +0000

When you're building a young B2B SaaS, Peppol e-invoicing lives in the "we'll deal with it later" pile. Invoicing is a feature, not your product. No customer has demanded it yet. And the whole thing looks like XML plumbing for an EU regulation that may not even apply to you this year.

Here's the trap: "later" has a habit of arriving as "this sprint, and it's now on fire." A customer signs, and during onboarding asks whether you can send their invoices over Peppol. Or your home market publishes a mandate date and your roadmap gets rewritten for you.

This article makes the opposite case. For an early-stage SaaS, the cheapest and lowest-risk time to add Peppol is before you're forced to — not because of urgency theatre, but because of how the costs actually break down once you look at them.

Where the EU mandates stand today

You don't need to memorise EU tax law. You need to know that the deadlines are real, dated, and arriving on a schedule you can plan around:

Market	Receive	Send (issue)	Network
🇧🇪 Belgium	Mandatory since 1 Jan 2026 (in-scope domestic Belgian VAT-liable B2B)	Mandatory since 1 Jan 2026 (in-scope domestic Belgian VAT-liable B2B)	Structured e-invoice, generally via Peppol
🇫🇷 France	1 Sept 2026 (all businesses)	1 Sept 2026 (large + mid-sized); 1 Sept 2027 (SMEs & micro)	Approved platforms; EN 16931 formats such as Factur-X, UBL and CII
🇩🇪 Germany	Since 1 Jan 2025 (domestic B2B must be able to receive)	Transition rules through 2026; through 2027 for issuers up to €800K prior-year turnover	EN 16931, typically XRechnung or ZUGFeRD; Peppol optional
🇪🇺 EU (ViDA)	—	1 July 2030 (intra-EU cross-border B2B digital reporting)	Real-time reporting based on e-invoicing / EN 16931

Primary references: Belgium's e-facture FAQ, France's impots.gouv.fr calendar, Germany's BMF e-invoice FAQ, and the European Commission's ViDA page.

Poland, Romania and Spain are phasing in their own mandates on top of these. The pattern is one-directional: structured e-invoicing is becoming the default for B2B across the bloc, with Peppol either mandated, supported or sitting close to the infrastructure in several markets. The EU's VAT in the Digital Age (ViDA) package locks in the cross-border digital-reporting layer for 2030.

The takeaway for a young SaaS is the good kind: you still get to choose when you do this work, on your own terms. Even if you aren't directly in scope yet, a growing share of your EU B2B customers either already are, or will be soon — and the direction of travel won't reverse. Doing it early and calmly is worth real money.

The two costs nobody puts on the roadmap

When founders estimate "add Peppol," they price the obvious thing — a vendor's monthly fee — and skip the two costs that actually hurt.

The build cost. Peppol looks like "just an XML format." It isn't. To send a compliant invoice you have to emit UBL 2.1 conforming to Peppol BIS Billing 3.0, with country-specific extensions (CIUS) layered on top. Then you need to:

Map your invoice model to UBL (your data shape is not UBL's shape)
Pass schema and Schematron validation before sending, or the access point rejects you
Look up recipients in the Peppol Directory across participant identifier schemes (0208 for Belgium, 0009 for France, 0007 for Sweden, 0088 for GLN, and so on)
Submit through a certified Access Point — you don't talk to recipients directly, and becoming an Access Point yourself is a multi-month, audited, fee-bearing project almost no SaaS takes on
Handle asynchronous delivery, where "accepted by the access point" is not "delivered," which is not "accepted by the recipient's accounting system"
Surface failures that can arrive hours later when a recipient rejects for a compliance reason
Archive everything in machine-readable form for seven years

In our experience that's roughly one backend engineer for two quarters to ship a first version — then ongoing maintenance every time a country updates its CIUS or a new mandate lands. For a team where invoicing is a feature and not the product, that's a tax you pay forever.

The cost of waiting. Do this work under a mandate deadline and you pay a rush premium. There's no time to learn the failure modes in a calm sandbox, no buffer for the recipient-rejected-it-on-Tuesday surprises, and no room to ship behind a flag and watch it for a week. In markets where the mandate is already live, there's also direct fine exposure — Belgium's regime runs €1,500 to €5,000 per escalating offence (the Belgium developer playbook covers exactly how that lands on engineering).

Against either of those, the line item everyone fixates on — what the API costs per month — is the cheapest part of the whole story.

Why "start early" is structurally cheaper

It's not a motivational slogan; it's a difference in how the work behaves.

When you have time, you integrate at your own pace. You wire the SDK into a sandbox that's free and unlimited, push fake invoices through, and deliberately break things to learn what invoice.refused looks like before it matters. You ship behind a feature flag, run it read-only alongside your existing flow, and make Peppol boring — which is exactly what infrastructure should be.

When you're under a deadline, you do the same work serially, at speed, with a fine clock ticking and a customer waiting. Same code, very different stress — and a meaningfully higher chance of shipping something that passes your tests but trips a recipient's Schematron in production.

There's an upside most founders miss, too: being Peppol-ready early is a sales asset. When an EU B2B prospect asks "can you send our invoices over Peppol?", "yes, today" closes deals that make your competitors say "it's on the roadmap."

The early-stage on-ramp: sandbox, then a pilot

This is where getpeppr fits, and it's built around exactly this "start small" shape. (It's what we ship — but the reasoning holds for any decent Peppol-as-a-service API.) The whole idea is a TypeScript-first wrapper around a certified Access Point: a JSON object goes in, a Peppol-compliant invoice goes out, and you never touch the XML unless you ask to.

Step one is free. Create an account and the sandbox is yours — free forever, no credit card, no time limit. You get the full SDK surface, real validation errors, and webhook events — just no live Peppol traffic. This is where a young team should live for the first week: learn the model with zero commitment.

Step two is a pilot, not a platform contract. When you're ready to send for your first real customers, the Platform Pilot tier is sized for precisely that moment: €99/month, up to 10 production Legal Entities, €0.35 per successfully sent document, as a 6-month pilot bridge. It's described as being "for early SaaS platforms validating production Peppol with first customers," includes guided onboarding, and has a defined conversion path to the larger Starter and Growth tiers as you grow.

Be aware of one honest caveat: production sending is contract-gated — a signed platform agreement and a DPA are required before live customer sending is enabled. That isn't a paywall; it's the compliance reality of sending invoices on another company's behalf. Plan a few days for it rather than discovering it the afternoon a customer wants to go live.

If you're sending your own invoices rather than acting as a platform, the direct-business tiers are public and self-serve: Starter €49/mo (100 docs), Pro €149/mo (800 docs), Business €399/mo (2,000 docs), with overage from €0.20/doc.

The TypeScript path, in about fifteen lines

Here's the entire happy path. The code uses real @getpeppr/sdk v1.5.0 calls.

Install and initialise. Keys are environment-prefixed — sk_sandbox_... for test, sk_live_... for production. Switching environments is a key change, not a code change.

npm install @getpeppr/sdk

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

const peppol = new Peppol({ apiKey: process.env.GETPEPPR_API_KEY });

Send an invoice. The shape mirrors the EN 16931 model — supplier, customer, line items with VAT — but stays JSON-shaped:

const result = await peppol.invoices.send({
  number: "INV-2026-001",
  from: {
    name: "Your Customer Ltd",
    peppolId: "0208:BE0456789012", // the legal entity sending
    country: "BE",
  },
  to: {
    name: "Acme Corp",
    peppolId: "0208:BE9876543210",
    street: "123 Business Ave",
    city: "Brussels",
    postalCode: "1000",
    country: "BE",
  },
  lines: [
    { description: "Consulting services", quantity: 10, unitPrice: 150, vatRate: 21 },
  ],
});

Under the hood the SDK builds UBL 2.1, validates it against Peppol BIS Billing 3.0, signs the envelope, and submits via the Access Point.

Validate offline first, with no key at all. The @getpeppr/cli package (v0.4.3) generates, validates and converts invoices entirely offline. Use it to sanity-check your JSON shape before you wire up the live API:

npx @getpeppr/cli validate my-invoice.json

Handle status asynchronously. Peppol delivery isn't synchronous — send() gives you a queued ID, and the rest arrives via webhooks (invoice.sent, invoice.accepted, invoice.refused, invoice.error, invoice.paid, and friends). Signatures are HMAC-SHA256 on the Getpeppr-Signature header, and the SDK verifies them for you:

const event = peppol.webhooks.constructEvent(
  req.body,
  req.headers["getpeppr-signature"] as string,
  process.env.PEPPR_WEBHOOK_SECRET!,
);

if (event.type === "invoice.refused") flagForReview(event.data.invoiceId);

That's the whole surface. If you're sending on behalf of many customers — the multi-tenant case where one master API key fans out to N legal entities — the platform integration docs cover that model end to end (master keys, per-tenant legal entities, KYB), and the multi-tenant pattern (G2 in this series) walks through the code.

The boring truth about doing it later

Retrofitting Peppol under a deadline is the same engineering as doing it calmly now — minus the safety margins. You lose the sandbox-learning week, the flag-gated rollout, the parallel-run validation, and the option to push a fix without a customer breathing down your neck. You also lose negotiating leverage: "we need this live in three weeks" is not the position you want to be in with any dependency.

Starting early converts a future fire drill into a quiet afternoon of integration work. For a young SaaS, that trade is almost always worth making while it's cheap.

Next steps

Create a sandbox key — free, no credit card, full SDK. Push a fake invoice through this week.
Validate one of your real invoices offline first: npx @getpeppr/cli validate your-invoice.json. Two minutes, zero commitment.
For the regulatory context, read the Belgium developer playbook (G1). For the multi-tenant architecture, read how to add Peppol to your SaaS (G2).
Building a platform that sends for many customers? The platform integration docs cover master API keys, per-tenant legal entities, and KYB by country.

No call required, no demo to book — just an API key. The mandates are arriving on a published schedule, and the calmest time to get ready is now, on your own terms.

— Zero Loop Labs

How to add Peppol e-invoicing to your SaaS without making it your team's problem

Zero Lopp Labs — Sun, 24 May 2026 20:26:06 +0000

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.

Region	Practical status	Notes
Belgium	Domestic B2B structured e-invoicing live since 1 Jan 2026	Peppol is the main rail. Common scheme: `0208` for Belgian CBE/KBO.
Germany	B2B e-invoice receiving obligation live since 1 Jan 2025; issuing phases in 2027-2028	Peppol can be part of the stack, but Germany is not Peppol-only. XRechnung/ZUGFeRD context matters.
France	Rollout starts 1 Sept 2026	Requires approved platforms/PDP-style flows. Peppol alone is not the whole France compliance story.
Nordics	Mature e-invoicing markets	Strong Peppol usage, but sender onboarding and identifier schemes differ by country.
EU cross-border	ViDA digital reporting from 1 July 2030	This is EU-wide digital reporting, not a blanket "Peppol mandate".

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:

Map your invoice model to the provider's JSON shape. Unit-test the mapper against representative invoices.
Run offline validation and XML conversion in CI for a small fixture set.
Send through sandbox first and compare the resulting XML with your current pipeline.
Move read-only status display first, then flip sends for one low-volume customer.
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

Belgium's e-invoicing grace period ended. Here's the developer's playbook.

Zero Lopp Labs — Tue, 28 Apr 2026 12:05:58 +0000

The grace period is over

On 27 March 2026, Belgium's FPS Finance went on Radio 2 to confirm what most CFOs in Brussels were quietly dreading: the three-month tolerance period for B2B e-invoicing wouldn't be extended. Since 1 April 2026, the new rules are fully enforced.

If your company sends invoices between Belgian VAT-registered businesses and you're still emailing PDFs, you're now exposed to a graduated penalty regime: €1,500 for the first offence, €3,000 for the second, €5,000 for the third — within a three-month escalation window. The Royal Decree of 8 July 2025 codified this in article 13ter of Royal Decree No. 1, with the penalty schedule in Royal Decree No. 44.

This article isn't a legal explainer. It's a developer's playbook: what the law actually requires from your stack, why this lands on your engineering team and not just your finance department, and a working TypeScript path to compliance.

What the law actually requires

Three things, in order of how often they trip up dev teams.

A structured electronic format. PDFs are out. The mandate requires invoices in formats conforming to EN 16931 — primarily UBL 2.1 and CII 16B. Hybrid formats like Factur-X and ZUGFeRD are recognised for specific cases. In practice, for Belgium, you generate UBL 2.1 XML following the Peppol BIS Billing 3.0 specification.

The Peppol network as the default transmission channel. You can't just email an XML file. Invoices flow through Peppol, a four-corner network of certified Access Points. Alternative channels (EDI, point-to-point) are allowed only by mutual agreement and only if they meet the same EN 16931 standards. The default Peppol track must always be available — your customer can require it.

Coverage scope. All B2B transactions between Belgian-established VAT-registered taxpayers fall under the mandate. That includes foreign companies with a Belgian fixed establishment, and VAT groups. Out of scope: B2C, cross-border (until ViDA in 2030), and entities exclusively performing Article 44-exempt activities. Self-billing benefits from an extended tolerance until end of June 2026.

Existing record-keeping rules still apply — but now to structured XML. Seven years of archival, machine-readable.

Why your engineering team owns this

In most companies, e-invoicing was a finance problem. Print, sign, send. That's no longer true. The 2026 mandate is a systems integration problem first, and a finance problem second.

You need to:

Generate UBL 2.1 XML that validates against EN 16931 schematron rules
Look up your trading partners' Peppol identifiers
Submit through a certified Access Point (you don't get to be one — that's a regulated entity with infrastructure requirements)
Receive incoming invoices through the same network
Handle status callbacks (accepted / rejected / errored) via webhooks
Persist everything for seven years

None of that lives on a finance team's laptop. It lives in your codebase, with your auth, your retry logic, your monitoring, your audit trail.

If your invoicing today is an export-to-PDF function in your accounting page, the gap between "what you have" and "what the law requires" is a backend project, not a vendor selection.

The 4-corner Peppol model in plain English

Peppol's architecture has four parties. Most articles describe it as a network. It's easier to think of it as a delivery contract.

[ You ] → [ Your Access Point ] → [ Recipient's Access Point ] → [ Recipient ]
  C1            C2                          C3                       C4

C1 — You. The supplier issuing the invoice. You generate UBL XML.
C2 — Your Access Point. A certified service provider that signs your message, validates it against Peppol BIS 3.0, and routes it.
C3 — Recipient's Access Point. The buyer's certified provider, who validates and delivers.
C4 — Recipient. Your customer, whose accounting system receives the structured invoice.

You only operate C1. C2 is a vendor choice — you connect to one Access Point, and that single connection gives you reach to every Peppol participant in the EU and beyond. The Access Point handles certificate management, dynamic discovery (looking up where to send a given recipient's invoice), and message-level acknowledgements.

In Belgium, all in-scope businesses must be Peppol-capable, which in practice means having a contract with — or an integration into — a certified Access Point. Becoming an Access Point yourself is a multi-month project with annual fees, audits, and certificate authorities. Almost no SaaS does it directly.

This is the same model that has run B2G invoicing in Belgium federally since 1 March 2024 (and regionally since 2017 for Flanders, 2020 for Brussels, 2022 for Wallonia), through the Mercurius platform. The 2026 mandate just extends the four corners to B2B. A five-corner variant arrives in 2028 for e-reporting — the fifth corner being FPS Finance itself.

A TypeScript path to compliance

Here's where getpeppr fits. We're a TypeScript-first wrapper around a certified Access Point, with the Stripe-style developer experience: a JSON object goes in, a Peppol-compliant invoice goes out.

Install the SDK:

npm install @getpeppr/sdk

Initialise the client. API keys are environment-prefixed — sk_sandbox_... for test, sk_live_... for production:

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

const peppol = new Peppol({ apiKey: process.env.GETPEPPR_API_KEY });

Send your first invoice. The shape mirrors the EN 16931 model — supplier and customer identification, line items with VAT rates, totals — but stays JSON-shaped:

const result = await peppol.invoices.send({
  number: "INV-2026-001",
  to: {
    name: "Acme Corp",
    peppolId: "0208:BE9876543210",
    street: "123 Business Ave",
    city: "Brussels",
    postalCode: "1000",
    country: "BE",
  },
  lines: [
    {
      description: "Consulting services",
      quantity: 10,
      unitPrice: 150,
      vatRate: 21,
    },
  ],
});

console.log(`Invoice sent! ID: ${result.id}`);

Under the hood, the SDK generates UBL 2.1 XML, validates it against Peppol BIS Billing 3.0 schematron rules, signs the envelope, and submits via a certified Access Point. You don't see the XML unless you ask for it.

What's not shown above but matters in production:

Status updates via webhooks. Peppol delivery is asynchronous. Your endpoint receives invoice.accepted, invoice.rejected, and invoice.errored events with HMAC-SHA256 signature verification.
Directory lookup. Before sending, you usually want to verify the recipient is on the network. peppol.directory.lookup("0208:BE...") returns capability metadata — country, registered name, supported document types.
Credit notes and corrections. All EN 16931 invoice types are supported (380 standard, 381 credit note, 383 debit, 386 prepayment, 389 self-billed). The same .send() method handles them by setting isCreditNote: true plus an invoiceReference.

The sandbox is free and unlimited. No real Peppol traffic is generated, but you get the full API surface, validation errors, and webhook events. When you switch the key prefix from sk_sandbox_ to sk_live_, the only change in your code is the apiKey value. Live pricing: Starter €49/mo (100 docs), Pro €149/mo (800 docs), Business €399/mo (2,000 docs), with overage from €0.20/doc.

What's not in scope (yet)

The 2026 Belgium mandate is intentionally narrow. If you operate beyond it, you have more time — but you're already on the same regulatory glide path.

B2C transactions stay outside the mandate. You can keep emailing PDFs to consumers.
Cross-border invoices (intra-EU and extra-EU) are out of scope until the EU's "VAT in the Digital Age" (ViDA) Digital Reporting Requirements take effect on 1 July 2030.
Article 44-exempt entities (mostly certain financial, medical, and educational services) don't have to issue structured e-invoices for their exempt activities.
Self-billing has an extended tolerance until end of June 2026 — that's two months from now.
Pre-existing invoicing fines (late issuance, missing fields, incorrect VAT rounding) remain in force on top of the new technical-readiness penalty regime.

Looking ahead, 1 January 2028 brings near-real-time e-reporting to FPS Finance via Peppol's five-corner model, replacing the annual customer listing. Your 2026 work is the foundation for it — same Access Point, same XML, plus a tax-authority recipient.

If you're building B2B SaaS for the EU, the practical horizon isn't "Belgium 2026". It's "ViDA 2030". Belgium is operationalising now what the rest of the EU is preparing.

Next steps

If you're a developer at a Belgian B2B SaaS, three things are worth doing this week:

Map your invoice flow. Where does PDF generation live in your codebase? How do you identify customers' VAT numbers? How do you persist invoices today? You need this before scoping any integration.
Verify your customers' Peppol presence. Many are already receiving invoices via Peppol from B2G suppliers since 2024. The Peppol Directory lookup is a one-line check.
Spin up a sandbox. getpeppr.dev — free, unlimited, takes an afternoon to wire into a typical Node.js codebase. No call required, no demo to book. Just an API key.

The grace period is over. The first €1,500 fine could land on someone's desk this quarter.

SWIFT Is Killing MT940 — Here's How to Future-Proof Your Bank Statement Pipeline

Zero Lopp Labs — Mon, 23 Mar 2026 17:06:11 +0000

On November 22, 2025, SWIFT pulled the plug on legacy MT payment messages. Cross-border payments now run exclusively on ISO 20022's MX format.

MT940 — the bank account statement format your reconciliation pipeline probably depends on — wasn't part of that first wave. It's a reporting message, not a payment message. But it's next. SWIFT has formally deprecated MT940, stopped maintaining it, and announced that disincentives for continued usage are coming.

If your application parses bank statements, you need a migration plan. Here's what's actually happening, what the formats look like under the hood, and how to build a pipeline that handles both.

What MT940 Actually Looks Like

Before we talk about replacing MT940, let's look at what we're replacing. Here's a real MT940 statement:

:20:STMT2603230001
:25:NL91ABNA0417164300
:28C:15/1
:60F:C260322EUR1234,56
:61:2603220322D45,00NTRFNONREF//ACME-INV-2026-042
:86:999~00SEPA OVERBOEKING~20KENMERK: ACME-INV-2026-042
~21Acme Corp Ltd~22PAYMENT FOR SERVICES~23March 2026
~30DEUTDEDB~31DE89370400440532013000~32Acme Corp Ltd
~33Frankfurt
:62F:C260322EUR1189,56

If you've never parsed this, here's a field-by-field breakdown:

Tag	Name	What's in it
`:20:`	Transaction Reference	Message identifier (max 16 chars)
`:25:`	Account ID	Your IBAN or account number (max 35 chars)
`:28C:`	Statement Number	Sequence number (`15/1` = statement 15, page 1)
`:60F:`	Opening Balance	`C` = Credit, `260322` = 22 Mar 2026, `EUR`, `1234,56`
`:61:`	Statement Line	Date + D/C + amount + type code + reference (max 80 chars)
`:86:`	Information	Free-text transaction details (up to 6 lines × 65 chars)
`:62F:`	Closing Balance	Same format as opening balance

The :86: field is where the real pain lives. Banks cram debtor names, payment references, creditor IBANs, and remittance information into a single text block. There is no universal standard for how this data is structured.

The ~ delimiters you see above? That's one bank's convention (common in SEPA countries). Other banks use / prefixes, ? codes, or just dump everything as plain text. You end up writing bank-specific regex patterns to extract structured data — and they break every time the bank changes their layout.

What CAMT.053 Looks Like Instead

Here's the same transaction in CAMT.053:

<Ntry>
  <Amt Ccy="EUR">45.00</Amt>
  <CdtDbtInd>DBIT</CdtDbtInd>
  <BkgDt><Dt>2026-03-22</Dt></BkgDt>
  <VlDt><Dt>2026-03-22</Dt></VlDt>
  <AcctSvcrRef>ACME-INV-2026-042</AcctSvcrRef>
  <NtryDtls>
    <TxDtls>
      <Refs>
        <EndToEndId>ACME-INV-2026-042</EndToEndId>
      </Refs>
      <RltdPties>
        <Cdtr>
          <Nm>Acme Corp Ltd</Nm>
          <PstlAdr>
            <TwnNm>Frankfurt</TwnNm>
          </PstlAdr>
        </Cdtr>
        <CdtrAcct>
          <Id><IBAN>DE89370400440532013000</IBAN></Id>
        </CdtrAcct>
      </RltdPties>
      <RltdAgts>
        <CdtrAgt>
          <FinInstnId>
            <BIC>DEUTDEDB</BIC>
          </FinInstnId>
        </CdtrAgt>
      </RltdAgts>
      <RmtInf>
        <Ustrd>PAYMENT FOR SERVICES March 2026</Ustrd>
      </RmtInf>
    </TxDtls>
  </NtryDtls>
</Ntry>

No regex. No bank-specific parsing rules. The creditor name is in <Cdtr><Nm>. The IBAN is in <CdtrAcct><Id><IBAN>. The BIC is in <CdtrAgt><FinInstnId><BIC>. The remittance info has its own dedicated <RmtInf> element — with support for both unstructured text and structured sub-fields.

The full CAMT.053 document wraps everything in a clear hierarchy:

Document
  └─ BkToCstmrStmt (Bank-to-Customer Statement)
      ├─ GrpHdr       → Message ID, creation timestamp
      └─ Stmt         → One per account
          ├─ Acct      → IBAN, BIC, account name
          ├─ Bal[]     → OPBD, CLBD, CLAV, FWAV (all timestamped)
          └─ Ntry[]    → One per transaction
              └─ NtryDtls
                  └─ TxDtls → Refs, parties, agents, remittance

Here's the technical comparison side-by-side:

Feature	MT940	CAMT.053
Format	Proprietary text (SWIFT FIN)	XML (ISO 20022, XSD-validated)
Transaction details	Packed into `:61:` (80 chars) + `:86:` (6×65 chars)	Dedicated elements: `Refs`, `RltdPties`, `RltdAgts`, `RmtInf`
Remittance info	Crammed into `:86:`, bank-specific delimiters	Structured `<RmtInf>` with `<Strd>` sub-fields, unlimited length
Balance types	Opening (`:60F:`) and Closing (`:62F:`) only	OPBD, CLBD, CLAV, PRCD, FWAV — all with timestamps
Currency	Single currency per statement	Multi-currency with exchange rate details per transaction
Character set	SWIFT X charset (A-Z, 0-9, basic punctuation — no accents)	Full UTF-8 / Unicode
Date format	`YYMMDD` (ambiguous century)	ISO 8601: `YYYY-MM-DD`
Validation	Manual — hope the parser handles edge cases	XSD schema validation built-in

The Migration Timeline — What's Actually Happening

There's a lot of confusion around "SWIFT is killing MT940" because the migration is happening in waves. Here's the accurate picture:

What already happened (November 22, 2025):
SWIFT ended the MT/ISO 20022 coexistence period for payment messages. MT103 (credit transfers) and MT202 (institution transfers) are formally retired. All cross-border payments now use ISO 20022 MX format exclusively via the FINplus service.

What's happening now (2026):
MT940 and other reporting messages are deprecated and no longer maintained by SWIFT — but they haven't been withdrawn yet. J.P. Morgan's ISO 20022 FAQ puts it clearly: "Reporting and statement messages will not be immediately withdrawn from the FIN service. Although these message types are deprecated and no longer maintained by SWIFT, disincentives for their use will be introduced at a later date."

Banks are transitioning on their own timelines. J.P. Morgan has been accepting CAMT.052/053/054 since Q4 2024. Bank of America completed its Fedwire ISO 20022 implementation in July 2025. 44% of banks are behind schedule on their November 2026 milestones.

What's coming (2027+):
SWIFT's roadmap targets full MT message retirement, including enquiry and investigation messages (MT199/MT299 → camt.110/camt.111) by November 2027. The reporting messages (MT940 → CAMT.053) will follow.

The bottom line: MT940 still works today, but no one is maintaining or improving it. New features, new validation rules, new regulatory requirements — all of that goes into CAMT.053. Building on MT940 now is building on a dead-end.

Your Options as a Developer

Option 1: Build It Yourself

There are open-source libraries for individual formats:

mt940-rs (Rust) — MT940 parser
pycamt / camt_parser (Python) — CAMT.053 parsers
ofxstatement (Python) — OFX converter
Cmxl (Ruby) — MT940 parser with extensible design

The problem: you need multiple libraries plus glue code to normalize outputs into a common model. You need to handle bank-specific :86: field variations, character encoding edge cases (MT940's SWIFT X charset vs. UTF-8), date format conversions (YYMMDD → YYYY-MM-DD), and amount parsing (comma vs. dot decimal separators).

For a single-format, single-bank integration, this works. For anything multi-bank or multi-format, you're signing up for ongoing maintenance as banks change their implementations.

Option 2: Enterprise Aggregators

Plaid (12,000+ institutions), Finicity (Mastercard), and Wise offer bank data APIs. But they solve a different problem — they connect to live bank accounts via OAuth. If you already have statement files (SFTP drops, email attachments, file exports), these platforms are overkill. They're also expensive and come with heavy onboarding.

Option 3: A Dedicated Conversion API

This is the gap. You have files in format A, you need them in format B. No bank connections, no OAuth flows, no aggregation. Just conversion — stateless, fast, spec-compliant.

That's what we're building.

Introducing FinConvert

FinConvert is a REST API that converts bank statement files between financial formats. One endpoint, any supported format in, any supported format out.

The core architecture uses a Universal Transaction Model: every input format is parsed and normalized into a single internal representation, then serialized to the requested output format. This means adding new formats requires N+M adapters, not N×M conversion paths.

Currently supported:

Direction	Formats
Input	MT940, CAMT.053 (OFX, BAI2, QIF coming soon)
Output	CAMT.053, CSV, JSON, OFX (MT940 output coming soon)

Design principles:

Privacy-first — No files are stored. Conversion is stateless. Your financial data is processed in memory and discarded.
Spec-compliant — Output is validated against official SWIFT and ISO 20022 XSD schemas.
Fast — Sub-200ms average conversion time. Pure computation, no I/O bottleneck.
London-hosted — EU data residency for compliance-conscious teams.

Show Me the Code

Convert an MT940 file to structured JSON:

curl:

curl -X POST https://api.finconvert.dev/v1/convert \
  -H "Authorization: Bearer fc_your_api_key" \
  -F "file=@statement.mt940" \
  -F "output_format=json" \
  -o converted.json

TypeScript:

async function convertStatement(file: File): Promise<ConvertedStatement> {
  const formData = new FormData();
  formData.append("file", file);
  formData.append("output_format", "json");

  const response = await fetch("https://api.finconvert.dev/v1/convert", {
    method: "POST",
    headers: {
      Authorization: "Bearer fc_your_api_key",
    },
    body: formData,
  });

  if (!response.ok) {
    throw new Error(`Conversion failed: ${response.status}`);
  }

  return response.json();
}

What you get back — structured, typed, no regex required:

{
  "statement": {
    "account": "NL91ABNA0417164300",
    "currency": "EUR",
    "opening_balance": 1234.56,
    "closing_balance": 1189.56,
    "statement_number": "15/1",
    "date": "2026-03-22"
  },
  "transactions": [
    {
      "date": "2026-03-22",
      "amount": -45.00,
      "currency": "EUR",
      "type": "DEBIT",
      "reference": "ACME-INV-2026-042",
      "description": "PAYMENT FOR SERVICES March 2026",
      "creditor": {
        "name": "Acme Corp Ltd",
        "iban": "DE89370400440532013000",
        "bic": "DEUTDEDB"
      }
    }
  ],
  "transaction_count": 1,
  "format_source": "MT940",
  "format_output": "JSON"
}

That MT940 :86: field with bank-specific ~ delimiters? Parsed into clean, typed JSON. The creditor IBAN that was buried in ~31? Extracted into creditor.iban. No bank-specific logic on your end.

Pricing

Usage-based — you pay for what you convert:

Plan	Price	Conversions/month
Free	$0	100
Pro	$49/mo	5,000
Business	$149/mo	50,000
Enterprise	Custom	Custom

The free tier is enough for testing and low-volume integrations. No credit card required.

What's Next

FinConvert is currently in early access. We're onboarding developers from the waitlist and expanding format support based on demand.

On the roadmap:

OFX, BAI2, and QIF input support
MT940 output (for systems that still require it during the transition)
Auto-format detection — upload any file, we figure out what it is
Batch conversion endpoint for bulk processing
Bank-specific :86: field profiles for higher extraction accuracy

If you're building anything that touches bank statement data — accounting software, reconciliation tools, fintech integrations, ERP connectors — the MT940 deprecation is real. It still works today, but the writing is on the wall: SWIFT has stopped maintaining it, banks are migrating, and every new feature goes into CAMT.053.

Join the waitlist at finconvert.dev to get early access and lock in free-tier usage during beta.

Built by Zero Loop Labs — the same team behind SealTrail (tamper-proof audit trails) and PDFForge (document generation API).

Why your INSERT INTO audit_log proves nothing

Zero Lopp Labs — Fri, 13 Mar 2026 11:11:08 +0000

You've seen this pattern. You might have written it yourself. I know I did.

CREATE TABLE audit_log (
  id         SERIAL PRIMARY KEY,
  user_id    TEXT NOT NULL,
  action     TEXT NOT NULL,
  resource   TEXT,
  metadata   JSONB,
  created_at TIMESTAMPTZ DEFAULT now()
);

Every time something important happens — a user signs a contract, an admin changes permissions, a payment goes through — you INSERT INTO audit_log. Job done. You have an audit trail.

Except you don't.

The problem nobody talks about

That audit_log table sits in the same database as everything else. Anyone with write access can do this:

-- Oops. Never happened.
UPDATE audit_log SET action = 'invoice.viewed' WHERE action = 'invoice.deleted';

-- Or just make it disappear entirely
DELETE FROM audit_log WHERE user_id = 'admin_42' AND action = 'permission.escalated';

No trace. No alert. No way to know it ever happened.

This isn't a theoretical attack. It's the default state of every audit log built on a regular database table. Your DBA can do it. A compromised admin account can do it. A SQL injection exploit can do it. And nobody will ever know.

"But we have backups"

Sure. But backups tell you what the data was, not whether it was tampered with between now and then. If someone edits a row on Monday and you check the backup on Friday, you're comparing against a backup that might already include the edit.

"We use triggers and permissions"

Better. But triggers can be disabled by superusers. ALTER TABLE ... DISABLE TRIGGER ALL is one command. And PostgreSQL SECURITY DEFINER functions can bypass row-level security.

The fundamental issue isn't about access control. It's about provability. Can you prove — cryptographically, not just organizationally — that a log entry hasn't been modified since it was written?

With a regular INSERT? No. You can't.

What auditors actually want

When a compliance auditor asks "show me the audit trail for this transaction," they're not asking for a database dump. They want to know:

Completeness — Are all events present? Can you prove nothing was deleted?
Integrity — Can you prove nothing was modified after the fact?
Ordering — Can you prove the sequence of events hasn't been rearranged?

A plain audit_log table answers none of these questions with certainty.

SOC 2, HIPAA, PCI-DSS Requirement 10, GDPR Article 32 — they all expect or require audit records with demonstrable integrity. "We have a database table" doesn't cut it.

Hash chains: the fix

The solution has existed since the 1990s (Haber & Stornetta, the paper that later inspired Bitcoin's blockchain). The idea is simple:

Each log entry includes a cryptographic hash of itself and the previous entry.

Event 1: hash("payload_1" + GENESIS_HASH)        → hash_1
Event 2: hash("payload_2" + hash_1)               → hash_2
Event 3: hash("payload_3" + hash_2)               → hash_3

Now if someone modifies Event 2, hash_2 changes. But Event 3 was computed using the original hash_2. The chain breaks. The tampering is immediately detectable.

You can't silently edit a single row without invalidating every subsequent hash in the chain.

What this looks like in practice

Here's a concrete example. You're logging invoice events in a SaaS app:

import { SealTrail } from "sealtrail";

const st = new SealTrail({ apiKey: process.env.SEALTRAIL_API_KEY });

// Log an event — hash chain is built automatically
const event = await st.events.log({
  actor: "finance_user_42",
  action: "invoice.approved",
  resource: "inv_12345",
  context: { amount: 5000, currency: "USD" }
});

console.log(event.hash);            // "a1b2c3d4e5f6..."
console.log(event.chain.position);  // 42

Each event gets a SHA-256 hash computed from the canonicalized event payload (actor, action, resource, context), the previous event's hash, and the event timestamp.

The hash and chain position are returned with every event. They're not just metadata — they're cryptographic proof.

Verification: the part that matters

Logging isn't enough. The whole point is that you — or an auditor, or an automated compliance check — can verify that nothing was touched:

const result = await st.events.verify("evt_abc123");

if (result.valid) {
  console.log("Event integrity verified");
  console.log("Chain intact:", result.chainIntact);
} else {
  console.error("TAMPER DETECTED");
  console.error("Expected:", result.computedHash);
  console.error("Got:", result.eventHash);
}

Verification recomputes the hash from scratch. If the stored hash doesn't match the computed one, someone changed the data. If chainIntact is false, someone broke the link between events — meaning an event was inserted, deleted, or reordered.

This isn't trust. It's math.

The DIY trap

At this point you might be thinking: "I can build this myself. SHA-256, a previous_hash column, done."

I thought the same thing. Here's what I ran into:

Concurrent writes. Two events arrive at the same millisecond. Both read the same previous_hash. Both compute their hash against it. You now have a forked chain. Fix: atomic transactions with unique constraints on chain position. Retry on conflict.

Canonical serialization. JSON.stringify({ a: 1, b: 2 }) and JSON.stringify({ b: 2, a: 1 }) produce different strings, therefore different hashes. You need deterministic JSON canonicalization, or your verification breaks when key order varies.

Chain partitioning. One global chain becomes a bottleneck. You need per-resource or per-tenant chains. But then you need to manage chain creation, head tracking, and cross-chain references.

Pagination at scale. Offset-based pagination breaks when events are being inserted. You need cursor-based pagination with stable sort keys.

Retry logic. Rate limits, network failures, concurrent conflicts — your client needs exponential backoff with jitter, and it needs to handle 409 Conflict responses specifically for chain contention.

It's solvable. But it's a week of work to build, and a lifetime of maintenance to keep secure. And if you get the canonicalization wrong, your entire chain is silently invalid.

Stop building underpants

There's a term in engineering for components that every team rebuilds from scratch despite it not being their core business: underpants (as in, everyone needs them, nobody should be hand-stitching them).

Your audit trail is underpants. It needs to work. It needs to be tamper-proof. But it's not what your users are paying you for.

I built SealTrail because I needed this for my own SaaS products and got tired of reimplementing it. It's an API — npm install sealtrail, log events, verify integrity. Hash chains, cursor pagination, isolated chains per resource or tenant, and cryptographic verification are handled for you.

// Your entire audit trail integration
import { SealTrail } from "sealtrail";

const st = new SealTrail({ apiKey: process.env.SEALTRAIL_API_KEY });

// Log (events are chained per chain — default or custom)
await st.events.log({
  actor: userId,
  action: "document.signed",
  resource: documentId,
  context: { ip: request.ip },
  chain: "documents"  // optional — isolates chains per resource type
});

// Verify
const proof = await st.events.verify(eventId);
// proof.valid === true | false

Three lines to log. One line to verify. Hash chain built automatically.

TL;DR

	`INSERT INTO audit_log`	Hash chain audit trail
Can admin silently edit?	Yes	No — hash changes, chain breaks
Can rows be deleted?	Yes	Detectable — position gaps
Can order be changed?	Yes	No — each hash includes previous
Cryptographic proof?	No	SHA-256 chain verification
Compliance-ready?	Questionable	Verifiable record

If your audit log is a regular database table, it proves nothing. It's a convenience log, not an audit trail.

If that's fine for your use case, carry on. But if you're handling financial data, healthcare records, legal documents, or anything where "we can prove this wasn't tampered with" matters — you need hash chains.

I'm Sylvain, solo founder at Zero Loop Labs. I build developer tools. SealTrail is my latest — a tamper-proof audit trail API for developers. Try it free.