ediverse

Tapez pour rechercher dans les standards, messages, outils et glossaire.

ediverse Explorer la plateforme

À la une PEPPOL BIS Billing 3.0 L’obligation européenne d’e-invoicing arrive : France sept 2026, Belgique janv 2026, Allemagne 2025.

— 01

Fondamentaux

— 02

Standards

— 03

Messages phares

— 04

Outils

France — Mandat e-invoicing 2026 / 2027

La France a opté pour un modèle décentralisé bâti autour des Plateformes de Dématérialisation Partenaires (PDP) immatriculées et d'un Portail Public de Facturation (PPF) recentré sur l'agrégation des données fiscales.

Timeline réglementaire

Le mandat français trouve son fondement dans la loi de finances pour 2020 et a été précisé par une série d'ordonnances, décrets et arrêtés. Les principaux jalons publiés au Journal officiel :

  • Loi 2019-1479 du 28 décembre 2019 — Loi de finances pour 2020, article 153. Habilitation à généraliser l'e-invoicing B2B par voie d'ordonnance et création d'une obligation de transmission de données de facturation à l'administration (e-reporting).
  • Ordonnance 2021-1190 du 15 septembre 2021. Pose les principes de l'obligation, des deux flux jumeaux (e-invoicing entre assujettis français et e-reporting pour les flux B2C et internationaux), et de la certification des PDP.
  • Décret 2022-1299 du 7 octobre 2022. Spécifie les modalités de mise en œuvre, le calendrier (rendu caduc par les reports), la procédure d'immatriculation des PDP, et les obligations de mentions sur facture.
  • Arrêté du 7 octobre 2022. Fixe les modèles sémantiques et les syntaxes (UBL 2.1, CII, Factur-X) ainsi que le socle minimal de 24 mentions obligatoires en sus de l'EN 16931.
  • Communiqué DGFiP du 28 juillet 2023. Report initial du calendrier avec une mise en service prévue en 2026.
  • Article 91 de la Loi de Finances pour 2024 (Loi 2023-1322 du 29 décembre 2023). Confirme le calendrier : septembre 2026 pour la réception et l'émission grandes entreprises et ETI, septembre 2027 pour les PME et TPE en émission.
  • Décret 2024-266 du 25 mars 2024. Refonte technique et réorganisation des modalités opérationnelles autour des PDP avec une PPF recentrée sur l'annuaire et l'agrégation fiscale.

Approfondissements — 13 pages dédiées

Treize pages dédiées approfondissent chaque dimension du chantier français — la réforme 2026, les spécifications techniques, et l'usage B2B réel qui pré-existe et survivra à la réforme.

Réforme 2026

  • PPF — Portail Public de Facturation · Architecture AIFE, API REST + SFTP, formats UBL 2.1 / CII / Factur-X, certificats RGS, France Connect Pro.
  • PDPs immatriculées · Registre DGFiP, procédure d'immatriculation 36 mois renouvelable, 10+ opérateurs majeurs (Iliad, Docaposte, Tiime, Pennylane, Cegedim, Sage…).
  • E-reporting · La seconde moitié de la réforme : transactions B2C, B2B intra-EU, statuts de paiement. Sanctions 250 € par facture non transmise.
  • 10 statuts du cycle de vie · Machine à états facture : Déposée → Rejetée → Approuvée → Refusée → Paiement transmis → Encaissée → Archivée. Events JSON inter-PDP selon spec AIFE.
  • Calendrier final 2026 / 2027 · 1ᵉʳ sept 2026 : réception universelle + émission grandes / ETI. 1ᵉʳ sept 2027 : émission PME / microentreprises. Décret 2024-1099 post-arbitrage.

