Introduction et concepts

Le sous-module E-Invoicing permet l'interconnexion d'Axelor Open Suite (AOS) avec une Plateforme Agréée (PA, anciennement appelée PDP - Plateforme de Dématérialisation Partenaire) dans le cadre de la facturation électronique inter-entreprises.

Cette documentation a été rédigée à partir de la version 8.10 du module Dématérialisation, dans lequel le sous-module E-Invoicing a été introduit. Elle est compatible avec AOS 8.5 et versions ultérieures.

Historique des versions du sous-module E-Invoicing

Version	Commentaire
8.10	Introduction du sous-module E-Invoicing : interconnexion avec une PA, gestion de l'annuaire et des adresses électroniques, émission et réception de factures, traitements automatisés.

Compatibilité AOS

Le sous-module E-Invoicing a été ajouté au module Dématérialisation à partir de la version 8.10.

Version module dématérialisation	De AOS	À AOS
8.10	AOS - 8.5	AOS - 8.5

Présentation Générale

E-Invoicing est un sous-module du module Dématérialisation d'Axelor, conçu pour assurer la communication entre Axelor Open Suite (AOS) et une Plateforme Agréée (PA) dans le cadre de la facturation électronique inter-entreprises. Il prend en charge la recherche et la gestion des adresses électroniques des tiers en interrogeant l'annuaire de la facturation électronique, la soumission des factures émises vers le destinataire via la PA, la récupération des factures reçues, ainsi que le suivi du cycle de vie de chaque flux échangé.

Ce sous-module s'inscrit dans la suite des composants de dématérialisation d'AOS et s'appuie sur deux d'entre eux :

• Axelor File Generator pour la génération des fichiers de factures sortants au format Factur-X, UBL ou CII ;
• Axelor Data Capture pour le traitement et l'intégration des factures entrantes dans l'ERP.

Contexte

La réforme française de la facturation électronique impose progressivement la dématérialisation des échanges de factures inter-entreprises (B2B). À partir de septembre 2026, les grandes et moyennes entreprises devront émettre et recevoir leurs factures au format électronique. Cette obligation sera étendue aux petites entreprises en septembre 2027 pour l'émission des factures, tandis que la réception électronique deviendra obligatoire pour toutes les entreprises dès septembre 2026. Dans ce cadre, les entreprises ne s'échangent plus directement leurs factures : elles passent par des Plateformes Agréées (PA) immatriculées par l'administration fiscale française, qui assurent la transmission, la conservation et la traçabilité des flux.

Pour garantir l'interopérabilité entre les PA — c'est-à-dire la capacité pour une entreprise utilisant la PA A d'envoyer une facture à une entreprise utilisant la PA B —, la spécification AFNOR XP Z12-013 définit les API standardisées que les PA doivent exposer.

Le sous-module E-Invoicing implémente la partie cliente de cette spécification : il consomme les API d'une PA au nom de l'entreprise utilisatrice d'AOS afin de réaliser les opérations d'annuaire, d'émission et de réception de factures.

À la date de rédaction de cette documentation, le sous-module est aligné sur la version 1.2 de la norme AFNOR XP Z12-013 (publiée en février 2026), qui constitue la version la plus récente de la spécification.

Architecture

Architecture du sous-module E-Invoicing : positionnement entre AOS, File Generator, Data Capture et la Plateforme Agréée.

