Acompte, auto-facture, affacturage en Factur-X : types et champs

Les ERP « volume » (intérim, services) n’émettent pas que des factures 380. Ils enchaînent acomptes, auto-factures, parfois affacturage. Le XML Factur-X doit porter le bon type, les bonnes références et le bon sens des parties — sinon le destinataire lit une facture classique là où le métier a versé un acompte.

Périmètre : champs et types documentaires. Pas le cycle de vie plateforme (déposée, rejetée, encaissée).

En bref

• Distinguez le type de document, les parties métier et la personne qui établit la facture.
• Conservez les références réelles de l’opération et des factures d’acompte pour les reprendre dans la facture finale.
• Auto-facture : l’acheteur établit la facture pour le fournisseur ; les rôles vendeur et acheteur restent ceux de l’opération.
• Affacturage : lorsque le règlement doit être versé au factor, mappez-le en payee BG-10 (pas buyer, pas seller, pas un rôle « payeur » EN16931).
• Totaux et acomptes déjà versés doivent rester arithmétiquement cohérents.

Ce qui change dans le XML

Les codes exacts UNTDID dépendent de votre table de mapping — figez-la dans le dépôt, ne la laissez pas orale.

Acompte et lien vers le solde

Conservez les références de commande ou de contrat lorsqu’elles existent, puis les numéros et dates des factures d’acompte émises. La facture finale peut ainsi reprendre les acomptes concernés selon la méthode et le profil retenus. N’inventez pas un numéro de facture finale future pour renseigner la facture d’acompte.

La fiche FNFE-MPE sur les acomptes distingue notamment la reprise en ligne, la reprise en pied et le traitement par avoir d’acompte. Le mapping doit suivre la méthode choisie : le montant de l’acompte ne va pas systématiquement dans le seul champ « déjà payé » BT-113.

Auto-facture : émission par l’acheteur, rôles métier conservés

En autofacturation, l’acheteur établit la facture au nom du fournisseur dans le cadre d’un mandat. Le fournisseur reste le vendeur BG-4 et l’acheteur reste BG-7, même si le sens d’émission change. La fiche FNFE-MPE sur l’autofacturation distingue ces rôles et le circuit d’échange.

Dans le XML CII, conservez le vendeur dans SellerTradeParty et l’acheteur dans BuyerTradeParty. Le binding CII EN16931 rattache les contrôles du nom vendeur et du nom acheteur à ces éléments respectifs.

Dans vos tests de mapping, comparez les identifiants des deux parties à une fixture métier de référence. Une permutation doit faire échouer ce test de mapping : ne supposez pas qu’un contrôle XSD ou Schematron détectera à lui seul une identité commerciale mal affectée. Ces vérifications documentaires ne prouvent ni le mandat ni l’acceptation par une PA.

Affacturage : factor → payee seulement s’il est bénéficiaire

L’affacturage ne rend pas automatiquement le factor payee. Lorsque le règlement doit être versé au factor, mappez-le comme payee BG-10 (payee.name BT-59, payee.identifier BT-60). Sinon, ne forcez pas un BG-10 fictif.

Dans tous les cas, le factor n’est ni le buyer documentaire, ni le seller, ni un rôle « payeur » EN16931.

Séparez :

• parties documentaires (seller / buyer métier — inchangées) ;
• payee / factor (BG-10) seulement quand les fonds vont au factor (et non au seller) ;
• compte crédité : payment.iban ou payment.account_proprietary_id (BT-84), éventuellement payment.account_name (BT-85) et payment.bic (BT-86).

Ne mappez jamais l’IBAN du factor sur payment.debtor_account_iban (BT-91) : BT-91 est le compte débité en prélèvement (acheteur), pas le compte crédité du bénéficiaire.

Pour un éventuel payer / EXT-FR-FE-BG-02 : ne l’inventez pas dans le JSON — ne documentez et n’envoyez que les chemins présents dans le schéma ErpInvoiceData vendorisé (x-api-commit de la doc).

Totaux et acomptes déjà versés

Pour contrôler les totaux documentaires, distinguez trois égalités EN16931 :

• BR-CO-13 : BT-109 = BT-106 - BT-107 + BT-108 — total HT = somme des lignes nettes − remises documentaires + charges documentaires.
• BR-CO-15 : BT-112 = BT-109 + BT-110 — total TTC = total HT + TVA.
• BR-CO-16 : BT-115 = BT-112 - BT-113 + BT-114 — montant dû = total TTC − montant déjà payé + arrondi.

Ces relations figurent dans les règles CII EN16931. BT-113 représente un montant déjà payé ; son utilisation dépend du traitement documentaire retenu. Ne déduisez pas une seconde fois en pied un acompte déjà repris dans les lignes.

Exemple arithmétique, lorsque le paiement est porté en BT-113 : lignes nettes de 1 000,00 €, remise documentaire de 50,00 €, charge documentaire de 10,00 € et TVA de 192,00 €. Le total HT vaut 960,00 € et le TTC 1 152,00 €. Avec 300,00 € déjà payés et un arrondi de +0,02 €, le montant dû est 852,02 €. Cet exemple de totaux ne constitue pas une facture complète ni une preuve de conformité France CTC.

Un écart doit être rattaché à la règle et aux valeurs réellement contrôlées. Il ne suffit pas d’annoncer un rejet générique « BR-CO-* » : vérifiez également les règles d’arrondi et le profil exécuté.

Jeu de cas volume (intérim) pour un Sprint

1. Facture classique 380.
2. Facture finale reprenant les références des factures d’acompte selon la méthode choisie.
3. Auto-facture : vérifier que le fournisseur reste vendeur et que l’acheteur reste acheteur.
4. Avoir sur facture 380.
5. Cas négatif : permuter les identifiants vendeur/acheteur et vérifier que le test de mapping les distingue de la fixture métier de référence.

Limites

• Pas de workflow PA (déposée / rejetée / encaissée).
• Preuve packs : /meta.

— Équipe FacturX API