The conversation usually starts with the platform. "We are evaluating NetSuite versus S/4HANA." "Should we move from Business Central to D365 F&O?" "Our board wants Xentral." The question feels like the strategic question, because the answer comes with a price tag, a migration roadmap and a vendor pitch. It is not.

The strategic question — the one that decides whether the next five years run smoothly or burn through three CFOs and a board re-shuffle — sits one level above. It is the question of architecture: how ERP, finance, operations, governance and the surrounding systems hold together as one operating model. The platform is what serves that architecture. Not the other way around.

What "architecture" actually means here

We are not talking about Visio diagrams. We mean the small set of decisions that, once taken, determine the shape of every subsequent build — and how expensive it will be to change them later.

For international groups, those decisions cluster into five layers:

  1. Operating model. Which entities, which countries, which legal flows. Centralised, federated, hybrid. This is not an IT question; it is a governance question that IT has to follow.
  2. Finance architecture. Chart of accounts, multibook, intercompany model, tax architecture, consolidation logic, reporting layer. The shape of the numbers — before the first module.
  3. Master data and process architecture. Customer, item, supplier, project — and the processes that move them. Where data is born, where it is governed, where it is consumed.
  4. System landscape. ERP plus the adjacent systems that always show up: CRM, EPM, HRIS, e-commerce, WMS, BI. What lives inside the ERP, what lives outside, and how the seams are designed.
  5. Operating governance. Who owns what after go-live. Change management, release governance, incident pathway, audit posture. The part that everyone postpones — and pays for later.
If those five layers are decided well, the platform choice becomes a logical consequence. If they are not, the platform choice becomes a coin toss between two equally expensive mistakes.

Why "platform-first" fails so reliably

When the platform is chosen first, every subsequent decision becomes a hostage of that choice. The chart of accounts is shaped to fit whatever the platform makes easy. The consolidation logic is reverse-engineered from the platform's reporting structure. Intercompany flows are bent to match the platform's elimination model. Master data is centred on the platform's record types. By the time the architecture conversation actually happens — usually six months in, when the first regulatory question hits — it is too late. The architecture has already been quietly written by the implementation consultants, optimised for delivery speed, not for the operating model.

This is also where the classical reseller incentive becomes visible: the platform choice is where the margin sits, so the platform conversation comes first. That is not a conspiracy theory; it is just how that business model is structured. It works fine in simple, single-entity environments. It produces predictable damage in international, multi-entity, finance-deep operations.

The assessment-first model

The alternative is straightforward — and it is how we work inside the group: a two-week assessment that produces a one-page target-architecture sketch before any platform conversation lands.

The assessment covers:

  • Operating model and legal flows — what the group actually is.
  • Finance architecture — chart of accounts logic, multibook need, intercompany pattern, statutory and group reporting handover.
  • System landscape — what already exists, what stays, what needs to leave.
  • Industrial and operational depth — manufacturing, services, retail, regulated activity.
  • Time, budget and risk window — what can actually be carried, by whom, in what sequence.

The output is not a 60-slide deck. It is a one-page sketch of the target architecture, a short list of platforms that can carry it, and a clear reading of which one is the best fit for this operation — with the trade-offs named, not hidden.

Key takeaway

Choose the architecture first. Let the platform follow. The platform is a tool that serves the architecture — not the strategy that defines it.

What this looks like across the JPS-iQ portfolio

Inside the group, this principle is the reason we are deliberately ERP-agnostic. The architecture decides which platform makes sense — not the other way round.

  • For mid-market services and retail with multi-entity finance depth: NetSuite tends to be the cleanest fit.
  • For commerce volume and DACH-process realism: Xentral often carries further than people expect.
  • For Microsoft estates with a controlled growth path: Microsoft Dynamics 365 / Business Central.
  • For regulated manufacturing and finance-control-heavy environments: SAP S/4HANA.
  • For globally distributed teams with strong CRM/finance integration needs and pragmatic budgets: Zoho.

Whatever the platform, OPCON carries the execution layer and BPO carries the finance operations — so the architecture stays accountable from blueprint into live operations, on every platform in the group.

What to do with this on Monday morning

If you are inside an active selection or a stalled programme, the most useful test is the simplest one: ask the next person who pitches you a platform whether they can describe your target architecture in one page without mentioning their product. If they can, listen. If they cannot, you are not in an architecture conversation. You are in a vendor conversation — and that is a different conversation, with different consequences.

For boards, CFOs and COOs, the practical move is to insulate the architecture conversation from the platform conversation. Run the assessment first. Take the platform decision afterwards, on the back of a sketch you can defend in front of the audit committee. The cost of doing that is two weeks. The cost of not doing it tends to be measured in years.