Le sous-module E-Invoicing se positionne comme le point de contact entre AOS et la PA. Il orchestre les échanges sans se substituer aux modules chargés des formats : la génération des fichiers de factures sortants reste assurée par Axelor File Generator (au format Factur-X, UBL ou CII), et l'intégration des factures entrantes dans AOS reste assurée par Axelor Data Capture. E-Invoicing apporte au-dessus de ces deux modules la couche d'interconnexion avec la PA (authentification, routage, soumission, suivi des statuts, gestion de l'annuaire).

Cycle de fonctionnement

Le sous-module E-Invoicing met en œuvre les API standardisées définies par la norme AFNOR XP Z12-013 (version 1.2, février 2026), qui régit les échanges entre les systèmes d'information des entreprises et les Plateformes Agréées. La présente sous-section détaille le cycle fonctionnel tel que prescrit par la norme.

Outre la PA, deux autres acteurs interviennent dans le cycle :

• Le PPF (Portail Public de Facturation), administré par la DGFiP, qui concentre les données de cycle de vie et reçoit une copie des flux à des fins de suivi par l'administration fiscale.
• Le Client API : le système d'information de l'entreprise (par exemple AOS) ou sa Solution Compatible (SC), qui consomme les API publiées par la PA.

Vue d'ensemble du cycle de vie d'une facture

Vue d'ensemble du cycle de vie d'une facture électronique : phases de transmission et de traitement entre le vendeur, les PA et l'acheteur.

Le cycle de vie d'une facture électronique se décompose en deux grandes phases :

• Phase de transmission — la facture est acheminée depuis le système du vendeur vers celui de l'acheteur via la Plateforme Agréée du vendeur (PAe), puis celle de l'acheteur (PAr).
• Phase de traitement — l'acheteur, ou son système d'information, renvoie ensuite différents statuts de suivi (prise en charge, approbation, refus, etc.), transmis jusqu'à la PAe et à l'administration fiscale.

À chaque étape de ces échanges, des comptes-rendus normalisés (CDAR) sont générés par les PA ou les SC afin de tracer et confirmer les changements de statut de la facture.

Cycle d'émission détaillé

Le cycle d'émission décrit le parcours d'une facture émise par le vendeur jusqu'à sa mise à disposition de l'acheteur :

Vendeur → Client API du vendeur (par exemple AOS) → PAe → PAr → Client API de l'acheteur → Acheteur.

Parcours nominal :

1. Dépôt du flux par le Client API. Le Client API transmet la facture à la PAe, qui contient les métadonnées du flux et le fichier de la facture (Factur-X, UBL ou CII). La PAe attribue un identifiant unique au flux et positionne son statut technique à Pending (en attente de traitement). Cet identifiant est retourné en synchrone au Client API.

2. Contrôles techniques par la PAe. La PAe réalise sur le flux déposé les contrôles techniques : antivirus, validation du schéma XSD, contrôle du doublon technique, contrôle de la taille du fichier (la norme fixe une taille maximale de 100 Mo). Si tous les contrôles techniques réussissent, le statut passe à Ok et le flux entre en phase de contrôles fonctionnels.

3. Contrôles fonctionnels par la PAe. La PAe réalise ensuite les contrôles fonctionnels du flux : cohérence métier, validation Schematron, vérification du routage vers la PAr du destinataire. Si tous les contrôles réussissent, la PAe émet la facture vers la PAr et met à jour le statut du flux.

4. Transmissions. Lors de cette émission, la PAe transmet un flux CDAR et un flux 1 au PPF (la facture est mise à disposition de l'administration fiscale) ainsi qu'un flux 2 (facture) à la PAr du destinataire.

5. Réception par la PAr. La PAr réceptionne le flux et réalise à son tour ses propres contrôles. En cas de succès, elle en informe via un flux CDAR retransmis à la PAe et accessible au Client API du vendeur.

6. Mise à disposition de l'acheteur. La PAr met à jour le statut lorsqu'elle met la facture à disposition du Client API de l'acheteur. Ce statut marque la fin de la phase de transmission au sens de la norme.

7. Phase de traitement (côté acheteur). L'acheteur, via son Client API, peut alors produire des statuts de cycle de vie en retour pour informer le vendeur de l'avancée du traitement de la facture : Prise en charge (intégration dans le système de l'acheteur), Approuvée, En litige, Refusée, et autres. Chaque transition est matérialisée par un flux CDAR transmis à la PAr, puis retransmis à la PAe et au PPF.

Trois cas d'erreur sont prévus par la norme à différents points du parcours d'émission.

• Flux irrecevable (statut technique Error). Si un contrôle technique échoue dès le dépôt (étape 2), la PAe positionne flowAckStatus à Error et précise un code d'erreur normalisé. Le flux n'est pas accepté ; aucun CDAR n'est produit. Le Client API doit corriger l'erreur signalée et re-déposer le flux.

Code d'erreur	Signification
EmptyAttachment	Une ou plusieurs pièces jointes sont vides.
AttachmentTypeError	Type ou extension de pièce jointe non conforme.
EmptyFlow	Le flux est vide.
InvalidSchema	Schéma XML invalide.
FileSizeExceeded	Taille limite de fichier atteinte.
FlowTypeError	Type ou extension du flux non conformes.
AlreadyExistingFlow	Le flux a déjà été envoyé et réceptionné.
VirusFound	Contrôle antivirus en échec.
ChecksumMismatch	Empreinte numérique incohérente.
OtherTechnicalError	Autre problème technique.

• Rejet à l'émission (statut 213, phase de transmission). Si les contrôles fonctionnels échouent au niveau de la PAe (erreur Schematron, problème de routage, règle de gestion en erreur, …), la PAe produit un flux CDAR de statut 213 (Rejetée à l'émission), transmis au PPF. Le statut d'acquittement technique du flux facture reste Ok (le dépôt s'est techniquement bien déroulé), mais le cycle de vie fonctionnel s'arrête en rejet.

• Rejet à la réception (statut 213, phase de réception). Si la PAr rejette le flux à la suite de ses propres contrôles, elle produit un flux CDAR de statut 213 (Rejetée à la réception), retransmis à la PAe. Comme précédemment, le statut d'acquittement technique reste OK mais le cycle s'arrête en rejet côté réception.

Cycle de réception détaillé

Le cycle de réception décrit, du point de vue d'une entreprise destinataire de factures, comment celles-ci lui parviennent depuis le système du vendeur via les deux PA, et comment elle accuse leur traitement :

Vendeur (extérieur) → PAe (du vendeur) → PAr (de l'acheteur) → Client API de l'acheteur → Acheteur.

Parcours nominal :

1. Réception d'un flux entrant par la PAr. La PAr, après avoir reçu le Flux 2 (facture) transmis par la PAe, met le flux à disposition du Client API de l'entreprise destinataire.

2. Notification au Client API. Selon la configuration, la notification peut prendre deux formes :

   • Interrogation périodique (polling) : le Client API interroge la PAr par POST /flows/search en mode différentiel sur la propriété updatedAt, et récupère ainsi les nouveaux flux disponibles.
   • Notification webhook (annexe normative D de la norme, en pré-version) : la PAr appelle directement le Client API à chaque arrivée ou évolution d'un flux.

3. Récupération du flux par le Client API. Le Client API récupère le flux par un appel, en précisant le composant souhaité (les métadonnées, la facture telle que reçue, le PDF lisible ou une version convertie dans un autre format standardisé).

4. Intégration dans le système d'information. La facture est intégrée dans le système d'information de l'acheteur. Côté AOS, ce traitement s'appuie sur le sous-module Data Capture, qui extrait les données utiles et crée ou met à jour la facture dans l'ERP.

5. Production des statuts de cycle de vie. Après intégration, le Client API peut produire successivement les statuts de cycle de vie correspondant au traitement effectif de la facture côté acheteur : Prise en charge, Approuvée, En litige, etc. Chaque statut est transmis sous forme de flux CDAR à la PAr, qui le retransmet à la PAe et au PPF.

Ici aussi, trois types d'erreurs sont possibles :

• Flux entrant irrecevable. Si la PAr juge le flux entrant irrecevable à sa propre étape de contrôle (avant mise à disposition), elle ne le transmet pas au Client API destinataire et produit un flux CDAR de statut 213 (Rejetée à la réception) à destination de la PAe.

• Refus fonctionnel par le Client API. Lorsque le Client API examine la facture reçue et décide de la refuser (par exemple : facture non due, erreur de destinataire, contenu non conforme aux accords commerciaux), il produit un flux CDAR de statut 210 (Refusée), accompagné d'un code motif de refus normalisé. Ce statut remonte à la PAr, puis à la PAe et au PPF.

• Mise en litige. Lorsque l'acheteur conteste tout ou partie de la facture sans la refuser purement et simplement, il peut produire un statut En litige pour suspendre le cycle dans l'attente d'un échange avec le vendeur.

Fonctionnalités

• Connectivité avec une PA — Interface unifiée vers les API d'une PA conforme à la spécification AFNOR XP Z12-013, avec deux modes d'authentification au choix : clé d'API ou OAuth2.
• Gestion multi-plateformes — Possibilité de configurer plusieurs plateformes d'accès par société (environnement de test, environnement de production, ou plusieurs PA en parallèle), avec règles de routage dédiées par type d'opération (annuaire, émission, réception).
• Adresses électroniques des tiers — Stockage des adresses électroniques (SIREN, SIRET, TVA intracommunautaire, DUNS, GLN, Odette, code de routage) sur la fiche tiers.
• Gestion de l'annuaire — Recherche d'entreprises dans l'annuaire de la facturation électronique (via l'API de consultation annuaire de sa PA) par numéro de SIREN ou de SIRET, et récupération des adresses électroniques disponibles.
• Émission de factures électroniques — Génération du fichier XML structuré (Factur-X, UBL ou CII) via le sous-module File Generator, soumission à la PA via API, suivi du flux émis (statuts d'acquittement technique, statuts AFNOR fonctionnels, motifs de rejet, dates d'événements, identifiants externes).
• Réception de factures électroniques — Récupération des flux entrants depuis la PA, déclenchement du pipeline Data Capture pour l'intégration de la facture dans AOS, conservation des fichiers originaux pour les besoins de conformité.
• Suivi du cycle de vie des flux — Traçabilité complète des opérations : statuts techniques d'acquittement, statuts AFNOR fonctionnels, codes motif normalisés, actions requises (à valider, à corriger, etc.), dates d'événements et identifiants externes fournis par la PA.
• Traitements automatisés — Exécution planifiée des synchronisations récurrentes (annuaire, statuts de factures, événements, soumission des factures en attente) via le mécanisme de batchs.

info

Les fonctionnalités suivantes sont identifiées comme évolutions à venir du sous-module. Elles ne doivent pas être considérées comme livrables dans la version 8.10 et feront l'objet d'évolutions dans les versions ultérieures.

• Webhooks entrants — Réception de notifications poussées par la PA (par exemple à chaque changement de statut d'un flux), avec validation par secret partagé pour garantir l'authenticité de l'appel.
• E-reporting — Transmission à l'administration fiscale, via la PA, des données de transactions B2C (vers les particuliers) et des transactions internationales, ainsi que des données de paiement, dans le cadre des obligations déclaratives complémentaires de la réforme.
• Génération CDAR — Production des Comptes-Rendus d'Analyse normalisés associés au cycle de vie d'une facture entrante (notification de prise en charge, refus, encaissement, etc.).

Concepts

Le sous-module E-Invoicing s'articule autour de cinq composants centraux, chacun matérialisé par une entité paramétrable dans AOS.

Plateforme d'accès

La plateforme d'accès représente, dans AOS, la configuration d'accès à une PA donnée. Elle porte l'URL de base, les identifiants d'authentification, l'environnement de fonctionnement (Sandbox ou Production), les paramètres de robustesse réseau (temporisations, politique de relance en cas d'incident) et l'état du dernier test de connectivité.

Une même installation d'AOS peut comporter plusieurs plateformes d'accès. Cela permet par exemple de connecter simultanément l'application à plusieurs PA différentes.

Règle de routage

La règle de routage est l'objet qui, pour une plateforme d'accès donnée, spécifie comment réaliser une opération particulière (recherche annuaire, émission de facture, réception de facture, e-reporting). Une plateforme d'accès porte autant de règles de routage qu'il y a d'opérations qu'elle prend en charge.

Les quatre types de routage disponibles sont :

• Annuaire (Directory) : appels à l'API d'annuaire de la PA pour la recherche et la maintenance des adresses électroniques.
• Émission (Emission) : appels à l'API de flux pour la transmission des factures et cycles de vie émis par l'entreprise vers ses clients via la PA.
• Réception (Reception) : appels à l'API de flux pour la récupération des factures et cycles de vie émis par les fournisseurs ou leur PA et acheminées vers l'entreprise via sa PA.
• E-reporting : appels à l'API de flux pour la transmission des données déclaratives à l'administration fiscale via la PA.

Adresse électronique

L'adresse électronique est rattachée à un tiers (client ou fournisseur) dans AOS. Elle représente un identifiant officiel utilisé pour acheminer les factures électroniques à destination ou en provenance de ce tiers via la PA.

Plusieurs formes d'adresse électronique sont prises en charge, conformément aux schémas d'identification d'entreprise reconnus dans le cadre de la facturation électronique, notamment les identifiants construits sur la base de :

• SIREN — numéro d'identification d'une entreprise (9 chiffres).
• SIRET — numéro d'identification d'un établissement (14 chiffres).
• TVA intracommunautaire — numéro de TVA européen.
• DUNS — identifiant Dun & Bradstreet.
• GLN — Global Location Number (codification GS1).
• Odette — codification utilisée principalement dans le secteur automobile.

Un tiers peut posséder plusieurs adresses électroniques. L'une d'elles peut être marquée comme adresse par défaut ; elle sera alors utilisée par défaut pour le routage des factures émises vers ce tiers.

Flux

Le flux est l'unité d'échange entre AOS et la PA. Chaque opération de transmission ou de réception donne lieu à un flux, qui consigne son contenu, son contexte et son cycle de vie.

Selon sa direction, un flux représente soit une facture émise par l'entreprise et transmise à la PA, soit une facture reçue par la PA et récupérée par AOS. Il peut aussi représenter, dans des cas spécifiques, un compte-rendu de cycle de vie (CDAR), un flux d'e-reporting (FRR), ou un flux générique JSON.

Batch e-invoicing

Le batch E-Invoicing est l'objet de paramétrage qui permet d'automatiser les opérations récurrentes du sous-module (synchronisations d'annuaire, remontées de statuts, transmissions de factures). Chaque batch correspond à une action précise et est rattaché à une plateforme d'accès. Six actions sont actuellement définies.

• Synchronisation de l'annuaire : Synchronise les adresses électroniques des tiers avec l'annuaire de la facturation électronique.
• Synchronisation des factures : Récupération des flux de factures entrants disponibles.
• Envoi des flux de factures : Génération et envoi des factures non traitées à la PA.
• Soumission des factures en attente : Envoi des flux de factures déjà générés et non envoyés à la PA.
• Synchronisation du cycle de vie des flux : Synchronise les événements de cycle de vie des flux (changements de statut, motifs, actions requises). En cours de développement.
• Envoi de l'E-reporting : Soumet les flux d'e-reporting (transactions B2C, transactions internationales). En cours de développement.