Réception factures électroniques 2026 : valider Factur-X reçus (cabinets comptables)

En bref

Réception obligatoire dès le 1er septembre 2026 pour toutes les entreprises assujetties à la TVA.
Pour les cabinets comptables : centaines/milliers de Factur-X entrants par mois, générés par des logiciels différents, de qualité variable.
Pipeline recommandé : réception PDP → /extract?validate=true (extraction + validation en une requête) → intégration ERP si conforme.
Les factures invalides ne doivent PAS être intégrées — rejet au dépôt avec rapport d’erreur transmis au fournisseur.
L’endpoint /validate retourne un rapport JSON structuré exploitable par votre GED ou votre moteur d’intégration.

Au 1er septembre 2026, toutes les entreprises assujetties à la TVA devront pouvoir recevoir des factures électroniques au format structuré. Pour les cabinets d’expertise comptable — plus de 21 000 en France (source : Conseil National de l’Ordre des Experts-Comptables, 2025) — cela signifie des centaines ou des milliers de documents entrants par mois, provenant des clients de chaque cabinet, transmis via des Plateformes de Dématérialisation Partenaires (PDP) différentes.

La question n’est pas de savoir si ces factures arriveront. Elles arriveront. La question est : comment garantir que ce que vous recevez est conforme, complet et exploitable avant de l’intégrer dans la comptabilité ?

Cet article s’adresse aux développeurs et CTO d’éditeurs de logiciels comptables, aux intégrateurs techniques travaillant pour des cabinets, et aux responsables SI qui construisent le pipeline de réception. Le contexte réglementaire complet et l’architecture PDP sont traités dans le guide technique 2026 pour développeurs. La checklist développeur couvre l’ensemble des items à livrer avant septembre 2026.

Ce que “réception obligatoire” change concrètement

La réception obligatoire ne signifie pas “recevoir un PDF par email”. Elle signifie que votre logiciel doit traiter des documents structurés transmis par la PDP du fournisseur vers la PDP du destinataire. Le cadre de la réforme française accepte trois formats de facture électronique :

Factur-X : un PDF/A-3 avec XML CII embarqué
CII XML : un fichier XML Cross-Industry Invoice pur (sans conteneur PDF)
UBL XML : un fichier XML Universal Business Language pur (sans conteneur PDF)

Concrètement, le flux est le suivant :

Le fournisseur de votre client émet une facture via sa PDP
La PDP du fournisseur transmet le document à la PDP de votre client (dans l’un des trois formats ci-dessus)
Votre logiciel récupère le document depuis la PDP (API, webhook, dépôt SFTP)
Votre logiciel doit identifier le format reçu, extraire ou lire le XML structuré, valider la conformité du document, puis intégrer les données dans la comptabilité

Le point critique : vous ne contrôlez pas la qualité de ce que vous recevez. Le fournisseur peut utiliser un logiciel qui génère des factures mal formées — que ce soit un Factur-X avec un XML CII incomplet, un UBL avec des champs manquants, ou un CII avec des totaux incohérents. Si votre pipeline intègre ces données sans vérification, vous créez des écritures comptables fausses.

Pour les cabinets comptables, le risque est multiplié par le nombre de clients et de fournisseurs différents. Un cabinet qui gère 200 dossiers avec chacun 10 à 50 fournisseurs reçoit potentiellement des factures générées par des dizaines d’éditeurs logiciels différents, avec des niveaux de conformité variables.

Les 3 risques de ne pas valider les factures reçues

Risque 1 : données incomplètes

Le XML est présent dans le PDF, mais il manque des champs essentiels. Le vendeur n’a pas renseigné BT-30 (identifiant légal, typiquement le SIRET), ou BT-5 (devise) est absent, ou les lignes de détail sont vides parce que le document a été généré en profil MINIMUM. Le logiciel d’intégration extrait ce qui existe, mais les écritures comptables sont incomplètes — il manque l’identification du tiers, le montant HT par ligne, ou la ventilation TVA.

La cartographie complète des champs obligatoires et leur signification comptable est détaillée dans Champs obligatoires EN16931 : cartographie et mapping ERP.

Risque 2 : données incohérentes

