FacturX API n'est pas une Plateforme Agréée : preflight avant PA

FacturX API sert à détecter, réparer ou compléter les erreurs documentaires Factur-X avant que la facture n’entre dans le circuit officiel de transmission.

Ce n’est pas une Plateforme Agréée, et ce n’est pas une Solution Compatible à lui seul. Son rôle est plus précis : préparer techniquement le document, PDF/A-3, XML CII, profil Factur-X, règles EN16931 et contrôles France CTC lorsqu’ils sont exécutés, avant remise à l’architecture PA / SC choisie par le client.

Cette frontière est importante : FacturX API réduit le risque de rejet documentaire, mais ne transmet pas officiellement la facture, ne fait pas d’e-reporting et ne promet pas un verdict fiscal final.

En bref

• FacturX API travaille sur le document : PDF/A-3, XML CII, profil Factur-X, EN16931, France CTC quand le profil est exécuté.
• FacturX API ne transmet pas officiellement les factures.
• FacturX API ne remplace pas la Plateforme Agréée choisie dans l’architecture client.
• FacturX API ne garantit pas l’acceptation finale d’un flux transmis.
• La transmission officielle, l’e-reporting et la réception pour compte client restent dans le périmètre des Plateformes Agréées et des composants habilités de l’architecture.

Le schéma cible

Pour un éditeur ERP, un intégrateur ou un logiciel métier, le schéma sain ressemble à ceci :

ERP / logiciel métier
  -> FacturX API
      scan
      convert
      repair
      validate
      rapport de validation documentaire
      profils appliqués
      artefacts exécutés
      diff de réparation, si disponible
  -> Solution Compatible de l'architecture client, si applicable
  -> Plateforme Agréée choisie pour la transmission officielle
  -> PPF / administration selon le circuit applicable

La frontière est volontairement nette. FacturX API améliore le document avant sa remise au flux officiel. La Plateforme Agréée opère la transmission officielle et les obligations associées.

Ce que dit le cadre officiel

La page impots.gouv.fr sur les Plateformes Agréées décrit leur rôle dans l’émission, la transmission, la réception des factures électroniques et la transmission de données à l’administration.

La même page distingue aussi une solution compatible non immatriculée d’une Plateforme Agréée : sans immatriculation, un opérateur n’a pas la qualité de PA et n’est pas autorisé à assurer les fonctionnalités réservées à cette dernière. Ce point est important pour les équipes qui parlent encore d’ex-PDP : le vocabulaire a changé, mais la frontière entre brique logicielle et plateforme habilitée reste structurante.

La page economie.gouv.fr Tout savoir sur la facturation électronique pour les entreprises rappelle le calendrier et le principe de transmission via une Plateforme Agréée, directement ou au travers d’une Solution Compatible.

FacturX API doit donc se présenter comme une brique documentaire amont, pas comme l’acteur qui opère la transmission réglementaire.

Ce que FacturX API fait

Scanner un document

Le scanner répond à la question :

Qu'est-ce qui ne va pas dans ce fichier ?

Il peut séparer :

• le conteneur PDF/A-3 ;
• la présence du XML Factur-X ;
• la structure XML ;
• les règles EN16931 ;
• les profils appliqués ;
• les erreurs réparables ;
• les données métier nécessaires, lorsqu’elles ne peuvent pas être déduites sans ambiguïté du document ;
• les cas où le résultat reste non conclusif.

Voir Lire un rapport de scan Factur-X.

Convertir un PDF ERP en Factur-X

Quand l’ERP possède déjà un PDF lisible mais pas un XML CII complet, FacturX API peut construire le document Factur-X à partir du PDF et de invoice_data JSON.

Le point critique : l’API ne doit pas inventer la facture. Les données métier viennent de l’ERP.

Le pipeline Convert porte aussi les problèmes d’enveloppe Factur-X : génération du PDF/A-3, association du XML et production d’un document hybride exploitable à partir d’un PDF ERP.

Voir Convertir un PDF ERP en Factur-X sans réécrire l’export.

Réparer un XML non conforme

Le endpoint Repair travaille sur un XML Factur-X / CII et renvoie un XML corrigé. Une réparation acceptable est traçable et limitée :

