Sovos Docs

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-26 is equal to DL (Factor role code) in the EXTENDED-CTC-FR profile.

  • 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-FR profile 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 IDDescriptionValue
BT-3Invoice type code393 (factored) or 501 (self-billed factored)
BG-10Payee (beneficiary)Factor or treasury entity identification
BT-59Payee nameFactor legal name
BT-61Payee legal IDFactor SIREN (optional)
EXT-FR-FE-26Payee role codeDL (Factor) from United Nations Trade Data Interchange (UNTDID) 3035
EXT-FR-FE-27Factor VAT IDIntra-community VAT number
EXT-FR-FE-28Factor e-addressFor invoice or status replication
BT-84Payment account (IBAN)Factor bank account
BT-85Account nameFactor account holder name
BT-86Payment BICFactor BIC code
BT-21/BT-22Note (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
FieldSCI path
BT-3 Invoice typeInvoice/InvoiceTypeCode
BG-10 PayeeInvoice/PayeeParty
BT-59 Payee nameInvoice/PayeeParty/PartyName/Name
BT-61 Payee legal IDInvoice/PayeeParty/PartyLegalEntity/CompanyID
EXT-FR-FE-26 Role codeInvoice/PayeeParty/IndustryClassificationCode
EXT-FR-FE-28 Factor e-addressInvoice/PayeeParty/EndpointID
BT-84 Payment accountInvoice/PaymentMeans/PayeeFinancialAccount/ID
BT-85 Account nameInvoice/PaymentMeans/PayeeFinancialAccount/Name
BT-86 Payment BICInvoice/PaymentMeans/PayeeFinancialAccount/FinancialInstitutionBranch/ID
BT-22 Note (subrogation)Invoice/Note