I have this conversation roughly once a month. Someone from an IT team tells me their master data lives in SAP, or Dynamics, or Oracle — and therefore they do not need an MDM tool. The ERP already has the customer table, the product table, the cost centre list. Everything is in one place. Problem solved.
Except it is not solved. It is just hidden. The ERP stores master data the same way a filing cabinet stores documents — technically it holds them, but nobody would call it a document management system. Storage is not governance.
ERPs are transaction engines, not data governance tools
An ERP exists to process transactions. Purchase orders, invoices, journal entries, production orders. Master data — customers, suppliers, materials, GL accounts — is the reference data that those transactions point to. The ERP needs it, so the ERP stores it. But the ERP was never designed to manage it in any meaningful sense of that word.
What does management actually look like? Versioned history of every change. Approval workflows before a new cost centre goes live. Audit trails that tell you who changed a supplier's bank details on a Tuesday afternoon three months ago. Cross-system distribution so your BI platform, your e-commerce system, and your ERP all agree on what the product hierarchy looks like.
Your ERP does none of this. It lets you edit a customer record and saves the new value on top of the old one. History gone. No approval step. No distribution to other systems. The record changed, the transaction engine keeps running, and nobody else is notified.
The one-ERP-to-rule-them-all fantasy
The argument usually goes: “We standardized on SAP, so all our master data is in SAP.” In practice, this is rarely true. Even organizations that run a single ERP instance have master data scattered across other systems:
- Power BI or SSRS: reporting platforms that maintain their own dimension tables, sometimes refreshed from the ERP, sometimes manually maintained
- E-commerce platforms: product catalogues with their own category hierarchies that may or may not match the ERP
- CRM systems: customer records entered by sales reps who never touch the ERP
- Spreadsheets: the universal fallback — someone always has a "master" Excel file with data the ERP cannot accommodate
- Data warehouses: ETL pipelines that snapshot ERP master data but diverge as soon as someone edits the warehouse copy directly
The moment two systems hold overlapping reference data, you have a governance problem. Which one is authoritative? How do changes propagate? Who decides when a new product category is “official”? The ERP has no answer for these questions because it was never designed to answer them. It processes orders. That is its job.
What breaks when your ERP is your MDM
These are not hypothetical problems. I have seen every one of them in production:
Silent overwrites
A user edits a customer's credit limit in the ERP. The old value is gone. Three weeks later, finance asks why an order was approved beyond the limit — and there is no record of the change. The ERP does not maintain field-level change history for most master data tables.
No approval gate
A junior accountant creates a new GL account directly in the ERP. It goes live immediately. No review, no sign-off from the controller. Two months later, the chart of accounts is a mess and the monthly close takes an extra day because someone has to figure out what that account was supposed to be.
Copy-paste distribution
When the product hierarchy changes in the ERP, someone emails the updated list to the BI team, who manually update their dimension table. Except the email gets delayed, the BI team uses last month's version for a board report, and the numbers do not match the ERP. This happens quarterly.
Vendor lock-in on structure
Your ERP's master data schema is rigid. Adding a custom field to the supplier table means a support ticket, a change request, maybe a consultant. Your business needs evolve faster than your ERP vendor's release cycle, so the overflow goes into — you guessed it — spreadsheets.
No cross-system identity
Customer "Acme Corp" is ID 10034 in the ERP, CUST-087 in the CRM, and row 212 in the warehouse. Nobody maintains the mapping. When a data analyst tries to join these systems, they spend the first two days just matching records manually.
What a dedicated MDM tool gives you
A proper MDM system does not replace your ERP. It sits alongside it and takes ownership of the reference data that your ERP (and every other system) depends on. The division of labour is clear: the MDM tool governs the data, the ERP consumes it.
| Capability | ERP | MDM tool |
|---|---|---|
| Change history | Overwrites the previous value | Full version history per field, per record |
| Approval workflows | Changes go live immediately | Propose → review → approve → commit |
| Audit trail | Limited or requires add-ons | Every change attributed to a user with timestamp |
| Cross-system distribution | Not its job | Integration views, REST API, or export |
| Flexible data model | Rigid schema, vendor-controlled | User-defined entities and attributes |
| Who can edit what | Module-level access | Entity-level and field-level permissions |
| Bulk operations | Row-by-row or custom scripts | Import, export, bulk edit with validation |
This is not about replacing your ERP investment. It is about recognising that the ERP was built for one thing and master data governance is a different thing. You would not use your ERP as a project management tool just because it stores employee records. The same logic applies to master data.
When it is time to separate MDM from your ERP
Not every organization needs a standalone MDM tool. If you run a single ERP, have fewer than 500 master records, and nobody else consumes that data — you are probably fine. But if any of these sound familiar, the ERP is no longer enough:
- Multiple systems need the same reference data and you are syncing them manually
- You have no audit trail for who changed a critical reference record and when
- Business users manage overflow master data in Excel because the ERP is too rigid
- Adding a field to a master data table requires a change request to your ERP vendor
- Your BI reports and your ERP disagree on fundamental dimensions like product categories or cost centres
- Regulatory audits require you to prove who approved a master data change — and you cannot
If three or more of those apply, you have outgrown ERP-based master data management. The question is no longer whether you need a separate tool — it is which one.
How Primentra fits into an ERP landscape
Primentra runs on your SQL Server infrastructure — the same infrastructure your ERP likely uses. It stores master data in a structured model of models, entities, and attributes that you define yourself, and exposes that data through two channels:
- Integration views: SQL views in the [mdm] schema that your ETL pipelines, SSRS reports, and data warehouse can query directly. Your ERP can pull from these views on a schedule to stay in sync.
- REST API: HTTP endpoints for systems that cannot talk SQL Server. Your e-commerce platform, your CRM, your internal tools — anything that speaks HTTP can read and write master data through the API.
Changes go through approval workflows when you want them to. Every edit is logged in the audit trail with the user's name and timestamp. Permissions control who can see and edit which entities. The data model is yours to change — adding an attribute takes ten seconds, not a change request.
The ERP keeps doing what it does best — processing transactions. Primentra keeps the reference data underneath those transactions clean, versioned, and distributed. Two tools, two jobs, zero overlap.
Common questions
Why can't I just manage master data inside my ERP?
ERPs store master data as a side effect of running transactions. They are not designed to govern, version, or distribute that data. You end up with no audit trail on reference data changes, no approval workflows, no cross-system consistency, and no single source of truth when multiple systems hold overlapping master records.
What is the difference between ERP master data and MDM?
ERP master data is the set of reference records (customers, products, cost centres) that an ERP needs to process transactions. MDM is a discipline and toolset for governing those records across systems — ensuring they are accurate, consistent, versioned, and distributed to every system that needs them. The ERP is one consumer of master data, not the authority over it.
When should a company invest in a separate MDM tool?
When more than one system consumes the same reference data (e.g. your ERP, your BI platform, your e-commerce system all need the same product hierarchy), or when you need audit trails, approval workflows, and versioned history for reference data changes. If you are managing master data in spreadsheets because the ERP UI is too rigid, that is another strong signal.
Is Primentra an ERP replacement?
No. Primentra is a master data management tool that sits alongside your ERP. It governs your reference data — entities, hierarchies, domain values — and distributes clean, approved records to your ERP and other systems via integration views or the REST API. The ERP continues to run transactions; Primentra makes sure the reference data behind those transactions is correct.
How does Primentra integrate with existing ERP systems?
Primentra stores data in SQL Server and exposes integration views in the [mdm] schema that any ETL tool, stored procedure, or reporting platform can query directly. For real-time integrations, the REST API supports reading and writing entity records over HTTP. Both methods work with SAP, Dynamics, Oracle, or any other ERP that can consume SQL views or call HTTP endpoints.
Ready to separate master data from your ERP?
Primentra runs alongside your existing ERP on SQL Server. Define your data model, set up permissions and approval workflows, and start distributing clean reference data to every system that needs it. The 60-day trial includes everything — no credit card, no sales call.