• normaliser une devise ;
• corriger un format de date ;
• corriger une valeur structurée lorsque la source est non ambiguë ;
• corriger une règle EN16931 réparable sans décision métier ;
• revalider après correction.

Une réparation ne doit pas inventer :

• un régime TVA ;
• une raison d’exonération ;
• un acheteur ;
• un SIRET ;
• un montant contradictoire ;
• une décision métier.

Voir Moteur de réparation EN16931 vs validateur Factur-X.

Valider un document selon des profils explicites

Le rapport doit dire :

{
  "appliedValidationProfiles": ["facturx_en16931_base"],
  "skippedValidationProfiles": [
    {
      "profile": "fr_ctc",
      "reason": "not_executed_in_this_run"
    }
  ],
  "unsupportedValidationProfiles": []
}

Ce JSON est un exemple de réponse simplifiée. Dans l’interface, la règle de confiance est simple : le libellé affiché doit refléter les profils réellement exécutés.

Si France CTC n’est pas dans appliedValidationProfiles, l’interface ne doit pas dire que le document a été contrôlé France CTC.

Ce que FacturX API ne fait pas

Encadré anti-confusion

À écrire :

• “validation documentaire”
• “préparation technique avant transmission par la PA”
• “profil appliqué”
• “artefacts exécutés”
• “erreurs réparables ou données métier nécessaires”

À éviter :

• vocabulaire de certification externe non obtenue ;
• formulation laissant croire à une transmission administrative ;
• formulation laissant croire que la PA est remplacée ;
• promesse de verdict final sur tous les flux ;
• promesse fiscale globale ;
• attribution du statut SC à la seule brique FacturX API.

Cette discipline de wording protège le produit et le client. Elle rend aussi l’intégration plus crédible pour les éditeurs ERP qui doivent expliquer leur architecture à leurs propres clients.

Exemple concret

Un ERP BTP génère déjà des PDF propres, mais ses Factur-X échouent sur des problèmes documentaires récurrents :

• GuidelineID incohérent ;
• XML absent ou mal attaché ;
• SIREN acheteur non propagé ;
• calcul de TVA arrondi différemment entre ERP et XML.

Sans preflight, l’erreur apparaît tard, dans le connecteur PA, chez le client, ou dans un retour de support difficile à diagnostiquer.

Avec FacturX API, l’ERP dispose, pour les contrôles documentaires exécutés, d’un diagnostic avant transmission :

• ce qui passe dans le périmètre testé ;
• quelles corrections déterministes sont proposées ;
• quelles données métier restent nécessaires ;
• ce qui reste hors périmètre, notamment la transmission officielle et le verdict de Plateforme Agréée.

Pourquoi cette brique reste utile

Ne pas être PA ne réduit pas la valeur du produit. Au contraire, cela précise le rôle :

Avant FacturX API :
  l'erreur documentaire apparaît tard, souvent après intégration PA.

Avec FacturX API :
  l'ERP détecte, répare ou complète le document avant de le remettre au flux officiel.

La valeur pour un éditeur ERP vertical :

• moins de support sur les erreurs PDF/A-3, CII et Schematron ;
• des rapports lisibles par l’équipe produit et l’équipe support ;
• des exemples de non-régression sur les cas clients ;
• un chemin clair entre “corrigeable automatiquement” et “donnée métier nécessaire” ;
• une intégration compatible avec plusieurs architectures PA / SC.

Quelle action choisir ?

Comment le présenter dans une offre ERP

Le message le plus juste est :

Notre ERP utilise FacturX API pour préparer et contrôler techniquement les documents Factur-X avant leur remise au circuit de transmission officiel géré par la Plateforme Agréée retenue.

Ce message ne promet pas une habilitation que le produit ne porte pas. Il explique pourtant la valeur concrète : moins d’erreurs documentaires, des corrections tracées, et un document plus propre avant le flux officiel.

Articles liés

• Preflight Factur-X en amont d’une Plateforme Agréée
• Scanner une facture Factur-X avant envoi via une Plateforme Agréée
• Facture rejetée par une Plateforme Agréée : workflow développeur