At Churpy, we strongly believe all businesses should receive and apply payments due to them easily and cheaply.
In this 3rd blog — we’ll be discussing how businesses can reconcile bank payments (SWIFT, Pesalink, RTGS) layered on the virtual accounts technology that we have built together with NCBA bank. Buckle up!
Let’s be unassuming and get a few definitions out of the way, shall we?
Introduction: About the payment rails
Today, if you are sending or receiving funds across borders, you are likely using the SWIFT bank network, with your funds being relayed as structured SWIFT financial messages between the banks involved. This payment rail is what we know as Real Time Gross Settlement RTGS, and according to CBK by June 2022, more than 608,000 local RTGS payments valued at USD 36.6 Billion were remitted within the month. This value looks poised to grow as RTGS remains a critical channel of businesses settling their accounts receivable bills.
Fig 1: CBK RTGS value as at June 2022
Source: KEPSS/RTGS | CBK (centralbank.go.ke)
Lastly, Pesalink (arguably Kenyan Banks’ rebuttal to MPesa) is run by Integrated Payments Services Limited IPSL, a profit arm of the Kenya Bankers Association. This payment method allows for round the clock bank to bank remittances from Ksh 10 up to Ksh 999,999 in near real-time (IPSL stipulates a transaction latency of no more than 50 seconds). The beauty therein lies in the low transaction charges with most banks charging between $1 to $2 for transactions upto ~$9,000. Further, it has proven to be popular with medium sized businesses executing large transactions over the weekend or after working hours. Comparatively, RTGS charges in various banks vary from $3 to $5, but I digress!
Payer Attribution Challenge. Who was the payer?
Bank transaction notifications all have designated fields for identifying the remitter or debtor, as well as the transaction details. For instance in SWIFT/RTGS;
· The Ordering customer’s details (remitter name in line 1 followed by their address in line 2–4) are included in field 50
· The remittance reference e.g. Invoice numbers, Customer references, Contract number etc. are included in field 70
· Any other free formatted Sender to Receiver information pertinent to the transaction are included in field 72 of the SWIFT message.
Typically, SWIFT and Pesalink payments are ideal for settling episodic transactions where the remitter is known and the payment is anticipated and is unique. With all the aforementioned details, Accounts Receivable payment attribution and allocation of open invoices is therefore expected to be straightforward right?
However, from our engagement with a significant number of businesses big and small, that’s not the case. So wherein lies the problem?
Biggest challenge while reconciling is as follows:
The challenge presents in two major ways;
i. Most large-scale businesses e.g., in Manufacturing and FMCG doing B2B transactions ordinarily receive a single RTGS/SWIFT/Pesalink payment against a bunch of invoices, and are separately furnished with a remittance advice in excel or pdf format (typically from the remitter’s ERP) with a breakdown of the invoices paid. What then ensues for the paid company, is a less than desirable manual process of eye-balling, identifying, ticking off, allocating and adjusting entries against each invoice, raising discrepancies to the payer etc in a bid to apply the full value of the payments and closeout on the pending invoices and generate requisite reports to the business. This is typically and dreadfully dubbed the Month-end, a process we are working with several such large businesses to transform.
ii. Statements availed by most banks currently truncate or exclude some of the aforementioned information critical to the reconciliation process. For instance, it is typical for the first row of the Ordering customer (field 50) to be picked and be reflected in the bank statement, whereas the 2nd to 4th row in field 50 containing critical differentiating information such as the remitter’s other names and address is omitted in the statement. Whereas Churpy’s APIs can surface the full information from bank Core Banking Systems to effectively overcome this hurdle; this approach ultimately falls short of achieving a 100% auto reconciliation rate in the receiving client’s ERP; a problem we have successfully tackled.
Example use case:
Consider this scenario: A fast-growing large hardware supply business — Hardware A has their customers (other hardware stores) buying cement from their depots countrywide in consignments of 100 or 200, typically being a small lorry load with each going for Ksh 500 a bag.
The hardware supplier gets paid through multiple rails including Cash, RTGS and Pesalink through thousands of transactions a month, most reflecting in their bank statements either as Ksh 50,000, Ksh 100,000 or multiples of Ksh 500. It is also not uncommon for some of its buyers to pay partially, sending multiple payments against the same consignment. To top it all, some individual buyers actually have the same / overlapping names and it is not always easy to identify who actually paid in. In the beginning, the accounting team could cope, but the payment attribution and invoice allocation process became more challenging as transaction volumes surged.
Cases of cash misapplication also became commonplace. The CFO could not get an accurate on-demand position of applied payments, or of overdue debtors and oftentimes opted for expensive external debt instruments to fund their growing operations whereas there was a significant value of unapplied funds. Occasionally these unapplied/irreconcilable funds were written on at quarter end. A less than desirable outcome.
Compounding the problem, cases of internal fraud were rife especially around unapplied payments and went undetected for long. Often upon realization of the said incidents, the funds were unrecoverable. To top it up, the accountants, some quite highly qualified, lamented that the process of reconciling across the various payment types was disjointed and manual. They were not particularly fond of the late nights spent on the reconciliation process every last week of the month.
Which Shoe Fits?
So in comes Churpy. Through its Virtual Accounts offering in collaboration with NCBA bank and another Pan-African bank, we enable such businesses to automate their collection process while retaining the current customer payment journey as below;
Fig 2: Churpy Virtual Account
This is how the solution would work for Hardware A, fully automated end to end;
1. Working closely with NCBA, Churpy has built a technology that allows Hardware A to generate Virtual Accounts for each of its customers. Customers pay into their dedicated Virtual Accounts and the payments are redirected into the main account with sufficient payer details as to enable automated reconciliation at ERP level.
2. Hardware A’s customers no longer have to quote any references in their transactions. They just pay into their designated virtual account.
3. All received funds are validated by NCBA and applied into Hardware A’s main collection account. Realtime push notifications are sent out to Hardware A and their customer as deemed necessary.
4. Optionally, for bulk payments, Hardware A’s customers have a special marketplace portal in Churpy where they can upload the supporting remittance advice in CSV, excel or Pdf and Churpy performs 3-way reconciliation knocking off outstanding invoices as a result.
5. For confirmed payments, Churpy automatically allocates against open invoices in Hardware A’s ERP via an API integration, given that Churpy has built integration into more than 23 ERPs e.g. SAP, Sage, QuickBooks, Microsoft Dynamics Business Central etc.
6. Hardware A can easily extend the same collection setup for all other existing collection rails e.g. MPesa and Cash, and still achieve 100% payment attribution and automated allocation.
Fig 3: Churpy’s ERP API Plugins
With this, the Finance function now has latitude for more strategic level contribution to the business including minimizing day sales outstanding, eliminating material losses and cases of fraud through timely reconciliation, increasing cash flow cycles, and providing accurate and timely metrics and information to the CFO for critical decision making..
.. Oh and still managing a 5pm sign off on end-month, all thanks to Churpy Virtual Accounts.
The writer is a Tech futurist, and a co-founder at Churpy.