Certification PA France — Guide technique complet pour le mandat e-invoicing 2026

Le régime des Plateformes Agréées (PA) constitue l'ossature technique et juridique du mandat e-invoicing B2B français de 2026. Une PA est une plateforme privée certifiée par la DGFiP (Direction Générale des Finances Publiques) pour émettre, recevoir et suivre le cycle de vie de factures structurées au nom d'entreprises françaises assujetties à la TVA. La certification exige de démontrer la conformité aux 393 champs de données obligatoires, de passer environ 1 841 contrôles schematron et règles métier, et de réussir un audit d'interopérabilité technique avec le PPF (Portail Public de Facturation), le hub central opéré par l'État. Flowie détient la certification PA pour le marché français. Ce guide explique l'architecture réglementaire, la spécification technique, le choix des formats, les obligations de cycle de vie et les patterns d'implémentation concrets que la certification PA impose.

Ce que la certification PA recouvre réellement sous le régime DGFiP

Le terme « Plateforme Agréée » a remplacé l'ancienne désignation « Plateforme de Dématérialisation Partenaire » (PDP) dans la communication officielle de la DGFiP. Le changement de nomenclature est plus que cosmétique : la désignation PA consolide le périmètre de certification pour couvrir les canaux d'émission et de réception sous une seule habilitation, alors que les premières moutures du mandat traitaient ces capacités comme dissociables.

La certification PA est délivrée par la DGFiP à l'issue d'un processus d'audit formel appelé « immatriculation technique ». Cet audit vérifie :

• Capacité technique : la plateforme sait générer, valider et router des factures structurées dans les trois formats imposés (UBL 2.1, UN/CEFACT CII, Factur-X)
• Interopérabilité : la plateforme sait échanger des données avec le PPF en utilisant la spécification API standardisée
• Gestion du cycle de vie : la plateforme sait émettre, recevoir et propager les statuts de cycle de vie obligatoires (Déposée, Refusée, Approuvée, En cours de paiement, Payée, et autres)
• Résidence des données et sécurité : la plateforme satisfait aux exigences de protection des données applicables au titre du RGPD et aux directives d'hébergement de la DGFiP

La certification n'est pas perpétuelle. Les plateformes certifiées doivent maintenir la conformité aux spécifications DGFiP mises à jour — les « Spécifications Externes B2B » — au fur et à mesure de leur évolution. Une modification matérielle de la spécification technique déclenche une obligation de re-attestation.

Le mandat s'applique à toutes les entreprises françaises assujetties à la TVA pour les factures B2B domestiques. Le calendrier au début 2026 (dernière communication stable de la DGFiP) est le suivant :

• 1er septembre 2026 : obligation de réception pour toutes les entreprises françaises assujetties à la TVA, quelle que soit leur taille ; obligation d'émission pour les grandes entreprises et les ETI (entreprises de taille intermédiaire)
• 1er septembre 2027 : obligation d'émission étendue aux PME et micro-entreprises

Ces dates remplacent les échéances cibles de 2024 et 2025, toutes deux reportées. Les dates de septembre 2026 doivent être traitées comme des hypothèses de planification courantes mais vérifiées contre les publications officielles de la DGFiP avant tout engagement contractuel.

Le fondement légal du mandat découle de l'article 289 du Code Général des Impôts français, tel que modifié, et du décret d'application publié au Journal Officiel (référence Legifrance citée dans les sources de ce guide). La base légale européenne sous-jacente est l'article 218 de la Directive TVA 2006/112/CE, qui autorise les États membres à imposer la facturation électronique pour les transactions domestiques sous certaines conditions.

Le modèle à 5 acteurs et l'architecture des flux de données

Le mandat français repose sur une architecture en relais. Aucune facture ne circule directement d'un émetteur à un destinataire — chaque transaction transite par une PA de chaque côté et, au minimum, par le PPF pour le reporting fiscal. Cette conception donne à la DGFiP une visibilité transactionnelle complète sans obliger émetteurs et destinataires à se connecter directement à un portail gouvernemental.

