Why Your ERP Doesn’t Govern Your Data (And What Does)

There’s a belief that runs deep in mid-market finance: if we buy the right ERP, our data problems go away.

It’s understandable. The ERP vendor says it. The implementation partner implies it. The RFP response promises “integrated data management” and “built-in controls.” So you spend six months and a significant budget implementing Business Central, or SAP Business One, or Pohoda, or Helios — and you expect governed data to come out the other end.

It doesn’t. What comes out is recorded data. That’s not the same thing.

This distinction — between data that’s been recorded and data that’s been governed — is the gap that causes most of the pain in mid-market finance. And it’s a gap that no single ERP is designed to close.

What your ERP actually does

An ERP is a transaction recording system. That’s its job, and most modern ERPs do it well. Here’s what a properly implemented ERP gives you:

Transaction capture. Every invoice, payment, journal entry, and stock movement gets recorded with a timestamp, a user ID, and an audit trail. The ledger is intact.

Basic access controls. User roles, posting permissions, approval workflows for purchase orders or payment runs. Who can do what is defined — at least in theory.

Chart of accounts structure. A single, consistent coding framework within that system. Transactions are classified according to one schema.

Regulatory compliance features. VAT handling, statutory reporting templates, localisation for the jurisdiction you operate in. Business Central handles UK VAT. Pohoda handles Slovak DPH. SAP B1 handles whatever you configure it for.

Period management. Open and close periods, prevent backdated posting, enforce cut-off dates within the system.

That’s a solid foundation. But notice what’s missing from this list.

What your ERP doesn’t do

Cross-system validation. Your ERP validates data within itself. It has no opinion about whether revenue in the CRM matches revenue in the GL. Or whether the headcount in your HR system matches the salary costs in your payroll run. Or whether the inventory value in your warehouse system matches the stock balance on your balance sheet. The moment you run more than one system — and every mid-market company does — you have a validation gap that the ERP can’t see.

Data quality enforcement beyond basic types. An ERP will reject a letter in a numeric field. It won’t reject a EUR 500,000 invoice when your typical invoice is EUR 5,000. It won’t flag that you’ve posted the same vendor invoice twice with a slightly different reference number. It won’t notice that a cost centre hasn’t been used in 18 months and probably should be archived. These are data quality controls, and they sit above what an ERP is built to do.

Cross-entity consistency. You run three legal entities. Each has its own chart of accounts — or worse, the same chart of accounts applied inconsistently. Entity A codes marketing consultancy as “Professional Services.” Entity B codes it as “Marketing Costs.” Entity C splits it across both. Your ERP enforces the structure within each entity. Nobody enforces consistency across entities. When you try to consolidate, the numbers don’t compare.

Reconciliation between systems. APQC data shows that organisations running multiple ERP instances spend 2.3x more on the financial close than single-ERP organisations. That cost isn’t in the software licence. It’s in the reconciliation — the manual matching of data between systems that nobody designed to talk to each other. Your ERP doesn’t reconcile against external systems. Your team does, in spreadsheets, at month-end.

Master data governance. Your customer is “Acme Ltd” in the ERP, “ACME Limited” in the CRM, and “Acme” in the billing system. Your vendor has two supplier codes because someone created a new one instead of finding the existing one. Your chart of accounts has 15 dormant accounts that nobody uses but nobody has deactivated. Master data governance — the discipline of maintaining clean, consistent, authoritative reference data across systems — is not an ERP function. It’s an organisational discipline. The ERP just stores whatever you put in.

Ownership and accountability. Who owns the accuracy of revenue data? Not the ERP. Who is responsible for ensuring intercompany balances match? Not the system. Who decides whether a reconciliation exception is material and needs investigation? Not the software. Governance requires human ownership with defined responsibilities. An ERP provides the platform. It doesn’t assign the accountability.

The single-system illusion

Here’s where the disconnect originates. If you ran a single ERP with a single entity, one currency, and no external systems — the ERP would be close to governing your data. Everything is in one place. One chart of accounts. One set of posting rules. One audit trail.

But that company doesn’t exist in the mid-market.

The reality looks more like this. A mid-market company with operations across two or three countries runs Pohoda for the Slovak entity, Business Central for the UK entity, and maybe Helios or SAP Business One for the Czech operation. Each system is correctly implemented for its jurisdiction. Each records transactions accurately within its own walls.

The problem isn’t inside any single system. The problem is between them.

Intercompany transactions are booked at different times. Exchange rates aren’t aligned. Account structures don’t map cleanly. Consolidation requires someone — usually the most senior person on the finance team — to spend days each month manually matching, adjusting, and reconciling data across systems to produce group-level numbers.

That’s not a system failure. It’s a governance gap. And no ERP vendor’s product roadmap is designed to close it, because ERPs are designed to serve a single entity’s transaction processing needs — not to govern data across a multi-system landscape.

The “we’ll fix it in the implementation” trap

Every ERP implementation begins with good intentions about data quality. The project plan includes a data migration workstream. The implementation partner runs data cleansing workshops. Master data is mapped, deduplicated, and loaded into the new system.

Then the go-live happens and the governance stops.

Nobody maintains the chart of accounts actively. New accounts get added without removing old ones. The validation rules that were configured during implementation get relaxed because they “slow people down.” Master data discipline decays because there’s no process to sustain it — the implementation partner has moved on, and the internal team is dealing with day-to-day operations.

Eighteen months after go-live, the data quality is back where it started. Not because the ERP failed, but because data governance was treated as a project, not a discipline. Implementation is a point in time. Governance is continuous.

What actually governs your data

