FacturX API
Technique

Checklist développeur : réception facturation électronique septembre 2026

Mis à jour le 12 min de lecture Par FacturX API

Checklist technique pour vérifier la réception obligatoire depuis septembre 2026 et préparer l’émission 2027 des PME. Formats, validation, pipeline, intégration ERP, tests.

En bref

  • Réception obligatoire au 1er sept. 2026 pour toutes les entreprises assujetties à la TVA (toutes tailles). Émission PME/TPE au 1er sept. 2027 (GE/ETI émettent dès 2026).
  • Pipeline de réception : identifier le format reçu via la PA et appliquer les contrôles correspondants avant l’intégration :
    • Factur-X : contrôler le conteneur PDF/A-3 → extraire le XML CII embarqué → contrôler XSD, Schematron et le profil applicable.
    • UBL 2.1 : lire le XML UBL → contrôler XSD, Schematron et le profil applicable ; aucun conteneur PDF/A-3 n’est requis pour ce XML.
    • CII pur : lire le XML CII standalone → contrôler XSD, Schematron et le profil applicable ; aucun conteneur PDF/A-3 n’est requis pour ce XML.
  • Ne jamais faire confiance au contenu reçu — validation preflight via /api/v1/validate avant intégration ERP.
  • Côté émission 2027 : si le format choisi est Factur-X, générer un PDF/A-3 avec son XML CII embarqué. Pour ce XML CII, encoder le SIREN légal (BT-30, schemeID 0002) et distinguer le SIRET d’établissement (schemeID 0009), le format de date 102, le N° TVA avec préfixe pays, et les codes BR-AE-* pour l’autoliquidation.
  • Les rejets de PA sont le pire scénario (retard paiement + relances manuelles). Preflight systématique en CI/CD et tests d’intégration.

Depuis le 1er septembre 2026, les entreprises dans le champ de la réforme doivent pouvoir recevoir les factures électroniques de leurs fournisseurs tenus de les émettre. L’émission s’applique depuis cette date aux GE et ETI, puis au 1er septembre 2027 aux PME et micro-entreprises, selon le calendrier officiel.

Cette checklist aide les développeurs et intégrateurs à vérifier le flux de réception désormais requis et à préparer l’émission 2027 des PME et micro-entreprises. Chaque item est une tâche technique concrète.

Le contexte réglementaire complet, l’architecture PA et le socle technique sont traités dans le guide technique 2026 pour développeurs. Cet article suppose que vous connaissez les bases.

Ce que “réception obligatoire” signifie techniquement

La réception obligatoire ne signifie pas “avoir un email pour recevoir des PDF”. Elle signifie que votre système doit être capable de :

  1. Recevoir des factures structurées au format Factur-X (PDF/A-3 + XML CII), UBL 2.1 ou CII pur, via une PA (Plateforme Agréée)
  2. Extraire les données machine du document reçu pour les intégrer dans votre comptabilité
  3. Valider la conformité du document avant de l’intégrer (un fournisseur peut envoyer une facture mal formée)
  4. Renvoyer un statut d’acceptation ou de rejet via la PA

Pour septembre 2026, vous n’avez pas besoin de générer des Factur-X si votre client est une PME ou TPE. L’émission viendra en 2027. Mais si votre logiciel sert des GE ou ETI, l’émission est aussi requise dès septembre 2026.

Le flux passe par une PA. Le PPF ne route plus les factures — il gère l’annuaire et la concentration des données fiscales. Votre logiciel interagit avec la PA de votre client, qui reçoit les factures de la PA de l’émetteur. Pour comprendre ce modèle à 5 coins, voir la section architecture du guide technique.

Checklist : réception (septembre 2026)

☐ Choisir votre PA

La PA est la plateforme qui recevra les factures pour le compte de votre client. C’est la décision la plus structurante car elle détermine les formats de réception, les API d’intégration et les flux de statuts.

Ne choisissez pas pour votre client — mais votre logiciel doit être capable de s’interfacer avec la PA retenue. Identifiez les PA les plus probables dans votre segment de marché et commencez les intégrations techniques (API, webhooks, formats d’échange).

☐ Définir le format de réception

Votre système doit traiter au moins un des trois formats normés : Factur-X, UBL ou CII pur. La PA peut proposer de convertir entre formats, mais votre pipeline d’intégration doit gérer le format convenu.

En France, Factur-X est l’un des trois formats obligatoires en réception et est particulièrement adopté par les PME/TPE. Si vous n’avez pas de contrainte spécifique, commencez par là. Pour un comparatif technique des trois formats, voir Factur-X vs UBL vs CII : quel format choisir.