Specs techniques

  • Factur-X — FNFE-MPE · 5 profils MINIMUM → EXTENDED, PDF/A-3 hybride + XML CII embarqué. Schematron rules FNFE-MPE + CIUS France.
  • Modèle CTC 5-corner · Hybride entre 4-corner PEPPOL et clearance pur. Comparaison avec Italie SdI, Brésil NF-e, Pologne KSeF, Allemagne Wachstumschancengesetz.
  • Annuaire central · API REST + OAuth 2.0, lookup par SIREN, JSON + JSON-LD, webhooks DGFiP, TTL cache 24h recommandé.
  • Chorus Pro · Plateforme B2G historique depuis 2017. 73 000 entités publiques, 124M factures/an. Migration vers PPF transparente.

Usage B2B réel

  • EDIFACT retail · Carrefour, Leclerc, Auchan, Casino, Intermarché, Système U — subsets EANCOM 2002 S4/S5, ~3 milliards de messages/an.
  • EDIFACT automotive · Stellantis, Renault Group, Valeo, Forvia, Faurecia — standards Galia + VDA + Odette, transport OFTP2 sur ENX.
  • GS1 France + ECR France · Émetteur national GTIN/GLN/SSCC, EPCIS traçabilité, GS1 Digital Link déploiement 2025-2026.
  • TVA — régimes français · Auto-entrepreneur, micro-BNC, réel simplifié, réel normal. Taux 0/2,1/5,5/10/20 %. Auto-liquidation BTP, déchets, télécom B2B.

Schéma technique

Trois syntaxes sont acceptées par la PPF française et par les PDP :

  • UBL 2.1 — la syntaxe OASIS dérivée de PEPPOL BIS Billing 3.0, conforme au modèle sémantique EN 16931. Voir notre page PEPPOL et la spécification officielle docs.peppol.eu/poacc/billing/3.0/.
  • UN/CEFACT CII 16B — Cross Industry Invoice, syntaxe XML onusienne utilisée comme structure interne par Factur-X.
  • Factur-X 1.0 — PDF/A-3 avec XML CII embarqué, profil EN 16931 par défaut. Voir la page dédiée Factur-X / ZUGFeRD.

Le profil français impose 24 mentions complémentaires en sus du tronc EN 16931 (mentions Code général des impôts article 242 nonies A annexe II, numéro SIREN, conditions de règlement, pénalités de retard, etc.). Les règles métier BR-FR-XX du CIUS français sont consolidées dans la spécification publiée sur le site de la DGFiP. Exemple minimal d'un invoice Factur-X profil EN 16931 (le XML embarqué dans le PDF) :

xmlfacturx-en16931-fr.xml
<?xml version="1.0" encoding="UTF-8"?>
<rsm:CrossIndustryInvoice
    xmlns:rsm="urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100"
    xmlns:ram="urn:un:unece:uncefact:data:standard:ReusableAggregateBusinessInformationEntity:100"
    xmlns:udt="urn:un:unece:uncefact:data:standard:UnqualifiedDataType:100">
  <rsm:ExchangedDocumentContext>
    <ram:GuidelineSpecifiedDocumentContextParameter>
      <ram:ID>urn:cen.eu:en16931:2017#compliant#urn:factur-x.eu:1p0:en16931</ram:ID>
    </ram:GuidelineSpecifiedDocumentContextParameter>
  </rsm:ExchangedDocumentContext>
  <rsm:ExchangedDocument>
    <ram:ID>FR-2026-09142</ram:ID>
    <ram:TypeCode>380</ram:TypeCode>
    <ram:IssueDateTime>
      <udt:DateTimeString format="102">20260901</udt:DateTimeString>
    </ram:IssueDateTime>
  </rsm:ExchangedDocument>
  <rsm:SupplyChainTradeTransaction>
    <ram:ApplicableHeaderTradeAgreement>
      <ram:SellerTradeParty>
        <ram:Name>Atelier Numérique SAS</ram:Name>
        <ram:SpecifiedLegalOrganization>
          <ram:ID schemeID="0002">80214579500024</ram:ID>
        </ram:SpecifiedLegalOrganization>
      </ram:SellerTradeParty>
      <ram:BuyerTradeParty>
        <ram:Name>Coopérative Aquitaine</ram:Name>
        <ram:SpecifiedLegalOrganization>
          <ram:ID schemeID="0002">52145201400018</ram:ID>
        </ram:SpecifiedLegalOrganization>
      </ram:BuyerTradeParty>
    </ram:ApplicableHeaderTradeAgreement>
  </rsm:SupplyChainTradeTransaction>