flowchart LR
    A["Émetteur\n(Issuer)"] -->|"Facture structurée\nUBL / CII / Factur-X"| B["PA Émetteur\n(Issuer's PA)"]
    B -->|"Facture validée\n+ événements de cycle de vie"| C["PPF\n(Portail Public de Facturation)"]
    C -->|"Conversion de format\nsi nécessaire"| D["PA Destinataire\n(Recipient's PA)"]
    D -->|"Facture délivrée\n+ mises à jour de statut"| E["Destinataire\n(Recipient)"]
    B -->|"Données e-reporting\n(B2C / transfrontalier)"| C
    D -->|"Callbacks de cycle de vie\n(Approuvée, Payée, etc.)"| C
    C -->|"Propagation des statuts"| B

Les cinq acteurs portent chacun des obligations distinctes :

Émetteur — l'entreprise française assujettie à la TVA qui génère la facture. Responsable du peuplement de tous les champs obligatoires. N'interagit pas directement avec le PPF.

PA Émetteur — valide la facture contre la spécification de 393 champs et les règles schematron avant le routage en aval. Transmet les mises à jour de statut de cycle de vie au PPF. Flowie opère dans ce rôle pour ses clients émetteurs.

PPF (Portail Public de Facturation) — le hub central opéré par l'État, géré par la DGFiP. Reçoit toutes les factures pour la visibilité fiscale, exécute le routage de format et propage les statuts de cycle de vie. Le PPF est gratuit mais offre un périmètre fonctionnel minimal au-delà de la transmission de base.

