Moteur de réparation EN16931 vs validateur Factur-X : diagnostic, repair, ERP

Un validateur répond à la question : “ce document passe-t-il les règles ?”
Un moteur de réparation répond à une question plus utile pour un éditeur ERP : “comment produire un document conforme sans réécrire tout mon pipeline ?”

Cette distinction est centrale. Le marché contient déjà des validateurs Factur-X, des bibliothèques open source et des outils de contrôle. Le manque opérationnel est ailleurs : transformer un PDF ou XML imparfait en Factur-X conforme EN16931, avec une correction traçable.

En bref

• Valider est nécessaire, mais ne résout pas le rejet.
• Une erreur peut venir du conteneur PDF/A-3, du XML CII, du profil, d’une règle Schematron ou d’une donnée ERP absente.
• Un moteur de réparation applique seulement des corrections déterministes et refuse d’inventer des données métier.
• Le diff avant/après est indispensable pour l’audit technique.
• Pour les éditeurs ERP et intégrateurs, la valeur se situe dans le passage “diagnostic → correction → revalidation”.

Ce que fait un validateur

Un validateur Factur-X contrôle un document contre un ensemble de règles :

• PDF/A-3 ;
• présence du XML embarqué ;
• XSD CII ou UBL ;
• Schematron EN16931 ;
• listes de codes ;
• règles de profil.

Sortie typique :

{
  "valid": false,
  "errors": [
    {
      "id": "BR-CO-14",
      "message": "Le total TVA doit correspondre à la somme des montants TVA par catégorie.",
      "location": "/rsm:CrossIndustryInvoice/..."
    }
  ]
}

C’est utile. Mais pour un éditeur ERP, ce n’est que le début du travail. Le validateur ne dit pas toujours :

• quelle erreur est la cause racine ;
• quelles erreurs sont des effets de cascade ;
• si la correction peut être automatisée ;
• si la donnée vient du PDF, du XML ou de l’ERP ;
• comment revalider après correction ;
• comment éviter que le même cas revienne.

Ce que fait un moteur de réparation

Un moteur de réparation prend le rapport de validation comme point de départ, puis applique une stratégie de correction encadrée.

Le moteur ne doit pas “deviner” une facture. Il doit savoir quand corriger et quand s’arrêter.

Les erreurs réparables

Une erreur est réparable automatiquement quand la transformation ne dépend pas d’une décision métier.

Exemples :

• date 2026-04-28 à convertir en 20260428 ;
• devise eur à normaliser en EUR ;
• séparateur décimal à corriger sous contrainte explicite ;
• namespace CII attendu ;
• métadonnées XMP Factur-X absentes ou incohérentes ;
• relation d’attachement PDF/XML incorrecte ;
• profil PDF/A-3 à réenvelopper.

Chaque changement doit être visible :

{
  "ruleReference": "R001",
  "path": "/rsm:CrossIndustryInvoice/rsm:ExchangedDocument/ram:IssueDateTime",
  "beforeValue": "2026-04-28",
  "afterValue": "20260428",
  "changeCategory": "correction"
}

Sans diff, une correction automatique est difficile à accepter dans un système ERP. Avec diff, elle devient vérifiable.

Les erreurs qui demandent l’ERP

Certaines erreurs ne doivent pas être corrigées par heuristique. Elles demandent une donnée que l’ERP connaît.

Exemples :

• SIRET acheteur absent ;
• IBAN absent ;
• motif d’exonération TVA ;
• lignes de facture incomplètes ;
• catégorie TVA mal choisie ;
• conditions de paiement ;
• numéro de facture définitif ;
• adresse pays acheteur ou vendeur.

FacturX API traite ces cas via invoice_data JSON dans le /convert : le client envoie le PDF produit par l’ERP et les champs business connus, sans réécrire entièrement son export XML.

Cette nuance change le coût d’intégration. Au lieu de reconstruire tout le pipeline Factur-X dans l’ERP, l’équipe peut ajouter un appel API qui combine le document existant avec les données métier.

Les erreurs à ne pas réparer automatiquement

Un bon moteur doit aussi refuser.

Cas à ne pas corriger automatiquement :

• total TTC et total HT contradictoires ;
• catégorie TVA incompatible avec le taux ;
• facture sans ligne réelle ;
• XML tronqué ;
• plusieurs vendeurs ou acheteurs possibles ;
• devise absente alors que plusieurs devises apparaissent dans le PDF ;
• taux d’autoliquidation déduit uniquement depuis un libellé ambigu.

La réparation automatique est utile précisément parce qu’elle est bornée. Si le moteur invente, il déplace le risque vers l’éditeur ERP.

Pourquoi cela compte en amont d’une PA

La PA choisie par le client final joue le rôle prévu par la réforme. FacturX API ne remplace pas cette PA. Son intérêt est de produire un document conforme EN16931 avant la remise dans ce flux.

Pour un éditeur ERP vertical, cela donne une architecture plus souple :

ERP / logiciel métier
  ↓
FacturX API : diagnostic, réparation, conversion
  ↓
Factur-X conforme EN16931
  ↓
Plateforme Agréée choisie par le client final

Le client final garde sa liberté de choix de PA. L’éditeur ERP garde la maîtrise de son export et évite une réécriture complète sous contrainte de calendrier.

Comment évaluer une solution

Questions à poser :

1. Le rapport sépare-t-il PDF/A-3, XML CII, XSD et Schematron ?
2. Les corrections sont-elles expliquées par un diff ?
3. Les corrections ambiguës sont-elles refusées ?
4. Le moteur accepte-t-il des données ERP séparées via JSON ?
5. La validation avant/après est-elle incluse ?
6. Le produit indique-t-il clairement ce qu’il ne fait pas : transmission officielle, archivage légal, rôle PA ?

Si la réponse est non, vous regardez probablement un validateur, pas un moteur de réparation.

Sources et articles liés

• Facturation électronique et plateformes agréées
• Factur-X 1.08 / ZUGFeRD 2.4, FNFE-MPE
• Build vs Buy : construire sa conformité Factur-X ou utiliser une API
• Corriger automatiquement un XML CII Factur-X invalide
• Intégrer la conformité Factur-X dans votre ERP en 3 jours