This article is written by our partner, Cobase

Oracle NetSuite is a cloud-based ERP platform designed to bring core business processes together in one environment, spanning financial management, reporting and consolidation as well as areas such as billing, projects, CRM and operations. Its multi-entity and multi-currency capabilities make it particularly relevant for organisations whose financial complexity increases as they expand internationally.

Around the core ERP sits a broad ecosystem of implementation partners, technology providers and integrated applications. As companies scale, this ecosystem becomes increasingly important. The ERP may sit at the centre of the finance architecture, but it also needs to connect effectively with the wider financial landscape, including banks, payment providers and other specialist applications.

One of the partners operating in this ecosystem is Novutech, a European finance transformation and NetSuite specialist supporting growing and international organisations with ERP implementation, integration and optimisation.

We spoke with Marta Obrador, Director, Business Transformation Practice & UK Lead at Novutech, about the type of companies NetSuite is best suited to, what makes ERP transformations successful and why bank connectivity should be considered as part of the wider finance architecture.

What type of companies are the best fit for NetSuite, and what makes the platform stand out from other cloud ERP solutions?

“For me, the best fit is really a company in motion: a business that is scaling quickly, expanding internationally or simply dealing with increasing financial complexity.

As organisations add entities, markets and currencies, finance needs more structure without creating more fragmentation. That is where NetSuite is particularly strong. It gives companies a single cloud-based foundation for financial management, consolidation and broader operational processes, while still giving them room to grow.

What matters is that finance teams gain the structure and visibility they need without having to redesign the whole environment every time the business changes.”

As an implementation partner, where do you add the most value and what do successful ERP projects tend to get right from the start?

“Our value lies in connecting people, processes and technology. An ERP project is never only about implementing a system. You also need to think carefully about how people will use it and how the processes around it should work.

The strongest projects usually get a few fundamentals right early on: clear ownership, good-quality data, the right integrations and, importantly, clear priorities.

I also think focus is critical. Companies sometimes try to solve everything at once. The better approach is to focus on what really matters, make good use of best practices and build a realistic path to adoption. That creates a much stronger foundation for the transformation.”

How are customer expectations around finance and treasury changing, and what does that mean for the role of the ERP?

“Finance is moving away from simply recording what happened in the past. Teams are increasingly expected to provide insight, support decisions and help shape what happens next.

That changes the role of the ERP as well. It needs to become a trusted platform for decision-making, not just a place where transactions are recorded.

At the same time, the ERP cannot operate in isolation. If you want finance processes to become truly efficient, it also needs to connect well with banks, payment processes and the wider finance technology landscape. That is where the conversation increasingly moves from ERP alone towards a more connected finance architecture.”

Where does ERP-to-bank connectivity typically become challenging, particularly for companies operating across multiple banks and countries?

“The real challenge is not usually connecting to one bank. Complexity starts to build when a company has several banks, entities, countries, accounts and payment formats, but still wants one consistent process.

Without the right connectivity layer, that complexity often ends up with the finance team. People are moving between bank portals, uploading or downloading files, fixing exceptions and reconciling transactions manually.

As the organisation grows, that becomes increasingly difficult to scale. You may have implemented a strong ERP, but if the banking side remains fragmented, a lot of manual work still remains. Ideally, you want to abstract that complexity away from the finance team.”

What does a strong ERP-to-bank setup look like to you, and what should companies consider when designing it?

“For me, a strong setup creates one trusted flow from payment creation in the ERP through to bank execution and then back into reconciliation and reporting.

Automation is obviously important, but it should never come at the expense of control. You still need clear visibility, the right approvals and enough flexibility to support how the organisation operates.

Companies should also think beyond the situation they have today. If you know you are likely to add entities, countries, banks or accounts, the architecture needs to support that. It is much better to design connectivity as part of the overall finance architecture than to keep adding separate bank interfaces over time.”

Why do you like working with Cobase, and what does combining your ERP expertise with Cobase’s banking connectivity bring to customers?

“What we like about the combination is that it extends the value of NetSuite beyond the ledger and into the day-to-day banking and treasury processes.

NetSuite provides the financial core, while Cobase creates a consistent connection between that core and the banking landscape. For internationally growing companies, that is particularly relevant because the number of banks, accounts and entities can increase quite quickly.

Customers should not have to choose between having a strong ERP and having strong banking connectivity. By combining our NetSuite and transformation expertise with Cobase’s multi-bank connectivity, we can help create a finance architecture that is much more connected and scalable.”

Also Read

• Bank Connectivity: What ISO 20022 really solves and what it doesn’t
• The story behind Europe’s Instant Payments Regulation
• Bank Connectivity: Global expansion meets local banking reality
• Bank Connectivity: The long failure to standardise banking
• Perfecting the art of Bank Connectivity
• Bank Connectivity: The myth of the global bank

---

Join our Treasury Community

Treasury Masterminds is a community of professionals working in treasury management or those interested in learning more about various topics related to treasury management, including cash management, foreign exchange management, and payments. To register and connect with Treasury professionals, click the button below.

