Use case 10: Factoring with subrogation (third party unknown at creation)
When the factor is unknown at invoice creation, the seller issues a standard invoice and later designates the factor using a CDAR lifecycle status (code 225 or 226).
Description
This use case covers the scenario where a Factor is not known at the time of invoice creation. The seller issues a standard invoice (type 380) to the buyer through the normal e-invoicing flow. The seller then contracts with a Factor and assigns the receivable through subrogation or assignment. Because the invoice has already been sent and cannot be modified, the Factor is designated through a lifecycle message (Flow 6 CDAR status) that informs the buyer of the new beneficiary and updated bank details.
This is a two-phase process: Phase 1 follows the standard invoice flow. Phase 2 begins when the seller decides to factor the invoice and uses lifecycle statuses to communicate the change to all parties. The buyer must then redirect payment to the Factor. The seller remains fully responsible for the Encaissee status creation.
- Key characteristics
Factor unknown at invoice creation; standard invoice (type 380) initially.
Subrogation or assignment happens after invoice transmission.
Lifecycle status Factored (code 225) designates Factor after transmission.
The CDAR message includes a new beneficiary (MDG-41) and new bank details (MDG-43).
Confidential factoring uses status code 226 (not sent to the buyer).
The seller still responsible for the Encaissee status.
The Factor changes during the invoice life is possible (new lifecycle message).
- Relationship to other use cases
Use case 10 is the post-transmission counterpart of use case 8, where Factor is known at creation. Use case 8 embeds Factor information directly in the invoice, and use case 10 uses lifecycle messages to achieve the same result after the invoice has been sent. The CDAR status mechanism (Factored, code 225) is unique to use case 10 and provides a standardized way to change payment destination without modifying the original invoice. Confidential factoring (code 226) is a specific variant where the buyer is not informed.
Business and tax context
- Legal and regulatory framework
-
The same legal basis as use case 8 applies for the factoring operation itself. The key difference is procedural: The subrogation or assignment occurs after the invoice has entered the e-invoicing system. The lifecycle message mechanism defined in XP Z12-012 (CDAR format) provides the standardized means to communicate the change of beneficiary.
For confidential factoring (code 226), the status must not be sent to the buyer or PA-R. The seller may need to request a change of payment bank account through separate means.
- Common business scenarios
-
- Late factoring decision
Seller issues standard invoice then decides to factor for cash flow.
- Selective factoring
Seller factors only certain invoices after approval by buyer.
- Confidential factoring
Buyer unaware; seller uses Factor-held account as payment destination.
- Factor change
Mid-lifecycle switch from one Factor to another.
- Tax and accounting implications
-
The same obligations as use case 8 apply: The seller keeps all fiscal obligations. The Encaissee status is only triggered by the actual buyer payment to the Factor. The lifecycle message mechanism does not change the Flow 1 tax data already sent to the data concentrator (CdD) of the Portail Public de Facturation (PPF)..
Important: The Factored lifecycle status (code 225) changes the payment destination but does not modify the invoice itself. The original Flow 1 tax data remains unchanged. For confidential factoring (code 226), the status must not be sent to the buyer.
Key data requirements
| Field ID | Description | Value |
|---|---|---|
| BT-3 | Invoice type code | 380 (standard, initially no factoring) |
| MDT-105 | Status code | 225 (Factored) or 226 (Confidential Factored) |
| MDG-41 | New beneficiary | Factor identification in CDAR message |
| MDT-155 | Beneficiary ID | Factor SIREN |
| MDT-158 | Beneficiary role | DL (Factor) |
| MDT-178 | Factor e-address | Electronic address |
| MDG-43 | Data to update | New bank details (BT-84, BT-85, BT-86) |
| MDT-127 | Note code | ACC (subrogation clause) |
Implementation considerations
- Seller considerations
-
Create Factored lifecycle status (code 225 or 226) with all needed CDAR fields.
Include subrogation clause in the lifecycle note (code ACC).
For confidential factoring (226), make sure the status is not sent to the buyer.
Manage Factor change scenarios with additional lifecycle messages.
- Buyer considerations
-
Process Factored lifecycle status and update payment destination.
Redirect payment to the new IBAN provided in the CDAR message.
- General considerations
-
The PA-E must support CDAR lifecycle status creation and transmission for Factored (225 and 226).
The PA-R must support processing the Factored status and showing new bank details to the buyer.
Note: The Factor designated after transmission needs access to the invoice and its full lifecycle history including the subrogation status. The Sovos solution handles this through its interface with role-based permissions, letting Factors get replicated invoices, monitor approval statuses, and track collection events for assigned receivables. - SCI mapping
Use case 10 primarily uses CDAR lifecycle messages (Flow 6) rather than invoice fields for Factor designation. The original invoice follows standard SCI mapping.
Field SCI path BT-3 Invoice type Invoice/InvoiceTypeCodeBG-4 Seller Invoice/AccountingSupplierParty/PartyBG-7 Buyer Invoice/AccountingCustomerParty/PartyBT-84 Payment account Invoice/PaymentMeans/PayeeFinancialAccount/IDBT-112 Total amount with VAT Invoice/LegalMonetaryTotal/TaxInclusiveAmountBT-115 Amount due Invoice/LegalMonetaryTotal/PayableAmount
