UNSPSC, the United Nations Standard Products and Services Code, is a hierarchical taxonomy for classifying products and services. Every item is assigned a numeric code that places it at a point in a tree, from a broad segment at the top down to a specific commodity at the bottom.
It is the scheme most procurement platforms assume by default, it appears as a field in essentially every catalog file format, and it is populated badly almost everywhere. Its value is entirely a function of consistency: a code meaning one thing in one supplier’s file and something else in another’s is worse than no code at all, because it produces totals that look authoritative and are not.
The hierarchy
A UNSPSC code is read as a series of two-digit pairs, each pair narrowing the classification one level. Four levels make up the standard eight-digit code.
- Segment. The broadest grouping, covering an entire domain of goods or services. Office equipment and supplies, food and beverage products, or building and construction materials sit at this level.
- Family. A group of related categories inside the segment.
- Class. A group of related commodities inside the family.
- Commodity. The specific product or service being classified.
An optional fifth pair, the Business Function level, extends the code to ten digits. It describes the function the item performs in the transaction, distinguishing, for instance, an item being rented from the same item being bought outright or being used in manufacturing. It exists in the standard, but most procurement platforms store and exchange the eight-digit form and leave the fifth level empty.
The structure has one property worth understanding, because it is what makes the scheme useful for reporting. Since the pairs run from general to specific and the leading pairs never change as you descend, truncation is aggregation. Drop the last pair from a commodity code and you have its class, drop two and you have its family. A spend report by family is arithmetically the same dataset as one by commodity, grouped differently, with no re-mapping. Unused levels are zero-filled rather than omitted, so a code carried only to family level still occupies the full eight digits.
How a code narrows in practice
Take an ordinary purchase, a case of disposable nitrile gloves.
At segment level the item falls into a broad domain, and which domain depends on intended use. That is the first real decision: gloves bought for a clinical setting belong in a medical segment, while the same physical gloves bought as hand protection for a maintenance team belong under safety and protective equipment. The standard supports both, and the organisation has to pick one convention and hold to it.
Assume the safety reading. The family narrows to protective clothing and personal safety equipment, a grouping that also holds eye protection, hearing protection and protective footwear. The class narrows again to hand protection, sitting alongside the other protective article types in that family. The commodity is the specific kind of glove, distinguished at that level from leather work gloves, chemical-resistant gauntlets and cut-resistant gloves.
Notice what the code does not carry: not the size, the thickness, whether the glove is powdered, the pack quantity, or the colour. UNSPSC answers what kind of thing this is. It does not describe the thing. Anything turning on specification, technical comparison in particular, needs attributes held elsewhere, either in the catalog record or in a different scheme.
Why classification matters at all
A classification code is infrastructure. Nothing about it is visible to the person raising a requisition, and several things depend on it.
Cross-supplier comparison. Without a shared code there is no dimension on which two suppliers’ items can be compared. Each supplier’s category names are its own, so any comparison built on them compares naming conventions.
Category reporting. Classification is the thing that turns transactions into categories, which is the whole basis of spend analysis and every sourcing decision taken from it.
Policy application. Approval thresholds that differ by category, restricted or controlled categories, preferred-supplier rules, and sustainability or safety requirements attached to particular kinds of goods all require the system to know what category a line belongs to before the requisition is submitted.
Tax determination. In some jurisdictions the rate applicable to a supply depends on the nature of the goods or service, and classification data can feed the determination logic. It is a supporting input, not an authority: tax treatment is governed by the relevant tax code, not the product taxonomy.
Search and navigation. The browse tree a buyer clicks through is usually generated from classification data, and poor codes produce a structure that sends people to free-text ordering instead, which is where off-contract spend begins.
UNSPSC and eCl@ss
eCl@ss is the other scheme encountered regularly, particularly in European industrial, technical and MRO categories and in BMEcat catalog content. The two are often presented as alternatives, which understates how different their purposes are.
UNSPSC is broad and shallow. It spans every category an organisation might buy, from professional services to raw materials, and stops at saying what kind of thing an item is. That breadth is why it is the near-universal default in procurement and P2P platforms, and why it is usually the classification field a catalog schema exposes.
eCl@ss is narrower in coverage and far deeper in structure. Alongside the classification tree it carries attribute dictionaries: for a given class it defines the properties that describe items in it, with units and permitted values, so two components can be compared on the same specification set. That orientation towards engineering and technical master data makes it the stronger scheme where the buying decision turns on specification, and the heavier one to populate and maintain.
Organisations operating in both worlds often carry both, using UNSPSC for spend reporting and policy across the estate and eCl@ss in the technical categories where attributes matter. That is a legitimate design and a doubled maintenance burden, since both schemes are versioned and revised, and a mapping built against one release does not stay correct indefinitely.
Suppliers rarely provide usable codes
The practical reality of classification is that the data does not arrive classified.
A supplier typically provides one of four things: no classification at all, its own internal taxonomy built for its own warehouse and sales reporting, a classification field populated at the wrong level of granularity, or a single code applied uniformly across an entire file because the export required the field to be non-empty. Each has to be turned into a usable code on the buyer’s side, and that is recurring work rather than a one-off load task. New items arrive constantly and assortments are revised, so mapping is a maintained process, not a project step. This is one reason catalog management is harder than the first load makes it look.
Three approaches carry most of the load in practice. Rules on description keywords handle large volumes of straightforward items cheaply. Part number prefix patterns work well for suppliers with structured internal numbering. The highest-return technique is mapping the supplier’s own taxonomy to yours once at node level, rather than item by item: agree that this branch of their tree maps to that branch of yours, and every current and future item under it is classified automatically. That mapping survives assortment changes in a way that item-level mapping does not, and it turns a recurring per-item cost into an occasional per-node one. It is worth pushing for the supplier’s own category tree during supplier onboarding for precisely this reason.
Classify to the depth you will actually use
The most common design mistake is choosing granularity for its own sake rather than for a decision it supports.
Over-classification means assigning commodity-level codes across an entire assortment when category managers work two levels up. Every new item then needs a decision, every ambiguous item needs a ruling, and the payoff is a level of detail nobody queries. The maintenance cost is real and continuous while the analytical benefit is zero.
Under-classification is the opposite failure and it is worse. Everything coded at segment level tells you money was spent on office supplies, which you already knew, and supports no sourcing decision.
The usable rule is to classify at the level where a decision gets made. If sourcing events are run at class level, classify to class, and go deeper only in the categories where the extra detail genuinely changes something: high spend, high price variance between sites, or regulatory obligations attached to specific commodities. Different depths in different categories is a sound design, not an inconsistency, as long as it is deliberate, documented, and applied the same way by everyone.
How classification fails in practice
Applied inconsistently across suppliers. One supplier’s nitrile gloves are coded under safety equipment and another’s under medical supplies. Each file is defensible on its own and the aggregate is meaningless. This failure is particularly damaging because nothing in the output signals it: the category total renders cleanly and is simply wrong.
Assigned at load and never revisited. Codes are set when a catalog is first imported and then inherited by every subsequent refresh. New items arrive carrying whatever the supplier sent, coverage decays quietly, and nobody notices until a category report stops matching what the business knows it buys.
Different business units working at different levels. One site classifies to commodity, another to family, a third inherits supplier codes unaltered. Any group roll-up is forced down to the coarsest level present, so the most carefully classified data is wasted by the least.
No convention for ambiguous items. Items that could legitimately sit in two places get classified differently by two people in the same week. The fix is dull and effective: a written convention for the known ambiguous cases, and one named person who decides new ones.
Version drift. Codes from different releases of the scheme coexist in the same dataset, deprecated commodities linger, and mappings built against an older version are never refreshed. The dataset still validates. It just no longer aggregates the way anyone expects.
Treated as a field rather than a decision. The code exists because a validation rule demanded a non-empty value, and no one is accountable for whether it is right. Data in this state passes every technical check and fails every analytical use.
Classification only pays off when it is maintained across every supplier and every refresh, which is a content operations problem rather than a taxonomy one. That is the part SupplierForge is built around: ingesting supplier content in whatever form the supplier can produce, then validating, classifying and normalising it centrally, so one maintained source of classified content feeds the downstream P2P systems instead of each inheriting whatever a supplier put in the field.