Shadow ERP: When Departments Buy Their Own Systems

The finance director discovers it during a reconciliation. Commission payments do not tie to the sales figures in the ERP, because the sales team has been running its pipeline in a CRM nobody in finance knew existed, and the numbers in that system are the ones the commission calculation was based on. This is shadow ERP. Not one rogue purchase but a pattern: departments buying operational systems that hold transactional data, run business processes and produce numbers that the official system of record knows nothing about. By 2013 it was widespread enough that IT departments had stopped pretending they had an application inventory.

Why Departments Bought Their Own Systems

It is tempting to frame this as indiscipline. It was mostly a rational response to conditions that IT had created. The ERP was genuinely bad at their job. General-purpose enterprise systems handle accounting, inventory and procurement well and handle field service scheduling, marketing campaign management, professional services delivery and recruitment poorly. A department with a specialised need was choosing between a purpose-built tool that worked and a module that did not. IT's timeline was measured in quarters. A request submitted in January entered a prioritisation process, competed with other requests, and might be scheduled for the following financial year. A SaaS subscription took a corporate card and an afternoon. When the alternative to eighteen months is one day, the decision is not close. The purchase fell below procurement thresholds. Eight hundred dollars a month on a departmental budget line requires no capital approval, no architecture review and no security assessment. The governance framework was designed for large purchases and was structurally blind to a hundred small ones. Nobody was accountable for the whole. Each individual decision was defensible. The sales director improved sales operations. The marketing manager improved campaign management. The HR lead improved recruitment. No single person was responsible for the consequence of all of them together, which is where the cost landed.

What It Actually Costs

The cost is almost never the subscriptions, which is why the problem persists. It is the reconciliation, and it is carried by finance. The numbers disagree and someone has to resolve it. Revenue in the CRM, revenue in the ERP, revenue in the billing platform. Three figures, three definitions of when revenue is recognised, one monthly exercise to explain the difference. That exercise never ends and never produces anything of value. Master data forks. Each system has its own customer list, its own product catalogue and its own supplier records, maintained independently. Within two years the same customer exists under four slightly different names with three different addresses, and no reliable way to match them. Manual re-entry appears everywhere. Data captured in the departmental tool must reach the ERP for financial posting. In the absence of integration that means exports, spreadsheets and re-keying — which is both a cost and a control weakness, since a manual transfer is a manual opportunity to change a number. Controls do not apply. Approval workflows, segregation of duties, audit trails and access reviews exist in the ERP because auditors required them. A shadow system running a business process with commercial consequence typically has none, and its existence is not disclosed to the auditors. Data protection obligations go unmet. A departmental tool holding customer or employee data is a processor. It needs a contract, a lawful basis, a place in the data map and a retention position. Shadow systems have none of these, and they are precisely the systems that get missed in a subject access request or a breach assessment. And the exit cost is real. Three years of operational history in a tool nobody sanctioned is not easily migrated. By the time the problem is addressed, the system is load-bearing.

The Response That Does Not Work

Prohibition. It has been tried continuously for twenty years and it fails for a simple reason: the underlying need is real and the official channel remains slow. Banning departmental purchases produces the same purchases made less visibly — on personal cards, under generic expense codes, with free tiers that never appear in procurement at all. The second failed response is consolidation by decree: an instruction that everything must run in the ERP. This ignores that the ERP genuinely could not do several of these jobs, and it converts departments from unsanctioned buyers into unhappy users of an inadequate tool, which lasts until the next renewal cycle and then reverts.

The Response That Does

The organizations that got this under control treated it as a supply problem rather than a discipline problem. Make the sanctioned path fast. A lightweight evaluation — security, data protection, integration, contract — completed in days rather than months, with a pre-approved catalogue for common categories. If the governed route is quicker than the ungoverned one, most people take it. Amnesty first, then enforcement. Invite departments to register what they are already running, with an explicit commitment not to punish disclosure. This produces a real inventory in weeks, which no audit or network scan will achieve. Enforcement after amnesty is credible; enforcement before it drives everything further underground. Distinguish systems of record from systems of work. A tool that helps a team organise its work and holds no authoritative data is low risk and should be easy to approve. A tool that holds transactional data, produces reportable numbers or processes personal data is a different category and needs real review. Applying one standard to both is why governance gets ignored. Mandate integration rather than ownership. The useful requirement is not "you must use the ERP". It is "any system holding transactional data must integrate with the system of record, with defined master data ownership and no manual re-keying". That permits good specialised tools while preventing the reconciliation problem. Follow the money. Expense reports, corporate card statements and accounts payable contain the actual application inventory. A quarterly review of software charges finds more than any survey.

