Use case 8: Factoring and treasury centralization (third party known at invoicing)
When the factor or treasury entity is known at invoicing time, the seller names it as the payee in BG-10 using type code 393 or 501.
Description
This use case addresses invoices that must be paid to a third-party beneficiary identified at the time of invoicing. The most common scenarios are factoring and treasury centralization within corporate groups:
- Factoring
- The seller assigns its receivable to a Factor, who becomes the legal owner of the debt.
- Treasury centralization
- The seller designates a group entity responsible for collecting payments on behalf of all group members.
The Factor or treasury entity is identified in the invoice within the payee block (BG-10). When you use the EXTENDED-CTC-FR profile, the role code EXT-FR-FE-26 with value DL from United Nations Trade Data Interchange (UNTDID) 3035 qualifies the beneficiary as a Factor. The invoice type code changes to 393 (factored invoice) or 501 (self-billed factored invoice) to signal the factoring arrangement.
A key distinction exists between refinancing and collection: When the Factor advances funds to the seller, this is refinancing and does not constitute collection. The invoice is considered collected (Encaissee) only when the buyer pays the Factor. The seller remains responsible for sending the Encaissee lifecycle status.
- Key characteristics
Factor or treasury entity designated in BG-10 (Payee) at invoice creation.
The invoice type codes are 393 (factored), 501 (self-billed factored ), 396, and 502 (credit notes).
EXT-FR-FE-26is equal to DL (Factor role code) in theEXTENDED-CTC-FRprofile.Invoice replication to Factor through Pan-European Public Procurement On-Line (PEPPOL) or API (optional PA-E functionality).
Buyer pays Factor directly, not the seller.
Refinancing by Factor does not equal collection (only the buyer payment is equal to Encaissee).
The seller remains responsible for the Encaissee status (Factor does not substitute for fiscal obligations).
- Relationship to other use cases
Use case 8 shares the Payee (BG-10) structure with treasury centralization scenarios but adds factoring-specific elements (invoice type codes, subrogation clauses, and role codes). Use case 9 (Distributor/Depositary) uses similar BG-10 mechanics but without factoring semantics. Use case 10 (Factoring with Subrogation) differs fundamentally because the Factor is unknown at invoice creation and is designated through lifecycle messages after transmission. Use case 3 (Third-Party Payer) addresses the payer side and use case 8 addresses the payee or beneficiary side.
Business and tax context
- Legal and regulatory framework
-
Factoring is a credit operation under Article L. 313-1 of the Code Monetaire et Financier. It is a regulated financial service provided by specialized credit institutions, founded on the purchase of commercial receivables. The legal basis for receivable transfer can be conventional subrogation (Code Civil), Daily assignment (Code Monetaire et Financier), or standard assignment of receivables.
The standard e-invoicing framework under Article 289 bis Code général des impôts (CGI) applies. Factored invoices use specific type codes (393, 501) that are distinguishable from standard invoices (380). The
EXTENDED-CTC-FRprofile lets you fully identify the Factor with role codes and electronic addresses for replication. - Common business scenarios
-
- Classic factoring
Seller assigns receivables to Factor for immediate cash flow; buyer pays Factor.
- Reverse factoring
Buyer-initiated supplier financing program; Factor pays seller early based on buyer approval.
- Confidential factoring
Buyer unaware of factoring; pays seller account held at Factor.
- Treasury centralization
Group entity collects all payments on behalf of subsidiaries.
- Non-recourse factoring
Factor assumes credit risk; recourse factoring: seller keeps risk.
- Tax and accounting implications
-
The seller keeps all fiscal obligations regardless of the factoring arrangement. When VAT is due on receipt, the seller must send the Encaissee status only when the buyer has paid the Factor. Factor refinancing is not a taxable event. The Factor must inform the seller when the buyer has paid so the seller can issue the Encaissee status.
If the payment is cancelled, the seller must send an Encaissee cancellation status with negative amounts.
Important: Refinancing by the Factor is not collection. The Encaissee status must only be sent when the buyer pays the invoice to the Factor. The seller remains responsible for all fiscal obligations including Encaissee.
Key data requirements
| Field ID | Description | Value |
|---|---|---|
| BT-3 | Invoice type code | 393 (factored) or 501 (self-billed factored) |
| BG-10 | Payee (beneficiary) | Factor or treasury entity identification |
| BT-59 | Payee name | Factor legal name |
| BT-61 | Payee legal ID | Factor SIREN (optional) |
| EXT-FR-FE-26 | Payee role code | DL (Factor) from United Nations Trade Data Interchange (UNTDID) 3035 |
| EXT-FR-FE-27 | Factor VAT ID | Intra-community VAT number |
| EXT-FR-FE-28 | Factor e-address | For invoice or status replication |
| BT-84 | Payment account (IBAN) | Factor bank account |
| BT-85 | Account name | Factor account holder name |
| BT-86 | Payment BIC | Factor BIC code |
| BT-21/BT-22 | Note (code ACC) | Subrogation or assignment clause |
Implementation considerations
- Seller considerations
-
Use invoice type 393 or 501 for factored invoices and populate BG-10 with Factor details.
Include subrogation clause in BT-22 with subject code ACC.
Track Factor notifications to determine when to issue the Encaissee status.
Factor refinancing does not trigger Encaissee; only the buyer payment does.
- Buyer considerations
-
Pay to the IBAN designated in the invoice (BT-84), which is the Factor account.
Recognize factored invoice types (393, 501) and adjust payment routing accordingly.
- General considerations
-
PA-E may optionally support invoice or status replication to Factor through PEPPOL or API.
PA-E may optionally support getting Encaissee status prepared by Factor on behalf of the seller.
Note: The Factor needs access to factored invoices and their lifecycle statuses to track receivables. The Sovos solution handles this through its interface with role-based permissions, letting Factors monitor invoice statuses, get replication of relevant documents, and optionally prepare Encaissee statuses for the seller without needing direct platform-to-platform integration. - SCI mapping
Field SCI path BT-3 Invoice type Invoice/InvoiceTypeCodeBG-10 Payee Invoice/PayeePartyBT-59 Payee name Invoice/PayeeParty/PartyName/NameBT-61 Payee legal ID Invoice/PayeeParty/PartyLegalEntity/CompanyIDEXT-FR-FE-26 Role code Invoice/PayeeParty/IndustryClassificationCodeEXT-FR-FE-28 Factor e-address Invoice/PayeeParty/EndpointIDBT-84 Payment account Invoice/PaymentMeans/PayeeFinancialAccount/IDBT-85 Account name Invoice/PaymentMeans/PayeeFinancialAccount/NameBT-86 Payment BIC Invoice/PaymentMeans/PayeeFinancialAccount/FinancialInstitutionBranch/IDBT-22 Note (subrogation) Invoice/Note
