Why do ERP systems still differ?

Most ERP demonstrations cover familiar ground: customers, suppliers, invoices, inventory, projects, and reports.

The differences become more consequential when you ask how those elements relate. What is a company? What triggers revenue? Where is a cost collected? Can a project own stock? Which information must survive a correction?

An ERP embodies assumptions about how organisations work. Some are visible in the interface. Others sit deep in the transaction model, accounting engine, and security structure.

We look at those assumptions before deciding whether a product is a good fit.

1. Geography
2. Industry
3. Size and budget
4. Product history

1. Geography: where the business must work

We begin with the jurisdictions in which the business operates and reports. A missing capability here can exclude an otherwise attractive system.

Europe and the United States provide useful contrasts, but neither is a single operating environment. The applicable accounting framework, legal entities, tax registrations, business activities, and local practices matter more than a continental label.

Accounting is more than a chart of accounts

Consider the presentation of expenses. German commercial law permits both the Gesamtkostenverfahren and the Umsatzkostenverfahren. The distinction changes the information needed to explain performance: expenses by their nature, or costs associated with the functions that generated revenue. The requirement needs to be established for the reporting framework in use. ⁴

The ERP consequence extends beyond the final report. We need to know where costs are captured, how inventory changes are represented, how allocations work, and how the management view reconciles to the statutory accounts.

Revenue introduces another dimension. Under IFRS 15, revenue follows the satisfaction of performance obligations. That can require the system to connect contract terms, delivery or service evidence, allocation, billing, and recognition. An invoice alone may not contain the information needed. ⁹

This makes the relationship between commercial documents and accounting events an evaluation question. It does not mean that every order is a performance obligation or that an order should automatically create recognised revenue.

We also examine accruals and deferrals, asset acquisition and depreciation postings, parallel accounting requirements, period controls, and correction procedures. The requirement is to produce the correct accounting outcome with a traceable process, including where an interim posting must subsequently be adjusted.

Indirect tax changes the transaction design

A tax rate is only one part of the problem.

The system may need to consider the nature of the supply, the customer or supplier's status, the place of supply, exemptions, recoverability, and reporting obligations.

VAT reverse charge and US use tax illustrate why similar-looking self-assessment processes need distinct treatment. UK reverse charge rules for services can require the recipient to account for output tax and, subject to entitlement, input tax. California use tax concerns the use, storage, or consumption of taxable merchandise where the corresponding tax has not been collected. These are different tax mechanisms. ^{31, 32}

Even within one country, geography can affect the calculation. Canada's GST/HST guidance ties the applicable rate to place-of-supply rules and distinguishes provincial situations. A country code alone is insufficient. ³³

In evaluation, we trace representative transactions through calculation, posting, settlement, correction, and filing. We examine treatment by line or supply category, rounding, non-recoverable input tax, and the reconciliation between tax records and the general ledger.

Structured invoicing and digital reporting make those connections more important. The EU's ViDA programme explicitly connects electronic invoicing with digital reporting and fraud prevention. Local mandates and effective dates must be checked separately. ¹⁴

Local operations reach well beyond tax

The practical questions include:

• Closing and audit

  Can the business control periods, preserve posting history, apply required numbering, and provide the records and exports its accountants and auditors need?

• Reconciliation

  Can teams match and clear open items, investigate a balance, and explain the relationship between subledgers, tax reporting, and the general ledger?

• People and payroll

  How do working time, leave, benefits, expenses, social contributions, and local payroll connect to finance and project costs?

• Banking

  Which banks, payment formats, authorisation methods, statement feeds, and reconciliation processes must be supported?

• Collections and cash

  How are reminders, staged dunning, disputes, cheques, and cash transactions handled where they are relevant?

• Language and documents

  Can users work in their languages while invoices, reports, and external communications meet the recipient's requirements?

For banking, names need careful interpretation. EBICS is a bank communication standard with a European footprint; open banking addresses another set of connectivity and service needs. The UK also has a developed open-banking ecosystem. We assess the actual bank service and process rather than infer coverage from a broad regional label. ^{35, 34}

Local tax advisers and auditors belong in this discussion early. Their role is to clarify requirements and workable evidence, while the business retains ownership of its operating model.

Multi-everything: growth changes the relationships

Multi-company, multi-currency, multi-language, and multi-ledger capabilities are valuable because the business may change shape.