☐ Implémenter l’extraction XML

Une facture Factur-X reçue est un PDF/A-3 contenant un XML CII embarqué en pièce jointe. Votre code doit extraire ce XML pour récupérer les données structurées (numéro, date, montants, lignes, identifiants fiscaux).

Les étapes techniques : détecter la pièce jointe factur-x.xml ou ZUGFeRD-invoice.xml, vérifier l’attribut AFRelationship, extraire le flux XML, parser les namespaces CII (rsm:, ram:). Les cas d’échec courants (XML 0 bytes, AFRelationship incorrect, BOM UTF-8) sont documentés dans Extraire l’XML d’un PDF Factur-X reçu.

☐ Valider les factures reçues

Ne faites jamais confiance au contenu d’une facture reçue. Un fournisseur peut envoyer un document structurellement invalide ou sémantiquement incohérent. Validez avant d’intégrer dans votre comptabilité.

La validation couvre quatre niveaux : conformité PDF/A-3 (ISO 19005-3), structure Factur-X (XML embarqué avec les bons attributs), validation XSD du XML, et validation Schematron des règles métier EN16931. Un fichier qui passe le XSD peut échouer sur des dizaines de règles Schematron. Le détail de ces niveaux est dans Valider EN16931/Factur-X : XSD vs Schematron, erreurs BR-*.

# Validation via l'API FacturX
curl -X POST https://api.facturxapi.com/api/v1/validate \
  -H "Authorization: Bearer votre-cle-api" \
  -F "file=@./facture-recue.pdf"

☐ Mapper vers votre ERP

Les données extraites du XML CII utilisent le modèle sémantique EN16931 (Business Terms : BT-1 pour le numéro, BT-2 pour la date, BT-109 pour le total HT, etc.). Votre pipeline doit transformer ces BT en champs de votre ERP.

La cartographie complète des Business Terms, avec leurs XPaths CII et les champs ERP correspondants, est dans Champs obligatoires EN16931 : cartographie et mapping ERP. Pour les guides spécifiques par ERP : Odoo, Dolibarr, Invoice Ninja.

☐ Gérer les rejets

Votre système doit pouvoir renvoyer un statut à la PA : facture acceptée, rejetée (avec motif), ou en attente de traitement. Ce workflow de cycle de vie est spécifique à chaque PA, mais le principe est commun : chaque facture reçue doit avoir un statut explicite.

Prévoyez un mécanisme de file d’attente pour les factures en erreur (validation échouée, données incomplètes, doublon potentiel) avec une interface de revue manuelle.

☐ Archiver les originaux

L’obligation légale impose la conservation du document original pendant 10 ans. Le PDF/A-3 reçu — pas une copie reconvertie, pas un export de votre ERP — doit être archivé dans un système garantissant l’intégrité et l’horodatage.

Le format PDF/A-3 est précisément conçu pour l’archivage long terme (ISO 19005-3). Pour comprendre pourquoi PDF/A-3 et pas PDF/A-1, voir PDF/A-3 vs PDF/A-1 : pourquoi Factur-X exige PDF/A-3.

☐ Tester en conditions réelles

Les PA proposent des environnements de test (sandbox, recette). Utilisez-les. Envoyez des factures de test dans les trois formats, avec des cas limites : multi-taux TVA, autoliquidation, avoirs, factures avec et sans lignes de détail. Vérifiez que votre pipeline de réception, extraction, validation et intégration ERP fonctionne de bout en bout.

Checklist : émission (septembre 2027)

Pour les PME et TPE, l’émission est obligatoire au 1er septembre 2027. Pour les GE et ETI, c’est déjà septembre 2026. Dans tous les cas, commencez la préparation dès que la réception est stabilisée.

☐ Générer le XML CII depuis l’ERP

Mappez les données de votre ERP vers le modèle EN16931 pour produire un XML CII D22B conforme. C’est l’inverse du mapping de réception — cette fois, vous êtes la source de données. Le guide complet de ce mapping est dans Données ERP vers Factur-X CII : mapper JSON vers XML EN16931.

☐ Produire le conteneur Factur-X

Le XML CII doit être embarqué dans un PDF/A-3 avec les bons attributs (AFRelationship, métadonnées XMP, profil ICC). Produire un PDF/A-3 réellement conforme est la zone de friction la plus documentée de la réforme. Voir PDF/A-3 pour Factur-X : checklist de conformité et pièges courants et Convertir une facture PDF en Factur-X 1.08 contrôlé.

