In the first three articles of this series, I looked at why ERP-to-bank connectivity matters, why timing is important and why banking complexity tends to increase quickly as organisations grow across more entities, countries and banks.
The final piece is about something I have come to value more and more over the past five years: technology alone is not enough.
A company can choose a strong ERP, a strong connectivity platform and a sensible target architecture, and still struggle if the implementation is not handled well. The real value comes from how those pieces are brought together, how responsibilities are divided and whether the partners involved have enough experience to guide the organisation through the difficult decisions.
About the author
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.
.svg)
The right solution starts with fit, not features
One thing I would be careful with in any finance transformation is the search for the “best” system. In practice, there is rarely one universal answer. The better question is whether the solution fits the organisation today and whether it can still support the business as it changes.
That applies to ERP, but equally to banking connectivity. A company operating in one country with two banks has very different requirements from an international organisation with twenty entities, multiple banking relationships and a more centralised treasury function. The right architecture depends on the operating model, growth plans, level of centralisation, control requirements and internal capabilities.
This is why I think technology selection should start with context rather than a feature list. A solution may be very powerful, but if it introduces unnecessary complexity or does not align with the way the organisation wants to operate, that power does not automatically translate into value.
Good architecture creates clear responsibilities
A well-designed finance architecture should make it clear which system is responsible for what. The ERP should remain the financial backbone of the organisation, managing the core financial process, master data, accounting and the wider workflow around finance.
The connectivity layer should manage the interaction with the banks: connectivity, payment transmission, bank reporting and the complexity of working across different banking relationships. The bank, in turn, remains responsible for executing the transaction.
That separation sounds simple, but it matters. Problems often start when systems begin compensating for each other. The ERP becomes overloaded with bank-specific logic, the connectivity layer starts taking on processes that belong in finance, or local teams build workarounds because the target model was never clearly defined.
Good architecture avoids that. Each component should do what it is best at, while the overall process remains coherent.
The same principle applies to partners
The strongest implementations I see usually have one thing in common: the right expertise is involved at the right time.
An experienced ERP implementation partner understands the financial process, the data model and how the ERP should be configured. A banking connectivity specialist understands bank onboarding, payment formats, communication methods, account structures and the practical realities of dealing with multiple banks. The customer understands its own business, operating model and priorities.
When those perspectives come together early, the project becomes much stronger. Not because more parties are involved, but because fewer assumptions are made and the responsibilities become clearer.
This is also where experience matters. A partner that has implemented similar setups many times before will recognise risks earlier. They know where bank onboarding tends to take longer, when payment testing should start, where standardisation is likely to create value and where a specific exception may genuinely be necessary.
That kind of experience is difficult to capture in a project plan, but it has a major impact on execution.
A good partner should also challenge you
I think this is an important part of the partner role.
A good implementation partner should not simply deliver exactly what the customer asks for if the design creates unnecessary complexity. They should be willing to challenge the assumptions behind it.
If a company wants separate banking processes for every entity, the partner should ask whether that is really necessary. If the customer wants to recreate a highly manual process in a new ERP, the partner should question whether that is the right target state. If every bank is going to be connected differently, the question should be whether that will still make sense when the organisation has doubled in size.
The objective of a transformation should not be to reproduce the current environment more efficiently. It should be to create a better one.
This is also why standardisation needs to be intentional. Which entities should follow the same payment process? Where should approvals sit? Who should own banking access? How should new banks or entities be onboarded? Which differences are genuinely required and which are simply historical?
Those decisions shape the scalability of the environment long before the technical configuration begins.
Future-proof does not mean predicting everything
The term “future-proof” is often used too loosely. No organisation can predict exactly what its finance environment will look like in five years, and that is not the point.
A future-proof architecture should simply make change easier.
Adding a new bank should not require redesigning the ERP. Adding a new entity should not mean creating an entirely new payment process. An acquisition should not force the organisation to start from zero. Changing a banking relationship should not require rebuilding the full finance flow.
This is what scalability really means in practice: reducing the amount of rework required when the business changes.
The best implementations create a repeatable model. The first implementation may take the most design effort because the process, roles and integration model need to be agreed. But once that foundation is in place, the next entity or bank should be easier to add because the organisation is extending a proven model rather than inventing a new one.
The value often becomes visible after go-live
ERP and banking projects are often measured heavily on implementation milestones: was the project delivered on time, did the system go live, did the integration work?
Those are important questions, but they are not the final test.
The more meaningful questions come afterwards. Can finance operate more efficiently? Can a new entity be onboarded faster? Can treasury see cash more clearly? Can payment processes be governed consistently? Can the organisation add another bank without redesigning the architecture?
That is where the real value of the infrastructure becomes visible.
At Cobase, we see our role as making the connection between the ERP and the banking landscape more scalable and manageable. The ERP remains the financial core. Cobase manages the banking connectivity layer. The implementation partners bring the ERP and process expertise. The customer owns the operating model.
When those roles are clear and the parties work together early, the architecture becomes easier to maintain and much more capable of supporting future growth.
The final lesson
After seeing hundreds of organisations go through finance transformation, the biggest lesson for me is that the right solution is rarely about choosing one system.
It is about choosing the right combination: the right ERP for the company, the right connectivity model for the banking landscape, the right operating model for finance and the right partners to bring it all together.
That combination should solve the problems the organisation has today, but it should also make tomorrow easier.
Good financial infrastructure should give finance more control without adding unnecessary complexity. It should make growth easier rather than harder. And it should allow the organisation to evolve without rebuilding the foundation every few years.
That, ultimately, is what a scalable and future-ready finance architecture should achieve.
This is the fourth and final article in a four-part series on ERP-to-bank connectivity and modern finance infrastructure.
