Facturation électronique 2026 : guide technique développeurs (EN16931, Factur-X, PDP)

La réforme de facturation électronique française n’est pas un sujet comptable. C’est une contrainte d’ingénierie logicielle avec une date butoir légale. Tout logiciel qui génère, reçoit ou traite des factures entre entreprises françaises assujetties à la TVA doit intégrer un pipeline technique qui n’existait pas dans la plupart des stacks il y a deux ans.

Ce guide s’adresse aux développeurs et architectes qui doivent livrer cette conformité — pas aux DAF qui veulent comprendre la réforme à haut niveau. Chaque section répond à une question technique concrète.

Ce que la réforme impose réellement

Le dispositif réglementaire, tel que publié par le ministère de l’Économie et la DGFiP, impose trois obligations distinctes avec des calendriers différents.

Obligation de réception — 1er septembre 2026

Toutes les entreprises assujetties à la TVA, quelle que soit leur taille, doivent être capables de recevoir des factures électroniques au format normé via une Plateforme de Dématérialisation Partenaire (PDP) à partir du 1er septembre 2026. C’est la date la plus proche et elle s’applique sans exception.

Obligation d’émission — 1er septembre 2026 (GE et ETI)

Les grandes entreprises (plus de 5 000 salariés ou plus de 1,5 Md€ de chiffre d’affaires) et les entreprises de taille intermédiaire doivent aussi émettre leurs factures au format normé dès cette date.

Obligation d’émission — 1er septembre 2027 (PME et TPE)

Les petites et moyennes entreprises et les très petites entreprises ont un délai supplémentaire d’un an pour l’émission.

La conséquence pratique : si votre logiciel a des clients GE/ETI, vous devez être prêt pour les deux volets (émission et réception) en septembre 2026. Si vous ciblez uniquement des PME, la réception reste obligatoire en 2026 — c’est le flux entrant que votre client doit traiter.

Ce qui compte techniquement : une facture conforme à la réforme n’est pas un PDF envoyé par email. C’est un document structuré au format normé (Factur-X, UBL ou CII), acheminé via une PDP accréditée, et accompagné des métadonnées de routage nécessaires à l’annuaire.

Architecture post-PPF : le modèle à 5 coins

Pendant longtemps, la réforme française était décrite avec un modèle en “Y” : l’émetteur envoie sa facture à un hub central (le Portail Public de Facturation, PPF), qui la transmet au destinataire. Le PPF devait jouer ce rôle de concentrateur gratuit pour les entreprises qui ne souhaitaient pas passer par une PDP privée.

Ce modèle a été abandonné. Le PPF ne sera plus un hub de routage des flux de facturation. Son rôle est aujourd’hui limité à deux fonctions :

• L’annuaire : le référentiel central des adresses électroniques de facturation (la “boîte aux lettres” de chaque entreprise et sa PDP)
• La concentration des données : transmission à la DGFiP des données fiscales pour le pré-remplissage TVA

Le routage des factures passe désormais exclusivement par les Plateformes de Dématérialisation Partenaires. Le modèle en place est dit “à 5 coins” (5-corner model) :

┌─────────────┐     ┌──────────────┐     ┌──────────────┐     ┌─────────────┐
│   Emetteur  │────▶│  PDP émission│────▶│ PDP réception│────▶│  Récepteur  │
│  (logiciel) │     │   (privée)   │     │   (privée)   │     │  (logiciel) │
└─────────────┘     └──────┬───────┘     └──────┬───────┘     └─────────────┘
                           │                    │
                    ┌──────▼────────────────────▼──────┐
                    │   Annuaire + Données fiscales     │
                    │          (PPF / DGFiP)            │
                    └───────────────────────────────────┘

Les implications pour votre stack :

1. Votre logiciel ne parle plus à l’État directement — il parle à la PDP de votre client, qui parle à la PDP du destinataire
2. Chaque PDP a sa propre API d’ingestion — mais les formats de factures restent standardisés (Factur-X, UBL, CII)
3. L’administration publie des services d’annuaire pour identifier la PDP et l’adresse de facturation d’un SIREN — les modalités d’accès dépendent du cadre d’intégration et des spécifications en vigueur
4. La validation du format reste votre responsabilité — la PDP rejette les factures non conformes, mais ce rejet intervient après que vous avez soumis la facture

