Facture électronique

Format FRR : produire l'e-reporting (flux 10) depuis son ERP

Un ERP peut construire lui-même le fichier d'e-reporting et le déposer auprès d'une Plateforme Agréée en syntaxe « FRR ». Il ne peut jamais le transmettre à l'administration : seule la plateforme le fait.

Page de référence Cette page approfondit un point précis de la réforme. Le parcours complet, avec vos dates selon votre taille et votre plan d'action, est dans le guide de la facture électronique.

L'essentiel en 5 points

FRR veut dire « FRench Reporting ». C'est une valeur de syntaxe de la norme AFNOR XP Z12-013, pas une notion juridique.
Le contenu est le flux 10 des spécifications AIFE : un XML propre à l'administration, ni UBL ni CII.
L'ERP produit et dépose, la PA transmet. Aucun logiciel n'est raccordé directement à l'administration.
La responsabilité ne se délègue pas. Que la PA construise le fichier ou non, les données restent les vôtres.
L'acceptation d'un FRR construit chez vous se négocie : faites-la écrire au contrat, versions comprises.

Ce que désigne FRR

FRR est un terme d'intégration. Dans XP Z12-013 (mai 2025), l'API entre le système d'information et la plateforme accepte un dépôt d'e-reporting en syntaxe FRR, et son cycle de vie en syntaxe CDAR. Les textes officiels, eux, parlent de flux 10.

Terme	Origine	Ce qu'il désigne
Flux 10	Spécifications AIFE	Le message d'e-reporting (transactions et paiements) que la PA transmet à l'administration.
FRR	AFNOR XP Z12-013	La syntaxe qui identifie un fichier d'e-reporting déposé auprès de la PA par l'API standard.
CDAR	XP Z12-012 et Z12-013	Les statuts de cycle de vie, y compris ceux d'un e-reporting. Voir le format CDAR.
Flux 8 et 9	Spécifications et XP Z12-013	Des factures internationales (8) ou B2C (9) au format du socle, que la PA convertit elle-même en flux 10.

Certaines plateformes emploient d'autres libellés (EReporting, EReportingB2C), ce que la norme autorise. Faites confirmer la valeur exacte avant de développer. Et méfiance envers une « certification XP Z12-013 » : une norme expérimentale ne se certifie pas.

Ce que contient le fichier

Le flux 10 est décrit par les annexes 6 (format) et 7 (règles de gestion) des spécifications externes v3.2 du 30 avril 2026, livrées avec leurs XSD. Il n'existe pas de CSV réglementaire : un export interne doit être transformé en XML avant dépôt.

Bloc	Contenu	Maille
10.1	Factures d'opérations internationales entre entreprises	Une occurrence par facture
10.2	Paiements de ces factures (prestations de services)	Une occurrence par encaissement
10.3	Opérations avec des non-assujettis, facturées ou non	Par jour, devise et catégorie
10.4	Encaissements de ces opérations	Par jour et par taux

L'en-tête de transmission porte notamment :

le type de transmission (TT-4) : IN initiale, ou RE rectificative, qui annule et remplace la période ;
l'identifiant de la plateforme émettrice (TT-8) : un fichier construit par l'ERP porte déjà la PA qui le transmettra, l'ERP se paramètre donc par plateforme ;
le SIREN du déclarant (TT-13) et son rôle, vendeur ou acheteur (TT-15) ;
la période des transactions (TT-17 et suivant) et celle des paiements (TT-89 et suivant), qui peuvent différer.

Qui déclare quels blocs, et à quel rythme selon le régime de TVA : suis-je concerné par l'e-reporting.

Qui produit, qui transmet

Acteur	Rôle dans l'e-reporting
ERP, caisse, middleware	Prépare le fichier et le dépose auprès d'une ou plusieurs PA. Ne transmet rien à l'administration.
Plateforme Agréée	Contrôle le fichier, le transmet, restitue les statuts. Seul maillon habilité.
Solution de l'administration (ex-PPF)	Reçoit et contrôle les flux 10, agrège ceux d'une entreprise qui utilise plusieurs PA.

La DGFiP prévoit expressément un fichier « issu d'une solution compatible », et la FNFE-MPE admet un e-reporting créé dans le système de gestion de l'entreprise. L'entreprise et la plateforme sont sanctionnées séparément : sous-traiter le fichier ne transfère pas la responsabilité. Le barème : sanctions et amendes.

