Invoice payable to a Third Party - known party & cash pooling

[svanteschubert]

Background

Invoice payable to a Third Party known at the time of invoicing (factoring, cash pooling)

French Use Case n°8: Invoice payable to a third party determined at the time of invoicing (factoring, cash pooling)

The invoice must be paid to a third party determined at the time of invoicing. The receivable associated with the invoice is assigned to a bank or factor by the supplier as part of a contract. Invoice payment data must only be transmitted when the factor has received payment from the customer, and not when the supplier has been paid by the factor (VAT payability rule).

The specifics of the data and associated management rules are :

• The factor must be entered in block BG-10 "BENEFICIARY".
• The elements used to pay the factor for a transfer in block BG-17 "TRANSFER".
• Invoice type in BT-3 must be set to 393 (Factored invoice).

The specific features of the life cycle or associated processes are :

• Transmission of flow 2 from supplier's MPS to buyer's MPS
• Generation and transmission of flow 1 to the PPF (case of circuit C)
• Two options are available for transmitting the e-reporting payment data stream (depending on the commercial agreements between the supplier and the factor):
  • Option 8-1: Supplier transmits payment data e-reporting flow
  • Option 8-2: the third-party factor transmits the payment data e-reporting flow

Option 8-1 can be described as follows:

Figure 7: Invoice payable to a third party determined at time of invoicing (Option 1)

The steps in case 8-1 are :

Step	Stage name	Responsible player	Description
1	Invoice creation with factor	Supplier	The factor is known as soon as the invoice is created. When sending an invoice flow, use block BG-10 "BENEFICIARY" to identify the factor, and block BG-17 "TRANSFER" for elements used to pay the factor in the case of a transfer. Invoice type in BT-3 must be set to 393 (Factored invoice). A flow 1 is sent by the supplier's PDP1 to the PPF in parallel with flow 2
2	Receiving stream 1	PPF
3	Receipt of invoice	Buyer	The buyer's PDP 2 makes the invoice available to him. The buyer processes the invoice according to the lifecycle procedure, up to the optional "payment forwarded" status. A lifecycle flow is sent to the supplier's PDP.
4	Invoice processing and update from status up to "Payment forwarded	Buyer
5	Invoice payment to factor and status transmission	Buyer
6	Receiving invoice status	Supplier	The lifecycle flow sent by the buyer's PDP 2 is received by the supplier's PDP 1.
7	Invoice collection	Third parties	The third-party factor collects the invoice payment. The transmission of this Information to the PPF is based on the platforms' commercial offer.
8	Go to à update at status "and transmission of payment data	Supplier	The supplier updates the "cashed" status on behalf of the third-party factor via his PDP. The supplier's PDP transmits the e-reporting of payment data to the PPF.
9	Receiving e-reporting feeds payment details	PPF	The PPF receives the payment data stream transmitted by the supplier
10	Reception from status "cashed	Buyer	The supplier's PDP 1 can send a lifecycle flow to the buyer's PDP 2, if its commercial offer allows.

Option 8-2 can be described as follows:

Figure 8: Bill to be paid to a third party designated for billing (Option 2)

The steps in case 8-2 are :

Step	Stage name	Responsible player	Description
1	Invoice creation with factor	Supplier	The factor is known as soon as the invoice is created. When sending a flow, use block BG-10 "BENEFICIARY" to identify the factor, and block BG-17 "TRANSFER" for elements used to pay the factor in the case of a transfer. Invoice type in BT-3 must be set to 393 (Factoring invoice). A flow 1 is sent by the supplier's PDP1 to the PPF in parallel flow 2
2	Receiving stream 1	PPF
3	Receipt of invoice	Buyer	The buyer's PDP 3 makes the invoice available to him. The buyer processes the invoice according to the lifecycle procedure, up to the optional "payment forwarded" status. A lifecycle flow is sent to the supplier's PDP.
4	Invoice processing and update from status up to "Payment forwarded	Buyer
5	Invoice payment to factor and status transmission	Buyer
6	Receiving invoice status	Supplier	The lifecycle flow sent by the buyer's PDP 3 is received by the supplier's PDP 1.
7	Invoice collection	Third parties	The third-party factor collects the invoice payment.
8	Receiving e-reporting feeds payment details	Third parties	The third-party factor's PDP 2 transmits the payment e-reporting flow to the PPF. /!\: Legally, the obligation to transmit payment data rests with the supplier.

More generally, in case n°8, the services offered by the PPF are :

• If both the buyer and the third party are connected to the PPF, the latter will be able to view/modify the invoice and its lifecycle.
• If both the supplier and the third party are connected to the PPF, the latter will have access to view/modify the invoice and its life cycle.
• Actors connected to the PPF will be notified of any change in invoice status.

NOTE: The text/pictures of this use case no. 8 were taken from the French government site! The text was extracted from V2.3 - deepl English DOCX and any pictures were taken from V2.2 - original English PDF)

[edmundgray]

see also #48, #49 Bill-To Party is discussed elsewhere, it is the Party who is known to be paid.

Cash Pooling is where one subsidiary pays the invoice of another. The subsidiary is not known at the time of creating the invoice. This might be a requirment for a Remittance Advice where one payer was substituted for another. Therefore it is out of scope.