What format does Belgium's B2B e-invoicing mandate require?

Peppol BIS Billing 3.0 in UBL syntax, delivered over the Peppol network through a registered access point. The requirement covers the channel as well as the format: a compliant UBL file emailed as an attachment does not satisfy the mandate, and a Factur-X or ZUGFeRD hybrid on its own does not either. Parties may bilaterally agree on another EN 16931-compliant channel, but Peppol is the legal default every business can rely on.

Who does Belgium's mandate apply to and since when?

All VAT-registered Belgian businesses for domestic B2B transactions, since January 1, 2026, in a single step: no phase-in by company size and no turnover threshold. Belgium chose the opposite approach to Germany's and France's staged rollouts. Only specific categories, such as certain flat-rate schemes, fall outside the scope.

Is there a Peppol API for Belgium?

Not as a single national API. Integrating means two layers: an access point provider whose API transmits documents over the network, and a document layer that produces and validates the Peppol BIS UBL those transmissions carry. InvoiceXML is the second layer: POST /v1/create/ubl builds BIS 3.0 documents from JSON, and POST /v1/validate/ubl runs the full EN 16931 plus Peppol rule set. It does not operate an access point and does not send; any Belgian access point provider slots in next to it.

How are Belgian companies addressed on Peppol?

By their KBO/CBE enterprise number, registered as the Peppol endpoint identifier under the EAS scheme 0208. The enterprise number matches the Belgian VAT number without the BE prefix. In an invoice document that means the buyer's electronic address (BT-49) carries the enterprise number with scheme 0208, and the same pair addresses the seller in BT-34.

Do I need to validate invoices myself if my access point already does?

Practically, yes. Most access points run the BIS Schematron at the gate and reject failures, but that check fires at transmission time, in production, with provider-specific error formats. Running the same official rules yourself, in CI against representative invoices and in the pipeline before handoff, turns every one of those late rejections into an immediate structured finding with a rule id and field path, while your team is still looking at the code that caused it.

Does InvoiceXML send invoices over the Peppol network?

No. InvoiceXML creates and validates the documents: Peppol BIS 3.0 UBL for Belgium, plus EHF, NLCIUS, PINT, XRechnung, ZUGFeRD, Factur-X and CII. Transmission is your access point provider's job, and the two connect through the validated UBL file you hand over.

Belgium Peppol Mandate for Developers: UBL and BIS 3.0

Belgium skipped the phase-in. Where Germany staggers its B2B mandate over years and France sorts companies by size, Belgium switched on January 1, 2026 in one move: every VAT-registered business, sending and receiving, structured invoices only. A plain PDF is no longer a valid domestic B2B invoice. And Belgium is the strictest of the large EU mandates about the channel: the invoice must be a Peppol BIS Billing 3.0 UBL document delivered over the Peppol network, not merely a file in the right format.

For the businesses affected, that sentence is mostly about picking software. For the developers behind that software (the ERP integrations, the SaaS invoicing features, the AP pipelines), it decomposes into two jobs with a clean seam: transport, which a registered access point provider handles end to end, and the document layer, which is yours: producing UBL that passes the BIS rules, addressing parties correctly, and proving compliance before anything reaches the gate. This guide covers the second job. The legal timeline and business-facing FAQ live on the Belgium mandate page; the two-layer architecture in full is the subject of the Peppol API integration guide.

The Big Bang in one paragraph

Since January 1, 2026, domestic B2B invoices between VAT-registered Belgian businesses must be structured e-invoices sent and received over the Peppol network, with no rollout stages and no size threshold. The required document is Peppol BIS Billing 3.0 (UBL syntax), which is EN 16931 tightened by the network's own rule set. Parties may agree bilaterally on another EN 16931-compliant channel, but Peppol readiness is the legal default every counterparty can rely on, so in practice Belgian B2B traffic is Peppol traffic. B2G ran ahead of this: suppliers to Belgian public bodies have been invoicing over Peppol since the early 2020s, and the B2B mandate folded both worlds onto the same network.

What the mandate means in code

Strip the legal language and a Belgian-ready invoicing feature needs four things:

A UBL 2.1 document conforming to Peppol BIS Billing 3.0. Not generic EN 16931: the BIS overlay adds the rules that generic validation never checks, including mandatory electronic addresses on both parties and the required buyer or purchase order reference (PEPPOL-EN16931-R003).

Correct participant addressing. Belgian endpoints are identified by the KBO/CBE enterprise number under EAS scheme 0208. Wrong scheme, no delivery.

A registered access point. Your own, via a provider contract, or the one embedded in the accounting platform you integrate with. Its API takes your finished UBL and handles SMP lookup, AS4, and delivery. This is the layer InvoiceXML deliberately does not provide; access points appear in this guide only as the transport your documents are handed to.

Validation you control. The gate at the access point rejects failing documents in production. The mandate makes every such rejection a compliance incident, which is the argument for running the same official rules yourself, earlier, where failures are cheap.

Addressing Belgian buyers

The field Belgian integrations get wrong most often is the electronic address pair. Every BIS document carries one for each party: an identifier plus an Electronic Address Scheme (EAS) code saying how to read it. For Belgian companies the pair is the enterprise number under scheme 0208:

"buyer": {
  "name": "Vlaamse Distributie NV",
  "electronicAddress": { "identifier": "0417497106", "schemeId": "0208" },
  "postalAddress": { "line1": "Meir 24", "postCode": "2000", "city": "Antwerpen", "country": "BE" }
}

Three details worth pinning to the wall:

The enterprise number is the VAT number without the prefix. A company with VAT identifier BE0417497106 has enterprise number 0417497106. Both facts can live in the same document (the VAT identifier in BT-48, the enterprise number as the electronic address), and they are different fields doing different jobs.

