01
Reconnaître le document avant de le valider
La validation commence par une classification sûre de l’entrée. Un document CII doit être traité avec ses propres namespaces et règles, sans réutiliser par commodité des chemins conçus pour UBL. Cette séparation permet de produire des findings stables et d’éviter qu’une transformation implicite masque le fichier réellement livré par l’ERP. Le hash du document testé reste l’ancre de la preuve.
- Classifier CII explicitement.
- Appliquer les schémas et règles associés au profil testé.
- Conserver provenance du moteur, version et empreinte d’entrée.
02
Faire le lien avec le mapping source
Lorsqu’un terme métier est absent ou contradictoire, la question suivante est de savoir quelle donnée ERP devait l’alimenter. Un mapping source → terme métier rend ce diagnostic plus direct. Il doit lui-même être validé : deux champs sources qui revendiquent le même rôle de manière incompatible ou un champ obligatoire sans cible doivent rester visibles comme éléments de blocage ou de revue, plutôt que d’être résolus par supposition.
- Versionner la matrice de mapping avec le projet.
- Refuser les conflits explicites plutôt que choisir arbitrairement.
- Relier les lacunes de couverture au champ source quand c’est possible.
03
Tester les variantes de production, pas un exemple de laboratoire
Un seul fichier CII valide peut provenir d’un scénario très simple. La recette doit couvrir les variantes qui changent la forme ou les données : types de client, cas fiscaux, avoirs, branches, devises ou modules ERP réellement utilisés. Regroupez ensuite les findings par cause et re-testez la source après correction. Vous obtenez une mesure de risque de cutover plus utile qu’une validation ponctuelle.
- Constituer un corpus représentatif et minimisé.
- Séparer erreurs documentaires et problèmes systémiques.
- Garder le premier run immuable pour comparer la remédiation.
Étape suivante
Passer du guide à une vérification concrète.
InvoiceBatch FR reste un preflight technique de corpus : il ne remplace pas votre ERP ou votre Plateforme Agréée et ne constitue ni une certification ni une preuve de transmission.
Voir le parcours de preflightSources officielles
Ces sources cadrent les affirmations réglementaires de cette page. Les contrats et API d’une PA réelle doivent en plus être vérifiés auprès du fournisseur concerné.