Ce dernier point est critique. La PDP valide techniquement à la réception. Un rejet signifie une facture non transmise, un délai de paiement compromis, et une relance manuelle. La validation doit intervenir dans votre pipeline, avant l’envoi à la PDP.

Le socle technique : trois formats, une norme

La réforme s’appuie sur la norme européenne EN16931 (publiée par le CEN TC 434). Cette norme définit le modèle sémantique d’une facture électronique : quels éléments sont obligatoires, optionnels, leurs types, leur cardinalité. EN16931 est la couche de signification. Les formats sont les couches de syntaxe.

Le cadre EN16931, dans ses bindings CEN publiés (EN 16931-3-2 et EN 16931-3-3), s’appuie sur UBL 2.1 et UN/CEFACT CII D16B. Factur-X 1.08 / ZUGFeRD 2.4, largement déployés en France et en Allemagne, utilisent CII D22B, une extension rétrocompatible de D16B. Les trois formats font partie du socle accepté par les PDP françaises.

UBL 2.1

Universal Business Language, maintenu par OASIS. Format XML utilisé dans les pays nordiques, le Royaume-Uni et sur le réseau Peppol. Structure en cbc: et cac: namespaces. Syntaxe de référence pour Peppol BIS Billing 3.0 ; également accepté par Chorus Pro.

<Invoice xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2">
  <cbc:CustomizationID>urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0</cbc:CustomizationID>
  <cbc:ID>FA-2026-001</cbc:ID>
  <cbc:IssueDate>2026-04-01</cbc:IssueDate>
  <!-- ... -->
</Invoice>

CII (UN/CEFACT)

Cross Industry Invoice, maintenu par UN/CEFACT. Format XML en namespaces rsm: et ram:. La liaison CEN officielle repose sur CII D16B ; Factur-X 1.08 utilise CII D22B, une extension rétrocompatible.

<rsm:CrossIndustryInvoice
  xmlns:rsm="urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100"
  xmlns:ram="urn:un:unece:uncefact:data:standard:ReusableAggregateBusinessInformationEntity:100">
  <rsm:ExchangedDocumentContext>
    <ram:GuidelineSpecifiedDocumentContextParameter>
      <ram:ID>urn:cen.eu:en16931:2017</ram:ID>
    </ram:GuidelineSpecifiedDocumentContextParameter>
  </rsm:ExchangedDocumentContext>
  <!-- ... -->
</rsm:CrossIndustryInvoice>

Factur-X

Factur-X est un conteneur hybride : un PDF/A-3 (conforme ISO 19005-3) avec un XML CII embarqué en pièce jointe. Le PDF est lisible par un humain. L’XML est traitable par machine. C’est un format hybride franco-allemand, co-développé par FNFE-MPE et l’association allemande FeRD, et largement utilisé en France. Factur-X 1.08 repose sur CII D22B, qui étend D16B (la liaison officielle CEN) de manière rétrocompatible. Les artefacts EN16931 publiés par ConnectingEurope restent centrés sur CII D16B ; Factur-X 1.08 introduit ses propres artefacts basés sur D22B.

facture.pdf (PDF/A-3b)
├── Contenu PDF visible (pour le comptable)
└── factur-x.xml (CII D22B, pièce jointe embarquée)
    ├── AFRelationship: Alternative
    ├── MimeType: text/xml
    └── Description: Factur-X

Quel format choisir ?

• Vous ciblez les entreprises françaises en B2B/B2C → Factur-X (lecture humaine + machine, format natif du marché français)
• Vous ciblez les administrations publiques françaises (Chorus Pro) → UBL 2.1 ou CII selon la configuration Peppol
• Vous avez des clients allemands ou autrichiens → ZUGFeRD (identique à Factur-X, même XML CII)
• Vous ciblez un réseau Peppol international → UBL 2.1 BIS 3.0