Le total TTC dans le XML (BT-112) ne correspond pas au total visible sur le PDF. Ou la somme des lignes (BT-106) ne correspond pas au total HT (BT-109). Ces incohérences arithmétiques sont vérifiées par les règles Schematron EN16931 (BR-CO-10, BR-CO-13, BR-CO-15), mais si votre pipeline ne les vérifie pas, vous intégrez des montants qui ne s’équilibrent pas. En comptabilité, un écart d’un centime sur un rapprochement bancaire déclenche une investigation. Un XML avec des totaux faux en déclenche des dizaines.

Risque 3 : format non conforme

Le PDF reçu n’est pas un vrai PDF/A-3 (ISO 19005-3). Le XML embarqué n’est pas du CII valide — namespace incorrect, balises malformées, encodage cassé. Le document ressemble à un Factur-X mais n’en est pas un au sens technique. L’extraction échoue silencieusement ou retourne des données partielles.

En comptabilité, intégrer des données issues d’un document non conforme expose le cabinet à un risque fiscal en cas de contrôle et à un risque d’audit si l’archivage légal (10 ans) porte sur un document qui n’est pas un original conforme. Pour comprendre les exigences techniques du conteneur PDF/A-3, voir PDF/A-3 pour Factur-X : checklist de conformité et pièges courants.

Pipeline de réception : identifier le format, extraire, valider, intégrer

La première opération sur chaque facture entrante est d’identifier son format. Le traitement diffère selon que vous recevez un Factur-X PDF, un CII XML pur ou un UBL XML pur.

Branche 1 : si Factur-X PDF reçu

Le premier traitement sur une facture Factur-X reçue est d’en extraire le XML CII embarqué. L’endpoint /extract prend le PDF en entrée et retourne le XML en base64, avec le profil détecté (MINIMUM, BASIC, EN16931, EXTENDED).

curl -X POST https://api.facturxapi.com/api/v1/extract \
  -H "Authorization: Bearer votre-cle-api" \
  -F "[email protected]"

La réponse contient le XML brut encodé en base64, la taille du XML, le profil détecté et le temps de traitement :

{
  "xml": "PD94bWwgdmVyc2lvbj0iMS4wIj8+...",
  "xmlSize": 2048,
  "profile": "EN16931",
  "filename": "facture-recue.pdf",
  "extractedAt": "2026-04-13T10:30:00Z",
  "durationMs": 38
}

Le XML retourné est en base64 — c’est à votre code de le décoder, puis de le parser pour en extraire les Business Terms dont vous avez besoin. Le mapping entre les XPaths CII et les champs comptables est à votre charge. L’API ne retourne pas un JSON comptable structuré ; elle retourne le XML tel qu’il est embarqué dans le PDF.

Si le PDF ne contient pas de XML embarqué, l’API retourne une erreur 422. Si le fichier n’est pas un PDF, c’est une erreur 415. Un PDF sans XML embarqué n’est pas un Factur-X valide. Cependant, un CII XML pur ou un UBL XML pur sont aussi des factures électroniques conformes au cadre de la réforme française — traitez-les via les branches 2 ou 3 ci-dessous.

Pour combiner extraction et validation en une seule requête, ajoutez le paramètre validate=true en query string. L’appel consomme alors 2 unités de quota au lieu de 1, mais vous évitez un aller-retour réseau :

curl -X POST "https://api.facturxapi.com/api/v1/extract?validate=true" \
  -H "Authorization: Bearer votre-cle-api" \
  -F "[email protected]"

Pour les méthodes d’extraction en Python, Java, PHP et CLI (sans passer par l’API), le guide complet est dans Extraire l’XML d’un PDF Factur-X reçu.

Branche 2 : si CII XML reçu

Un fichier CII XML pur (sans conteneur PDF) est une facture électronique valide au sens de la réforme. Aucune extraction n’est nécessaire — le fichier est directement le XML structuré. Envoyez-le directement à l’endpoint /validate :

curl -X POST https://api.facturxapi.com/api/v1/validate \
  -H "Authorization: Bearer votre-cle-api" \
  -F "[email protected]"

La validation vérifie la conformité XSD (schéma CII) et les règles Schematron EN16931. Les couches PDF/A-3 et structure Factur-X ne s’appliquent pas pour un XML pur.

Branche 3 : si UBL XML reçu

Le format UBL (Universal Business Language) est l’autre syntaxe acceptée par EN16931. Le traitement est identique à la branche CII : envoyez le fichier XML directement à /validate. L’API détecte automatiquement la syntaxe (CII ou UBL) à partir du namespace du document.

