Le 1er septembre 2026, toutes les entreprises françaises assujetties à la TVA devront être capables de recevoir des factures électroniques au format normé. Sans exception, quelle que soit la taille de l’entreprise. L’obligation d’émission suivra un an plus tard, le 1er septembre 2027, pour les PME et TPE (les GE et ETI émettent déjà depuis septembre 2026).
Il reste cinq mois. Pour les développeurs et intégrateurs qui n’ont pas encore commencé ou qui sont en cours d’implémentation, cette checklist couvre les deux échéances : ce qu’il faut livrer pour septembre 2026 (réception), et ce qu’il faut préparer pour septembre 2027 (émission). Chaque item est une tâche technique concrète.
Le contexte réglementaire complet, l’architecture PDP 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 :
- Recevoir des factures structurées au format Factur-X (PDF/A-3 + XML CII), UBL 2.1 ou CII pur, via une PDP (Plateforme de Dématérialisation Partenaire)
- Extraire les données machine du document reçu pour les intégrer dans votre comptabilité
- Valider la conformité du document avant de l’intégrer (un fournisseur peut envoyer une facture mal formée)
- Renvoyer un statut d’acceptation ou de rejet via la PDP
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 PDP. Le PPF ne route plus les factures — il gère l’annuaire et la concentration des données fiscales. Votre logiciel interagit avec la PDP de votre client, qui reçoit les factures de la PDP de l’émetteur. Pour comprendre ce modèle à 5 coins, voir la section architecture du guide technique.
Checklist : réception (septembre 2026)
☐ Choisir votre PDP
La PDP 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 PDP retenue. Identifiez les PDP 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 PDP 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://facturxapi.com/api/v1/validate \
-H "X-API-Key: votre-cle-api" \
-F "[email protected]"☐ 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 PDP : facture acceptée, rejetée (avec motif), ou en attente de traitement. Ce workflow de cycle de vie est spécifique à chaque PDP, 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 PDP 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 conforme.
☐ Valider avant transmission
Toute facture générée doit passer quatre niveaux de validation avant l’envoi à la PDP. Un rejet par la PDP 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 PDP
L’interface technique dépend de la PDP 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 PDP 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) : montants positifs, référence à la facture d’origine (BT-25), cohérence TVA - Autoliquidation (catégorie TVA
AE) : motif d’exonération obligatoire (BT-120), identifiants fiscaux requis des deux côtés, taux TVA à zéro - Multi-taux TVA : ventilation correcte dans le
taxBreakdown, 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.
Les 5 erreurs les plus courantes à anticiper
L’analyse des validations traitées par l’API et des retours de la communauté open source (Odoo, Dolibarr, Invoice Ninja) révèle cinq erreurs récurrentes.
1. Oublier BT-10 (référence acheteur) pour Chorus Pro. Pour certains débiteurs publics via Chorus Pro, la référence d’engagement ou le numéro de commande est obligatoire. Ce paramétrage est défini par le débiteur dans l’annuaire Chorus Pro — il ne s’applique 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. Les règles BR-CO-10, BR-CO-13 et BR-CO-15 vérifient que la somme des lignes correspond au total HT, et que HT + TVA = TTC. Un écart d’un centime (arrondi ligne par ligne vs arrondi global) suffit pour un rejet. Voir le catalogue des erreurs BR-*.
5. SIRET absent ou invalide. En pratique française, renseigner BT-30 (identifiant légal, souvent SIRET avec schemeID=“0002”) est fortement recommandé. Au niveau du noyau EN16931, l’identification du vendeur peut être satisfaite par BT-29, BT-30 ou BT-31 (règle BR-CO-26). La plupart des ERP ne remplissent pas BT-30 par défaut. Voir Champs obligatoires EN16931.
Timeline recommandée
Voici un calendrier réaliste pour un intégrateur qui démarre en avril 2026.
Phase 1 — Avril/Mai 2026 : fondations
- Choisir la PDP (ou identifier les PDP 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 PDP, extraction, validation, intégration ERP
- Implémenter le workflow de rejet/acceptation vers la PDP
- 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 PDP
- 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 PDP
- Gérer les cas spéciaux (avoirs, autoliquidation, multi-taux)
- Tester en sandbox PDP
1er septembre 2027 : émission opérationnelle
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 :
- Facturation électronique 2026 : le guide technique complet pour développeurs — le socle réglementaire, l’architecture PDP, les trois formats
- Factur-X vs UBL vs CII : quel format choisir — comparatif technique par contexte d’intégration
- Profils Factur-X : MINIMUM vers EXTENDED — matrice de choix du profil
Réception et extraction :
- Extraire l’XML d’un PDF Factur-X reçu — méthodes d’extraction en Python, Java, PHP et CLI
- Champs obligatoires EN16931 : cartographie et mapping ERP — Business Terms vers champs ERP
- API annuaire et routage SIRET — identification et routage des factures
Validation :
- Valider EN16931/Factur-X : XSD vs Schematron, erreurs BR-* — playbook de débogage complet
- Catalogue des erreurs BR-* EN16931 — référence de chaque règle Schematron
- KoSIT, Mustangproject ou API SaaS — choix du validateur
- Corriger automatiquement un XML CII invalide — réparation automatique des erreurs de format
Émission et génération :
- Convertir une facture PDF en Factur-X 1.08 conforme — les deux modes de conversion
- Données ERP vers Factur-X CII : mapper JSON vers XML — guide de mapping complet
- PDF/A-3 pour Factur-X : checklist de conformité — génération PDF/A-3 conforme
- PDF/A-3 vs PDF/A-1 : pourquoi Factur-X exige PDF/A-3 — différences techniques entre versions
- Python et Factur-X : générer, attacher et valider — guide Python complet
- PHP et mPDF : résoudre le bug XML 0 bytes — diagnostic mPDF
Par ERP :
- Odoo et Factur-X — configuration et erreurs courantes
- Dolibarr et Factur-X 2026 — module et intégration API
- Invoice Ninja et la réforme française — architecture e-invoicing
- Rejets Chorus Pro décryptés — erreurs B2G et corrections
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. 10 validations/mois gratuites, sans carte bancaire. Créer ma clé API gratuite