Quatre modèles d'architecture

Modèle	Atout	Limite	Pour qui
ERP natif	Maîtrise totale, rapprochement direct avec la CA3, changement de PA simple	Mapping à maintenir à chaque version des spécifications	ERP unique au modèle fiscal riche
Module de l'éditeur	Mises à jour déléguées	Calendrier de l'éditeur ; couverture des paiements à vérifier	Client d'un ERP du marché
Middleware	Un seul mapping pour plusieurs ERP et caisses, suivi centralisé	Une brique critique de plus	Groupe multi-ERP, multi-caisses
PA productrice	Peu d'effort interne	Logique fiscale chez la PA, souvent facturée au flux	TPE, PME, B2C très agrégé

Le bon choix se fait par bloc, pas globalement. Les blocs 10.1 et 10.2, facture par facture, gagnent à être construits là où vivent les données d'audit. Le 10.4 et le B2C de caisse peuvent partir chez la PA ou le logiciel de caisse.

Contrôler avant de déposer

Trois étages : validation XSD, règles de gestion de l'annexe 7, contrôles fiscaux internes (base × taux = TVA, bornes de période).
Le XSD ne suffit pas. Il contrôle peu (dates en texte libre, codes sans liste fermée) et il n'existe aucun Schematron officiel du flux 10 : un fichier valide peut être rejeté plus loin.
Un seul e-reporting par période, par SIREN et par PA. Si l'ERP construit le fichier, cette contrainte est à votre charge.
Une correction se fait en rectificative (RE), qui remplace toute la période.

Pour tester un mapping : le générateur d'e-reporting produit un flux 10 validé contre les XSD officiels, avec les règles de gestion contrôlées en français.

Ce que font les éditeurs

D'après leur documentation publique en septembre 2026. Ces fonctions évoluent vite, et certaines sont en bêta.

Solution	Qui construit le flux 10	Constat
Microsoft Dynamics 365 Finance	L'ERP	Fonction « France e-reporting » depuis la 10.0.49, décades et rectificatives comprises, envoi via une PA
SAP (DRC)	L'éditeur, aussi PA	DRC génère les e-reports
Oracle Fusion Cloud ERP	Plutôt la PA	Factures UBL et statuts CDAR ; pas de flux 10 natif documenté
Odoo	L'éditeur, aussi PA	Menu e-reporting et module de caisse pour le ticket Z
Axelor	L'ERP, prévu	Le type FRR est modélisé, l'envoi d'e-reporting encore en développement en 8.10
Sage, Cegid	L'éditeur, aussi PA	PA intégrée ; sérialisation FRR par l'ERP non documentée publiquement
B2Brouter	Au choix	Agrégation automatique, ou import d'un flux 10 construit ailleurs (API en bêta)
Iopole	La PA	Flux unitaires côté éditeur, agrégation et conformité côté PA

« Prêt pour la facture électronique » ne veut pas dire « produit le FRR ». Et quand l'éditeur de l'ERP est aussi la PA, on dépend d'un seul fournisseur pour les deux maillons. L'indépendance suppose un flux 10 produit dans une couche que vous maîtrisez, et déposable auprès d'au moins deux PA.

Ce qu'il faut exiger de sa plateforme

Quatre questions à poser à tout fournisseur, ERP comme PA :

Générez-vous le flux 10, ou seulement des factures et des statuts que la PA agrège ?
Quelle version de XP Z12-013, des XSD et de l'annexe 6 supportez-vous ?
Couvrez-vous les transactions ET les paiements, blocs 10.1 à 10.4 ?
Qui sérialise réellement le message déposé auprès de la PA ?

Puis, au contrat avec la PA :

l'acceptation d'un dépôt FRR déjà construit, et la valeur de syntaxe attendue ;
les versions supportées et le délai de mise à jour après une nouvelle publication de l'AIFE ;
la restitution des rejets et des statuts de cycle de vie, en clair ;
la concaténation de plusieurs fichiers par période et par SIREN ;
les engagements de service, la conservation des preuves et la portabilité en sortie ;
le partage des responsabilités entre donnée erronée et défaut de transmission.

Ces clauses complètent les 8 critères de choix d'une Plateforme Agréée.

Checklist technique ERP

