Receivable Finance
Introduction:
’Receivable Finance’ is a supplier-centric business which comprises of the discounting of supplier’s invoices by the supplier’s bank. The finance granted to the supplier is based on the
agreement between the supplier and the bank. The invoices are uploaded by the supplier and
are paid by the supplier’s bank, which are then repaid by the buyer on maturity. The approval
process of the invoices by the buyer takes place outside of the application. Receivables financing is a form of invoice financing.
Receivables finance is also known as accounts receivable financing. A business using accounts receivable financing sells some, or all, of its outstanding invoices to a third party known as the funder or financer. This effectively means that the supplier will receive early payment on those invoices by their bank.
Receivables finance is a mass business which requires full electronic interaction between all participants and high automation (STP) at the bank’s back office.
The application workflow engine handles the automated execution without user interaction,
e.g., adding invoices, creation of receivable offers, opening receivable finance, etc.
'Receivable Finance' process in the application
To support the whole ‘Receivable Finance’ flow, there are three modules that have been used to handle this automated process,
Receivable Invoices (RI):
This business module deals with Invoices (adding invoices to the pool automatically), as many invoices per pairing can be selected to generate one Receivable Finance (RF) contract (which can involve many RI contracts). A Receivable Finance RF contract has a ‘one to many’ relationship with a RI contract.
Transactions Add Invoice Set (RITOPN), Common Messages (RITFRE), Report Generator Invoice Set (RIRGEN) and Info Receivable Invoice Set (INFRID) are part of this module.
- Within the application, a pool of documents such as invoices (in an agreed XML/JSON structure) is imported automatically during the day based on the pairing configuration into the system through Manager for Incoming Messages or can be registered manually by the user. This
pool is automatically processed to generate a Receivable Invoice (RI) contract. - 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.
-
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.
Receivable Finance (RF):
This module handles the usual product standard transactions such as Offer (RFTPOP), Opening Receivable Finance (RFTOPN), Amendment (RFTAME) etc.
- When a Receivable Finance is executed, the financed amount is credited to the supplier and the credit line of the buyer is debited.
Receivable Repayment (RR):
Transactions Repayment (RRTSET), Common Messages (RRTFRE), Report Generator Repayment (RRRGEN) and Info Receivable Repayment (INFRRD) are part of this module.
-
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 or invoice details 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 where more than one finance contract can be paid in the same repayment contract.
- Once the information regarding funds is received by the bank from the buyer, a Repayment
transaction is triggered where the user manually selects the invoices that can be paid. When
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 through diary.
-
The afore mentioned transactions except the ’Repayment’ module are executed usually
without any direct user interaction. Although full STP is aspired, the complete business for
non-standard cases in a manual way is fully supported. -
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. - To support the whole Receivable Finance process, existing static data transactions
‘Maintaining Pairing Setup (DBxPSB)’ and ‘Finance Base Documents (DBxFBD)’ are used.
Additionally, a new static data transaction ‘Create Pending Entries (SPTCRE)’ is also maintained. - An automated flow with API’s is also supported. 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.
-
Comments
0 comments
Please sign in to leave a comment.