Pour un guide détaillé des différences techniques et du choix par cas d’usage, voir Factur-X vs UBL vs CII : quel format choisir selon votre intégration.

Le pipeline de validation de référence

Toute facture électronique doit traverser trois niveaux de validation avant d’être considérée comme conforme. Ces niveaux sont indépendants — un fichier peut passer l’un et échouer au suivant.

Niveau 1 — Conformité PDF/A-3 (pour Factur-X uniquement)

La norme ISO 19005-3 impose que le PDF soit un document d’archivage autonome :

• Toutes les polices embarquées (aucune référence à une police système)
• Tous les profils colorimétriques ICC inclus dans le fichier
• Aucune dépendance externe (pas de JavaScript, pas d’encryption)
• La pièce jointe XML doit avoir l’attribut AFRelationship: Alternative
• Les métadonnées XMP doivent identifier le niveau de conformité Factur-X

Un PDF généré “normalement” avec une lib PDF standard n’est généralement pas PDF/A-3 conforme. Les erreurs les plus fréquentes viennent de Ghostscript (profiles ICC mal intégrés) et de bibliothèques PHP comme mPDF (pièce jointe XML de 0 octets).

Niveau 2 — Validation XSD

Le fichier XML est validé contre le schéma XSD officiel EN16931. Le XSD vérifie la structure : présence des éléments obligatoires, types de données, cardinalité. Les erreurs XSD sont souvent les plus faciles à corriger — un champ manquant, un namespace incorrect, un type attendu date qui reçoit une string.

# Valider avec xmllint (exemple pour CII D22B)
xmllint --schema CrossIndustryInvoice_100pD22B.xsd factur-x.xml --noout

Niveau 3 — Validation Schematron

C’est le niveau le plus restrictif et le moins documenté. Les fichiers Schematron officiels (publiés par le CEN TC 434 et FNFE-MPE) définissent plusieurs centaines de règles métier codifiées avec le préfixe BR- (Business Rule).

Ces règles vérifient la cohérence sémantique de la facture, que le XSD ne peut pas vérifier :

• BR-CO-14 : le total TVA de la facture doit correspondre à la somme des montants de TVA par catégorie fiscale
• BR-CO-15 : le montant TTC (BT-112) doit égaler le montant HT (BT-109) plus le total TVA (BT-110)
• BR-16 : la facture doit contenir au moins une ligne de facturation (BG-25)

Une validation complète requiert les deux passes XSD et Schematron. Un fichier qui passe le XSD peut échouer sur 10 règles Schematron. Pour un guide exhaustif des erreurs BR-* et leurs corrections, voir Catalogue des erreurs BR-* : causes, correctifs, exemples XML.

Pipeline complet en pratique

Génération de la facture (ERP/logiciel)
        │
        ▼
[1] Validation XSD ──── ✗ ──▶ Corriger la structure XML
        │ ✓
        ▼
[2] Validation Schematron ─── ✗ ──▶ Corriger les règles métier BR-*
        │ ✓
        ▼
[3] Conformité PDF/A-3 ──── ✗ ──▶ Corriger le conteneur PDF
  (Factur-X uniquement) │ ✓
        │
        ▼
  Soumission à la PDP ────── ✗ ──▶ Facture rejetée (trop tard)

Ce pipeline peut être intégré en CI/CD via l’API FacturX :

curl -X POST https://facturxapi.com/api/v1/validate \
  -H "X-API-Key: votre-cle-api" \
  -F "[email protected]"

La réponse identifie le niveau d’échec, la règle concernée et le chemin XPath dans le XML :

{
  "valid": false,
  "profile": "EN16931",
  "errors": [
    {
      "id": "BR-CO-14",
      "level": "schematron",
      "message": "Le total TVA de la facture doit correspondre à la somme des montants de TVA par catégorie fiscale.",
      "location": "/rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:SpecifiedTradeSettlementHeaderMonetarySummation"
    }
  ],
  "pdfConformance": {
    "valid": true,
    "standard": "PDF/A-3b"
  }
}

Les cinq zones de friction