☐ Valider avant transmission

Toute facture générée doit passer quatre niveaux de validation avant l’envoi à la PA. Un rejet par la PA signifie une facture non transmise, un délai de paiement compromis et une relance manuelle.

Les quatre niveaux : conformité PDF/A-3 (veraPDF), structure Factur-X (XML embarqué avec les bons attributs), validation XSD (schéma CII D22B), validation Schematron (règles métier BR-*). Pour le choix de l’outil de validation, voir KoSIT, Mustangproject ou API SaaS.

☐ Transmettre via votre PA

L’interface technique dépend de la PA retenue par votre client : API REST, dépôt SFTP, webhook, ou autre mécanisme d’ingestion. Votre logiciel doit implémenter le connecteur adapté et gérer les erreurs de transmission (timeout, rejet technique, quota).

☐ Gérer les retours de statut

La PA renvoie des statuts pour chaque facture transmise : acceptée par le destinataire, rejetée, en attente. Votre logiciel doit traiter ces retours pour mettre à jour le statut de la facture dans l’ERP et déclencher les actions appropriées (relance, correction, archivage).

☐ Préparer les cas spéciaux

Parmi les erreurs fréquemment rencontrées en pratique :

  • Avoirs (typeCode 381) : convention de signes du format et du contrat d’entrée, référence à la facture d’origine (BT-25) et sa date si requise (BT-26), cohérence TVA
  • Autoliquidation (catégorie TVA AE) : motif textuel (BT-120) ou code de motif (BT-121), identifiants requis par les règles AE pour le vendeur et l’acheteur, taux TVA à zéro. Le régime fiscal doit correspondre à l’opération réelle
  • Multi-taux TVA : ventilation correcte dans le tax_breakdown, cohérence BR-CO-17 par catégorie, rattachement de chaque ligne au bon taux

Ces cas sont détaillés avec des exemples JSON et XML dans le guide de mapping ERP vers CII.

Warnings et erreurs fatales : vérifier le pack exécuté

Le calendrier légal et la sévérité d’un artefact sont deux informations différentes. L’obligation de réception du 1er septembre 2026 ne dépend pas d’une date de mise à jour du Schematron. La version du pack, son variant et les règles effectivement exécutées déterminent les avertissements ou erreurs du rapport ; l’acceptation par une PA dépend de ses contrôles et de son retour réel.

Au 20 septembre 2026, la publication France RFE 1.4.0.04 est disponible, tandis que les métadonnées de FacturX API déclarent 1.4.0.02 chargé. Ne confondez pas publication disponible, artefact installé et contrôle exécuté sur votre facture.

Un warning reste consultatif dans le pack qui l’émet : il ne devient pas une erreur fatale par anticipation. Un autre pack peut attribuer une sévérité différente à la même règle. Conservez séparément le verdict de la cible, la sévérité, le blocage de transmission et la possibilité de générer un candidat corrigé. Un contrôle non évalué ne vaut jamais validation.

Ce qu’un intégrateur doit faire :

  1. Tester les artefacts et le variant de sa cible, en conservant version, sévérités et résultat.
  2. Examiner les écarts selon leur effet réel et les données disponibles, sans transformer tous les avertissements en champs obligatoires.
  3. Automatiser ce contrôle en CI et vérifier séparément le flux avec la PA.

Cinq erreurs à anticiper

Voici cinq cas à inclure dans vos tests de génération et d’intégration.

1. Confondre les références demandées par Chorus Pro. BT-10 désigne la référence acheteur ; le numéro de commande relève de BT-13. Ne mappez pas automatiquement un engagement juridique vers BT-10 : vérifiez le mapping attendu pour le flux et le paramétrage du destinataire. Les exigences ne s’appliquent pas systématiquement à tous les flux B2G. Voir Rejets Chorus Pro décryptés.

2. Mauvais profil Factur-X. Utiliser le profil MINIMUM ou BASIC WL pour des factures B2B soumises à la réforme est insuffisant — ces profils ne contiennent pas les informations fiscales complètes requises. Le profil doit couvrir pleinement EN16931. Voir Profils Factur-X : MINIMUM vers EXTENDED.

3. Format de date incorrect. En CII, les dates utilisent le format AAAAMMJJ (ex: 20260901) avec l’attribut format="102". Les ERP exportent souvent en ISO 8601 (2026-09-01). Si vous construisez le XML vous-même, le format CII est strictement AAAAMMJJ.

