In the first two articles of this series, I looked at why ERP-to-bank connectivity matters and why the best time to address it is usually before or alongside an ERP transformation.
The next question is what happens when the organisation grows.
Because that is where banking complexity often starts to accelerate.
A company adds another entity, enters another country, opens another bank account, acquires a business or introduces a new payment process. None of those steps is necessarily difficult on its own. The challenge is the cumulative effect.
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 reasons banking complexity is often underestimated is that it rarely arrives as one big problem. A new country may require a local bank, an acquisition may bring in several existing accounts, and a new entity may introduce a different approval model or payment requirement. Each addition seems manageable, but over time finance can end up supporting a growing number of bank portals, account structures, payment processes, user rights and local workarounds.
At some point, the banking landscape stops being a collection of individual connections and becomes an architecture question. What makes this particularly interesting is that it often happens while the ERP programme is trying to achieve exactly the opposite: more standardisation, more automation and one consistent way of working across the organisation.
For me, that is why standardisation usually needs to come before automation. If every entity has its own payment process, approval logic and banking setup, automating those processes can simply automate variation. A stronger model starts by deciding what should be common across the group: where payments are created, where approvals take place, how bank statements are received, how new accounts are onboarded and which activities genuinely need to remain local. Once those decisions are clear, automation becomes much more powerful because you are scaling one model instead of optimising ten different ones.
Direct ERP-to-bank connectivity can work very well in a relatively simple environment. But as the number of banks grows, every connection can bring its own implementation effort, testing, technical requirements and ongoing maintenance. Add enough banks and the ERP gradually starts carrying more and more bank-specific logic, making future change harder.
The question is therefore not whether point-to-point connectivity is good or bad. It is whether it remains the right model for the complexity the organisation is moving towards. At a certain point, companies need to decide whether the ERP should continue managing each banking relationship separately or whether those relationships should sit behind a central connectivity layer.
This is where a multi-bank model becomes powerful. The ERP can follow one consistent financial process regardless of which bank ultimately receives a payment, while the connectivity layer handles much of the bank-specific variation. The same principle applies to incoming information: finance wants balances, statements and transaction data in a consistent way even when the underlying banks deliver them differently.
That separation matters. The ERP remains responsible for the financial process, while the connectivity platform manages the complexity towards the banks. As a result, adding another bank or entity does not necessarily require redesigning the ERP process itself.
Payments are often the first thing people think about when discussing bank connectivity, but cash visibility and control become equally important as organisations grow. If balances and transaction data are spread across multiple portals, finance teams can spend a surprising amount of time simply gathering information. Questions such as how much cash is available across the group, where balances are concentrated or which entities need funding become much harder to answer quickly when the underlying information is fragmented.
Governance becomes more challenging too. More entities and banks typically mean more users, permissions and approval structures. Finance needs to understand who can access which accounts, who can initiate or approve payments and whether consistent control principles are being applied across the group. The objective is not necessarily to centralise every activity, but to create central visibility and a consistent framework around the wider banking landscape.
M&A provides a particularly good stress test. An acquisition can bring new banks, accounts, currencies, payment processes, users and sometimes another ERP environment. If the existing architecture is standardised, bringing the acquired business into the group model can be relatively straightforward. If every connection and process is bespoke, integration can take considerably longer. That is why I see bank connectivity not only as an operational question, but also as part of a company’s broader ability to scale.
For me, there is one very practical test: how much additional complexity does each new bank, entity or country create?
If every new bank requires another ERP integration, another testing project, another operating procedure and a different way of working, the marginal complexity is high. If the organisation can add that bank to an existing connectivity model while keeping the ERP process largely unchanged, the marginal complexity is much lower.
That is the difference between simply being connected and actually being scalable.
The companies we see benefiting most from a centralised connectivity approach tend to have several things in common: they operate across multiple entities, use several banks, are internationally active and want more consistency in payments, reporting and control. They also usually expect the organisation to keep changing.
At that point, the objective is no longer to solve one integration problem. It is to create a banking architecture that can absorb future change. That is where we see Cobase adding value: providing a layer between the ERP and the banking landscape so that the financial process can remain consistent even as the organisation underneath it becomes more complex.
One of the most common mistakes is waiting until the banking setup becomes visibly difficult to manage. By then, local processes may be deeply embedded, direct connections may have multiplied and manual workarounds may already be part of daily operations. It is still possible to simplify that environment, but it is much easier to design for scale before complexity is fully built in.
If you have three banks today but know the business is expanding internationally, think about the future model now. If acquisitions are part of the strategy, ask how easily new entities and banking relationships can be incorporated. If finance is becoming more centralised, make sure the banking architecture can support that direction.
The goal is not to eliminate complexity altogether. Some variation between countries, banks and entities is unavoidable. The real goal is to stop every new bank, entity or country from creating an entirely new process.
In the final article of this series, I will look at what ultimately determines whether that architecture works in practice: the combination of technology, execution and the right implementation partners.
This is the third article in a four-part series on ERP-to-bank connectivity and modern finance infrastructure.