TL;DR
- Four objects decide whether an intake rollout works: suppliers, items, general ledger accounts, and cost centers.
- Supplier duplicates, conflicting category taxonomies, and retired cost centers block go-live. Specification detail and catalog breadth can be improved after launch.
- Intake rollouts stall at week six because that is when curated pilot data gives way to real request volume.
- Run the readiness test on 50 real requests before launch. Above 40 routing cleanly, go. Below 30, the master data work is the project.
- See how Merlin Intake handles procurement requests. Request a demo.
Intake goes live on the master data you already have, not the master data you intend to clean up afterward. Four objects decide whether it works: suppliers, items, general ledger accounts, and cost centers.
Deloitte surveyed procurement risk broadly rather than intake implementations specifically. The connection drawn here is that intake is where poor master data stops being a reporting inconvenience and becomes an operational failure, because a request cannot be routed against a supplier record that does not exist.
This piece is a pre-flight checklist for procurement operations teams inside an intake implementation, written to be run four to six weeks before go-live rather than during it.
Figure 1: Every routing decision reads down into master data.
Why do intake rollouts stall at week six?
Because weeks one through four test the happy path and week six is when real requests arrive.
The demo environment uses clean sample data. The pilot uses a curated category with a tidy supplier list. Then the rollout widens, and requests start arriving for suppliers that exist three times under slightly different names, for items with no category assignment, and against cost centers that were retired in a reorganization nobody told procurement about.
None of this is a platform failure. The platform is doing exactly what it was configured to do against the data it was given, which is the hardest kind of problem to diagnose in a steering committee, because the tool is behaving correctly and the outcome is still wrong. But the symptom presents as a platform failure, which is why intake projects lose sponsor confidence at precisely the moment they start touching real volume.
The four checks below are what separate a week-six stall from a week-six expansion.
Figure 2: Clean routing holds through pilot and drops when volume widens.
What must be true about supplier master data?
Every supplier a requester might name has exactly one active record, and that record carries the attributes routing depends on.
Duplicates are the primary offender. Where the same supplier exists as three records, intake will route three ways, spend will fragment across all three, and the consolidation reporting that justified the project will show nothing. Run a duplicate detection pass on normalized names and tax identifiers before go-live, not after. The pass is cheap. Unwinding fragmented spend across three supplier records six months later is not.
Each record also needs a status, a category assignment, and a contract flag. Intake decides whether to route a request to a preferred supplier, to a sourcing event, or to a policy exception, and it cannot make that decision against a record that carries only a name and an address.
What must be true about item and catalog data?
Items carry a consistent category taxonomy, a unit of measure, and enough specification detail to be matched.
Category taxonomy is where most organizations discover they have three of them: one in the ERP, one in the spend analytics tool, and one that lives in a category manager’s spreadsheet. Intake routes on category. Pick the authoritative one and map the others to it before launch. Existing catalog management practice is usually the fastest route to that decision.
Unit of measure sounds trivial and is not. A request for ten units against a supplier who sells by the case produces a purchase order that fails receipt matching weeks later, which is an exception the intake project will be blamed for. Specification detail matters for the same reason: a request that cannot be matched to a catalog item becomes a free-text line, and free-text lines are where category assignment quietly disappears.
What must be true about GL and cost center data?
Both are current, both are mapped to the org structure as it exists today, and both are exposed to intake in a form a requester can select without knowing the code.
Retired cost centers are the common failure. Finance closes them, the ERP retains them as historical records, and intake presents the full list. A requester picks a plausible-looking one, and the request codes to a center that cannot accept it. The error surfaces in finance rather than in procurement, which delays detection and costs procurement credibility with the function it most needs on side.
The requester-facing question matters as much as the data. Asking a marketing manager for a GL account guarantees either a wrong answer or an abandoned request. Asking what the purchase is for, and deriving the account from that, is the difference between data captured and data invented.
That survey measured intent to adopt, not readiness to adopt. The gap between the two is what this checklist addresses: near-universal ambition to automate sits on top of master data that was never built for automated routing, and the ambition arrives sooner than the remediation does.
How do you test readiness before go-live?
Take fifty real requests from the last quarter, the ones that actually came in rather than a representative sample, and run them against the four checks on paper. Count how many would route cleanly with no human intervention. Figure 3 sets out what waits and what cannot.
If the number is above forty, go. Between thirty and forty, go with a named owner for the exceptions. Below thirty, the master data work is the project and intake is the deliverable that follows it. Running this test on paper takes a day and is the single most useful hour-for-hour activity available before launch, because it converts an argument about readiness into a number. Teams running a structured 30-day proof of concept should fold this test into week one.
Merlin Intake reduces some of this burden by inferring category and coding from a plain-language description rather than requiring the requester to select them, and by working inside Microsoft Teams and Slack rather than a separate portal. Inference still resolves against the supplier, item, and cost center records underneath. Better capture at the front door raises the ceiling on what clean master data delivers. It does not substitute for it.
Figure 3: Which master data problems block go-live, and which can wait.
What can you fix after launch, and what cannot wait?
Specification detail, catalog breadth, and supplier attribute enrichment can all be improved after go-live without disrupting anything already running. The same sequencing logic applies when migrating from spreadsheets.
Supplier duplicates, category taxonomy conflicts, and retired cost centers cannot. Each of those produces incorrect routing on live requests, and incorrect routing during the first weeks is what teaches requesters that the new front door does not work.
Those figures describe process automation across procurement generally, not intake specifically. What they imply for this checklist is that the return available from automation is large enough to justify treating master data as a prerequisite rather than as cleanup, because automation applied to unreliable records reproduces the errors faster.
Frequently asked questions
1. What is master data in procurement?
Master data is the set of reference records that procurement transactions depend on: suppliers, items, general ledger accounts, and cost centers. Unlike transactional data, which records what happened, master data defines the valid options a transaction can reference. Intake, sourcing, and procure-to-pay all read from it. When it is wrong, every downstream process inherits the error.
2. Why does master data matter for procurement intake specifically?
Intake makes routing decisions at the moment a request is submitted, and those decisions read from master data. A request routes to a preferred supplier because a supplier record says the supplier is preferred, and codes to a cost center because that cost center exists and is active. Without reliable records, intake either routes incorrectly or falls back to manual triage, which removes the reason for implementing it.
3. How do I find duplicate supplier records?
Run a matching pass on normalized supplier names with punctuation, legal suffixes, and case removed, then a second pass on tax identifiers and bank details. Names alone produce false negatives because the same entity appears with different legal suffixes. Tax identifiers alone miss subsidiaries. Review the candidate pairs manually before merging, since some near-identical records are genuinely different legal entities.
4. What is a category taxonomy and why do we need one?
A category taxonomy is the hierarchical classification used to group what an organization buys. It determines how intake routes a request, how spend is analyzed, and which sourcing strategy applies. Most organizations have more than one taxonomy in use across different systems. The intake implementation should adopt a single authoritative taxonomy and map the others to it rather than attempting to reconcile them all.
5. How long does master data cleanup take before an intake rollout?
For most mid-to-large organizations, the critical subset takes four to eight weeks: supplier deduplication, taxonomy consolidation, and cost center validation. Full enrichment takes considerably longer and does not need to be complete before launch. Scope the work to what produces incorrect routing rather than to what would be ideal, or the cleanup becomes the project.
6. Can intake software work with bad master data?
It will run, but it will route unreliably and generate manual triage that the implementation was meant to eliminate. Platforms that infer coding from natural language reduce the burden on the requester without removing the dependency, because inference still resolves to records underneath. Poor master data does not stop intake from launching. It stops intake from delivering the outcome that justified it.
7. Who owns master data in a procurement intake project?
Ownership is usually split, which is the underlying problem. Supplier records typically sit with procurement or supplier management, item and catalog data with procurement or category teams, and GL and cost center data with finance. Name a single accountable owner for readiness across all four before the project starts, even if the underlying data remains distributed.
8. What is the difference between master data cleanup and data migration?
Migration moves records from one system to another. Cleanup corrects the records themselves. A migration performed without cleanup transfers existing errors into the new system faithfully and at scale. Intake implementations often require both, and the sequence matters: clean first where the records will be reused, migrate second.