This article is written by our partner, Cobase

ISO 20022 was supposed to unify banking. It probably won’t.

Few projects in modern banking have carried as much expectation as ISO 20022.

For years, it has been described as the future language of global finance, a common standard that would finally allow banks, payment systems, corporates, and financial institutions to communicate in a structured, consistent way. Richer data. Better interoperability. Fewer errors. Faster processing.

After decades of fragmented formats and incompatible messaging systems, ISO 20022 arrived with something close to utopian ambitions: the idea that banking might finally start speaking the same language.

And in one important sense, it is already changing the industry.

The migration is enormous in scale. SWIFT cross-border payments, domestic RTGS systems, clearing infrastructures, and banks across major markets are moving from older MT messaging formats toward ISO 20022 XML-based messages.

The technical benefits are real.

Legacy payment messages were notoriously constrained. Fields were short, often unstructured, and inconsistently interpreted. Critical information – addresses, remittance details, compliance data was frequently truncated as payments moved across systems. ISO 20022 introduces far richer and more structured data models, improving straight-through processing, compliance screening, and automation.

In theory, this should reduce fragmentation.

In practice, the picture is more complicated.

Because ISO 20022 does not standardise banking behaviour. It standardises messaging.

That distinction matters.

Two banks can both be fully ISO 20022 compliant and still process the same payment differently. One may require additional fields. Another may reject optional data that a third bank accepts. One market infrastructure may implement a specific version of a message type, while another introduces local usage guidelines layered on top of the global standard.

The industry has already developed multiple “flavours” of ISO 20022:

• CBPR+ for SWIFT cross-border payments
• SEPA usage guidelines in Europe
• domestic variants for markets like the UK, Switzerland, and the US
• bank-specific implementation rules on top of all of them

So while the syntax becomes more aligned, the operational reality remains fragmented.

In many ways, ISO 20022 is repeating a familiar pattern in banking: harmonisation at the framework level, divergence at the implementation level.

SEPA followed a similar trajectory. It standardised payment schemes across Europe, but banks still implemented formats differently. Corporates discovered that “ISO compliant” did not necessarily mean “interchangeable.”

The same dynamic is emerging again.

And then there is the migration itself.

One of the lesser-discussed realities of ISO 20022 is that it does not replace the old world overnight. For years, legacy MT formats and ISO 20022 messages have coexisted across the global payment ecosystem. Translation layers became necessary. Data moved between old and new standards, sometimes losing structure along the way.

Even after formal migration deadlines pass, coexistence does not truly disappear. Banks continue running legacy infrastructure internally. Corporate ERP systems remain unevenly upgraded. Some channels fully support enriched ISO data, while others still rely on reduced mappings for compatibility.

The result is not a clean reset, but another layer added onto an already layered system.

This is particularly visible for corporates.

For treasury teams, ISO 20022 is often presented as a simplification initiative. In reality, it frequently increases short-term complexity. Payment files need updating. ERP integrations require modification. Validation rules become stricter. Banks introduce their own migration timelines and interpretation guides. A format that works with one bank may still require adjustments for another.

What changes is not the disappearance of complexity, but its shape.

This is where orchestration becomes increasingly important.

Platforms like Cobase sit between corporates and the banking ecosystem, absorbing many of these differences. Instead of treasury teams managing each bank’s ISO implementation directly, the orchestration layer handles format conversion, message enrichment, validation, and routing centrally.

A single payment instruction may need to be transformed differently depending on whether it is sent via SWIFT CBPR+, SEPA, EBICS, or a proprietary bank API. Structured address requirements may differ by market. Optional ISO fields in one implementation may become mandatory in another.

From the corporate perspective, the goal is not to master every variation of ISO 20022.

It is to operate through a layer where those variations are managed automatically.

That is ultimately the paradox of ISO 20022.

It absolutely improves the global financial system. The richer data, standardised structures, and interoperability gains are significant. It reduces friction. It improves automation. It creates a more modern foundation for payments infrastructure.

But it does not eliminate the deeper forces that created fragmentation in the first place:

national regulation, local market practices, bank-specific implementations, legacy infrastructure, and competing commercial incentives.

ISO 20022 may unify the language of banking. It will not fully unify the system speaking it.

Also Read

• ERP system: Building a connected finance foundation for growth – Novutech
• The story behind Europe’s Instant Payments Regulation
• Bank Connectivity: Global expansion meets local banking reality
• Bank Connectivity: The long failure to standardise banking
• Perfecting the art of Bank Connectivity
• Bank Connectivity: The myth of the global bank

---

Join our Treasury Community

Treasury Masterminds is a community of professionals working in treasury management or those interested in learning more about various topics related to treasury management, including cash management, foreign exchange management, and payments. To register and connect with Treasury professionals, click the button below.

This article is written by our partner, Cobase

For companies expanding internationally, the operational challenge is rarely the expansion itself. Hiring entities can be established. Suppliers can be onboarded. Customers can be reached.

What becomes unexpectedly difficult is something more foundational: moving money locally.

