Bananarama & FinOps
Before fame and fortune, Bananarama worked in accounts payable* and that inspired their smash hit, Robert deNiro’s waiting.
Robert deNiro was their code name for Excel**.
Sooner or later in Financial Operations, Excel is there, waiting, to do the things your financial institution can’t or won’t do. For example, take bulk payment processing of supplier invoices. We often hear ‘our process is fully automated’ when we ask whether there are any issues around it.Now we know it is almost never fully automated, so we dive a bit deeper:
NoFrixion: “Oh that’s great - how do you do it?”
Company: “Our AP team produce the payments file, and they send it to finance who upload it to the bank and it’s processed”.
But when we ask some more questions, we typically see a little more colour - usually from someone who actually does the work, rather than someone a few steps above. And 9 times out of 10, Excel plays a starring role.
NoFrixion: How do the payments get authorised?
Company: We request authorisation by email from the approver. They reply with yes or no and we enter that on a spreadsheet.
NoFrixion: And how do you get the payment file to the bank?
Company: It’s all automatic - we simply upload a file and that’s it.
NoFrixion: How is that file produced?
Company: I’m not sure actually, let me check.
Eventually we hear something like:
…the ERP produces a file of payments to be made but it isn’t in a format the bank will use so it gets manually reformatted in Excel and exported to CSV. Then we mail it to Finance, and they upload it.
Each new beneficiary first needs to be approved separately, or the whole process fails. Same if there’s a typo - the whole process fails.
Once the process completes, we download a file in CSV format, re-format it in Excel, and mail it to Finance to update the ERP and do the bank reconciliation - they do that with both the Excel file from the bank and the original file from the ERP, so it is a bit messy.
The whole process involves five people, and takes about 7 hours including the back & forth and the bank reconciliation…
This is an example of an operational process developed to address an underlying system limitation.
In financial operations (FinOps), Excel is everywhere because it has been the most effective tool to mitigate (not solve) system limitations. Many, and likely most, of these system limitations are caused by a core banking service problem.
Frequently, the fact there is a problem is unknown - like in the example above. People don’t realise there is a system limitation because there is an operational process to work around it: “well we’ve always done it like this, so there must be a good reason”.
The good reason is that the limitation of traditional banking services meant no other options.
The system limitation is that the ERP and the Bank account are not connected directly.
Most financial institutions don’t allow software connections to their accounts. In many cases, they would like to but can’t because their core systems simply don’t support it.
Businesses are forced to use internet banking and this is the only way to instruct the bank to perform specific tasks - like make a payment, split an inbound payment etc.
If the ERP was directly connected to the bank account, then the five people could do something else and the 7 hours aren’t needed - once the digital process completes (all invoices approved and checked), the payments are made - instantly.
The good news is that this is possible.
It’s an example of programmable current accounts and it is exactly what we do at NoFrixion. This is how we transform Financial Operations. If you’d like to speak with an expert on FinOps, get in touch…
Notes re Bananarama:
* This is demonstrably untrue but makes a more interesting introduction.
** ditto
