Docs / Facturation électronique en Belgique (Peppol BIS)

Facturation électronique en Belgique (Peppol BIS)

Statut au 27/07/2026 : périmètre livré = génération UBL variante peppol-bis (Epic 6, Story 6.1), validation contre le rule pack officiel Peppol BIS Billing 3.0 (Story 13.1), conversion CII↔UBL, extraction UBL.

Ce que dit la réglementation

Depuis janvier 2026, les entreprises belges assujetties doivent pouvoir émettre et recevoir des factures électroniques structurées via le réseau Peppol, dans la spécialisation Peppol BIS Billing 3.0 (elle-même une spécialisation d'UBL 2.1, basée sur la norme EN 16931).

Ce que Heartwood couvre aujourd'hui

  • Génération UBL 2.1 dans la variante peppol-bis (POST /v1/generate/ubl?variant=peppol-bis) — même modèle pivot EN 16931 que la génération Factur-X/CII (Epic 1).
  • Validation contre le rule pack officiel Peppol BIS Billing 3.0 (ubl-peppol-bis-3.0.20, Story 13.1) : schéma XSD OASIS UBL 2.1 et les deux passes schematron officielles d'OpenPEPPOL (CEN-EN16931-UBL : socle EN 16931 générique ; PEPPOL-EN16931-UBL : règles additionnelles propres au réseau Peppol, codes PEPPOL-EN16931-R*). Sélectionnable explicitement (?rulepack=ubl-peppol-bis-3.0.20) ou retenu automatiquement : POST /v1/validate reconnaît un document UBL qui déclare lui-même viser Peppol (cbc:CustomizationID) et applique ce rule pack sans paramètre supplémentaire — voir rulepacks/README.md pour le mécanisme de sélection. La réponse cite toujours le pack appliqué avec sa version (rulepack.id, rulepack.version), jamais un « conforme » sans préciser contre quoi.
  • Conversion CII↔UBL (POST /v1/convert) — utile pour interopérer avec un partenaire français (CII) et un partenaire belge (UBL Peppol) sans ressaisie.
  • Extraction d'un UBL reçu vers JSON normalisé (POST /v1/extract) — même schéma que pour Factur-X/CII.

Limites connues

  • Le rule pack Peppol n'est vérifié que contre un seul exemple officiel (rules/examples/base-example.xml du dépôt OpenPEPPOL, release v3.0.20) lors du développement de cette story — pas contre le corpus complet du référentiel. Voir rulepacks/ubl-peppol-bis-3.0.20/NOTICE.md.
  • Les règles nationales Peppol (rules/national-examples/, ex. Grèce, Norvège) ne sont pas intégrées — seul le socle Peppol BIS générique (CEN + PEPPOL) l'est.
  • Les artefacts schematron Peppol ne sont jamais commités dans ce dépôt : la licence d'OpenPeppol AISBL interdit leur redistribution/repackaging sans accord préalable. scripts/peppol-rulepack/fetch-and-compile.sh les télécharge et les compile localement (dev, CI, build d'image) après vérification d'une empreinte SHA-256 figée — sans exécution préalable de ce script, la validation Peppol ne couvre que le schéma XSD (schematronChecked: false), jamais un faux "conforme" silencieux.
  • Le réseau Peppol lui-même n'est pas couvert : Heartwood génère/ valide/convertit/extrait des documents, mais ne transmet rien sur le réseau Peppol (pas un Access Point Peppol) — voir le README du projet pour le périmètre du produit.
  • [ASSUMPTION] : les variantes fr-socle, peppol-bis et xrechnung partagent aujourd'hui exactement le même socle de champs modélisés (core.Invoice) côté génération — aucune règle spécifique à Peppol BIS n'y est encore distinguée (la validation, elle, applique désormais les vraies règles officielles depuis Story 13.1).