From the outside, modern banking appears global. In practice, payments remain deeply domestic. Every country has its own infrastructure, conventions, and assumptions about how money should move. The further a company expands, the more it discovers that “international banking” is often just a thin layer sitting on top of highly local systems.

The differences begin with the payment rails themselves.

In Europe, SEPA created the impression of a unified market. Payments move quickly, account structures are standardised around IBANs, and cross-border euro payments are treated much like domestic ones. But step outside that environment and the assumptions start to break down.

In the United States, for example, there is no IBAN system. Payments move through ACH, wire networks, RTP, FedNow, card rails each with different rules, speeds, costs, and use cases. Routing depends on account numbers and ABA codes rather than internationally standardised identifiers. A European treasury team entering the US often discovers that concepts they assumed were universal simply are not.

Elsewhere, the fragmentation becomes even more pronounced.

In India, payments increasingly move through UPI and domestic instant payment infrastructure that evolved around local consumer and business behaviour. In Brazil, Pix transformed the speed and accessibility of payments almost overnight, but operates within a domestic ecosystem that foreign companies must adapt to. China relies on an entirely different architecture again, shaped by local regulation and platform dominance.

What emerges is not a global payment system, but a collection of national ecosystems connected imperfectly to one another.

For multinational companies, this creates an uncomfortable reality: global expansion often requires becoming locally native in financial operations.

That affects not just how payments are made, but which banks can realistically support them.

A bank may offer “global payments,” but local payment capabilities vary significantly by market. In some countries, foreign banks lack direct access to domestic clearing systems and rely on local correspondents. In others, domestic payment schemes are so dominant that local banking relationships become unavoidable.

This is one reason companies expanding internationally rarely reduce banking complexity over time. They accumulate it.

A company entering five new markets may end up adding:

• five new local banking relationships
• five different onboarding processes
• five sets of payments formats
• five separate operational models for approvals, reconciliation, and reporting.

Even seemingly simple concepts become localised.

Take IBANs.

Within Europe, IBANs were meant to standardise account identification and reduce friction across borders. In practice, they introduced another phenomenon entirely: IBAN discrimination.

Despite SEPA rules explicitly prohibiting it, companies and consumers still encounter situations where foreign IBANs are rejected for payroll, direct debits, or supplier payments not because the accounts are invalid, but because organisations continue to expect domestic bank accounts.

A German employer may refuse a Dutch IBAN for salary payments. A French utility provider may reject a non-French account for direct debit collection. Businesses expanding internationally quickly discover that legal harmonisation does not always translate into operational acceptance.

So even inside supposedly unified regions, localisation persists.

Then there is the issue of scale – not technological scale, but institutional scale.

As companies grow internationally, they often assume their relationship with banks will evolve proportionally. Instead, they encounter another layer of segmentation: the bank itself.

Banks do not treat all corporates equally. They organise clients into segments – commercial banking, mid-market, corporate banking, multinational coverage, financial institutions, each with different service levels, product access, pricing models, and internal priorities.

For a growing company, this can create strange transitions.

A business may be considered strategically important in one country but too small to receive meaningful support in another. A treasury setup that worked well at €50 million in revenue may become insufficient at €500 million, triggering migrations to different banking teams, platforms, and approval structures.

The experience changes not only because the company grows, but because the bank’s perception of the company changes with it.

At smaller scales, onboarding may be relatively quick and standardised. At larger scales, complexity increases: more compliance checks, more documentation, more internal approvals. Access to advanced liquidity structures or connectivity methods may only become available once a company reaches certain thresholds.

In other words, expanding globally does not just mean adapting to foreign banking systems.

It also means adapting to how banks categorise you within those systems.

Over time, many treasury teams realise that international expansion is less about building a single global banking model and more about managing controlled inconsistency at scale.

This is where orchestration increasingly becomes essential.

Because the challenge is no longer simply accessing banks. It is managing the differences between them, between countries, payment rails, regulations, formats, and even the internal structures of the banks themselves.

Platforms like Cobase sit in the middle of that complexity. Rather than forcing companies to adapt operationally to every local variation, they create a consistent layer across fragmented banking environments. Local payment rails, global banks, regional formats, SWIFT, EBICS, APIs—all become part of the same operational framework.

The underlying fragmentation remains. A payment in Brazil still behaves differently from one in Germany. A US banking setup still differs fundamentally from a European one.

But from the treasury perspective, those differences become manageable.

And for companies expanding globally, that distinction matters more than the promise of a perfectly unified system.

Because that system was never truly global to begin with.

Also Read

• Bank Connectivity: The myth of the global bank
• Bank Connectivity: The long failure to standardise banking
• Perfecting the art of Bank Connectivity
• Treasury is where risk meets opportunity: Vincent’s perspective
• Cash visibility starts with the treasurer, not the system: Julia’s perspective

---

Join our Treasury Community

Treasury Masterminds is a community of professionals working in treasury management or those interested in learning more about various topics related to treasury management, including cash management, foreign exchange management, and payments. To register and connect with Treasury professionals, click the button below.