Integration failures have a way of looking like technical problems when they're actually data problems. A connector fails. A mapping errors out. A record gets dropped. The immediate diagnosis points at the integration layer — but when you trace it back, the root cause is often a supplier record with a missing field, a cost center that exists in one system and not another, or a vendor ID that was entered three different ways across three different systems.
Master data is the foundation every integration builds on. When it's inconsistent, the integration is constantly trying to reconcile things that don't match — and eventually, it fails.
What master data problems look like in practice
The most common pattern is vendor duplication. A supplier gets added to the ERP under one name format, to the procurement platform under a slightly different format, and to the AP automation tool under a third. The systems don't recognize them as the same entity. Invoices from that supplier match against the wrong record, or don't match at all. Payment runs create duplicate entries. Spend reporting shows three separate lines for what is actually one supplier relationship.
A second pattern is incomplete records. Required fields that were optional during migration — a tax ID, a payment term, a bank account — get left blank. The system accepts the record. The integration accepts it. The downstream process rejects it when it tries to do something with a field that isn't there.
A third pattern is ownership gaps. Master data in most organizations is owned by no one specifically, which means it's maintained by everyone inconsistently. Finance updates vendors in the ERP. Procurement updates them in the procurement platform. AP updates them in the automation tool. No one checks whether the updates are consistent.
Why it's often invisible
Master data problems are invisible precisely because they look like normal operation. The records are there. The integrations run. The documents process. The failures are in the details: a payment that went to the wrong bank account, a report that double-counts a supplier, a reconciliation that never quite closes.
The people who notice are usually doing manual work to compensate — a finance analyst who knows to always check a specific vendor's records before month-end, or an AP specialist who re-enters certain invoices because the automated match never works for them. That manual work absorbs the impact of the data problem and makes it invisible to anyone not doing it.
The compounding effect
Master data problems compound in integration-heavy environments because every system is consuming the same flawed data and producing outputs based on it. Clean it in one system without cleaning it everywhere, and the integration replicates the problem back in the next run. The usual result is a cleanup project that appears to fix the issue and then slowly unwinds as the underlying data quality returns to its natural state.
Sustainable improvement requires understanding which system is the source of truth for each data element, what the governance process is for changes to that data, and how changes propagate to the systems downstream. Without those answers, cleanup is maintenance rather than a fix.
Where to start
The most practical starting point is a targeted audit of the data elements that integrations actually depend on. Not a full master data governance programme — just a clear picture of the records that are causing failures now.
In most cases, the scope is narrower than it looks. A specific category of suppliers. A set of cost centers that were migrated incorrectly. A payment term field that was interpreted differently across two systems. Fixing those, and establishing a clear owner for keeping them consistent, resolves most of the downstream failures.
The harder work — governance, ownership, process — is worth doing, but it's better done once the immediate integration failures are stable. A master data governance programme built on top of a broken integration is solving the wrong problem in the wrong order.