We only recommend systems built for the cloud and for AI. Not because it is fashionable, but because the alternative is paying enterprise money for constraints that were reasonable in 2005. Here is what we mean by modern, in the order we test it.
UX first
The user interface is not a coat of paint. In a modern ERP the interface is generated from the business object: add a field, and the form, the list, the search, the import, the export and the API all know about it. In older systems each of those is a separate development task, which is why "small changes" cost weeks.
We expect the interface to behave the way your people already expect software to behave: predictable placement, keyboard-friendly, search everywhere, undo where it matters. That expectation is set by the phone in their pocket, and it will not be lowered for the ERP.
Infrastructure-agnostic and responsive
Browser-based, on any device, without client installs or terminal servers. A warehouse worker on a scanner, a technician on a tablet in the field, a CFO approving a payment on a phone, an accountant on two monitors: one system, one login, layouts that adapt. Anything that requires "the ERP PC" fails this test.
API first
Every function the interface can perform must be reachable programmatically, for standard objects and for your custom ones. Three reasons:
Integration is no longer optional
E-invoicing networks, banks, payroll providers, web shops and tax engines connect through APIs or not at all.
Automation is moving from scripts to agents
AI agents will act on your ERP through its API, not by clicking through screens. A system with a beautiful interface and a thin API is closed to that future.
Evolution
An API-first platform lets you extend without forking, which is what keeps you on the upgrade path.
Scalability in the cloud
Elastic capacity for month-end, year-end, peak season and the acquisition you haven't announced yet. But scalability is a property of the architecture, not of the hosting: a shared application database that slows for every tenant at quarter-end is not scalable, whatever the brochure says.
Built for AI
AI in ERP is only as good as the data model underneath it. Clean master data, explicit processes and a coherent object model are the prerequisites; the assistant is the easy part. We assess AI readiness by asking what the system knows, not what the vendor demoed.
Why we still won't go "full cloud" on the vendor's terms
Here we depart from the brochure. Built for the cloud must not mean chained to one cloud. Public cloud, private cloud and on-premise are different answers to different questions: data ownership, sovereignty, latency, exit. For a Swiss family business with sensitive customer or engineering data, a private deployment can be the right call; for a fast-growing trading company, multi-tenant SaaS is. The system should allow the choice, and the choice should be yours, reversible and documented.
The same logic applies to your AI: models that touch sensitive business data should be able to run in isolation.
Why platform versus best-of-breed is still a conscious decision
Every ERP vendor promises to do everything. None does everything well. The right architecture is a deliberate mix. The platform owns the transactional spine (procure-to-pay, order-to-cash, inventory, finance) and the master data. Best-of-breed applications own depth where depth is decisive: country payroll, e-invoicing and tax clearance networks, warehouse execution, product data, analytics.
The mistake is not choosing one or the other. It is not choosing at all. Panorama Consulting's 2026 ERP Report found that among organisations over budget, the most common cause was an unexpected need for additional technology: misfits discovered late in the project 3. That is accidental architecture. We make the boundaries explicit before selection, so integrations are designed rather than discovered.
We draw what the platform has to hold together as three circles. Each outer circle is the breadth a business needs; its inner circle is the depth that decides the fit. The centre is where all three must work at once.
Use the arrow keys to move between the circles.
Outer circle
Platform ERP
One platform for the transactional spine: shared master data, one permission model, one interface and one API. A new requirement extends the platform instead of adding another system beside it.
In a demonstration we ask for a new approval rule and a role-specific view, and for both to survive an upgrade.
Inner circle
Low code, visual editor
Trained business specialists change fields, forms, views, rules and reports in a visual editor, without a development project. It shortens the distance between a process need and a working improvement, as long as every change has an owner.
We ask to see a new field added once and then used on a form, in a list, in a report and through the API, without code.
Outer circle
Multi-currency, multi-branch, global entities
The starting point for a business that trades across borders: invoices and payments in several currencies, more than one branch or site, and legal entities in more than one country.
We ask to see a foreign-currency invoice paid at a different rate, with the exchange difference posted where your accountant expects it.
Inner circle
Multi-ledger, multi-base-currency, multi-company
The depth behind global entities: each company keeps its own books in its own base currency, parallel ledgers hold different accounting treatments such as local GAAP and IFRS, and companies trade with each other inside one system. Multi-company alone does not mean multiple base currencies or parallel ledgers, so we test each one.
We ask to see your own entity structure: a transaction between two companies with different base currencies, and the consolidated view.
Outer circle
Modules for inventory, assets and services
Goods, assets and people's time follow different lifecycles. Stock is received, moved and sold; an asset is bought, maintained and depreciated; a service is planned, delivered and billed. The platform's own modules cover all three on the same customers, items and accounts.
We ask to see the joins: equipment sold with installation, and a service contract that consumes spare parts.
Inner circle
Projects combining inventory and time
Where the modules meet: one project consumes stock and people's time and bills both against one commitment. A capable project module and a capable inventory module do not, by themselves, establish that materials can flow through a service job with the required costing, ownership and billing.
We ask to see a project that consumes stock and approved time, including a change, a return and a billing exception.
Where the circles meet
The centre
A project across legal entities combines stock, people's time, currencies and local reporting, and a workflow changed in the editor must keep the right approvals and accounting throughout. This is what we look for in a modern ERP: all three circles in one platform and one data model.
Three convincing module demonstrations do not prove that the combined process works, so we test the centre explicitly.
Why UX is king
Because the people who decide on an ERP (managers, architects, consultants, developers) are not the people who will drive it every day. If the daily drivers cannot feel the controls, they stop looking at the dashboard. They keep their own list. Data quality collapses, and everything downstream (reporting, forecasting, AI) inherits the collapse. Garbage in, garbage out is not a technical failure. It is a UX failure that becomes a finance problem.
Sources
All regulatory statements as of September 2026.
- Panorama Consulting Group, The 2026 ERP Report: panorama-consulting.com (PDF: 4439340.fs1.hubspotusercontent-na1.net)