Loading a supplier catalog into a procurement system is a solved problem. Every platform has an importer, every supplier can produce a file of some kind, and the first load usually goes fine.
Keeping several hundred catalogs accurate, simultaneously, for years, across price changes and discontinued lines and supplier system migrations, is not solved anywhere. Catalog management is the discipline of managing that second problem, and it is where most procurement transformation programmes quietly lose their returns.
Why a loaded catalog stops being correct
A catalog is a snapshot of a moving thing. From the moment it is loaded, it starts drifting from reality in several independent ways at once.
Prices change. Contract renegotiations, indexed pricing, fuel and energy surcharges, currency movement, and volume tier changes all move the number. If the refresh cadence is quarterly and prices move monthly, the catalog is wrong most of the time it is being used.
Items get discontinued. The supplier stops carrying a line. It remains in the buyer’s catalog, employees keep ordering it, and the orders keep getting rejected or silently substituted.
Items get added. New products exist and are invisible to buyers, so purchasing happens off-catalog through free text.
Part numbers get reissued. A supplier changes internal SKU structure during a system migration and every reference in the buyer’s catalog breaks at once.
Packaging changes. The item now ships twelve to a case instead of ten. The price is updated. The unit of measure is not.
That last one causes more expensive errors than the rest combined, and deserves its own section.
The unit of measure problem
Unit of measure is a small field that carries an enormous amount of failure.
An item can be priced per piece, per box, per case, per pallet, per kilogram, per litre, per metre, per pack of a specified count. The supplier’s system, the buyer’s system, and the catalog file may each express this differently, and the abbreviations are not standardised in practice even where a standard exists. “EA”, “PC”, “PCE”, “UN” and “1” have all been used to mean a single unit.
Two things go wrong. The unit mismatch: the buyer orders in pieces what the supplier prices in cases, and the order is out by the case factor. And the order multiple: the item can only be supplied in multiples of six, the catalog does not carry that constraint, and every order for four gets adjusted upward without anyone deciding to.
Both surface late. The requisition looks reasonable, the approval passes, and the discrepancy appears either at the loading dock or in a failed invoice match. By then several people have handled it. See what is three-way matching for where these land.
Classification is not optional
Catalog lines need classification codes, usually UNSPSC and in some European industrial contexts eCl@ss, for anything above item-level ordering to work.
Without consistent classification you cannot report spend by category, because every supplier’s own category names are different. You cannot compare across suppliers, because there is nothing to compare on. You cannot apply category policy, because the system cannot tell what category a line belongs to. And you cannot spot that three suppliers are all selling the same thing at different prices.
Suppliers routinely provide either no classification or their own internal taxonomy. Mapping that to a common scheme is genuine work, and it has to be redone whenever the assortment changes. It is also the step most often dropped when a catalog load is running behind schedule, which is how organisations end up with a technically complete catalog that is useless for analysis.
Description quality decides whether anyone uses it
A catalog that cannot be searched successfully is functionally absent, however accurate it is.
Supplier descriptions are typically written for the supplier’s own warehouse and order-entry systems. They are abbreviated, heavy with internal codes, inconsistent in word order, and often truncated to a legacy field length. “GLV NTRL PWDRFREE BL L 100PK” is a real shape of description, and an employee searching for “nitrile gloves large” will not find it.
The consequence is not an empty search result and a shrug. The consequence is a free-text requisition, which means an unclassified line, a guessed price, and an invoice that will not match. Search failure at the catalog is where off-contract spend originates.
Fixing this means normalising descriptions into language the buying population actually uses, and maintaining that normalisation as content changes. It is unglamorous and it has a larger effect on catalog adoption than almost anything else.
The multiplication problem
Everything above is manageable for one catalog. The difficulty is that none of it stays manageable at scale, because the work multiplies along two axes at once.
A buying organisation with three hundred suppliers has three hundred content pipelines, each in a different format, on a different cadence, with different data quality, changing at a different rate. A group purchasing organisation serving many members has that multiplied again by the number of member systems the content has to land in, each with its own field expectations and import rules.
The formats alone are a project: CIF from suppliers on Ariba-derived tooling, BMEcat from continental European suppliers, cXML from the technically sophisticated, and spreadsheets in several hundred private shapes from everyone else. See what is a procurement catalog for what these formats actually carry.
This is why so many organisations end up with a small number of well-maintained catalogs covering their largest suppliers, and nothing at all for the long tail. It is not a lack of intent. It is that the per-supplier effort is roughly constant while the per-supplier value falls sharply as you move down the spend curve, and at some point the arithmetic stops working.
What actually helps
Four things move the needle, in rough order of return.
Validation at ingest rather than at use. Reject or flag a catalog file that has missing units of measure, prices outside plausible bounds, or unmapped classifications, at the moment it is loaded. The alternative is discovering the same problems one failed invoice at a time, months later, at far higher cost.
A refresh cadence matched to volatility, not to convenience. Quarterly refreshes for a category whose prices move monthly guarantee a permanent error rate. Either the cadence increases or the category moves to a live model such as PunchOut, as discussed in hosted catalog vs PunchOut.
Description normalisation. Rewriting supplier descriptions into searchable language, once, systematically, rather than per complaint.
Accepting the supplier’s real capability. Insisting on BMEcat from a supplier who has a spreadsheet and no technical staff produces no catalog at all. Accepting the spreadsheet and doing the structuring on the buyer’s side produces a working one.
That last principle is the one BoreaTech built around. SupplierForge ingests supplier content through whatever channel the supplier can actually manage, including CSV, SFTP, API and EDI, and handles the validation, classification and normalisation centrally so that one maintained source of truth can feed multiple downstream P2P systems. The point is to stop the per-supplier effort scaling linearly with supplier count, because that is the specific arithmetic that strands the long tail.