The procurement lead pulled spend by category to prepare the annual supplier negotiations, and the largest category in the company turned out to be Miscellaneous. Thirty-one percent of indirect spend, more than IT hardware and office supplies combined, sitting in a bucket that says nothing about who supplies it or what could be consolidated. No buyer chose that category. The item creation form defaulted to it, nothing required changing it, and four thousand items accumulated there over three years, one unremarkable save at a time.
Product classification looks like the easy part of product master data. It is a dropdown. You pick a category, the product gets a place in the tree, done. The reason it keeps producing spend cubes full of Miscellaneous is that classification is not one tree. It is several, each serving a different consumer at a different speed, and most organizations build one, make it serve everyone, and govern none of it.
One product, more than one tree
Ask what the classification is for and you get three different answers from three floors of the same building. The webshop wants a tree shoppers can navigate, and marketing wants to reshuffle it for the spring campaign. Procurement wants spend rolled up into categories that map to supplier markets, stable enough to compare year over year. And a trading partner wants none of your internal trees. They want a standard code.
The standards are reference data someone else maintains. UNSPSC is a four-level hierarchy of roughly 70,000 codes, and it is what spend analysis and procurement systems usually expect. ETIM is a class-and-feature model for technical products; an ETIM class does not just place a product, it defines which attributes the product should carry, which is why electrical and HVAC wholesalers ask for it by name. GPC is the GS1 classification that retail data pools require before they accept a product at all. Which of these you need is decided by who you trade with, not by preference.
The mistake is not picking the wrong tree. It is forcing one tree to serve every consumer at once. Merchandising needs to move things seasonally; finance needs them to hold still. A single tree cannot do both, so it ends up bad at both. The fix is to let one product carry several classifications as separate governed attributes: an internal tree you own, plus one code per standard your partners require. A master data system handles that without complaint. A spreadsheet is where it all collapses back into one column.
Where the tree breaks
None of these throw an error. Every record has a category, every dropdown was filled from the authorized list, and every failure below is invisible until someone tries to use the tree for the thing it was built for.
The catch-all that ate the catalog
The creation form needs a category, the default is Miscellaneous, and the record saves without changing it. So it saves without changing it, thousands of times, entered by people whose job that day was to get a product ordered, not to classify it. The bucket grows a few items a week for years, and every report that groups by category has a largest category that means nothing.
Two stewards, two branches
A cordless drill goes under Power tools when one steward creates it and under Drilling when another does, because both branches exist and both are defensible. Neither record is wrong on its own. But the product family is now split across the tree, spend undercounts both branches, and a duplicate check that compares within a category never sees the pair.
The tree that mirrors the org chart
The top levels are named after the departments that buy the products, because that is who was in the room when the tree was designed. Then the company reorganizes. Facilities merges into Operations, the categories no longer match any team that exists, and the choice is to rename history or live with a tree that describes the company of five years ago.
Products parked on branch nodes
Half the catalog is classified four levels deep and the other half stopped at level two, because the deeper levels did not exist yet or the creator was in a hurry. A rollup now mixes items filed as Fasteners with items filed as Hex bolts, stainless, M8. Comparing two categories means comparing levels of effort, not levels of a tree.
The standard that moved on
The UNSPSC mapping was built once, during onboarding, against whatever version was current. The standard has released twice since. Codes were added, split, and retired, the catalog still points at the old ones, and the first anyone hears of it is a trading partner rejecting a product feed because a code no longer exists.
The catch-all is the worst of the five because it is the only one that looks like compliance. Every item has a category, the field is never empty, validation passes. A blank would at least show up in a completeness report. Miscellaneous is a filled field that carries no information, and every completeness metric counts it as done.
Rules that keep a classification honest
Treat every tree as reference data: one owner, an approval step in front of structural changes, and a history, because a category that gets renamed or merged rewrites every report that ever grouped by it. The internal tree is yours to design. The standard ones arrive from outside on their own release schedule, and the mapping to your catalog has to be re-checked on every release, not built once during onboarding and admired.
Then two rules on the products, enforced when the record is saved. Products classify on leaf nodes only; if a product genuinely belongs on a branch, the branch is missing a leaf, and the fix is to add the leaf rather than relax the rule. And the catch-all is a queue, not a home. Letting an item be created as Unclassified is fine, because blocking creation only teaches people to pick a wrong category that looks plausible, which is harder to find later than an honest gap. What matters is that unclassified stays visible: a worklist somebody owns, a count on a dashboard, and an age limit that turns a three-week-old unclassified item into a task instead of a permanent resident.
The payoff goes beyond clean reports. Classification is the natural place to hang the rest of your product governance, because the category decides which attributes a product must carry before it counts as complete. A cable needs a cross-section and a sheath color. A safety glove needs a size and a protection class. Neither needs the other's fields, and a product with no category cannot be validated at all, because the system does not yet know what complete means for it. ETIM works this way by design. Your internal tree can work the same way, and once it does, classifying an item stops being paperwork and becomes the step that tells the system what the record still owes you.
If you are coming off MDS
MDS could hold a tree. Explicit hierarchies stored the parent-child structure, derived hierarchies rolled up domain attributes, and plenty of teams kept a UNSPSC code in a free-text attribute alongside. What MDS never did was enforce anything about it. Nothing stopped a member from being parked on a branch node, nothing versioned the mapping to a standard, and the size of the catch-all was invisible unless somebody wrote a query against the subscription views by hand.
If you are migrating off MDS, triage the classification data before it moves, not after. Count what sits in the catch-all, find the members hanging on branch nodes, check the standard codes against the current release. Some of that pile is three years of deferred decisions, and a migration is the one moment you have the budget, the attention, and a defensible reason to make them. Carry the pile across untouched and it will still be Miscellaneous in the new system, just with a fresher timestamp.
Common questions
What is product classification in master data?
The assignment of every product to positions in one or more category trees: an internal tree for navigation and reporting, plus standard schemes like UNSPSC, ETIM, or GPC for exchange with trading partners. Each tree is reference data with its own owner, and one product usually carries several classifications at once.
What is the difference between UNSPSC, ETIM, and GPC?
UNSPSC is a four-level, roughly 70,000-code hierarchy used mainly for spend analysis. ETIM is a class-and-feature model for technical products, where the class also defines which attributes the product should carry. GPC is the GS1 scheme retail data pools require. They serve different consumers, so many catalogs carry two or three.
Why do so many products end up in Miscellaneous?
The creation form requires a category, defaults to the catch-all, and lets the record save without changing it. The person creating the item is trying to get a product ordered, not classify it. Nothing flags the default afterward, and completeness metrics count the filled field as done, so the bucket grows for years.
Should a product have one classification or several?
Several. Navigation, spend reporting, and partner exchange need different trees that change at different speeds, and one tree forced to serve all of them ends up bad at all of them. Model each as a separate governed attribute: an internal tree you own, plus one code per standard your partners require.
Shrink the Miscellaneous bucket for good
Primentra models your category trees as governed entities: one owner per tree, approval in front of structural changes, domain attributes that keep products pointing at real categories, and a full audit trail when something moves. It runs on your own SQL Server, deploys in a day, and costs €7,500 per year flat. The 60-day trial runs against your real catalog, which is long enough to find out exactly how much of your spend has been hiding in the catch-all.