writing/blog/2026/08
BlogAug 6, 2026·6 min read

The ERP Trap: Why a New ERP Won't Fix Your Data

Gulf operators call it the ERP trap. The problem is rarely too few systems — it is too many that do not talk. How to tell which problem you actually have.

A board chairman asks a simple question: how much is our group earning right now?

Silence. Maybe twelve seconds of it. The CFO opens three reports. The IT director starts explaining which systems are in place. Each subsidiary sends back a different spreadsheet. Nobody can produce a single number.

This is not a story about a company that lacks systems. It is a story about a company that has too many.

The pattern has a name now

Saudi operators have started calling it "مقلب الـERP" — the ERP trap. The shape is consistent enough that people recognise it instantly when it is described.

A trading business grows. Revenue passes a threshold where informal coordination stops working. Branch invoices pile up, the online store does not agree with the warehouse, and month-end close starts taking three weeks. The owner asks for advice and hears the same answer everywhere: you need an ERP.

So they buy one. And two years later, the chairman still cannot get his number.

What makes this worth writing about is not that it happens. It is how widely and how independently people are now saying it out loud:

  • One enterprise architect with nine years in the field puts it bluntly: the biggest lie sold to holding companies today is that they need a new ERP. The problem in most groups is not a shortage of systems, it is an excess of them. One subsidiary on an ERP, one on Excel, one running operations over email and WhatsApp, one with dozens of apps that do not talk to each other.
  • A consultant writes that he is astonished at companies paying hundreds of thousands of dollars for ERP and CRM systems and ending up using under 10 percent of the capabilities.
  • Another notes that the most common cause of ERP implementation failure is treating it as a technical problem, when it is actually an enterprise strategy that cuts across every part of the organisation.

Even the ERP vendors have noticed. At least one regional ERP company is now spending advertising money not on its ERP, but on a separate integration and automation product that connects its ERP to everything else. Their own pitch says it plainly: the ERP alone is no longer enough.

When the vendors start selling the layer above the product, the market has moved.

Why buying a bigger ERP makes it worse

An ERP is a system of record. It is very good at being the authoritative place where one category of truth lives — usually finance, inventory, or procurement.

The problem in a growing group is not that any single record is missing. It is that there are five authoritative records and no agreement between them. Sales lives in the CRM. Stock lives in two warehouse systems because one branch was acquired. Cash lives in the accounting package. Fulfilment lives in the e-commerce platform. Each one is internally correct and collectively useless.

Buying a bigger ERP does one of two things:

  1. It replaces one of the five. You now have a more expensive system of record and the same four disagreements. This is the common outcome.
  2. It attempts to replace all five. This is the migration that takes eighteen months, consumes the operations team, and gets abandoned at 60 percent — leaving you with six systems instead of five.

Neither produces the chairman's number, because the chairman's number was never a record. It is a derived figure that requires reading across systems. No single system of record can produce it, no matter how large.

The question that separates the two problems

Before spending anything, it is worth establishing which problem you actually have. The diagnostic is not complicated:

You have a systems problem if: a specific business function genuinely has no software behind it. Nobody is tracking maintenance. Payroll is done by hand. There is no procurement process at all. In that case, buy the system — you are missing a system of record.

You have an integration problem if: every function is covered, but answering a cross-functional question requires a human to open several applications and reconcile them manually. Signs to look for:

  • Month-end close takes longer than a week, and most of that time is reconciliation rather than analysis.
  • Two departments quote different numbers for the same metric and both can defend theirs.
  • Somebody maintains a spreadsheet whose only job is to combine exports from two other systems.
  • A new report takes weeks because the data has to be assembled before it can be analysed.
  • Your team can tell you what happened last month but not what is happening this week.

If you recognise three or more of those, a new ERP will not help you. You do not need another place to put data. You need the data you already have to become one connected picture.

What actually fixes it

The work is unglamorous and much smaller than a migration. It has three parts.

Connect what exists. Most business systems today expose an API, and the ones that do not can usually be reached through their database or scheduled exports. The goal is not to move anything — it is to let systems exchange what they already know. Our guide on connecting AI and automation to your existing stack covers the architectures and patterns for this in detail.

Establish one reporting layer. Not a new system of record — a place where figures from all systems are brought together, reconciled once, and defined once. "Revenue" should mean exactly one thing across the group, and that definition should live in one place rather than in five people's heads.

Automate the reconciliation, not the reporting. Most organisations automate the wrong end. They build dashboards on top of numbers that still require manual assembly, which means the dashboard is only as fresh as the last person who updated the spreadsheet. Automate the joining and matching first. The reporting is the easy part once the data agrees with itself.

Done in this order, the chairman gets his number in weeks rather than quarters, and you keep every system you already paid for.

In Saudi Arabia, compliance is forcing the issue anyway

There is an additional reason this is urgent for businesses operating in the Kingdom.

ZATCA's Phase 2 for e-invoicing — the linking and integration phase — is rolling out in waves by revenue threshold, and it does not merely ask you to issue electronic invoices. It requires your invoicing systems to connect directly to the Fatoora platform. That is an integration requirement written into law, applied on a published schedule, with penalties attached.

Organisations that already treat integration as a discipline absorb each wave as routine work. Organisations running five disconnected systems discover, on a deadline, that they cannot cleanly answer where an invoice came from. We have written separately on the specific gotchas from real Saudi rollouts and on the broader Fatoora e-invoicing requirements — check which wave applies to you, since the schedule is set by your VAT-liable revenue and the notification comes to you directly.

The point is that compliance turns an operational annoyance into a dated obligation. If the systems were going to have to talk eventually, it is cheaper to make them talk deliberately than under a deadline.

The bottom line

The ERP trap is not caused by bad software. Most of these systems work exactly as designed. It is caused by a diagnosis error — treating an integration deficit as a systems shortage, and buying accordingly.

The test is simple. If a question about your business requires a person to open more than two applications and reconcile them by hand, the answer is not another application.

We do not sell ERP systems, which is precisely why we are comfortable saying this. What we do is connect the systems our clients already own, so that the number exists before somebody asks for it. If that twelve seconds of silence sounds familiar, tell us what your stack looks like and we will tell you honestly whether you have an integration problem or a systems one.