A branch, legal entity, reporting segment, and tax registration serve different purposes. We establish how the product represents each one and what that means for permissions, shared master data, transactions, and reporting.

Foreign currency also requires more than entering an exchange rate. Which rate source and date apply? How are transactions settled and revalued? How does group reporting translate the result, and where are translation differences explained?

The demonstration should follow an actual scenario: a second company, a transaction between companies, a different functional currency, and a consolidated view. The amount of reconciliation and manual administration required tells us more than the presence of a “multi-company” feature.

2. Industry: how the business earns its margin

Industry fit is best assessed through the flow of work, goods, money, and responsibility.

Manufacturing

Manufacturing requires a coherent relationship between materials, capacity, production progress, inventory value, and cost.

Cost types, cost centres, and cost objects help answer different questions: what was consumed, where responsibility lies, and what the cost belongs to. The cost object may be a product, production order, service, or project. Those concepts need to remain distinct even when a modern system presents them through common dimensions.

Distribution

Distribution puts pressure on purchasing, availability, fulfilment, warehouse execution, landed costs, pricing, and returns.

A system can have each feature and still create friction between them. We therefore follow the order through its exceptions: partial receipt, substitution, partial delivery, credit, return, and margin analysis.

Businesses built around assets

Asset-intensive businesses need to connect the financial asset with its operational life.

Maintenance, availability, utilisation, inspections, replacement decisions, and asset costs may require specialised systems. Evaluation establishes what belongs in the ERP, what belongs in an asset or maintenance application, and how the two remain consistent.

Services built around people's time

For professional and field services, capacity is perishable: unused time cannot be stored and sold next month.

Planning, skills, utilisation, chargeability, time capture, expenses, billing, and project forecasting need to work together. Improving one measure in isolation can hide problems elsewhere. High utilisation does not establish that the work is profitable, billable, or sustainable.

Services combined with goods and assets

This is where we pay particular attention.

A business may sell an ongoing service agreement, carry out a project, install equipment, consume spare parts, and subcontract specialist work under one customer relationship.

Those activities cross familiar module boundaries. 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.

Engineer-to-order businesses and maintenance organisations encounter different versions of this problem. We trace the complete commercial and operational lifecycle, including changes, warranty obligations, recurring charges, and the margin that management ultimately wants to understand.

Financial businesses

Where financial instruments are central to the business, valuation, positions, transaction volumes, and reconciliation with specialist systems require explicit attention.

A general ERP may provide the corporate accounting foundation while specialised applications manage the instruments and associated calculations. That boundary should be designed deliberately.

3. Size and budget: what the organisation can sustain

The right product must fit the organisation that will administer it.

We examine transaction volumes, organisational complexity, internal expertise, partner availability, implementation capacity, and the cost of change. A solution that depends on specialist administration deserves a realistic staffing and support model.

Affordability includes the years after purchase: integrations, upgrades, controls, training, and the work created when the standard product does not fit.

4. Product history: the assumptions that remain

The earliest customers and the problems a product was built to solve can leave lasting marks.

An accounting-led design may centre on ledgers and financial documents. A manufacturing-led design may centre on materials and production. A newer platform may give analytical dimensions and configurable business objects more prominence.

These are hypotheses to test in the product, not conclusions to draw from a founder's biography.

We examine the current data model, supported extensions, update process, and evidence of continuing investment. Mature software can provide depth and stability. It can also carry constraints that are difficult to change. Modular architecture and a broad community may help, but they still require coherent ownership and upgrade discipline.

A release announcement matters less than the product's ability to improve the workflows on which your business depends.

The two platforms we implement

The same questions shape our own recommendations. NetSuite was the first ERP built for the internet era. It was born in the United States, and in our assessment its European localisation keeps falling behind. That is why we recommend Odoo more and more often for a European footprint. NetSuite keeps its place in Europe in pure finance, in software and, less and less, in eCommerce.

Odoo had to reinvent itself. Its chief executive put other projects on hold for several years to carry the move to the cloud, and the new Odoo platform is built for it.

What this changes in our approach

We translate each material difference into a scenario that the proposed solution must demonstrate.

Can the local accountant close and explain the books? Can a technician complete a job and return unused stock? Can the business add an entity without rebuilding its reporting? Can the next administrator understand why the solution works as it does?

Those questions reveal the consequences of the architecture.