curl -X POST https://api.facturxapi.com/api/v1/validate \
  -H "Authorization: Bearer votre-cle-api" \
  -F "[email protected]"

Validation : les niveaux de contrôle

Quel que soit le format d’entrée, la validation vérifie les niveaux de conformité applicables :

Niveau	Factur-X PDF	CII XML pur	UBL XML pur
PDF/A-3 (ISO 19005-3)	Oui	N/A	N/A
Structure Factur-X (`AFRelationship`, XMP)	Oui	N/A	N/A
XSD (schéma structurel)	Oui (CII D22B)	Oui (CII D22B)	Oui (UBL 2.1)
Schematron EN16931 (règles métier BR-*)	Oui	Oui	Oui

Un document qui passe les couches structurelles peut échouer au Schematron. Un XML structurellement parfait (XSD valide) peut contenir des incohérences métier détectées uniquement par les règles BR-*. C’est la source de la majorité des erreurs en production. Pour comprendre la différence entre validation XSD et Schematron, voir Valider EN16931/Factur-X : XSD vs Schematron, erreurs BR-*.

Si vous n’avez pas utilisé le paramètre validate=true à l’extraction (branche 1), validez le PDF séparément :

curl -X POST https://api.facturxapi.com/api/v1/validate \
  -H "Authorization: Bearer votre-cle-api" \
  -F "[email protected]"

La réponse indique si le document est conforme et liste les erreurs et avertissements avec leurs codes BR-* :

{
  "valid": false,
  "errors": [
    {
      "rule": "BR-CO-10",
      "message": "La somme des montants nets des lignes ne correspond pas au total HT"
    }
  ],
  "warnings": [],
  "profile": "EN16931",
  "message": "Validation completed"
}

Si valid est false, la facture ne doit pas être intégrée automatiquement. Elle entre dans un workflow de traitement manuel ou de rejet.

Étape 3 : mapper vers le plan comptable

Le XML CII utilise le modèle sémantique EN16931, organisé en Business Terms (BT) et Business Groups (BG). Chaque BT correspond à un champ comptable exploitable :

Business Term	Description	Usage comptable
BT-112	Montant TTC	Montant à lettrer sur le compte fournisseur
BT-110	Montant total TVA	TVA déductible à ventiler
BT-109	Montant total HT	Base HT, répartition par compte de charge
BT-151	Catégorie TVA par ligne	Ventilation par taux (20%, 10%, 5.5%, 2.1%)
BT-2	Date de facture	Date de la pièce comptable
BT-1	Numéro de facture	Référence pièce
BT-30	Identifiant légal vendeur (SIRET)	Identification du tiers fournisseur

Cette transformation est entièrement côté client. L’API retourne le XML brut ; votre logiciel parse les XPaths CII pour extraire chaque Business Term et le mapper vers les champs de votre modèle comptable. La cartographie complète des BT avec leurs XPaths CII est dans Champs obligatoires EN16931 : cartographie et mapping ERP. Pour choisir le profil qui garantit la présence des champs nécessaires, voir Profils Factur-X : MINIMUM vers EXTENDED.

Cas fréquent : le fournisseur envoie un Factur-X invalide

Ce scénario n’est pas hypothétique. Les analyses de validation montrent que tous les émetteurs ne produisent pas des factures conformes. Un ERP mal configuré, un module de génération Factur-X avec un bug, un profil trop bas pour les champs requis — les causes sont variées et documentées dans la communauté open source (Odoo, Dolibarr, Invoice Ninja).

Quand votre pipeline détecte une facture invalide, trois options se présentent :

Option 1 : rejeter via la PDP. La PDP permet de renvoyer un statut de rejet avec un motif. Le rapport de validation structuré (liste des erreurs BR-* avec description) sert de justification technique. C’est l’option la plus propre : le fournisseur est notifié, il corrige et réémet.

Option 2 : signaler au fournisseur hors circuit PDP. Si le rejet PDP n’est pas encore implémenté, vous pouvez joindre le rapport de validation dans un email au fournisseur. Le rapport liste chaque erreur avec le code de règle, le champ concerné et une description lisible — c’est exploitable par l’éditeur logiciel du fournisseur pour corriger la génération.