The scheme must be numeric for Peppol. EN 16931's legacy alphabetic EAS codes (EM, AN, AQ, AS, AU) validate as generic EN 16931 and fail Peppol's PEPPOL-EN16931-CL008. The InvoiceXML create and validate endpoints pre-check exactly this and refuse a legacy code on a Peppol-bound document before the Schematron even runs.

The registration is the source of truth. The mandate's compliance steps include confirming each customer's endpoint in the Peppol directory; the electronic address you write must match what the buyer registered, which for Belgian companies is overwhelmingly the 0208 enterprise number.

Building the UBL

POST /v1/create/ubl builds the document from structured JSON, with Peppol BIS Billing 3.0 as the default profile, totals and the VAT breakdown computed from the lines, and the BIS-specific requirements enforced up front:

Try it online API documentation

curl -X POST https://api.invoicexml.com/v1/create/ubl \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "invoice": {
      "invoiceNumber": "F-2026-0331",
      "issueDate": "2026-09-29",
      "currency": "EUR",
      "buyerReference": "BESTELLING-2201",
      "seller": {
        "name": "Ateliers Wallons SPRL",
        "vatIdentifier": "BE0999999921",
        "electronicAddress": { "identifier": "0999999921", "schemeId": "0208" },
        "postalAddress": { "line1": "Rue de la Gare 5", "postCode": "4000", "city": "Liege", "country": "BE" }
      },
      "buyer": {
        "name": "Vlaamse Distributie NV",
        "vatIdentifier": "BE0417497106",
        "electronicAddress": { "identifier": "0417497106", "schemeId": "0208" },
        "postalAddress": { "line1": "Meir 24", "postCode": "2000", "city": "Antwerpen", "country": "BE" }
      },
      "lines": [
        {
          "quantity": 20,
          "unitCode": "H87",
          "item": { "name": "Gelaste stalen frames" },
          "priceDetails": { "netPrice": 85.00 },
          "vatInformation": { "rate": 21, "categoryCode": "S" }
        }
      ]
    }
  }' \
  --output invoice-ubl.xml

The response is the UBL file your access point's API takes from there, already carrying the BIS customization identifier and already validated against the rule set the gate will apply. If the data cannot produce a compliant document (a missing electronic address, no buyer reference, a VAT category whose rules are violated), the API returns HTTP 400 with the findings enumerated instead of a file. Reference documents to compare against live on the UBL samples page.

Validate before the access point sends

For documents built elsewhere (an ERP's UBL export, an existing generator, a partner's file you forward), POST /v1/validate/ubl runs the full stack: UBL schema, EN 16931 core rules, and the Peppol BIS overlay, returning every finding with its rule id, plain-language message, and the XPath where it fired:

Try it online API documentation

curl -X POST https://api.invoicexml.com/v1/validate/ubl \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -F "[email protected]"

Where it belongs in a Belgian pipeline, given the mandate's stakes:

In CI, over a folder of representative invoices: your standard case, a credit note, an exempt line, an intra-community buyer. Every rule change in a mapping shows up as a failing build, not a bounced invoice.

Before handoff, as the last step your pipeline runs before calling the access point's API. Nothing the gate would reject leaves your system, and your logs hold a structured verdict for every document, which is a better audit trail than a provider's error message formats.

On disputes, because "the file we handed to the access point on March 3 passed the official rules, here is the report" is a sentence that ends most conversations about whose fault a rejection was.

The receiving side of the mandate

The mandate obliges businesses to receive over Peppol too, and the receiving half of your integration inherits UBL files from every accounting system in Belgium. Three endpoints cover what AP workflows do with them: POST /v1/extract/json reads any received UBL into structured JSON for your approval screens and ERP import, deterministically, straight from the XML. POST /v1/render/ubl/to/pdf gives approvers and auditors a readable PDF twin of the machine document, the pattern the Peppol invoice to PDF guide builds out in full. And POST /v1/validate/ubl gives an independent verdict on any received file when provenance matters.

The rejections Belgian traffic actually hits

The failure modes cluster tightly, and all of them are catchable before the gate:

Failure	Rule	Pre-gate fix
Missing buyer reference and PO reference	`PEPPOL-EN16931-R003`	Carry `buyerReference` (or the order reference) on every document; the create endpoint refuses to build without one.
Missing electronic address on a party	BIS requirement on BT-34 / BT-49	Enforced as a field-level error at create time, before any XML exists.
Legacy alphabetic EAS scheme	`PEPPOL-EN16931-CL008`	Pre-checked with a message naming numeric alternatives such as 0208.
Totals that do not reconcile	BR-CO calculation rules	Let the API compute totals from the lines; send your own figures only to have them cross-checked.
VAT category inconsistencies (exemption reasons, rates)	BR-S / BR-E / BR-AE families	Category-aware checks run at create time; the validate endpoint reports the same rules on external files.

None of these is exotic; they are the ordinary output of hand-rolled UBL meeting a rule set with hundreds of checks. The mandate simply removed the option of not caring.

Get started

A Belgian integration can prove its document layer end to end before an access point contract exists: create a BIS 3.0 invoice from your own data, validate it, extract it back as JSON, all without a certificate or a network account. Create a free InvoiceXML account → and get 100 credits for free, no credit card required.

Related resources:

InvoiceXML is a REST API for European e-invoice compliance covering Peppol UBL, EHF, NLCIUS, PINT, XRechnung, ZUGFeRD, Factur-X, and CII. Stateless processing, GDPR compliant by architecture, and callable from any stack with an HTTP client. It operates on the document layer and is not an access point.

Belgium's Peppol Mandate for Developers: Validate BIS 3.0 Before Your Access Point Sends

Complete UBL Toolkit