If the ERP doesn’t do it, what does? Governance sits in a layer above and between your transaction systems. It’s a set of mechanics — not a piece of software, not a strategy document, not a maturity model.

A defined data model that spans systems

Before you can govern data across systems, you need to define what “the same data” means across those systems. Revenue in Pohoda, revenue in Business Central, and revenue in your billing platform need to map to the same definition. That means a unified chart of accounts structure, standardised cost centre logic, and agreed definitions for every metric that gets reported.

This mapping doesn’t live in any single ERP. It lives in a data layer — a structure that sits above your transaction systems and translates between them. It says: “Account 6100 in Entity A is equivalent to Account 5200 in Entity B, and they both map to ‘Professional Services Revenue’ in the consolidated view.”

Without this, your consolidation is an exercise in creative interpretation.

Validation rules that fire at the point of entry

Most mid-market finance teams rely on reconciliation at month-end to catch data problems. By then, you’re investigating differences that have been compounding for 30 days. The better approach is to catch errors at the point of entry — before they reach the ledger.

Range checks. Duplicate detection. Mandatory field enforcement. Chart of accounts validation against the master. These are preventive controls, and they’re remarkably effective. A range check that flags any invoice above 5x the historical average catches decimal errors, duplicate entries, and classification mistakes — all before they hit the GL.

Your ERP can enforce some of these. Most aren’t configured to. And the controls that matter most — the cross-system validation rules — can’t live in any single ERP because they require visibility across systems.

Reconciliation designed between systems

Grant Thornton’s 2026 research on the financial close found that the control gap isn’t inside systems — it’s between them. The 5-15 day close cycle that mid-market companies endure is mostly consumed by cross-system matching, variance investigation, and manual adjustment.

Effective reconciliation requires deliberate design. Which metrics get reconciled across which systems. How often. What tolerance threshold triggers investigation. Who owns each reconciliation. How exceptions get aged and resolved.

This is architecture. It doesn’t emerge from buying better systems. It emerges from deciding what data needs to agree, designing the checks, and running them systematically.

Ownership with defined responsibility

Every key data domain needs an owner. Someone who is accountable for the accuracy, completeness, and timeliness of that data. Revenue has an owner. Cost data has an owner. Intercompany balances have an owner. Master data has an owner.

In most mid-market finance teams, ownership is implicit. The most senior person handles the most complex reconciliations because they’re the only one who understands the full picture. That’s not governance — it’s dependency on institutional knowledge. Real governance makes the responsibility explicit, documented, and transferable.

Continuous monitoring, not month-end review

The pattern in mid-market is: run transactions for 30 days, then spend 10-15 days at month-end finding and fixing the problems. It’s entirely reactive. Every issue was avoidable if caught earlier.

Governed data means continuous monitoring. Daily reconciliation of key balances. Weekly intercompany matching. Automated alerts when something breaks a pattern. Not as a luxury — as a basic operating discipline.

The technology exists. The mid-market perception is that this requires enterprise-grade tools and enterprise-grade budgets. It doesn’t. It requires designed controls, automated execution, and someone who cares enough to build it.

The real question

When Gartner predicts that embedded AI in cloud ERP will drive 30% faster financial close by 2028, they’re not describing a software upgrade. They’re describing a scenario where data is already governed, validated, and reconciled — and AI accelerates the analysis layer on top. Without governed data, AI accelerates nothing. It generates faster wrong answers with higher confidence.

The real question for mid-market finance leaders isn’t “which ERP should we buy?” or “should we implement AI?” It’s: “Do we have the governance mechanics in place so that any tool — AI or otherwise — can trust our data?”

If you run multiple systems, the answer is almost certainly no. Not because your team is incompetent or your ERP is bad, but because governance across systems doesn’t happen by default. It has to be built.

The governance stack

Here’s what it actually looks like — the practical mechanics, not the maturity framework:

Layer 1 — Unified data model. A mapping structure that translates between your ERPs, defines consistent metrics, and creates a single version of truth for reporting. This is the foundation everything else depends on.

Layer 2 — Preventive controls. Validation rules at the point of entry: mandatory fields, range checks, duplicate detection, chart of accounts enforcement. These stop bad data from entering your governed data layer.

Layer 3 — Detective controls. Automated reconciliation between systems, trend break analysis, balance sheet substantiation. These find problems that prevention missed — ideally within days, not at month-end.

Layer 4 — Corrective controls. Defined workflows for investigating and resolving exceptions. Root cause tagging so you understand why something broke. Exception ageing so nothing festers. Adjustment protocols that are documented and reviewed.

Layer 5 — Ownership and monitoring. Named owners for each data domain. Continuous monitoring dashboards. Regular reviews. The close retrospective that improves the process every month.

Your ERP is Layer 0 — the transaction recording system that everything sits on. It’s necessary. But it’s the beginning, not the end.

What this means for ERP decisions

None of this is an argument against investing in your ERP. A well-implemented ERP is essential infrastructure. Business Central is a strong platform. SAP B1 handles complex multi-country requirements well. Pohoda and Helios serve their markets effectively. The ERP choice matters for transaction processing, regulatory compliance, and local reporting.

But if you’re evaluating an ERP investment with the expectation that it will “fix” your data problems — pause. Ask what governance mechanics will exist above and between your systems after implementation. Ask who will maintain the data model. Ask how cross-system reconciliation will work. Ask what happens to data quality twelve months after go-live when the implementation partner has left.

The ERP is the recording layer. Governance is the trust layer. They’re different things, built by different disciplines. Treating them as the same thing is the most expensive assumption in mid-market finance.