L’analyse des issues GitHub, questions Stack Overflow et discussions de forums ERP (Odoo, Dolibarr, InvoiceNinja) sur la conformité Factur-X révèle cinq zones de friction récurrentes, indépendamment du logiciel utilisé.

1. PDF/A-3 : la génération du conteneur

Produire un PDF/A-3 réellement conforme est difficile avec les outils généralistes. Les problèmes les plus fréquents :

• Ghostscript : la clause 6.2.3 de l’ISO 19005-3 exige un profil colorimétrique de sortie (DestOutputProfile) avec un espace GRAY, RGB ou CMYK. Un paramètre -sColorConversionStrategy=UseDeviceIndependentColor mal configuré déclenche une erreur de validation VeraPDF
• mPDF (PHP) : la pièce jointe XML est parfois corrompue (0 octets), rendant le Factur-X illisible par les validateurs
• Bibliothèques génériques : certaines génèrent un PDF/A-1 ou PDF/A-2 au lieu de PDF/A-3, invalidant l’attachement de fichiers

Pour un guide complet sur la génération PDF/A-3 conforme, voir PDF/A-3 pour Factur-X : checklist de conformité et pièges courants.

2. Profils Factur-X : lequel suffit ?

Factur-X définit cinq niveaux de complétude, du plus léger au plus complet :

Pour les échanges B2B soumis à la réforme, il faut viser au minimum un profil couvrant pleinement les exigences EN16931 et les contraintes françaises applicables. Les profils MINIMUM et BASIC WL sont insuffisants car ils ne contiennent pas les informations fiscales complètes. En pratique, le profil à utiliser dépend des exigences de la PDP et des spécifications françaises en vigueur — le profil EXTENDED (ou sa variante EXTENDED-CTC-FR) peut être requis pour couvrir les extensions nationales spécifiques à la France.

La valeur du champ GuidelineSpecifiedDocumentContextParameter/ID dans le XML détermine le profil — c’est ce que valident les Schematron de conformité de profil.

3. Erreurs de calcul des taxes

Les moteurs arithmétiques des ERP peuvent générer des incohérences avec les règles Schematron. Le cas le plus documenté est la règle BR-CO-14 : le total TVA de la facture doit correspondre à la somme des montants de TVA par catégorie fiscale.

Un arrondi à 2 décimales calculé ligne par ligne peut introduire un écart de 0,01 € avec le total arrondi globalement. C’est suffisant pour déclencher une erreur de validation. La solution standard : calculer le total TVA par agrégation des lignes, pas par calcul indépendant du total.

InvoiceNinja présente également un bug documenté sur les taxes incluses (BR-CO-14) : quand l’option “taxes incluses” est activée, la répartition dans la balise ApplicableTradeTax est calculée en TTC, créant une incohérence avec TaxTotalAmount qui reflète le montant HT. Voir InvoiceNinja et Factur-X : valider ses factures avant la réforme 2026 pour le détail de ce cas.

4. Champs obligatoires manquants

Certains champs EN16931 paraissent optionnels dans la norme générale mais deviennent obligatoires selon le profil ou les extensions nationales françaises :

• BT-30 : identifiant légal du vendeur (SIREN, avec schemeID="0002") — absent dans la plupart des configurations par défaut des ERP
• BT-48 : identifiant fiscal du vendeur (numéro de TVA intracommunautaire) — distinct du SIREN
• BG-16 : instructions de paiement — fortement recommandées dès que DuePayableAmount > 0, et rendues obligatoires par certaines CIUS nationales (ex. XRechnung pour l’Allemagne via BR-DE-1)
• BT-4 : type de transaction (B2B, B2G, B2C) — requis dans les extensions nationales françaises

Pour la cartographie complète des champs obligatoires par profil et leur mapping dans les structures XML CII et UBL, voir Champs obligatoires EN16931/Factur-X : cartographie et mapping ERP → XML.

5. Import entrant : extraction de l’XML depuis le PDF

La réception est aussi technique que l’émission. Un PDF Factur-X reçu contient un XML CII embarqué en pièce jointe. Pour traiter ce flux entrant de manière automatisée, votre logiciel doit :