</rsm:CrossIndustryInvoice>

Flux de soumission

Le modèle français est un quatre-corner décentralisé : l'émetteur (corner 1) confie sa facture à sa PDP (corner 2), qui la route via le réseau interopérable (potentiellement via la PPF comme concentrateur) jusqu'à la PDP du destinataire (corner 3), laquelle remet le document à l'ERP acheteur (corner 4). En parallèle, le concentrateur PPF agrège les données fiscales nécessaires à la DGFiP (e-reporting des montants, statuts de cycle de vie, flux B2C).

textflux-ppf-pdp.txt
┌──────────────┐    ┌─────────┐    ┌──────────────┐    ┌─────────┐    ┌──────────────┐
│ ERP Vendeur  │───>│ PDP-V   │───>│ PPF (DGFiP)  │───>│ PDP-A   │───>│ ERP Acheteur │
│ (corner 1)   │    │(corner 2)│   │ concentrateur │    │(corner 3)│   │ (corner 4)   │
└──────────────┘    └─────────┘    └──────────────┘    └─────────┘    └──────────────┘
                                          │
                                          ▼
                                ┌──────────────────┐
                                │ Données fiscales │
                                │  → DGFiP / TVA   │
                                └──────────────────┘

Le cycle de vie d'une facture comprend des statuts standardisés (déposée, rejetée, refusée, encaissée…) que les PDP s'échangent dans un format structuré, en complément du document métier.

Validation

Côté outillage :

  • Validateur officiel PPF — pas encore publié à la date de rédaction. La DGFiP a annoncé un service de validation accessible aux éditeurs avant la mise en service de 2026.
  • Validateur PEPPOL en ligne : /tools/peppol-validator/ — règles EN 16931 et règles PEPPOL CIUS pour les flux UBL.
  • Validateur EN 16931 : /tools/en16931-validator/ — règles métier de base BR-* et BR-CO-*.
  • Validateur communautaire OpenPEPPOL : peppol.helger.com — service public maintenu par Philip Helger, exécute le Schematron complet PEPPOL BIS Billing 3.0.

Pièges courants

  1. Distinction PPF vs PDP. Après les refontes de 2023-2024, la PPF n'est plus un portail d'envoi obligatoire pour les flux B2B : c'est un concentrateur fiscal. Toute architecture qui présume une remise directe à la PPF doit être revue ; les flux doivent transiter par une PDP immatriculée.
  2. Numéro SIREN vs SIRET dans l'annuaire. L'identifiant électronique français utilise le SIREN (9 chiffres) pour la personne morale, le SIRET (14 chiffres) pour l'établissement. Le schemeID PEPPOL est 0009 pour les deux mais les longueurs diffèrent — confusion fréquente, gel d'écriture côté SMP si la valeur est mal cadrée.
  3. 24 mentions obligatoires en sus d'EN 16931. Un fichier qui passe le Schematron PEPPOL générique peut échouer le CIUS français si une mention métier obligatoire manque (par exemple BT-23 texte d'usage métier, conditions de paiement détaillées, ou la référence contractuelle).
  4. Cycle de vie et statuts inter-PDP. Le mandat impose la remontée du cycle de vie (statuts déposée, refusée, encaissée…) entre PDP et vers la PPF. Une intégration qui ignore les statuts métier compromet la conformité même si les factures sont structurellement valides.
  5. e-reporting parallèle B2C et international. L'obligation n'est pas seulement l'e-invoicing B2B mais aussi un e-reporting des données de transaction pour les flux B2C et internationaux. Beaucoup d'implémentations oublient ce volet, qui requiert un canal distinct vers la DGFiP via la PDP.

Liens transverses