Qualifier chaque opération : B2B domestique, B2C, international, public, hors champ. La présence d'une facture ne dit pas le flux.
Versionner le référentiel : spécifications, XSD, annexe 7 et XP Z12-013 en configuration.
Modéliser les données hors du XML : déclarant, période, catégorie, référence de facture, ventilation de TVA.
Collecter les encaissements réels, règlements partiels, multi-factures et avoirs compris.
Paramétrer par PA l'identifiant émetteur (TT-8) et la périodicité selon le régime de TVA.
Implémenter le client API XP Z12-013 : OAuth2, dépôt, reprise sur erreur, suivi des statuts.
Rendre les dépôts traçables : fichier envoyé, version du mapping, PA cible, réponse, nouvelle soumission.
Réconcilier : opérations de l'ERP, fichiers générés, accusés de la PA, TVA comptabilisée et CA3.
Tester les cas limites : paiement partiel, plusieurs taux, avoir, devise, période sans opération, changement de PA.

Sources

Dossier de spécifications externes de la facturation électronique, AIFE / DGFiP, version 3.2 du 30 avril 2026 (annexes 6 et 7, XSD du flux 10), publié sur impots.gouv.fr.
Norme AFNOR XP Z12-013, version de mai 2025 (API entre système d'information et Plateforme Agréée).
DGFiP, fiche 7 « Transmission des données de transaction » ; FNFE-MPE, check-list de démarrage, juillet 2026.
Documentation publique de Microsoft, SAP, Oracle, Odoo, Axelor, Sage, B2Brouter et Iopole, consultée en septembre 2026.

Page à jour au 27 septembre 2026. Le caractère obligatoire du dépôt FRR repose sur la version de mai 2025 de XP Z12-013 ; sa reprise dans les révisions de 2026 reste à confirmer.

Citer cette page

Format FRR : produire l'e-reporting depuis son ERP, https://www.cabinetdigital.fr/facture-electronique/format-frr-e-reporting/

Questions fréquentes

Que signifie FRR en e-reporting ?

FRR signifie « FRench Reporting ». C'est la valeur de syntaxe que la norme AFNOR XP Z12-013 attribue à un fichier d'e-reporting déposé auprès d'une Plateforme Agréée par son API standard, à côté de CII, UBL, Factur-X et CDAR. Le terme n'apparaît ni dans la loi ni dans le décret : les textes officiels parlent de flux 10.

Le FRR est-il un format différent du flux 10 ?

Non. Le contenu d'un dépôt FRR est le flux 10 des spécifications externes de l'AIFE : un XML propre à l'administration, décrit par l'annexe 6 et contrôlé par des XSD. FRR est l'étiquette posée sur le dépôt, flux 10 est le message. Ce n'est ni de l'UBL ni du CII.

Mon ERP peut-il transmettre l'e-reporting directement à l'administration ?

Non. Seule une Plateforme Agréée est raccordée à la solution de l'administration. Un ERP, un logiciel de caisse ou un middleware peut préparer le fichier et le déposer auprès d'une PA, qui le contrôle puis le transmet. Une offre qui promet un envoi direct au portail public se trompe.

Une Plateforme Agréée est-elle obligée d'accepter un fichier FRR construit par mon ERP ?

Le dépôt d'un e-reporting en syntaxe FRR figure parmi les routes obligatoires de la version de mai 2025 de XP Z12-013. Sa reprise dans les révisions de 2026 reste à confirmer, et une PA peut attendre un libellé de syntaxe différent. Faites-le écrire dans le contrat, avec les versions supportées.

La Plateforme Agréée doit-elle construire l'e-reporting à ma place ?

Non. Construire le flux 10 à partir de vos factures ou de données brutes est un service que la PA peut proposer, souvent facturé, pas une obligation. Et quel que soit celui qui construit le fichier, les données restent sous votre responsabilité.

Faut-il signer électroniquement le fichier FRR ?

Aucune obligation générale de signer chaque fichier n'apparaît dans les textes. La sécurité porte sur le transport : la norme impose aux PA d'accepter une authentification OAuth2, et la PA garantit l'intégrité des données qu'elle transmet.

Peut-on déposer l'e-reporting en CSV ?

Pas auprès de l'administration : le seul format réglementaire est le XML du flux 10. Un CSV peut servir d'export interne ou d'import dans un outil, qui le transforme ensuite en XML. Certaines PA acceptent leur propre format d'import, à négocier au cas par cas.

Pour aller plus loin : e-invoicing ou e-reporting, le générateur d'e-reporting et le guide complet de la facture électronique.