Une facture affacturée met en jeu deux paiements distincts : l’avance que le factor verse au fournisseur dès la cession de la créance, puis le règlement que le client effectue à l’échéance entre les mains du factor. Pour les prestations de services soumises à la TVA sur les encaissements, seul le second compte fiscalement. L’avance du factor n’est pas l’encaissement à déclarer en e-reporting : le statut « Encaissée » doit correspondre au paiement effectif du débiteur. Confondre financement de la créance et encaissement fiscal, c’est déclarer une TVA exigible au mauvais moment, sur le mauvais montant.
L’autre point que les entreprises découvrent souvent trop tard, détaillé sur Ma Facture Électronique : la réforme n’intègre pas automatiquement le factor dans le circuit des plateformes agréées. La facture circule réglementairement entre la plateforme du fournisseur et celle de l’acheteur. Le partage de la facture et de ses statuts avec le factor dépend des fonctionnalités de la plateforme choisie, du portail du factor ou d’une intégration API ou EDI spécifique. Avant septembre 2026, la question n’est donc pas « suis-je conforme ? » mais « mon logiciel, ma plateforme agréée, mon factor et ma comptabilité savent-ils traiter le même flux ? ».
Facturation électronique et affacturage : ce qui change réellement
La réforme standardise la facture et sécurise son acheminement, mais elle ne remplace ni le contrat d’affacturage ni le circuit de remise des créances au factor. Quatre questions structurent le sujet, et leurs réponses tiennent en une ligne chacune.
La facture doit-elle toujours être envoyée au client ? Oui. La cession de créance ne change rien à l’obligation de transmettre la facture électronique à l’acheteur via les plateformes agréées.
Qui doit être désigné comme bénéficiaire du paiement ? Le factor, dès lors que la cession est notifiée. La norme prévoit un bloc dédié pour identifier ce bénéficiaire distinct du vendeur.
Le factor reçoit-il automatiquement une copie de la facture ? Pas nécessairement. La réplication de la facture et de ses statuts vers l’affactureur relève des fonctionnalités de chaque plateforme, pas du socle réglementaire obligatoire. Les cas d’usage décrits par l’AFNOR constituent un référentiel fonctionnel que les plateformes agréées ne sont pas tenues de couvrir intégralement.
Qui transmet le statut d’encaissement à l’administration ? En principe le fournisseur, via sa plateforme agréée. Les spécifications de la DGFiP prévoient que la transmission du flux de e-reporting des données de paiement peut suivre deux options, selon les accords commerciaux entre le fournisseur et le factor : soit le factor informe le fournisseur qui déclare, soit une organisation déléguée est mise en place.
Le circuit complet se lit ainsi :
1. Fournisseur → facture électronique → Client2. Fournisseur → facture cédée → Factor3. Factor → avance de trésorerie → Fournisseur4. Client → paiement à l’échéance → Factor5. Factor → information d’encaissement → Fournisseur / plateforme6. Plateforme → e-reporting de paiement → Administration
Trois flux cohabitent : le flux de facture (1), le flux de financement (2 et 3) et le flux de paiement (4 à 6). Ils ne sont pas identiques, ne transitent pas par les mêmes canaux et n’obéissent pas aux mêmes règles. La plupart des blocages viennent d’un système d’information qui les traite comme un seul.
Les quatre situations d’affacturage à distinguer
Parler « d’affacturage » au singulier est le premier piège. La norme AFNOR XP Z12-014 distingue plusieurs configurations, avec des traitements techniques différents. Traiter un affacturage confidentiel comme une cession notifiée, ou une subrogation postérieure comme un cas n°8, produit des factures non conformes ou des paiements mal orientés.
| Situation | Traitement |
|---|---|
| Factor connu avant l’émission | Cas AFNOR n°8 : le factor est directement indiqué comme bénéficiaire |
| Facture cédée après son émission | Cas n°10 : le bénéficiaire change après la création de la facture |
| Affacturage confidentiel | La cession ne doit pas être révélée au client |
| Affacturage inversé | Le dispositif est piloté par l’acheteur et ne suit pas le même circuit |
Cas n°8 : factor connu lors de la facturation
La facture naît affacturée. Le factor est identifié dès l’émission dans le bloc Bénéficiaire (BG-10), ses coordonnées de règlement figurent dans le bloc Virement, et le type de facture signale la cession. La clause de subrogation accompagne la facture pour informer juridiquement le débiteur. L’acheteur paie directement le factor, qui informe ensuite le vendeur de l’encaissement pour que celui-ci puisse transmettre le statut « Encaissée ».
Cas n°10 : cession après l’émission
Le vendeur a émis une facture commerciale classique, puis cède la créance. La subtilité : la facture initiale n’est pas modifiée. Le changement de bénéficiaire passe par un message de cycle de vie transmis à l’acheteur, avec l’identifiant du nouveau bénéficiaire, un code rôle « DL » désignant le factor, son adresse électronique et les nouvelles coordonnées bancaires (IBAN, titulaire, BIC). La norme distingue plusieurs statuts selon la configuration, dont le statut 225 pour une facture « affacturée » notifiée. Une modification silencieuse de l’IBAN dans l’ERP, sans notification structurée, laisse le client payer le fournisseur d’origine et expose au double paiement.
Affacturage confidentiel
L’acheteur ne doit pas savoir que la créance est cédée. Il continue de payer sur un compte présenté comme appartenant au fournisseur, mais domicilié ou contrôlé chez le factor. La norme prévoit un statut distinct (226) pour cette configuration, et les spécifications de la DGFiP précisent que seule une délégation du fournisseur sur son compte permet de garder le factor invisible aux yeux du client. Point critique à valider contractuellement : la plateforme doit garantir qu’aucune information de cycle de vie transmise au client ne révèle la cession. Toutes les plateformes ne gèrent pas ce cas de la même manière, et certaines ne le gèrent pas du tout.
L’affacturage inversé, enfin, inverse la logique : c’est l’acheteur qui met en place le programme et propose à ses fournisseurs un paiement anticipé. Le circuit documentaire part de la plateforme de l’acheteur, et les obligations du fournisseur s’en trouvent réduites. Il ne se paramètre pas comme un cas n°8.
Quelles données doivent apparaître dans une facture électronique affacturée ?
Une facture affacturée n’est pas une facture standard avec une mention en plus. Chaque information métier a son équivalent technique dans la norme, et c’est cet équivalent que les systèmes lisent.
| Information | Utilité | Donnée technique |
|---|---|---|
| Type de facture affacturée | Signaler que la créance est cédée | BT-3 |
| Identité du factor | Identifier le bénéficiaire du paiement | BG-10 |
| IBAN du factor | Orienter correctement le règlement | BG-17 / BT-84 |
| Clause de subrogation | Informer juridiquement le débiteur | BT-21 = ACC et BT-22 |
| Référence de la facture | Permettre le rapprochement | BT-1 |
| Adresse électronique du factor | Acheminer la facture ou ses statuts | Adresse de routage |
| Référence du contrat d’affacturage | Faciliter le traitement par le factor | Donnée contractuelle éventuelle |
Le type de document (BT-3) dispose de codes dédiés :
- 393 : facture affacturée ;
- 396 : avoir affacturé ;
- 501 : facture auto-facturée affacturée ;
- 502 : avoir auto-facturé affacturé ;
- 472 : facture rectificative affacturée ;
- 473 : facture rectificative auto-facturée affacturée.
Émettre une facture affacturée avec le code standard 380 constitue une erreur de conformité : la règle BR-FR-04 encadre les codes de type autorisés, et le factor comme la plateforme s’appuient sur cette donnée pour qualifier le flux.
La clause de subrogation obéit à la même logique. Elle doit être codée avec le code sujet ACC dans le champ structuré prévu, et pas seulement ajoutée en texte libre dans le PDF visible. Une mention décorative que l’œil humain lit mais qu’aucun système n’exploite ne déclenche ni le bon routage ni le bon traitement automatique.
Dernière précaution, technique mais décisive : certains codes de la norme restent assortis d’une réserve liée à leur intégration dans la maintenance de la norme européenne EN 16931. La bonne question à poser à sa plateforme n’est donc pas « êtes-vous compatible avec la norme ? » mais « quels codes acceptez-vous effectivement en production aujourd’hui ? ». La différence entre les deux réponses se découvre en général au premier rejet de flux.
Qui reçoit la facture et les statuts de traitement ?
Le client reçoit la facture pour la contrôler, la valider et la comptabiliser. Le factor, lui, finance une créance dont il doit suivre la vie complète : l’existence de la facture, sa transmission au client, son acceptation ou son refus, un éventuel litige, la création d’un avoir, le paiement transmis et l’encaissement effectif. Chacun de ces événements modifie la valeur ou le risque de la créance financée.
Or le réseau réglementaire n’assure pas cette réplication par défaut. Les échanges obligatoires relient la plateforme du fournisseur, celle de l’acheteur et l’administration. Le factor est un tiers dont l’alimentation en données relève d’une fonctionnalité métier : certaines plateformes proposent le partage de la facture et de ses statuts avec l’affactureur, d’autres exigent une connexion dédiée, un portail ou un export périodique. Un factor qui découvre un litige trois semaines après sa déclaration continue de financer une créance contestée, et le fournisseur en paiera le prix au moment de la régularisation.
La répartition des responsabilités mérite d’être écrite noir sur blanc :
| Action | Responsable principal |
|---|---|
| Création de la facture | Fournisseur |
| Transmission réglementaire | Plateforme agréée du fournisseur |
| Validation ou refus | Acheteur |
| Avance de trésorerie | Factor |
| Encaissement du règlement final | Factor |
| Information du fournisseur sur l’encaissement | Factor ou plateforme du factor |
| Transmission réglementaire du statut encaissé | Fournisseur ou délégataire autorisé |
La dernière ligne concentre le risque. Le fournisseur reste redevable du statut « Encaissée » alors que l’argent arrive sur le compte d’un tiers. Sans flux d’information organisé entre le factor et lui, ce statut sera transmis en retard, ou pas du tout.
Affacturage, TVA et e-reporting de paiement
Le e-reporting de paiement concerne les opérations dont la TVA devient exigible à l’encaissement : typiquement les prestations de services, lorsque l’entreprise n’a pas opté pour la TVA sur les débits et que l’opération n’est pas autoliquidée. Les données attendues comprennent le numéro de facture, la date et le ou les montants encaissés, ventilés par taux de TVA, transmises par le fournisseur à sa plateforme agréée. L’affacturage complique mécaniquement l’exercice, puisque celui qui encaisse n’est pas celui qui déclare.
Un exemple chiffré rend la règle concrète. Une entreprise de services émet le 2 octobre une facture de 12 000 € TTC. Le 4 octobre, le factor lui avance 10 800 €. Le 15 novembre, le client verse 7 000 € au factor, puis les 5 000 € restants le 30 novembre.
Si l’entreprise n’a pas opté pour la TVA sur les débits, le traitement correct est le suivant : l’avance de 10 800 € du 4 octobre n’est pas un paiement du débiteur, elle ne déclenche rien fiscalement. L’encaissement de 7 000 € du 15 novembre doit être rattaché à la facture avec sa date réelle, le solde de 5 000 € du 30 novembre également. La base de TVA exigible reste liée à la créance payée par le client, et non au montant net perçu après déduction des commissions du factor. Déclarer 10 800 € encaissés le 4 octobre reviendrait à anticiper l’exigibilité sur un flux de financement, avec un montant faux.
| Opération | E-reporting de paiement |
|---|---|
| Vente de marchandises classique | Généralement non |
| Prestation de services avec TVA à l’encaissement | Oui |
| Prestation avec option TVA sur les débits | Non au titre de l’encaissement |
| Paiement partiel du client au factor | Oui, pour le montant réellement payé |
| Avance financière du factor | Non |
| Acompte soumis à TVA à l’encaissement | Oui |
Reste la question opérationnelle : qui déclare le paiement en affacturage ? Le principe est que le fournisseur transmet, via sa plateforme. Mais il ne peut transmettre que ce qu’il sait. Les spécifications prévoient deux organisations possibles selon les accords entre fournisseur et factor : soit le factor restitue l’information d’encaissement au fournisseur, qui déclare, soit le flux est organisé avec une délégation. Le contrat d’affacturage doit désormais préciser ce point, avec un délai de restitution compatible avec la périodicité du e-reporting.
Les erreurs qui peuvent bloquer le financement ou provoquer un mauvais paiement
Chaque erreur ci-dessous a une conséquence concrète : un financement refusé, un paiement sur le mauvais compte, une TVA déclarée à tort ou un contrat d’affacturage violé. Le contrôle associé se met en place avant septembre 2026, pas après le premier incident.
| Erreur | Conséquence possible | Contrôle à prévoir |
|---|---|---|
| Facture émise avec le code standard 380 | Facture mal qualifiée ou refusée par le factor | Vérifier le code 393 |
| IBAN du fournisseur conservé | Paiement sur le mauvais compte | Contrôle automatique du bénéficiaire |
| Clause de subrogation uniquement dans le PDF | Donnée non exploitable automatiquement | Utiliser le code ACC |
| Factor non informé d’un litige | Financement maintenu sur une créance contestée | Répliquer les statuts |
| Avoir non transmis au factor | Solde de créance erroné | Lier facture et avoir |
| Statut encaissé posé lors de l’avance | E-reporting et TVA incorrects | Attendre le paiement du débiteur |
| Subrogation postérieure non notifiée | Client susceptible de payer le fournisseur | Procédure cas n°10 |
| Affacturage confidentiel révélé | Violation du dispositif contractuel | Gestion séparée des statuts |
| Paiements partiels non rapprochés | Mauvais lettrage et mauvaise TVA | Rapprochement facture par facture |
Deux lignes méritent une attention particulière. Le statut encaissé posé lors de l’avance est l’erreur la plus probable, parce qu’elle paraît logique en trésorerie : l’argent est arrivé, donc la facture est payée. Fiscalement, elle est fausse. Et la subrogation postérieure non notifiée est la plus coûteuse : un client qui paie de bonne foi le fournisseur alors que la créance appartient au factor crée un contentieux à trois, avec restitution, retard et perte de confiance du financeur.
Les 12 questions à poser à sa plateforme agréée et à son factor
La question « êtes-vous compatible avec l’affacturage ? » n’apporte rien : tout le monde répond oui. La compatibilité se vérifie point par point, sur le circuit réel, avec le contrat d’affacturage sous les yeux.
- Gérez-vous les cas AFNOR n°8 et n°10 ?
- Acceptez-vous les codes 393, 396, 472, 473, 501 et 502 en production ?
- Le factor peut-il être renseigné comme bénéficiaire structuré (bloc BG-10) ?
- La clause de subrogation est-elle intégrée avec le code sujet ACC ?
- L’IBAN du factor remplace-t-il automatiquement celui du fournisseur ?
- Une copie de la facture est-elle transmise automatiquement au factor ?
- Les statuts de refus, litige, approbation et paiement sont-ils répliqués vers lui ?
- Le factor peut-il transmettre l’information d’encaissement à la plateforme ?
- Les paiements partiels sont-ils correctement gérés et rapprochés ?
- Les avoirs sont-ils transmis au factor et déduits de la créance ?
- L’affacturage confidentiel est-il pris en charge sans informer l’acheteur ?
- Existe-t-il déjà une intégration testée avec notre société d’affacturage ?
La méthode qui tranche : demander une démonstration du circuit complet sur un jeu de test, avec une facture affacturée, un rejet, un avoir et un paiement partiel. Une plateforme agréée compatible affacturage sur le papier peut échouer sur le rapprochement d’un paiement partiel ou la confidentialité d’une cession. Le test avant septembre 2026 coûte une demi-journée. Le même test grandeur nature, sur des créances financées, coûte du fonds de roulement.
Questions fréquentes
Le factor reçoit-il la facture électronique via les plateformes agréées ?
Pas automatiquement. Le circuit réglementaire relie la plateforme du fournisseur et celle de l’acheteur. La transmission de la facture et de ses statuts au factor dépend des fonctionnalités de la plateforme, d’un portail du factor ou d’une intégration dédiée. Ce point se vérifie et se contractualise.
L’avance du factor doit-elle être déclarée en e-reporting de paiement ?
Non. Pour les prestations soumises à la TVA sur les encaissements, seul le règlement effectif du débiteur au factor constitue l’encaissement à déclarer, à sa date réelle et pour le montant réellement payé. L’avance est un financement, pas un paiement de la créance.
Que se passe-t-il si une facture cédée après émission n’est pas notifiée au client ?
Le client risque de payer le fournisseur d’origine, alors que la créance appartient au factor. Le cas n°10 prévoit un message de cycle de vie qui informe l’acheteur du nouveau bénéficiaire et des nouvelles coordonnées bancaires, sans modifier la facture initiale. Sans cette notification structurée, le montage juridique et le circuit de paiement divergent.
L’affacturage confidentiel reste-t-il possible avec la facturation électronique ?
Oui, mais il exige un paramétrage spécifique. La norme prévoit un statut dédié, et le dispositif repose sur une délégation du fournisseur sur son compte pour que le factor reste invisible du client. Toutes les plateformes ne le prennent pas en charge : c’est une question éliminatoire à poser avant de signer.
