Architecture préflight Factur-X pour ERP avant Plateforme Agréée

Un éditeur ERP n’a pas besoin de devenir Plateforme Agréée pour améliorer la qualité Factur-X de ses documents. Le bon emplacement pour FacturX API est en amont : entre le moteur de facturation de l’ERP et la PA choisie par le client final.

Ce pattern s’appelle ici “preflight Factur-X” : diagnostiquer, réparer ou convertir avant que le document n’entre dans le flux officiel.

En bref

• La PA reste la plateforme choisie par le client final.
• L’ERP garde son moteur métier et son PDF existant.
• FacturX API intervient comme brique technique : scan, repair, convert, validate.
• Les cas réparables sont traités automatiquement ; les champs métier manquants passent par invoice_data JSON.
• Le résultat est un Factur-X conforme EN16931 prêt à être remis dans le flux PA du client.

Architecture cible

ERP / logiciel métier
  ├─ données facture
  ├─ PDF lisible
  └─ règles métier sectorielles
        ↓
FacturX API
  ├─ scan / diagnostic
  ├─ repair si déterministe
  ├─ convert avec invoice_data JSON si besoin
  └─ validate avant sortie
        ↓
Factur-X conforme EN16931
        ↓
Plateforme Agréée choisie par le client final

FacturX API ne remplace pas la PA. Il prépare le document pour éviter de découvrir les erreurs trop tard.

Pourquoi ce preflight est utile

Sans preflight :

1. L’ERP produit une facture.
2. Le client final ou le connecteur la remet à sa PA.
3. Le document échoue.
4. Le support doit comprendre si le problème vient du PDF, du XML, du profil, de la TVA ou du mapping.
5. La correction est faite à chaud.

Avec preflight :

1. L’ERP produit une facture.
2. FacturX API scanne ou convertit.
3. Le document est revalidé.
4. Les erreurs récurrentes deviennent des règles ou fixtures.
5. La PA reçoit un document mieux préparé.

Le gain n’est pas seulement technique. C’est un gain de support, de confiance client et de prévisibilité avant les échéances 2026-2027.

Variante A : ERP qui génère déjà du Factur-X

Si l’ERP produit déjà un PDF Factur-X, le preflight peut être très simple :

PDF Factur-X ERP
  ↓
/validate ou /scan
  ↓
si invalide : /repair ou correction source
  ↓
Factur-X revalidé

Cas typiques :

• XMP incorrect ;
• PDF/A-3 non reconnu ;
• GuidelineID mal formé ;
• code unité non normalisé ;
• arrondi TVA incohérent ;
• SIRET ou IBAN absent.

Cette variante convient aux ERP qui ont déjà investi dans la génération Factur-X mais veulent fiabiliser la sortie.

Variante B : ERP qui génère un PDF mais pas le XML complet

C’est le cas où invoice_data JSON est le plus utile.

PDF ERP classique
  +
invoice_data JSON
  ↓
/convert
  ↓
PDF/A-3 + XML CII EN16931
  ↓
/validate

L’ERP n’a pas besoin d’implémenter tout le XML CII. Il fournit les données métier, et l’API construit la couche Factur-X.

À lire ensuite : Convertir un PDF ERP en Factur-X sans réécrire l’export.

Variante C : intégrateur multi-clients

Un intégrateur Dolibarr, Axelor ou ERP métier custom peut placer FacturX API comme brique commune à plusieurs projets.

Client A ERP custom ┐
Client B Dolibarr   ├─ normalisation interne ─ FacturX API
Client C Axelor     ┘

Le bénéfice est de mutualiser :

• diagnostic EN16931 ;
• gestion des profils ;
• artefacts Schematron ;
• cas de réparation ;
• reporting d’erreurs.

L’intégrateur garde son expertise métier client. FacturX API prend la couche document EN16931.

Points d’intégration à prévoir

1. Stocker l’artefact original

Conservez le PDF ou XML avant correction, au moins dans vos logs internes ou fixtures. Pour un produit stateless, l’API ne doit pas devenir votre archive.

2. Associer chaque erreur à une facture métier

Gardez le lien :

• invoice_id ERP ;
• client ;
• version de template ;
• profil attendu ;
• réponse API ;
• diff de réparation.

Ce lien permet d’identifier les erreurs récurrentes par template ou par type de facture.

3. Gérer le mode “bloquant” progressivement

Au démarrage, vous pouvez lancer le preflight en mode observation :

• scanner ;
• logguer ;
• afficher au support ;
• ne pas bloquer.

Puis passer en mode bloquant pour les erreurs qui doivent empêcher la sortie.

4. Ajouter des fixtures par cas réel

Chaque facture rejetée ou réparée doit devenir une fixture. C’est le moyen le plus simple d’éviter les régressions quand le template ERP change.

KPI à suivre

Ces KPI sont plus utiles qu’un simple nombre de validations.

Sources utiles

• Facturation électronique entre entreprises, calendrier officiel
• Facturation électronique et plateformes agréées
• Factur-X 1.08 / ZUGFeRD 2.4, FNFE-MPE
• Moteur de réparation EN16931 vs validateur Factur-X