SSolarc Labs

XP Z12-013 · API ERP → PA

API facturation électronique XP Z12-013 : connecter un ERP à une Plateforme Agréée

La DGFiP référence la norme AFNOR XP Z12-013 pour les API qui interfacent les systèmes d’information des entreprises avec les plateformes agréées. Ce cadre donne un vocabulaire commun au projet, mais il ne remplace pas le contrat technique de la PA réellement choisie. Une intégration robuste sépare donc les exigences de la réforme, le modèle interne de l’ERP, le contrôle avant envoi et l’adapter fournisseur qui porte l’authentification, les endpoints, les reçus et les règles de réconciliation.

Revu le 2026-09-01•Sources officielles DGFiP

01

Placer un gate déterministe avant l’effet externe

Avant toute soumission, liez la charge utile à une empreinte, vérifiez que le preflight requis est réellement clair et résolvez le destinataire sans deviner. Le gate doit échouer si une information nécessaire manque. Cette étape empêche un connecteur de transformer silencieusement un document non contrôlé en tentative externe et crée un point d’audit simple pour expliquer pourquoi une facture n’est jamais partie.

  • Hash exact du payload envoyé.
  • Statut de validation requis et explicite.
  • Route unique : absence ou ambiguïté bloque la tentative.

02

Relier XP Z12-013 au contrat API réel de la PA

XP Z12-013 couvre l’interface entre les systèmes d’information des entreprises et les plateformes agréées dans le corpus de normes référencé par la DGFiP. Pour l’implémentation, l’authentification, mTLS ou OAuth, les URLs, versions, codes d’erreur, limites et formats de reçus restent des propriétés du prestataire et du contrat réellement souscrit. Placez ces détails dans un adapter versionné : le domaine métier ne doit ni inventer une API universelle, ni traiter une sandbox comme une preuve de production.

  • Nommer la version XP Z12-013 utilisée comme référence de projet.
  • Versionner séparément le contrat et les endpoints de la PA choisie.
  • Conserver des fixtures provider-specific pour erreurs, reçus et changements de version.

03

Idempotence, reçus et réconciliation

Une tentative doit avoir une clé stable liée au payload, au routage et au contrat. Les événements du fournisseur doivent être corrélés et dédupliqués. Surtout, un timeout après une possible écriture doit produire un état `UNKNOWN_EXTERNAL` plutôt qu’un retry automatique. La réconciliation utilise ensuite un reçu ou statut autoritatif pour décider si le flux a réellement avancé. Cette logique protège contre les doublons et les faux succès.

  • Retry borné uniquement pour les erreurs réellement transitoires.
  • Événement dupliqué identique = replay ; même ID avec contenu différent = anomalie.
  • Succès de production uniquement sur preuve du fournisseur autorisé, jamais sur sandbox locale.

É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.

Lire le brief intégrateur

Sources 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é.