1. Détecter la présence d’une pièce jointe nommée factur-x.xml ou ZUGFeRD-invoice.xml
2. Vérifier l’attribut AFRelationship: Alternative
3. Extraire le XML
4. Valider sa conformité (le fichier reçu peut être non conforme)
5. Parser les champs EN16931 pour alimenter votre comptabilité

Des cas d’échec fréquents : PDF mal formé (XML non trouvé malgré la présence), AFRelationship incorrect (/Data au lieu de /Alternative), ou XML UTF-8 avec BOM mal géré par le parser.

XSD vs Schematron : comprendre la distinction

C’est le malentendu le plus fréquent dans les intégrations Factur-X.

Le XSD (XML Schema Definition) valide la forme : les éléments présents, leurs types, leur cardinalité. Il ne peut pas vérifier si TaxTotalAmount est cohérent avec la somme des lignes. Il vérifie uniquement que TaxTotalAmount est bien présent et qu’il contient un nombre décimal.

Le Schematron valide la sémantique : les règles métier, les cohérences entre champs, les contraintes conditionnelles. C’est le Schematron qui contient les règles BR-*.

Un fichier XML peut être XSD-valide et Schematron-invalide. Les deux passes sont nécessaires. Les outils qui n’exécutent que le XSD (nombreux validateurs “basiques”) ne détecteront pas les erreurs Schematron — celles qui causent les rejets en production.

Les fichiers Schematron officiels pour EN16931 sont publiés par le CEN TC 434 et distribués avec le validateur KoSIT (xrechnung-schematron). Les Schematron spécifiques au profil Factur-X France sont distribués par FNFE-MPE. Les versions ont leur importance — des règles ont été corrigées entre les releases.

Build vs Buy : construire ou intégrer ?

Le choix entre intégrer un validateur open source et utiliser une API tierce est une décision d’architecture avec des implications sur 3-5 ans.

Option A — Validateur embarqué (KoSIT, Mustang, VeraPDF)

Le validateur KoSIT exécute XSD + Schematron + vérification du statut d’acceptation. Mustang (Java) valide les profils ZUGFeRD/Factur-X avec support multi-profils. Les deux nécessitent une JVM et une gestion des artefacts (fichiers de schéma, XSD, Schematron) qui évoluent à chaque release normative.

Option B — API SaaS (FacturX API)

import httpx

def validate_invoice(pdf_path: str, api_key: str) -> dict:
    with open(pdf_path, "rb") as f:
        response = httpx.post(
            "https://facturxapi.com/api/v1/validate",
            headers={"X-API-Key": api_key},
            files={"file": f},
            timeout=30,
        )
    response.raise_for_status()
    return response.json()

result = validate_invoice("facture-2026-001.pdf", "votre-cle")
if not result["valid"]:
    for error in result["errors"]:
        print(f"[{error['id']}] {error['message']}")

Option C — Hybride

Validation légère XSD en local (rapide, détecte les erreurs structurelles évidentes) + API pour la validation Schematron complète avant soumission à la PDP. Réservé aux volumes très élevés avec contrainte de latence stricte.

Le critère de choix principal est le coût de maintenance des schémas. La norme EN16931 a eu plusieurs révisions. Les extensions françaises (profil EXTENDED) évoluent avec le cahier des charges de la réforme. Embarquer un validateur signifie gérer ces mises à jour manuellement, sous peine de valider des fichiers selon une version obsolète.

Prochaines étapes

Ce guide couvre les fondamentaux. Les articles suivants approfondissent les sujets spécifiques :

• Valider EN16931/Factur-X : XSD vs Schematron, erreurs BR-*, workflow de debug — le playbook de débogage complet
• PDF/A-3 pour Factur-X : checklist de conformité et pièges courants — génération, Ghostscript, VeraPDF, mPDF
• Factur-X vs UBL vs CII : quel format choisir — comparatif technique par contexte d’intégration
• Champs obligatoires EN16931/Factur-X : cartographie complète — mapping ERP → XML par profil

La clé API gratuite permet de tester l’intégration immédiatement — sans inscription, sans carte bancaire. Le quota gratuit couvre largement les phases de développement et de tests.