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 PA. Versions : /meta.
En bref
- Facture / avoir / acompte / auto-facture changent le type et parfois le sens seller/buyer.
- L’acompte doit pointer vers le solde (référence) sous peine de litiges de rapprochement.
- Auto-facture : inversion documentaire des parties — à tester avec fixtures dédiées.
- Affacturage : distinguer payeur et destinataire documentaire.
- Totaux et acomptes déjà versés doivent rester arithmétiquement cohérents.
Ce qui change dans le XML
| Cas | Idée documentaire | Point de vigilance |
|---|---|---|
| Facture | Type 380 | Baseline |
| Avoir | Type 381 + ref facture | Sens des montants |
| Acompte | Type adapté + ref future / contrat | Lien vers le solde |
| Auto-facture | Inversion seller/buyer | Qui « émet » dans le XML |
| Affacturage | Payeur ≠ destinataire doc | Ne pas écraser le buyer métier |
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
Sans référence stable (numéro de commande, contrat, facture finale attendue), le destinataire ne peut pas rapprocher. Le XML doit porter cette référence dans les BT prévus — pas seulement dans le PDF.
Auto-facture : inversion seller/buyer
En auto-facture, le destinataire « écrit » la facture pour le compte du fournisseur. Dans le XML, seller/buyer basculent par rapport à une facture classique. Une fixture qui doit échouer si l’inversion est oubliée vaut de l’or en CI.
Affacturage : payeur vs destinataire documentaire
Le factor peut être payeur sans devenir le buyer EN16931. Séparez :
- parties documentaires (seller/buyer métier) ;
- instructions de paiement (IBAN, destinataire des fonds).
Totaux et acomptes déjà versés
Les acomptes déjà versés apparaissent dans les totaux / prepaid. Vérifiez :
somme lignes + taxes - acomptes = montant dû
Un écart d’un centime est un BR-CO-* en production.
Jeu de cas volume (intérim) pour un Sprint
- Facture classique 380.
- Acompte puis solde avec référence croisée.
- Auto-facture avec inversion correcte.
- Avoir sur facture 380.
- Mutant : auto-facture sans inversion (doit échouer).
Limites
- Pas de workflow PA (déposée / rejetée / encaissée).
- Preuve packs :
/meta.
— Équipe FacturX API
Continuer la lecture
Articles liés
Pourquoi deux validateurs donnent des verdicts différents sur la même facture
Même XML, trois verdicts : versions de Schematron, agrégation des warnings, identifiants différents pour la même règle. Comment trancher avec le validateur ITB de la Commission et un corpus à recettes signées.
Lire l’article →Valider vos factures EN16931/Factur-X dans votre CI (GitHub Actions)
Ajouter la validation EN16931 1.3.16 (CII et UBL) dans GitHub Actions : cinq lignes de YAML, codes BR-* lisibles, fixtures qui doivent échouer. Sans Java local, sans compiler de Schematron.
Lire l’article →Pourquoi valider une facture électronique ne se résume pas à « valide / invalide »
Une facture peut être lisible, réparable ou générable sans être prête à transmettre. Découvrez les neuf niveaux d’un diagnostic documentaire fiable.
Lire l’article →Étape suivante recommandée
Vous industrialisez acomptes et auto-factures dans l'ERP.
Voici ce que vous allez obtenir :
- Figer la table des types UNTDID
- Ajouter refs acompte→solde
- Fixture auto-facture + mutant
- Brancher validate en CI