Master data sits under every process, so an error in it is charged to every process.
The difference is fan-out, and it is worth being precise about it.
A wrong transaction is wrong once. A wrong quantity on one purchase order affects that order, and correcting the order ends it. A wrong master record is different: it is referenced by every transaction that mentions it, every report that groups by it and every rule that reads it. The error is copied forward each time the record is used, and the copies are made by systems that have no way to know the record was wrong.
Duplication is the most expensive form of this. When one company is held as four suppliers, the business loses the ability to add anything up: spend by supplier, risk by supplier, performance by supplier, exposure by customer. The numbers are arithmetically correct and practically useless, and the people who read them learn to argue with them.
The second most expensive form is a missing attribute. A material with no planning parameters is planned with defaults, and the defaults buy the wrong quantity in the wrong week. The rules page shows how completeness is enforced at three levels so that a record reaches a consuming system in a usable state.
Read the left column for what the business says; the right column is where the fix belongs.
| What the business describes | What it costs | The cause in master data | Where Lima addresses it |
|---|---|---|---|
| "We think we are one of their biggest buyers, and they treat us as four small ones." | Volume discounts left unclaimed; weak negotiating position | One supplier held as several records, with no agreed identity | Golden records |
| "Two reports of the same revenue disagree, so we rebuild both." | Analyst time, and decisions delayed a cycle | Two hierarchies of the same customers, with different versions in use | Hierarchies and levels |
| "The planning run bought the wrong week again." | Excess inventory, and expedite costs on the lines that starve | Materials reaching planning with default parameters | Planning parameters |
| "A blocked supplier still received a purchase order." | Audit finding; in regulated industries, a reportable event | The block held in one system, with the others unaware | Integration and sync |
| "The same invoice was paid twice." | Cash out of the door, and a recovery process to bring it back | Two vendor records, so the duplicate check passes | Rules at three levels |
| "Nobody can say who changed the bank details." | Fraud exposure and a difficult audit conversation | Changes applied in systems that keep thin history | Audit trail |
| "Each new application needs its own customer load." | Weeks per project, repeated per project | Every consumer building its own copy and its own mapping | Headless API |
| "Our AI answers confidently and wrongly about customers." | Trust in the assistant, spent once | The model reading several unlinked versions of the same customer | Data services |
These are the outcomes the stories are built on.
Spend, exposure, revenue and risk aggregate to the real counterparty, so the number in the meeting survives the meeting. A $10B high-tech manufacturer consolidated 41,800 vendor records into 9,300 suppliers across three ERPs, then negotiated eleven agreements of one group into one.
The golden record is corrected, the audit trail records who and why, and the write-back carries the agreed value to the systems that own the field, with the acknowledgement stored beside the change.
A satellite application passes the keys it holds and receives the golden record, so a new system reads master data on day one of its project.
A sales reorganisation is a hierarchy version with an effective date; 24 months of history re-rolled in the showcase run, with both structures available in the same board pack.
Most programmes can name their first win before they start. These are the ones that recur.
| Function | First visible win | What to measure | Typical first domain |
|---|---|---|---|
| Procurement | Spend consolidated to the real supplier group | Addressable spend per supplier group; duplicate records removed | Supplier |
| Finance | One customer per counterparty for exposure and collections | Credit exposure accuracy; duplicate payments prevented | Customer |
| Planning | Materials reaching planning complete | Share of items with governed parameters; forecast bias | Planning parameters |
| Manufacturing and service | One equipment record per serial across structures | Warranty claims matched; installed base accuracy | Equipment and assets |
| Sales | Territories and account trees agreed and versioned | Time to re-roll a reorganisation; report disputes | Hierarchies |
| Compliance | Codes and compliance attributes held once | Findings per audit; blocked-party checks passed | Product compliance |
A $20B telecom leader maintains global customer and product codes across three divisions, feeding activation, forecasting and demand planning.
A $75B semiconductor equipment maker mastered materials across plants ahead of a 1,000-table planning integration, merging 61,000 duplicates.
A $100B semiconductor maker runs product warranty maintenance on golden equipment records, with a global control tower above them.
The supplier walkthrough on the showcase estate: two sources, 41,800 records, one working day.
Partly, and the honest parts are enough. Duplicate counts, incomplete-attribute counts and the number of systems holding each domain are all measurable in a one-week inventory on your own data; the inventory offer covers it. The savings per duplicate are yours to estimate, since they depend on your contracts.
The test is whether every consuming system agrees on identity today and whether a correction reaches all of them. Estates in good shape usually keep that agreement by hand, and the value then comes from the hours returned and from the speed of the next reorganisation or acquisition.
Three things per domain: what counts as the same thing, which source wins each field, and who stewards it. Lima makes those agreements visible as configuration, so they can be reviewed and changed with their history.
The first golden view on your own data takes about a working day, and a production-grade domain takes one to six days of configuration by catalogue entry. The first-domain page walks through the day.
Bring two systems that hold the same customers, suppliers or materials. In one working day we connect them, run the match on live rows, review the queue with your steward and publish the first golden view with its API.
