Si vous êtes une entreprise française, il y a de fortes chances que vous analysiez depuis plusieurs années l’impact des nouvelles exigences en matière de facturation et de déclaration électroniques. Vous avez probablement dû réévaluer cet impact à plusieurs reprises, à mesure que les délais, le champ d’application et les cas d’utilisation documentés évoluaient.
La réforme française de la facturation et de la déclaration électroniques, qui entrera en vigueur en septembre 2026, introduit un modèle basé sur le CTC couvrant à la fois la facturation nationale et la déclaration de TVA au niveau des transactions.
Si votre entreprise n’a pas son siège social en France mais y exerce des activités, votre approche de préparation peut être différente, même si les obligations restent les mêmes.
Axway est officiellement accréditée en tant que Plateforme Agréée (PA) dans le cadre de la réglementation française obligatoire en matière de facturation électronique et de déclaration électronique. Cette accréditation confirme la conformité totale d’Axway aux exigences définies par l’administration fiscale française (DGFiP). En savoir plus sur la facturation électronique Axway.
Architecture et écosystème CTC
L’architecture française s’appuie sur une plateforme centralisée (PPF) qui relie les entreprises et les prestataires de services à l’administration de la TVA. Les échanges de factures s’effectuent via Peppol eDelivery, sauf accord contraire. Ces échanges doivent être délégués à des prestataires de services agréés (Plateformes Partenaires, ou PA) et doivent respecter les exigences françaises en matière de souveraineté des données, notamment SecNumCloud.
Le champ d’application couvre les transactions B2B nationales et intracommunautaires, B2G/G2B, ainsi que les transactions B2C et les déclarations supplémentaires.
- Les transactions TVA nationales entrent dans le champ de la facturation électronique.
- Les transactions intracommunautaires, ainsi que les paiements et les transactions non accompagnés de factures (tels que les transactions B2C ou celles effectuées via un portail), relèvent du champ d’application de la déclaration électronique. Les données de déclaration doivent être consolidées et transmises en temps réel.
- Le statut des transactions est suivi grâce à des messages de cycle de vie échangés entre plusieurs parties.
La France n’est pas le seul pays à associer une plateforme de déclaration centralisée à des prestataires de services dans un cadre interopérable. En quoi la réforme française est-elle plus complexe que de nombreuses autres obligations CTC ?
Champ d’application, exigences en matière de données et délais
Les principales sources de complexité résident dans l’étendue du champ d’application et le niveau de détail des informations qui doivent être échangées dans des délais très courts.
La France n’a pas attendu la révision de la norme EN-16931, ni la définition finale des exigences de déclaration numérique (DRR) de ViDA. Le modèle impose déjà :
- une distinction claire entre les services et les biens,
- la détermination de la date fiscale sur la base de la réception effective du paiement (pour les services),
- la définition et le partage des données de transaction avec des partenaires tiers tels que des prestataires d’affacturage, des centres de services partagés ou des agents.
Illustration : une entreprise de vente au détail avec des transactions mixtes B2B et B2C.
Prenons l’exemple d’une entreprise de vente au détail. Elle doit séparer les transactions B2B (soumises à la facturation électronique) des transactions B2C (déclarées via le e-reporting agrégé). De plus, lors de la vente de bons d’achat tels que des cartes-cadeaux ou des crédits prépayés, une distinction doit être faite entre les biens et les services. Lorsque l’acheteur représente une entité publique, la facture doit alors suivre le canal B2G.
Une carte-cadeau polyvalente verra sa TVA déterminée lors de son utilisation pour un achat effectif de biens ou de services, le moment d’imposition étant fixé à ce moment-là.
Même si cette entreprise de vente au détail opère sur le marché national, l’approvisionnement de ces biens est susceptible d’être international. Les acquisitions intracommunautaires doivent être déclarées, tandis que les factures d’achat peuvent encore être sur papier ou au format PDF, ce qui accroît la pression sur le processus de dématérialisation.
Si le traitement des factures est externalisé vers un centre de services, cela peut également soulever des questions liées aux exigences en matière de souveraineté des données.
Alignement sur les normes européennes
À mesure que les discussions européennes progressent, l’effort visant à aligner la conception française sur les nouvelles préférences de l’UE devient plus visible.
En voici quelques exemples :
- les débats en cours concernant la prise en charge du format hybride Factur-X,
- les cas d’utilisation spécifiques à la France qui nécessitent des extensions au-delà de la Norme Européenne actuelle,
- les questions en suspens quant à savoir si le DRR doit contenir uniquement des données de facturation ou être enrichi d’informations relatives à la TVA.
Avant 2030, la mise à jour de la norme EN-16931 devrait être mise en œuvre. En conséquence, une migration des spécifications sera nécessaire.
Implications pour les environnements d’entreprise
Pour les organisations disposant d’un portefeuille mixte d’applications de back-office — et en particulier celles qui prennent déjà en charge des implémentations CTC dans d’autres pays —, cela signifie qu’un simple exercice de mappage ne sera probablement pas suffisant.
Cela soulève la question de l’approche à adopter.
Sélection d’un prestataire de services accrédité (Plateforme Agréée – PA)
Les entreprises peuvent choisir de passer un contrat directement avec une Plateforme Agréée (PA) locale accréditée. Pour faciliter cela, la France a défini une API standard pour l’intégration des systèmes de back-office avec les PA. Cette API reflète la complexité des exigences et est spécifique au contexte français.
Les entreprises peuvent également préférer continuer à travailler avec leur prestataire de services actuel. Si ce prestataire n’est pas accrédité, la sous-traitance à un PA constitue une solution envisageable. Dans ce cas, l’intégration entre prestataires de services peut s’appuyer sur la norme d’interopérabilité Peppol Service Provider-to-Service Provider (SP2SP), telle que promue par l’association GENA.
Orchestration des transactions
Une autre considération clé est la part de logique ERP ou financière qu’une entreprise souhaite déléguer à son prestataire de services.
Les événements du cycle de vie sont générés par la collaboration entre le fournisseur, la PA du fournisseur, l’acheteur, la PA de l’acheteur et, éventuellement, des partenaires externes tels que des prestataires d’affacturage. Parallèlement, les relations entre les transactions liées — telles que les prépaiements, les factures, les notes de crédit et les rapports — doivent être préservées.
Cette complexité est influencée par la structure de l’environnement back-office : non seulement la séparation entre les flux P2P et O2C, mais aussi la répartition fonctionnelle entre les systèmes ERP, financiers, de paiement et de détermination de la TVA.
Illustration : une entreprise de logistique, avec une orchestration entre les systèmes
Prenons l’exemple d’une entreprise manufacturière disposant de plusieurs sites de production et d’un centre de services partagés gérant la facturation et les paiements. Les commandes client peuvent provenir d’un système ERP, les factures d’achat d’une plateforme financière centrale, le workflow d’approbation intégré à la solution de dématérialisation, et les paiements d’une solution de trésorerie ou bancaire distincte. Dans le cadre de la réforme française, ces éléments doivent être corrélés pour générer des événements de cycle de vie et des données de reporting cohérents.
Un défi similaire se pose pour les entreprises de logistique ou de distribution gérant les prépaiements, les livraisons partielles et les notes de crédit. Préserver la relation entre ces transactions liées est essentiel pour un reporting TVA précis et difficile à réaliser lorsque les responsabilités sont réparties entre plusieurs applications.
Lorsque les données sont réparties entre plusieurs applications, une solution middleware peut assumer le rôle d’orchestration et garantir que toutes les données requises sont systématiquement mises à la disposition du prestataire de services.
Minimiser les risques et assurer la continuité : la phase pilote
Certains aspects du modèle permettent des choix pragmatiques. Par exemple, le rapprochement des paiements est principalement requis pour déterminer la date d’exigibilité fiscale des services. Les entreprises peuvent choisir de ne pas mettre cela en œuvre dans un premier temps et d’appliquer à la place la date de facturation comme date d’exigibilité.
Les autorités fiscales françaises ont lancé une phase pilote, accordant aux entreprises six mois pour valider leurs environnements et leur conformité à l’aide de transactions réelles. Compte tenu des exigences réglementaires, la participation à ces pilotes doit être considérée comme une mesure pratique d’atténuation des risques plutôt que comme un coût supplémentaire.
Considération finale
La réforme française vise en fin de compte une déclaration de TVA à 100 %, mais cela ne doit pas constituer un obstacle à la mise en service. S’attaquer à chaque exception dès le départ retarde souvent la stabilisation sans améliorer sensiblement la conformité. Une mise en service pragmatique consiste à sécuriser d’abord les flux de transactions standard à haut volume, tout en traitant progressivement les exceptions restantes après la mise en service et en s’alignant sur les autres déploiements de ViDa.
Axway est officiellement accréditée en tant que Plateforme Agréée (PA) et peut vous aider en France, en Europe ou à l’échelle mondiale.