In the first article of this series, I looked at why ERP-to-bank connectivity deserves a place in the wider finance architecture. The next question is a very practical one: when should companies start thinking about it?
My answer is usually: earlier than they think.
Ideally, bank connectivity should be considered before or alongside an ERP implementation, not after the ERP design is already largely fixed. That does not mean making the ERP programme bigger. It means making sure that the full financial flow is understood early enough to avoid unnecessary rework later.
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.
A typical ERP programme already involves a long list of decisions around processes, master data, approvals, reporting, integrations and testing. Because of that, bank connectivity can easily end up being treated as something to solve later: first get the ERP live, then connect the banks.
The problem is that banking is not just another external system. It is part of the same finance process.
If payments are created in the ERP, you need to know how they are transmitted, where approval takes place, what information comes back from the bank and how reconciliation will work. If those questions are answered only at the end of the project, parts of the ERP design may already need to be revisited.
That is why I prefer to start with the target process rather than the technical interface. Before deciding on protocols or formats, companies should be clear about where payments originate, where they are approved, how bank information returns to the ERP, which teams need visibility and how much of the process should be centralised.
Once that operating model is clear, the technical design becomes much easier.
One of the most important distinctions is between the target architecture and the functional rollout.
A company may decide that it only wants automated bank reporting in the first phase. Payments may come later. That can be a perfectly sensible approach.
But if the same banks and accounts will eventually be used for payments as well, it is worth considering that future setup during the initial implementation.
Why? Because connecting to banks can involve more than just technical configuration. There may be onboarding paperwork, authorisations, certificates, bank-side setup, file validation and testing. If the long-term objective is already clear, it can be more efficient to prepare the infrastructure once and activate additional functionality later.
I often use a simple analogy: install the wiring while the walls are open. You do not need to switch everything on immediately, but if you already know where you are going, it makes little sense to reopen the wall six months later.
This is also why phased rollouts can work very well. A company can start with one country, one group of entities or a limited number of banks, validate the end-to-end process and then extend the model. The key is that those phases are all part of the same architecture.
Another reason to start early is that bank connectivity introduces dependencies that the ERP team does not always control.
Depending on the bank and the type of connection, onboarding can require documentation, technical configuration, security certificates, account-level permissions and testing. Payments may also require specific authorisations or agreement changes.
That means bank connectivity should be included in project planning as a real workstream, not assumed to be something that can be switched on at the end.
This is one of the areas where experienced partners can help. If you know early which banks, countries and accounts are in scope, you can identify the likely requirements, sequence the work properly and avoid discovering a critical dependency just before go-live.
Timing also matters because good testing needs to be end to end.
It is not enough to confirm that the ERP can generate a valid payment file. A much better test is whether the payment can be created, transmitted, processed by the bank, returned with the right status information and ultimately reconciled correctly.
The same applies to bank reporting. Receiving a statement is one thing; making sure the data lands correctly in the ERP and supports the intended reconciliation process is another.
If bank connectivity is brought in too late, testing can become compressed or split into separate phases. That increases the risk that the ERP is technically live before the full finance process has really been proven.
For me, that is one of the strongest arguments for bringing the banking side into the discussion earlier. It allows the organisation to test the process it actually wants to operate, rather than just the ERP in isolation.
There is sometimes a concern that introducing bank connectivity early will make the ERP project too complex.
In my experience, the opposite is often true.
The aim is not to activate every bank, every payment flow and every country from day one. The aim is to make the right architectural decisions early enough that later phases become easier rather than harder.
A practical rollout can still be phased. Reporting can go live before payments. One country can be used as a first scope. A limited group of banks can be onboarded first.
What matters is that the company understands the destination before building the first phase.
That reduces the risk of temporary integrations becoming permanent, of processes being redesigned twice or of banks having to be approached again for avoidable configuration work.
When we start working with a company around ERP-to-bank connectivity, we usually want to understand the target setup before going too deeply into technical detail.
Which ERP is involved? Which banks and accounts are in scope? Is the requirement reporting, payments or both? Where should approvals sit? Which countries or entities make sense for a first rollout? What does the company expect its finance operating model to look like in a few years?
Those questions give us the context needed to design a practical path.
For some organisations, that means starting with a small first scope and expanding. For others, it makes more sense to prepare a broader banking setup from the start. There is no single rollout model, but there should be a clear architectural logic behind it.
That is the important point: the implementation can be phased, but the thinking should not be fragmented.
An ERP implementation is actually a very good moment to address this.
The company is already reviewing processes, cleaning data, defining controls, making integration decisions and thinking about the future operating model. That creates a natural opportunity to ask how banking should fit into the same picture.
If that conversation happens early, the organisation can design one coherent flow from ERP to bank and back again.
If it happens only after go-live, the company may find itself starting a second integration project immediately after finishing the first.
For me, the better principle is simple:
Design early, implement pragmatically and activate functionality when the organisation is ready.
That gives companies the flexibility to move in phases without creating unnecessary work later.
In the next article, I will look at what happens when organisations scale across more entities, countries and banks — and why banking complexity often grows much faster than expected.
This is the second article in a four-part series on ERP-to-bank connectivity and modern finance infrastructure.