en:app:030bsi:200rf:0010bsrftbas

Introduction

“Receivable Finance” is a supplier-centric business in which the invoices are uploaded by the supplier and are paid by the supplier’s bank. The invoices are then paid back by the buyer to the supplier's bank. The approval process of the invoices by the buyer takes place outside of the application.

It is a mass business which requires full electronic interaction between all participants and high automation (STP) at the bank’s back office.

"Receivable Finance" process in the application

Below steps give a detailed overview of the whole process in the application:

  • A pool of documents containing invoice details are imported into the system either automatically via Manager for Incoming Messages or can be registered manually by the user. The document pool is automatically processed to generate a Receivable Invoice (RI) contract. More details on this can be found under Add Invoice Set.
  • The Receivable Invoice (RI) contract contains the buyer and supplier details based on the pairing configuration and the invoices that are stored in the Finance Base Documents pool. As this is a mass business, during the day the supplier can upload multiple invoice sets (through xml/json file import). Each request creates one RI contract.
  • A Receivable Finance contract has a “one to many” relationship with a RI contract. As this whole business module deals with Invoices, as many as invoices per pairing can be selected to generate one RF contract (which can involve many RI contracts).
  • As this is a mass business, one can expect hundreds of invoices in an upload and the whole process is automated. Hence, to avoid a direct financing the application has this separate business module RI for Invoice upload. It also helps to communicate it to the Supplier regarding any failures to the invoice upload.
  • When a “Receivable Finance” is executed, the financed amount is credited to the supplier and the credit line of the buyer is debited.
  • Due to the nature of this business, the invoices are paid in bulk. This means that the buyer sends the supplier's bank the repayment amount and he may or may not have mentioned the RF contract numbers that needs to be paid. To handle this type of payments where as many RF contracts or invoices can be repaid, the business module Receivable Repayment (RR) is used.
  • Once the funds are received by the bank, a Repayment transaction is triggered where the user manually selects the invoices that can be paid. Once the financed invoices are paid, the buyer is debited and the liability amount is released from his credit line.
  • As per the application standards, it is also possible to initiate a Repayment transaction for one Receivable Finance (RF) contract via diary.
  • The above mentioned transactions are executed usually without any direct user interaction. Although full STP is aspired, the complete business for not standard cases in a manual way will be fully supported.
  • The workflow engine of the application handles the automated execution without user interaction, e.g. adding invoices, creation of receivable offers, opening receivable finance, etc.
  • Special cases like partial repayment of the invoices, payment on credit/debit is also supported.
  • As the invoices are paid in bulk, it is highly possible that there is some remaining amount from the money sent by the buyer. This remaining amount can be added in the Finance Base Documents pool as type of document namely “Payment on Account” (PoA) from the Repayment transaction. To handle this functionality, the buyer also needs a special type of account set-up called “Payment on Account D/C”. Once this document is added to the pool, a settlement entry is created with disposition “POC” to credit buyer's account which can later be used to pay any outstanding invoices in turn creating a settlement entry with disposition “POD” to debit buyer's account.
  • When an agreed interface format, e.g. APIs via a bank's web front-end application, will be used, the application can automatically generate messages to synchronize the database kept within the web front-end accessible for the buyer and supplier.
  • The application supports standardized communication channels to send direct messages to the buyer, the supplier and for interbank processing to banks:
    • Settlement information and free format messages can be sent through existing standardized channels, e.g. via the SWIFT-Network.
    • Payments can be sent through several clearing channels as interbank payment messages.
  • At the moment, an automated flow for remittance of funds for Opening Receivable Finance (via SPTCRE or API's) is only supported with internal bookings, when a direct account relationship is held.
    • In case of credit transfers through external channel, e.g. Swift, Target2 RTGS or SEPA payments etc., then the user has to manually process the transaction.
    • It can of course be automated based on the Project needs.

Process Flow

The benefits for the involved parties are as follows:

Funding Institution Short term and self-liquidating financing tool.
Buyer Good alternative to other more complicated and costly options in international trade finance, such as documentary credits.
Opportunity to extend or normalize payment timeframes without adding pressure to supplier communities.
Ensure the health of international supply chains and particularly, strategically important suppliers there by providing access to affordable financing.
Supplier Accelerated access to funds, enhanced cashflow and working capital, and reduced cost of financing.
No need to use operating lines of credit or other debt-based financing facilities.
Access to additional finance facilities; can bridge liquidity shock.
en/app/030bsi/200rf/0010bsrftbas.txt · Last modified: 2022/09/23 11:01 by bp