Option 3 : traitement dégradé avec alerte. Dans certains cas, les données du XML sont exploitables malgré des erreurs de conformité mineures (un avertissement sur un champ optionnel, un profil détecté comme BASIC alors qu’EN16931 est attendu). Le logiciel peut intégrer les données disponibles en signalant explicitement les anomalies au comptable pour revue manuelle. Cette option est un compromis — elle ne doit jamais être le comportement par défaut pour des erreurs sur des champs critiques (montants, TVA, identification).

Pour les éditeurs de logiciels comptables

Si vous développez un logiciel de comptabilité ou de gestion utilisé par des cabinets, la réception obligatoire est une opportunité produit. Voici comment l’exploiter.

Intégrer le pipeline de validation dans votre SaaS

L’intégration technique est directe : un appel à /extract?validate=true pour chaque facture Factur-X entrante (ou directement /validate pour un CII/UBL XML pur). Le coût est de 2 unités de quota par document pour extraction + validation combinées, 1 unité pour une validation seule. Pour un cabinet traitant 500 factures reçues par mois, c’est 500 à 1 000 unités selon le mix de formats.

Le flux dans votre application :

La facture arrive depuis la PDP (webhook ou polling)
Votre backend identifie le format (PDF → /extract?validate=true, XML pur → /validate)
Si valid: true : intégration automatique dans la comptabilité, voyant vert dans l’interface
Si valid: false : mise en quarantaine, voyant rouge, affichage des erreurs, bouton de rejet PDP

Le scan de conformité comme feature différenciante

La validation systématique des factures reçues n’est pas encore une pratique répandue dans les logiciels comptables. La plupart extraient le XML et intègrent les données sans vérification approfondie. Proposer un indicateur de conformité sur chaque facture entrante — un voyant vert/rouge avec le détail des erreurs — positionne votre logiciel comme celui qui protège le cabinet contre les factures fournisseurs défectueuses.

C’est un argument commercial tangible : “votre logiciel détecte les factures non conformes avant qu’elles n’entrent dans la comptabilité”. Pour un cabinet qui gère des centaines de dossiers, éviter une seule écriture comptable fausse justifie l’investissement.

Automatiser la boucle extraction-validation-intégration

Le scénario idéal vu par le comptable dans votre logiciel :

Ouvrir le dossier client → voir la liste des factures reçues ce mois
Chaque facture affiche son statut de conformité (conforme, erreurs, en attente)
Cliquer sur une facture conforme → les écritures comptables sont pré-remplies à partir du XML
Cliquer sur une facture en erreur → voir le rapport de validation, décider de rejeter ou traiter manuellement
Tableau de bord : taux de conformité par fournisseur, tendances, alertes sur les fournisseurs récurrents

Ce workflow transforme la contrainte réglementaire en gain de productivité. L’extraction automatique des données XML réduit la ressaisie manuelle, et la validation bloque les erreurs avant qu’elles ne polluent la comptabilité.

Erreurs fréquentes et fiches de diagnostic

« No Factur-X XML found » — PDF fournisseur sans XML embarqué
Profil GuidelineID — URN obsolète sur un Factur-X ancien
Namespace CII — URI incorrecte — mélange UBL/CII fréquent chez les petits fournisseurs
Format date 102 — ISO 8601 au lieu de yyyymmdd
Séparateur décimal — virgule sur montants français

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 "[email protected]"

10 opérations gratuites par mois, sans carte bancaire. Obtenir une clé API.

Aller plus loin

Cet article couvre le volet réception et validation. Voici les ressources complémentaires par sujet.

Contexte réglementaire :

Facturation électronique 2026 : le guide technique complet pour développeurs — architecture PDP, formats, calendrier
Checklist développeur : préparer la réception obligatoire du 1er septembre 2026 — tous les items techniques à livrer

Extraction et mapping :

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
Profils Factur-X : MINIMUM vers EXTENDED — matrice de choix du profil

Validation :

Valider EN16931/Factur-X : XSD vs Schematron, erreurs BR-* — debug des erreurs Schematron
Catalogue des erreurs BR-* EN16931 — référence de chaque règle
KoSIT, Mustangproject ou API SaaS — choix du validateur

Par ERP :

Odoo et Factur-X — configuration et erreurs courantes
Dolibarr et Factur-X 2026 — module et intégration API

Besoin de valider les factures reçues par vos clients ? L’API FacturX exécute extraction XML et validation 4 niveaux (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