4. Totaux arithmétiquement incohérents. BR-CO-10 contrôle la somme des nets de lignes ; BR-CO-13 en déduit le total HT après remises et charges documentaires ; BR-CO-15 vérifie HT + TVA = TTC. Contrôler les arrondis selon chaque règle, sans supposer une tolérance universelle d’un centime. Voir le catalogue des erreurs BR-*.

5. Confondre SIREN et SIRET. Dans le mapping France CTC, BT-30 porte le SIREN légal du vendeur à 9 chiffres avec schemeID="0002". Le SIRET à 14 chiffres identifie un établissement et relève du champ prévu pour cet usage, notamment BT-29 avec schemeID="0009" selon le flux. Au niveau du noyau EN16931, BR-CO-26 vérifie la présence de BT-29, BT-30 ou BT-31 ; les exigences France CTC se contrôlent séparément avec le pack applicable. Voir Champs obligatoires EN16931.

Repères du projet : réception 2026 et émission PME 2027

Les phases d’avril à septembre 2026 ci-dessous sont des repères historiques : elles servent désormais à vérifier ce qui est effectivement livré. La phase émission 2027 concerne les PME et micro-entreprises ; les GE et ETI sont déjà soumises à l’émission depuis septembre 2026.

Phase 1 — Avril/Mai 2026 : fondations

  • Choisir la PA (ou identifier les PA cibles de vos clients)
  • Réaliser un POC d’extraction XML depuis un Factur-X de test
  • Implémenter la validation des factures reçues (API ou validateur embarqué)
  • Mapper les Business Terms EN16931 vers les champs de votre ERP

Phase 2 — Juin/Juillet 2026 : intégration

  • Intégrer le pipeline complet : réception PA, extraction, validation, intégration ERP
  • Implémenter le workflow de rejet/acceptation vers la PA
  • Mettre en place l’archivage des originaux PDF/A-3
  • Tester avec des factures couvrant les cas limites (multi-taux, avoirs, autoliquidation)

Phase 3 — Août 2026 : validation

  • Tests en conditions réelles avec l’environnement sandbox de la PA
  • Tests de charge si le volume de factures entrantes est significatif
  • Validation du workflow complet de bout en bout avec les équipes comptables

1er septembre 2026 : réception opérationnelle

Phase 4 — Octobre 2026 à Juin 2027 : préparation émission

  • Implémenter la génération XML CII depuis les données ERP
  • Produire des conteneurs Factur-X PDF/A-3 conformes
  • Intégrer la validation 4 niveaux avant transmission
  • Connecter le flux d’émission à la PA
  • Gérer les cas spéciaux (avoirs, autoliquidation, multi-taux)
  • Tester en sandbox de la PA

1er septembre 2027 : émission obligatoire des PME et micro-entreprises

Erreurs fréquentes et fiches de diagnostic

Les 22 fiches unitaires : catalogue complet des erreurs BR-*.

Et maintenant ?

Tester ma facture maintenant →

 
curl -X POST https://api.facturxapi.com/api/v1/validate \
  -H "Authorization: Bearer VOTRE_CLE" \
  -F "file=@./facture.pdf"

Clé Sandbox : 100 factures traitées offertes les 14 premiers jours, puis 10 factures traitées/mois. Le scanner public reste gratuit et séparé du quota API. Obtenir une clé API.

Aller plus loin

Cette checklist est un point d’entrée. Chaque item renvoie vers un article technique approfondi. Voici la carte complète :

Contexte et architecture :

Réception et extraction :

Validation :

Émission et génération :

Par ERP :

Besoin de valider vos factures reçues ou générées ? L’API FacturX exécute les 4 niveaux de validation (PDF/A-3, structure Factur-X, XSD, Schematron) en une seule requête. Clé Sandbox : 100 factures traitées offertes les 14 premiers jours, puis 10 factures traitées/mois. Créer ma clé API gratuite

#réforme 2026 #checklist #facturation électronique #factur-x #EN16931 #PA #développeur

Et maintenant ?

Prochaines étapes

Choisissez l'étape suivante pour activer FacturX API sur votre stack. Tous les liens sont internes pour garder le suivi clair.

→

Vérifier une facture

Déposez un PDF ou XML pour obtenir un diagnostic EN16931 clair, sans compte.

→

Obtenir une clé API

Demandez une clé Sandbox par email : 100 factures traitées offertes les 14 premiers jours, puis 10 factures traitées/mois.

→

Voir les tarifs

Plans adaptés du prototype à la production : Sandbox, Launch, Scale, Business et accompagnement.

→

Documentation

Référence complète de l'API : endpoints, paramètres, exemples.