PA Destinataire — reçoit la facture du PPF (ou directement de la PA de l'émetteur dans les scénarios de connexion directe), la livre au destinataire et relaie les mises à jour de statut de cycle de vie en retour. Flowie opère dans ce rôle pour ses clients destinataires.

Destinataire — l'entreprise française assujettie à la TVA qui reçoit la facture. Responsable de la mise à jour des statuts de cycle de vie (Approuvée, Refusée, En cours de paiement, Payée) dans les délais fixés par la DGFiP.

La conversion de format est un service matériel que les PA doivent fournir. Un émetteur peut soumettre en Factur-X alors que la PA du destinataire ne supporte que l'UBL. Le PPF effectue un certain pontage de format, mais les PA sont tenues de gérer la conversion à l'intérieur de leurs propres chaînes de traitement pour garantir la livraison dans un format que le destinataire peut consommer. Ce n'est pas un prérequis d'ingénierie trivial : les trois formats partagent un modèle sémantique commun (EN 16931 / XP Z12-014) mais diffèrent substantiellement en encodage.

Les 393 champs obligatoires et 1 841 règles de validation — ce qui est réellement contrôlé

Les « Spécifications Externes B2B » de la DGFiP définissent 393 champs de données obligatoires dans le modèle de données de la facture. Ces champs couvrent :

• Champs d'identification : numéro de facture, date d'émission, code de type de document (BT-3), code devise
• Données vendeur et acheteur : identifiants légaux (SIRET, numéro de TVA, raison sociale, adresse)
• Données de ligne : description, quantité, prix unitaire, montant ligne, classification TVA par ligne
• Récapitulatif fiscal (BG-23) : base imposable, taux de TVA, montant de TVA par catégorie de TVA
• Conditions de paiement : date d'échéance, code moyen de paiement (IBAN ou équivalent), conditions d'escompte
• Champs de cycle de vie : type de processus, identifiant de routage et codes de statut de cycle de vie (périmètre BT-23)

La spécification ne se contente pas de lister des champs — elle impose des valeurs de listes de codes pour beaucoup d'entre eux. Par exemple, BT-3 (code de type de facture) doit être conforme à la liste de codes UNTDID 1001. BT-8 (type de date de valeur) doit être conforme à UNTDID 2005. Les valeurs non conformes provoquent des échecs de validation bloquants qui empêchent le routage.

La validation est appliquée sur deux couches :

Validation de schéma XSD — bonne formation structurelle. Un document UBL qui viole le XSD UBL 2.1, ou un document CII qui viole le XSD UN/CEFACT, est rejeté à l'ingestion. Cela attrape les erreurs d'encodage, les déclarations de namespace manquantes et les valeurs de champs malformées.

Validation de règles métier Schematron — exactitude sémantique sur l'ensemble des quelque 1 841 règles. Ces règles incluent :

• Contrôles de cohérence inter-champs (par exemple, le montant de TVA d'une ligne doit être égal à quantité × prix unitaire × taux de TVA dans la tolérance d'arrondi)
• Contrôles d'appartenance aux listes de codes (les valeurs doivent exister dans les listes UNTDID référencées ou autres listes de codes enregistrées)
• Règles de champs conditionnels (par exemple, BT-134 et BT-135 pour la période de facturation doivent être présents tous les deux si l'un est présent)
• Extensions spécifiques françaises préfixées EXT-FR-FE, définies sous la norme AFNOR XP Z12-013

Les normes AFNOR directement pertinentes pour le mandat sont :

• XP Z12-013 — modèle d'échange sectoriel, définissant les extensions spécifiques françaises (champs EXT-FR-FE-*) superposées à EN 16931
• XP Z12-014 — modèle de données de facture cœur, aligné sur la norme européenne EN 16931
• XP Z12-015 — modèle CTC (Continuous Transaction Controls), régissant les obligations de cycle de vie et de reporting de statut

Un échec de validation sur l'une ou l'autre couche produit une réponse d'erreur structurée que la PA doit relayer à l'émetteur avec l'identifiant de règle spécifique. Cette exigence implique que les plateformes PA doivent maintenir un mapping lisible par machine entre identifiants de règles et descriptions d'erreurs actionnables — une tâche d'ingénierie de contenu non triviale, étant donné que le jeu de règles couvre plusieurs normes AFNOR et les extensions de spécification propres à la DGFiP.

UBL, CII et Factur-X — quand chaque format s'applique et comment

Le mandat reconnaît trois formats de facture. Tous trois portent le même contenu sémantique (les 393 champs mappés sur EN 16931), mais ils diffèrent en structure, encodage et adéquation opérationnelle.

Propriété	UBL 2.1	UN/CEFACT CII	Factur-X
Structure	XML uniquement	XML uniquement	Hybride : PDF/A-3 embarquant du XML
Namespace racine	urn:oasis:names:specification:ubl:schema:xsd:Invoice-2	urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100	Variable selon le profil (le XML Factur-X est dérivé du CII)
Couche PDF lisible par humain	Non	Non	Oui — le PDF/A-3 porte la pièce jointe XML
Cas d'usage principal	Pipelines AP/AR automatisés à grande échelle ; écosystème Peppol	ERPs nativement CII ; convertisseurs depuis flux EDIFACT historiques	Environnements mixtes : traitement automatisé ET archivage lisible par humain
Détection de format	Namespace de l'élément racine, pas le nom de fichier ou le type MIME	Namespace de l'élément racine	Conteneur PDF/A-3 avec pièce jointe AFRelationship=Alternative nommée factur-x.xml
Quand le préférer	Pipelines AP/AR automatisés à grande échelle ; Peppol transfrontalier	Sortie native SAP SD/MM ; toolchains UN/CEFACT existantes	PME ; contextes nécessitant une facture lisible par humain en parallèle des données machine

Factur-X est le format le plus fréquemment demandé en pratique, parce qu'il permet à une entreprise de satisfaire à la fois son obligation d'archivage de la facture lisible par humain et son obligation sur les données structurées avec un seul fichier. Cependant, Factur-X introduit deux risques opérationnels que les PA doivent gérer : (1) les couches PDF et XML peuvent diverger si elles sont générées par des systèmes différents — la couche XML fait juridiquement foi, mais la divergence crée des problèmes de réconciliation ; et (2) certains générateurs PDF produisent des conteneurs PDF/A-3 qui échouent à la validation stricte alors même que le XML embarqué est correct.

Les PA ne sont pas autorisées à rejeter une facture au seul motif que l'émetteur a choisi un format différent de celui que le destinataire préfère. La conversion de format est une obligation de routage, pas un motif de rejet.

Pour les transactions transfrontalières de l'UE, le réseau Peppol utilise UBL 2.1 comme format principal. Le profil PEPPOL BIS Billing 3.0 est basé sur UBL. Les entreprises françaises avec un volume transfrontalier significatif devraient confirmer auprès de leur PA que l'UBL est nativement supporté — la conversion de Factur-X CII vers UBL est une transformation non triviale étant donné les différences de namespace et de listes de codes.

Pour une vue plus large des obligations de conformité au niveau UE, y compris la trajectoire de la directive ViDA vers le CTC obligatoire dans tous les États membres, consultez le guide tracker de conformité ViDA de ce hub.

Statuts de cycle de vie et obligation d'e-reporting

Cycle de vie des factures

Le mandat français définit un cycle de vie obligatoire pour chaque facture structurée. Les statuts de cycle de vie sont communiqués entre la PA de l'émetteur, le PPF et la PA du destinataire. La DGFiP exige que les mises à jour de statut se propagent dans des fenêtres de temps définies.

Les états principaux du cycle de vie, mappés au périmètre conceptuel BT-23, sont :

• Déposée — facture reçue par la PA de l'émetteur et transmise au PPF
• Refusée — le destinataire refuse explicitement la facture (refus métier, pas rejet technique) ; l'émetteur doit émettre un avoir ou une facture corrigée
• Approuvée — le destinataire reconnaît la facture comme commercialement acceptée
• En cours de paiement — le processus de paiement a été initié
• Payée — paiement confirmé

Des statuts supplémentaires couvrent les états d'erreur technique (rejetée par la PA de l'émetteur avant soumission, rejetée par la couche de validation du PPF) et les états spécifiques au routage (en transit, livrée à la PA du destinataire).

L'obligation de statut est bilatérale. Le destinataire est tenu de mettre à jour le statut — Approuvée, Refusée ou En cours de paiement — dans le délai fixé par la DGFiP. Cela introduit un changement opérationnel pour de nombreuses équipes AP françaises habituées à des workflows d'approbation de factures entièrement internes. Sous le mandat, un sous-ensemble de ces transitions de statut doit être communiqué à l'extérieur via la chaîne PA.

Obligation d'e-reporting

L'e-reporting est une obligation séparée mais parallèle de l'e-invoicing. Elle couvre :

• Transactions B2C — factures émises à des consommateurs français (non soumises à l'obligation de routage PA mais soumises au reporting transactionnel)
• Transactions B2B transfrontalières — factures entre une entreprise française assujettie à la TVA et une contrepartie non française

Pour l'e-reporting, la PA ne route pas une facture structurée vers la PA d'un destinataire. À la place, elle transmet un récapitulatif de données de transaction (les « données de transaction ») au PPF à intervalles définis. Les éléments de données requis pour l'e-reporting sont un sous-ensemble des 393 champs obligatoires — spécifiquement les identifiants fiscaux, les montants, les ventilations TVA et les dates de transaction.

L'e-reporting s'applique aux ventes (sortantes) comme aux achats (entrants depuis des fournisseurs non français). Les entreprises avec un revenu B2C significatif ou un volume d'achat international doivent s'assurer que leur PA gère l'e-reporting parallèlement au flux de routage PA standard. Ce sont des canaux de soumission au PPF architecturalement distincts.

PPF (plateforme de l'État) face à PA (plateformes privées) — choisir la bonne

Le PPF est opéré par la DGFiP et est disponible gratuitement à toutes les entreprises françaises assujetties à la TVA. Il supporte le minimum obligatoire : soumission de facture structurée, routage de base et enregistrement des statuts de cycle de vie. Il ne fournit pas de connecteurs ERP, d'automatisation de workflow, d'outillage d'onboarding fournisseurs ou d'orchestration des achats.

Dimension	PPF (plateforme État)	PA (plateforme privée certifiée)
Coût	Gratuit	Abonnement ou tarification à la transaction
Support des formats	UBL 2.1, CII, Factur-X	UBL 2.1, CII, Factur-X (obligatoires) ; connecteurs ERP-spécifiques variables selon l'éditeur
Support du cycle de vie	Statuts obligatoires uniquement	Cycle de vie complet + intégration workflow avec ERP et systèmes AP/AR
Connectivité ERP	API uniquement ; pas de connecteurs préconstruits	Connecteurs préconstruits pour les principaux ERP (SAP, Oracle, Microsoft, etc.)
UX / portail	Portail DGFiP basique	Dépendant de l'éditeur ; va du minimal aux dashboards AP/AR complets
Archivage	La DGFiP stocke les copies fiscales	Dépendant de l'éditeur ; inclut typiquement l'archivage long terme selon la loi française (10 ans)
E-reporting	Soumission directe via API PPF	Géré par la PA pour le compte du client
Recommandé pour	Très petites entreprises avec un volume de factures minimal et aucun besoin d'intégration ERP	Toutes les entreprises avec systèmes ERP, structures multi-entités ou volume de factures transfrontalier

Le PPF ne doit pas être écarté — c'est la garantie de l'État que toute entreprise française dispose d'un parcours conforme, quelle que soit sa taille. Mais pour toute entreprise faisant transiter ses factures par un ERP, l'absence de connecteurs natifs au PPF impose des workflows d'upload manuel, qui introduisent des erreurs de réconciliation et ne tiennent pas la charge au-delà de faibles volumes de factures.

La décision d'architecture clé pour un CFO ou un IT Architect évaluant les options PA est : la logique de validation et de routage de la plateforme s'intercale-t-elle entre l'ERP et le PPF (le modèle PA), ou bien l'ERP exporte-t-il un fichier qui est uploadé manuellement vers le PPF ? Le second cas crée un trou de conformité : les données de facture de l'ERP et l'enregistrement fiscal du PPF peuvent diverger sans réconciliation automatisée.

Pour les entreprises gérant plusieurs environnements ERP — par exemple, une instance SAP pour une filiale aux côtés d'une instance Oracle Fusion pour une autre — une PA qui abstrait les différences de format et consolide le statut de cycle de vie dans une surface de workflow unique est structurellement nécessaire. Le guide multi-ERP orchestration vs replacement de ce hub couvre cette décision architecturale en détail.

Calendrier de certification, prérequis techniques et obligations continues

Le processus de certification DGFiP

La certification PA (« immatriculation technique ») est initiée en soumettant une candidature à la DGFiP. La DGFiP ne publie pas de calendrier fixe de créneaux d'audit ; le processus est tiré par la demande et les délais ont varié. La phase de test formelle de la DGFiP a duré environ trois mois pour la cohorte ayant débuté le 14 octobre 2025, avec des fenêtres d'intégration rapportées par les plateformes agréées dans la fourchette de quatre à six semaines. Les délais bout-en-bout de la candidature initiale à la délivrance de la certification s'estiment au mieux à plusieurs mois et devraient être vérifiés contre la capacité courante de la DGFiP.

L'audit technique couvre cinq domaines :

1. Conformité à la spécification — démonstration que la plateforme implémente correctement les 393 champs obligatoires et passe la suite de règles schematron
2. Tests d'interopérabilité — tests d'échange API en direct avec l'environnement de test du PPF, couvrant les canaux de soumission et de callback de statut
3. Conversion de format — démonstration de conversion sans perte entre UBL, CII et Factur-X pour un ensemble défini de factures de test
4. Sécurité et résidence des données — revue de l'architecture d'hébergement, du chiffrement, des contrôles d'accès et de la documentation de conformité RGPD
5. Préparation opérationnelle — démonstration du monitoring, de la réponse aux incidents et des engagements SLA pour l'environnement de production

Prérequis techniques pour les plateformes PA

Au minimum, une PA doit implémenter :

• Une API d'ingestion de factures structurées acceptant les trois formats
• Validation XSD et schematron avant soumission au PPF
• Intégration de l'API de soumission PPF (validation synchrone et callback de statut asynchrone)
• Propagation bidirectionnelle des statuts de cycle de vie (côté émetteur et côté destinataire)
• Soumission d'e-reporting pour les transactions B2C et transfrontalières
• Archivage long terme (10 ans selon la loi comptable française) en format fiscalement recevable

Obligations continues

Une fois certifiée, une PA doit :

• Surveiller les mises à jour de spécification DGFiP et appliquer les changements de conformité dans les délais fixés par chaque notice de mise à jour
• Participer aux re-tests d'interopérabilité périodiques si la DGFiP publie une version de spécification qui modifie l'API du PPF ou le jeu de règles schematron
• Maintenir des journaux d'audit suffisants pour démontrer la conformité aux inspecteurs DGFiP
• Notifier la DGFiP des changements matériels apportés à l'architecture, à la localisation d'hébergement ou à la posture de sécurité de la plateforme

La certification n'est pas un jalon ponctuel. La spécification a été mise à jour à plusieurs reprises sur la période 2022–2026, et les opérateurs PA doivent maintenir un processus permanent pour suivre les sorties de spécification et évaluer leur impact sur le pipeline de validation de production.

Comment Flowie se conforme — architecture et choix d'implémentation

Enregistrement PA et infrastructure

Flowie est enregistrée auprès de la DGFiP en tant que Plateforme Agréée. L'infrastructure tourne sur des environnements cloud à Francfort et en Belgique (résidence UE), satisfaisant les exigences de résidence des données de la DGFiP et le périmètre de certification ISO 27001:2022 propre à Flowie. Des accords de traitement des données conformes au RGPD sont en place pour toutes les données de factures traitées via le canal PA.

Pipeline de validation

Le pipeline de validation de Flowie implémente une approche en deux étapes qui reflète la séquence de validation propre à la DGFiP :

Étape 1 — Validation structurelle : Les factures entrantes sont validées contre le XSD pertinent (XSD UBL 2.1, XSD UN/CEFACT CII ou XSD du XML embarqué Factur-X). Les erreurs structurelles sont retournées de manière synchrone avec le chemin de schéma précis qui a échoué.

Étape 2 — Validation des règles métier : Le moteur de règles schematron évalue toutes les règles applicables du jeu de règles cœur EN 16931, des extensions PEPPOL BIS le cas échéant, et des extensions spécifiques françaises EXT-FR-FE définies sous XP Z12-013. Les résultats de validation référencent l'identifiant de règle précis (par exemple, BR-CO-20, EXT-FR-FE-180) et incluent le chemin du champ et la valeur observée. Cette réponse d'erreur structurée permet aux connecteurs ERP de remonter aux opérateurs de factures un guide de correction actionnable, sans recherche manuelle de règle.

Le moteur de règles est mis à jour en phase avec les sorties de spécification DGFiP. Chaque mise à jour passe par une évaluation d'impact de changement contre le jeu de règles de production avant déploiement, pour éviter les régressions sur des formats de factures auparavant valides.

Gestion et conversion des formats

Flowie accepte les factures en UBL 2.1, CII et Factur-X à l'ingestion. Le traitement interne normalise tous les formats vers un modèle objet de facture canonique aligné sur XP Z12-014. La livraison sortante convertit depuis ce modèle canonique vers le format préféré ou requis par le destinataire. La détection de format utilise exclusivement le namespace de l'élément racine — pas le nom de fichier, le type MIME ou la déclaration de type de document — parce que le namespace est le seul discriminant fiable et autoritaire à travers les variations d'export ERP observées en production.

Pour Factur-X spécifiquement, l'extraction et la ré-incorporation de la couche XML depuis le conteneur PDF/A-3 sont gérées indépendamment du payload PDF. La couche XML est l'enregistrement faisant juridiquement foi ; la couche PDF est conservée pour archivage mais n'est pas utilisée pour les décisions de validation ou de routage.

Intégration du cycle de vie

Les statuts de cycle de vie circulent de manière bidirectionnelle à travers le bus d'événements de Flowie. Quand un destinataire met à jour un statut (Approuvée, Refusée, En cours de paiement), cet événement est :

1. Validé contre les transitions de statut autorisées pour l'état courant de la facture
2. Transmis au PPF dans la fenêtre requise
3. Repoussé vers le connecteur ERP de l'émetteur sous forme d'événement structuré

Cela signifie que l'ERP de l'émetteur reçoit les mises à jour de statut de paiement par le même canal qu'il utilise pour soumettre les factures — aucun login portail séparé n'est requis pour suivre l'acceptation des factures. Pour les organisations multi-entités gérant des dizaines de filiales sur différents ERPs, cette surface de statut consolidée représente une différence opérationnelle matérielle par rapport au modèle basique du PPF.

Knowledge graph Astral et résolution fournisseurs

Le knowledge graph Astral de Flowie joue un rôle spécifique dans la couche de routage PA. Quand une facture arrive et que le routage de la PA destinataire doit être déterminé, Astral résout le SIRET du destinataire contre son registre des PA enregistrées, l'annuaire de routage du PPF et le réseau fournisseurs propre à Flowie. Cette étape de résolution détermine si la facture doit être routée directement vers un compte PA Flowie d'une contrepartie, vers une PA enregistrée différente via le relais PPF, ou vers le PPF pour une livraison basique à une entreprise utilisant uniquement le portail de l'État.

Astral maintient également un enregistrement du format préféré de chaque fournisseur, qui pilote la décision de conversion de format sortant à l'étape PA Destinataire. Pour les grandes organisations achats avec des centaines de fournisseurs actifs, cette configuration au niveau fournisseur élimine le besoin de spécifier manuellement les préférences de format par lot de factures.

E-reporting

Flowie traite l'e-reporting comme un canal latéral automatisé dans le même pipeline de traitement des factures. Les données de transactions B2C et les données de transactions B2B transfrontalières sont identifiées à l'ingestion sur la base du numéro de TVA et du code pays de l'acheteur, extraites dans le format de payload e-reporting et soumises au PPF pour le compte du client à la cadence de reporting requise. Cela est transparent pour l'ERP du client — l'ERP soumet toutes les factures par un endpoint Flowie unique, et Flowie les route vers le bon canal en aval (relais PA ou e-reporting) en fonction du type de transaction.

Environnements multi-ERP

Beaucoup de clients de Flowie opèrent sur plusieurs instances ERP — un pattern courant chez les groupes industriels avec des filiales acquises faisant tourner SAP, Oracle ou des ERPs mid-market côte à côte. Le Workflow Builder de Flowie fournit une couche d'orchestration no-code qui permet aux équipes finance opérations de configurer par entité les règles de validation de factures, le routage de cycle de vie et la réécriture vers l'ERP, sans code d'intégration custom pour chaque instance ERP. La couche de validation et de routage PA siège sous Workflow Builder, de sorte que les obligations de conformité sont satisfaites uniformément quel que soit l'ERP qui a soumis la facture. Pour le détail du fonctionnement de cette couche d'orchestration en contextes multi-ERP, consultez multi-ERP orchestration vs replacement.

Pour explorer les capacités produit France-spécifiques de Flowie en e-invoicing, visitez la page produit e-invoicing France. Pour les patterns d'intégration entre systèmes ERP, voir la page intégrations. Pour discuter d'un scénario de déploiement spécifique, contactez l'équipe Flowie.

FAQ

À quelle date le mandat e-invoicing France s'applique-t-il à mon entreprise ?

L'obligation de réception débute le 1er septembre 2026 pour toutes les entreprises françaises assujetties à la TVA, quelle que soit leur taille. Cela signifie que vos systèmes comptables fournisseurs doivent être capables de recevoir et de traiter des factures structurées à partir de cette date. L'obligation d'émission — émettre des factures structurées — débute le 1er septembre 2026 pour les grandes entreprises et les ETI (entreprises de taille intermédiaire), et le 1er septembre 2027 pour les PME et micro-entreprises. Ces dates reflètent la dernière communication stable de la DGFiP au début 2026 et remplacent les dates antérieures reportées. Vérifiez contre les publications officielles de la DGFiP avant toute planification contractuelle.

Quelle est la différence entre le PPF et une PA ?

Le PPF (Portail Public de Facturation) est le hub central opéré par l'État et géré par la DGFiP. Il est gratuit, gère le routage basique des factures et le reporting fiscal, et constitue le point de relais obligatoire pour toutes les transactions. Une PA (Plateforme Agréée) est une plateforme privée certifiée qui se connecte au PPF pour le compte du client, et ajoute l'intégration ERP, la validation avancée, la conversion de format, le workflow de cycle de vie et l'automatisation de l'e-reporting. Chaque facture passe toujours par le PPF — une PA ne le contourne pas. Le PPF suffit pour une facturation à très faible volume et opérée manuellement ; une PA est opérationnellement nécessaire pour toute entreprise faisant transiter ses factures par un ERP.

Combien de champs obligatoires la spécification PA France impose-t-elle ?

Les « Spécifications Externes B2B » de la DGFiP définissent 393 champs de données obligatoires. Ils couvrent l'identification, les données des parties (vendeur et acheteur), les lignes, les récapitulatifs fiscaux (BG-23), les conditions de paiement et les codes de cycle de vie. La spécification inclut également environ 1 841 règles de validation — contrôles structurels XSD et contrôles de règles métier Schematron — qui doivent toutes passer pour qu'une facture soit acceptée par le PPF. Les échecs de validation référencent des identifiants de règles précis afin que les opérateurs ERP puissent identifier et corriger le problème de données.

Quel format de facture utiliser — UBL, CII ou Factur-X ?

Le mandat accepte les trois formats. Factur-X est le choix le plus courant pour les entreprises qui ont également besoin d'une archive PDF lisible par humain, puisqu'il embarque le XML structuré dans un conteneur PDF/A-3. UBL 2.1 est le format utilisé par le réseau Peppol et est préféré pour les transactions transfrontalières ou les entreprises déjà sur Peppol. CII est le format de sortie natif de certaines configurations SAP SD/MM. Tous trois portent les mêmes 393 champs de données sémantiquement ; le choix est piloté par la capacité d'export de l'ERP, la préférence du destinataire et les exigences d'archivage. Une PA certifiée doit supporter les trois formats et exécuter la conversion entre eux quand nécessaire.

L'e-invoicing couvre-t-il les transactions B2C ?

Non — l'obligation de routage PA couvre les transactions B2B domestiques entre entreprises françaises assujetties à la TVA. Les factures B2C (émises à des consommateurs français) et les factures B2B transfrontalières (avec des contreparties non françaises) sont couvertes par une obligation d'e-reporting séparée. L'e-reporting impose de soumettre des récapitulatifs de données de transaction au PPF — pas de router des factures structurées complètes via la chaîne PA. La distinction importe pour les entreprises avec des portefeuilles de factures mixtes : leur PA doit gérer à la fois le routage PA et l'e-reporting comme canaux de soumission parallèles.

Combien de temps prend la certification PA, et une entreprise non française peut-elle devenir PA ?

Le processus de certification DGFiP (« immatriculation technique ») prend typiquement quatre à six mois entre la candidature initiale et la délivrance de la certification, sur la base de l'expérience des plateformes ayant mené l'audit à son terme. Cette estimation reflète la capacité de la DGFiP au début 2026. Les entreprises non françaises peuvent candidater à la certification PA — les règles de la DGFiP ne réservent pas la certification aux entités domiciliées en France. En revanche, des exigences de résidence des données s'appliquent : les données de factures pour les transactions TVA françaises doivent être hébergées dans une juridiction satisfaisant aux exigences de la DGFiP, ce qui en pratique signifie une infrastructure résidente UE. Une PA non française certifiée doit également pouvoir interagir avec l'API du PPF en temps réel, ce qui a des implications pour la latence et l'architecture de connectivité.