When companies modernise their finance environment, the ERP is usually at the centre of the discussion. That makes sense. It is where financial processes are structured, transactions are recorded, approvals are managed and reporting starts to come together. But there is another part of the architecture that often receives less attention than it should: how the ERP actually connects to the banks.
At first glance, that may sound like a technical integration topic. In reality, it has a direct impact on how finance operates day to day. Payments need to move from the ERP to the bank. Bank statements and transaction data need to come back. Cash needs to be visible. Approvals need to be controlled. And once multiple entities, countries and banks are involved, what looked like a simple connection can quickly become a much broader finance architecture question.
Daan Kurvers is Head of Partner Sales at Cobase. He has been with Cobase for five years and has seen hundreds of companies rethink the way they connect finance systems, banks, payments and treasury processes. In this series, he shares some of the patterns he sees in the market and the practical lessons companies can take from them.
One of the most common situations I see is a company that has made a significant investment in a new cloud ERP and has successfully standardised a large part of its internal finance processes. Reporting improves, workflows become more automated and the ERP becomes a much stronger financial backbone. But when you look at the banking side of the process, the picture can still be surprisingly manual.
Payment files may still be downloaded from the ERP and uploaded into several bank portals. Bank statements may still be collected from different sources and reintroduced into the finance process. Local entities may still maintain their own payment and approval routines. In other words, the ERP has moved forward, but the last mile between the ERP and the banks has not necessarily moved with it.
That matters because from the perspective of finance, these are not separate processes. A payment does not stop being part of the finance process once it leaves the ERP. The full process continues until the instruction reaches the bank, is executed, the resulting transaction data comes back and the item can be reconciled. If the first half of that flow is automated and the second half is fragmented, the end-to-end process is still fragmented.
Banking complexity rarely arrives all at once. It usually develops gradually as the business grows. A company adds another legal entity, then enters another country, then adds a local bank. An acquisition may bring in several more accounts and payment processes. Over time, finance can end up supporting a patchwork of portals, formats, approval structures and local ways of working.
Each individual change may seem manageable. The problem is the cumulative effect. At the same time that the ERP programme is trying to standardise finance, the banking landscape can be becoming more fragmented. That tension is often where companies start to feel that their original setup no longer scales as well as it once did.
This is also why I think standardisation is often more important than automation. If every entity has its own process, automating those processes can simply automate fragmentation. A better approach is to first decide what the common model should be: where payments originate, where approvals take place, how bank information comes back, how reconciliation should work and which exceptions genuinely need to remain local.
For a relatively simple organisation, connecting the ERP directly to one or two banks can work perfectly well. But once the number of banks, entities and countries increases, the question changes. It is no longer simply, “How do we connect this bank?” It becomes, “How do we want the ERP to interact with the banking landscape as a whole?”
That distinction is important. A point-to-point model means that every new banking relationship can bring its own technical setup, file formats, testing, security requirements and maintenance. A multi-bank connectivity model approaches the problem differently. Instead of asking the ERP to deal with every bank individually, a connectivity layer sits between the ERP and the banks and absorbs much of that variation.
This is the role Cobase can play. The ERP remains the financial core, while Cobase handles the connectivity towards the banking landscape. The objective is not to replace the ERP or to create another unnecessary system. It is to make the connection between finance and the banks more consistent, scalable and easier to manage.
In practice, that can mean payments being generated in the ERP and transmitted through a controlled banking layer, while bank statements and transaction information flow back automatically. It can also make it easier to add new banks or entities without redesigning the ERP process from scratch. The value is therefore not only technical; it affects how efficiently finance can operate and how easily the organisation can grow.
The banking environment itself is also changing. Payment standards continue to evolve, instant payments are becoming more common and expectations around speed, data quality and control are increasing. At the same time, finance teams are under pressure to provide more timely cash visibility and reduce manual work.
That makes it increasingly important to think of bank connectivity as infrastructure rather than as a one-off interface. A good architecture should allow the organisation to adapt without forcing the ERP team to revisit the entire process every time a bank changes a requirement or the company expands into another market.
One of the questions I often ask is very simple: will your banking landscape still look the same in three years? In most growing organisations, the answer is no. There may be more entities, more banks, more currencies or more centralisation. That is why the connectivity model should be assessed not only against today's setup, but also against where the organisation expects to go.
For me, the key point is that ERP-to-bank connectivity should not be treated as a small technical topic at the edge of an ERP project. It is part of the financial infrastructure of the company.
The right setup should allow the ERP to remain the financial backbone while making banking complexity easier to manage. It should reduce manual work without reducing control. It should make it easier to add new banks, entities and countries. And most importantly, it should support the way finance wants to operate in the future, not only the way it operates today.
That is also where we increasingly see Cobase adding value: creating one scalable connection between the ERP and the banking landscape, while allowing each system to focus on what it does best.
In the next article, I will look at one of the most practical questions in this discussion: when should companies actually start thinking about ERP-to-bank connectivity, and why can waiting until the ERP is nearly live create unnecessary work?
This is the first article in a four-part series on ERP-to-bank connectivity and modern finance infrastructure.