Belgium 2026: the developer's playbook

This is the first edition of the EU e-Invoicing Mandate Tracker — the monthly digest for developers building on Peppol. Editions land here first, then in subscribers' inboxes.

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 subsequent offences. A second or later offence only counts if the administration establishes it at least three months after the previous offence that resulted in a fine. The Royal Decree of 8 July 2025 codified the technical requirements 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 had an extended tolerance until end of June 2026 — that window has now closed too.

Existing record-keeping rules still apply — but now to structured XML. Invoices and copies must be retained for ten years, with the structured invoice kept machine-readable throughout that period.

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 / refused / error) via webhooks
Persist everything for ten 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 extends the four-corner exchange to B2B. Belgium's federal coalition agreement targets near-real-time e-reporting from 2028, but that measure has not yet been transposed into law and its final technical model is still to be defined.

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: "ACMEDIA",
    peppolId: "0208:0685660237",
    street: "Rue de la Loi 200",
    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 validates your JSON locally, then sends that structured JSON to the getpeppr gateway. The gateway handles UBL generation and provider translation; the certified Access Point handles network signing and routing. If you need to inspect the generated document locally, the SDK also exposes peppol.toXml().

What's not shown above but matters in production:

Status updates via webhooks. Peppol delivery is asynchronous. Your endpoint receives invoice.accepted, invoice.refused, and invoice.error 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:0685660237") returns capability metadata — country, registered name, supported document types.
Credit notes. The same .send() method handles a credit note when you set isCreditNote: true and provide the original invoice number in 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's extended tolerance ended on 30 June 2026 — it is now fully enforced as well.
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, Belgium's coalition agreement targets near-real-time e-reporting from 2028, intended to replace the annual customer listing. That obligation has not yet been enacted, so its final routing and technical requirements should not be assumed. The structured data you implement for 2026 is useful groundwork, but the eventual reporting integration may still require changes.

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.