When employees bypass your procurement portal to send emails or submit free-text requests, it is rarely an issue of willful non-compliance—it is almost always a catalog data failure. The usability of your entire intake workflow relies heavily on a handful of critical procurement catalog fields that dictate whether requesters can actually find, select, and receive what they need. When taxonomy, units of measure, or specification fields are misconfigured, search results come up empty, quantities get miscalculated, and invoices fail downstream. In this article, we break down the vital procurement catalog fields that determine intake success, why full catalog cleanses are a waste of time, and the exact three-step sequence you should follow to fix your data.
TL;DR
- Three field groups decide it: taxonomy and search terms, unit of measure, and the specifications that distinguish adjacent items.
- Weak taxonomy sends requesters to email, because an empty search result reads as an absent item.
- Unit of measure errors are the most common catalog defect and they surface at receipting rather than at ordering.
- Fix search terms first, then unit of measure on high-volume items. Do not attempt a full catalog cleanse.
- See how Merlin Intake handles procurement requests. Request a demo.
Three field groups decide whether a catalog supports intake: what the item is called, how it is counted, and what distinguishes it from the nearly identical item beside it.
Taxonomy, unit of measure, and specification fields. Each fails in a different way and each failure surfaces somewhere other than the catalog, which is why catalog problems are usually diagnosed as intake problems, sourcing problems, or invoice problems instead.
This is written for procurement operations leaders whose catalog exists and technically works, but whose requesters keep going around it.
Why does taxonomy decide adoption?
Because a requester who cannot find an item concludes the catalog does not have it, as Figure 1 sets out, and acts on that conclusion immediately.
They do not conclude that the search terms differ from the category structure. They conclude the item is absent, and they raise a free-text request or buy it elsewhere. From procurement’s side this looks like non-compliance. From the requester’s side it was a reasonable response to an empty result.
The fix is not a better hierarchy. It is search terms that match how requesters describe things, held alongside the formal category structure rather than instead of it. Procurement needs the hierarchy for reporting and spend analysis. Requesters need synonyms. These are different artifacts serving different people and a catalog can carry both.
A catalog that only supports the formal taxonomy is a catalog optimized for the people who do not use it.
Figure 1: An empty search result reads as an absent item.
APQC measured productivity in aggregate rather than catalog data quality. The connection here is that spreads of that size are not explained by transaction mechanics, which vary little between organizations. They are explained by how much work arrives ready to process.
What breaks when unit of measure is wrong?
Everything downstream, and quietly.
A box of one hundred versus a single unit is the archetypal case. The requester orders ten, meaning ten units, and receives ten boxes. Receipting flags a quantity discrepancy, invoice matching fails, and someone spends an afternoon on it weeks later, by which point the cause is no longer obvious.
Unit of measure errors are the most common catalog defect and the most consistently underestimated, because each individual instance looks like a one-off mistake rather than a data problem. They also concentrate in specific supplier feeds, which means they are findable if anybody looks at the feed rather than at the individual exceptions.
Two rules prevent most of it. Display the unit of measure prominently at the point of selection rather than in a detail view. And keep the requester-facing unit and the purchasing unit visibly distinct where they differ, since assuming they are the same is what produces the ten-boxes outcome.
Unit of measure deserves one more note because it interacts with search. An item found under the wrong search term and ordered in the wrong unit produces two failures from one root cause, and the second one arrives weeks later attached to an invoice.
Which specification fields actually matter?
The ones that distinguish this item from the item next to it.
Catalog records tend toward either extreme: a description so sparse that three similar items are indistinguishable, or a specification dump copied from a supplier datasheet that nobody reads. Both produce the same behavior, which is a requester picking one at random or asking procurement which to choose, and the second is a support ticket the catalog existed to prevent.
The useful test is to look at the items that sit adjacent in a search result and ask what a requester would need to choose correctly between them. Usually it is two or three attributes: capacity, compatibility, size. Those are the specification fields worth maintaining. The rest is reference material and belongs behind a link.
Adjacency is the right unit of analysis here rather than the item, because an item only needs to be distinguishable from what it competes with.
Deloitte surveyed procurement risk broadly rather than catalog fields. Its bearing is direct: catalog taxonomy, unit of measure, and specification fields are the master data a requester actually touches, which makes them the visible surface of the risk CPOs already rank first.
How does catalog quality show up in intake metrics?
As category match rate and exception rate, neither of which sounds like a catalog problem.
When taxonomy is weak, requests arrive as free text because the requester could not find the item, and free-text requests are the ones that fail to match a category. When unit of measure is wrong, requests match perfectly and produce receipt and invoice exceptions weeks later, which is why the two problems are so often confused.
The diagnostic value is in which metric moves. A falling category match rate points at taxonomy and search terms. A rising exception rate with stable match rate points at unit of measure and specification data. The two problems feel identical from the requester’s side and require entirely different fixes.
Merlin Intake captures the request conversationally and determines the category from the description, which reduces the taxonomy dependency at the point of capture. It does not repair the catalog. A request correctly categorized against an item with the wrong unit of measure still produces the exception downstream.
None of this is a one-off exercise. Catalogs degrade continuously as suppliers change packaging, new items arrive through feeds, and categories drift. The realistic commitment is a recurring review of the highest-volume items rather than a project with an end date, and treating it as a project is why so many catalog cleanses are done twice.
The three groups also fail at different speeds, which affects sequencing. Taxonomy problems show up the day a requester searches. Unit problems show up weeks later at invoice. Specification problems show up as a question to procurement that never gets logged as a catalog issue at all.
What should you fix first?
Search terms, then unit of measure on your highest-volume items, then specification fields on adjacent pairs, as Figure 2 sets out.
Search terms first because they cost nothing but attention and they directly address the behavior that sends requesters elsewhere. Twenty minutes with the actual search log, looking at what people typed and got nothing for, is usually the highest-return catalog work available, and it needs no data migration or vendor involvement.
Unit of measure second because errors are concentrated rather than distributed, so auditing the top items by volume catches most of them. Specification fields third because the work is per-item and only pays where items genuinely compete.
Do not attempt a full catalog cleanse. It takes longer than anyone budgets, and the majority of items in most catalogs are never ordered.
Figure 2: The order to fix in.
Hackett measured savings leakage rather than catalog governance. The relevance is that leakage occurs where a negotiated price fails to reach the transaction, and a catalog record with the wrong unit is one of the ways that happens quietly.
Improving catalog adoption and reducing intake friction does not require a massive, multi-month catalog overhaul. By targeting the specific procurement catalog fields that requesters interact with every day, starting with search synonyms, auditing units of measure on top-volume items, and refining key specification attributes, you eliminate the root causes of off-channel spending and invoice errors.
Focus your cleanup where real user friction occurs, and build a governance process that keeps your intake workflow moving smoothly. Ready to eliminate catalog guesswork and guide requesters to the right outcomes effortlessly? Request a demo to see how Zycus Merlin Intake turns conversational requests into governed purchasing paths.
Frequently asked questions
Q1. What is catalog governance in procurement?
Catalog governance is the ongoing maintenance of the data that makes a catalog usable: category structure and search terms, units of measure, and the specification fields that distinguish similar items. It is distinct from catalog content management, which concerns which items are listed rather than whether they can be found and ordered correctly.
Q2. Why do requesters bypass the procurement catalog?
Most often because they searched, found nothing, and concluded the item was unavailable. That is usually a search term problem rather than a content problem, since the item exists but is described in procurement’s language rather than the requester’s. Bypass looks like non-compliance and is frequently a reasonable response to an empty result.
Q3. What causes unit of measure errors in procurement?
Supplier feeds where the purchasing unit differs from the consumption unit, combined with catalogs that display only one. A requester ordering ten of an item packaged in boxes of one hundred receives a hundredfold overage, which surfaces at receipting or invoice matching rather than at ordering.
Q4. How many specification fields should a catalog item have?
Enough to distinguish it from the items that appear beside it in a search result, which is usually two or three attributes such as capacity, compatibility, or size. Longer specifications copied from supplier datasheets are reference material and belong behind a link rather than in the record.
Q5. How does catalog quality affect intake performance?
Weak taxonomy lowers category match rate, because requesters who cannot find items submit free text. Poor unit of measure and specification data raise exception rate, because requests match correctly and fail later at receipt or invoice. Which metric moves identifies which problem you have.
Q6. Should you clean the whole catalog?
No. Full catalog cleanses take longer than budgeted and most items in a typical catalog are never ordered. Fix search terms across the catalog, since that is cheap, then audit unit of measure on the highest-volume items, then specification fields only where items genuinely compete.
Q7. What is the fastest catalog improvement available?
Reviewing the search log for terms that returned nothing and adding those as synonyms to existing items. It costs a short session, requires no data migration, and directly addresses the behavior that sends requesters to email.
Q8. Does intake software fix catalog problems?
It reduces dependency on taxonomy at the point of capture, since a platform that infers category from a description does not require the requester to navigate a hierarchy. It cannot repair unit of measure or specification data, and a correctly categorized request against a badly specified item still fails downstream.