Practical Guidance for Application Portfolio Governance

• Run an amnesty before you run an audit. People disclose when disclosure is safe. You cannot govern a portfolio you cannot see.
• Search the card statements and expense data. This is the single most effective discovery method and almost nobody does it systematically.
• Tier your review process by risk. A team task board and a system holding customer transactions should not face the same approval path.
• Make integration the requirement, not consolidation. Specialised tools are frequently the right answer; disconnected data never is.
• Assign master data ownership per domain explicitly. Which system is authoritative for customer, product, price and employee. Everything else consumes from it.
• Fix the speed of the sanctioned route. Shadow IT is a symptom of internal latency. Governance that is slower than a credit card will be bypassed indefinitely.
• Include shadow systems in your data map and processor register. They hold personal data, they are processors, and they are the ones that get missed in an access request or a breach.
• Review renewals annually against actual use. Portfolios accumulate. Most organizations are paying for several tools that nobody has opened in a year.

The Regional Version

For multi-entity groups in the Gulf, shadow systems proliferate faster than in single-country businesses, and the cause is structural rather than cultural. A group with operating entities in the UAE, Saudi Arabia, Qatar and Egypt typically has local management with genuine autonomy, local regulatory requirements the group system does not handle, and local vendors selling directly into each market. Each entity solves its own problem locally, and group IT discovers the result at consolidation. The consequences here are sharper than elsewhere for two reasons. First, statutory reporting is per entity and per jurisdiction, so a shadow system holding transactional data in one country creates a statutory reporting problem rather than merely an internal reconciliation one. Second, cross-border data flows now require a documented basis under the UAE framework and Saudi PDPL — and an unsanctioned tool procured locally, hosted in an unknown jurisdiction, holding employee or customer data, is exactly the flow that has no basis and no record. There is also a practical discovery difficulty. Where local entities pay local vendors in local currency through local banking relationships, the card-statement approach that works well in a centralised finance function works less well. Groups that have handled this successfully generally ran the amnesty entity by entity, in-country, with local finance leads rather than from headquarters.

The Next Wave, Arriving Faster

Every structural condition that produced shadow ERP now applies to AI tools, with the friction reduced to almost nothing. An employee can adopt an AI service in under a minute, frequently at no cost, without a corporate card and therefore without appearing in any expense review. The tools are being embedded into software already approved for other purposes, which means new data flows appear without anyone making a decision. And the data involved — documents, customer correspondence, financial extracts, code — is often more sensitive than what departmental SaaS handled. The discovery methods that worked before mostly do not work here. There is no purchase to find. Network monitoring catches some of it. Browser extensions and identity provider logs catch more. But the only approach that has been reliably effective is the same one that worked for shadow SaaS: make the sanctioned option genuinely good and genuinely fast, and give people a safe way to tell you what they are already using. The organizations handling AI adoption well are not the ones with the strictest policies. They are the ones that provided an approved tool early, made access easy, and asked openly what people were using instead. That was the correct answer in 2013 and the cost of getting it wrong has gone up.

Common Questions

What is shadow ERP?

Departmental systems that hold transactional data, run business processes and produce reportable numbers outside the official system of record — a CRM, a billing tool, a field service platform or a recruitment system bought on a departmental budget without IT or finance involvement.

Why is the subscription cost not the real problem?

Because the cost lands in finance as reconciliation work. Multiple systems produce different revenue figures under different definitions, master data forks across systems, manual re-keying appears between them, and none of it has the controls an auditor expects.

Does banning departmental software purchases work?

No. The underlying need is real and the official route remains slow, so purchases continue less visibly on personal cards, under generic expense codes or on free tiers that never reach procurement at all.

What is the most effective way to discover shadow systems?

An amnesty — inviting disclosure with an explicit commitment not to punish it — combined with a systematic review of corporate card statements, expense reports and accounts payable for software charges. Both find substantially more than network scanning or surveys.

---

Application Portfolio Review — Outpace finds what your organization is actually running, what it is costing you in reconciliation, and which systems need to be integrated rather than removed.