A procurement catalog is the structured, priced, approved list of things an employee is allowed to buy through the procurement system. It turns purchasing from a negotiation into a selection.
That distinction matters more than it sounds. When an employee picks a catalogue item, the part number, description, unit of measure, supplier, and contract price are all correct because they were loaded that way. When an employee types what they want into a free-text box, every one of those fields becomes something a buyer, an AP clerk, or a supplier has to reconstruct later. Catalogue coverage is, for that reason, one of the few procurement metrics that predicts almost everything else.
The three types of catalog
Hosted catalogs
A hosted catalog lives inside the buyer’s procurement system. The supplier provides content as a file, the buyer loads and validates it, and from then on the items are searchable alongside every other catalogue in the system.
The advantages are real. Search works across suppliers, so an employee looking for gloves sees every contracted option in one result set. The buyer controls exactly what is visible. There is no dependency on the supplier’s website being up. And because the data sits locally, reporting and classification are straightforward.
The cost is maintenance. A hosted catalog is a snapshot. The moment the supplier changes a price, discontinues an item, or adds a line, the buyer’s copy is wrong, and stays wrong until someone loads a new file.
PunchOut catalogs
A PunchOut catalog inverts the arrangement. Instead of importing content, the procurement system sends the employee out to the supplier’s own web store, authenticated and with contract pricing applied. The employee shops there, and the completed cart is returned into a requisition in the buyer’s system.
Nothing goes stale, because nothing was copied. The supplier maintains their own content, which is work they were doing anyway. Configurable products, real-time stock, and large assortments that would be unwieldy as a flat file all work naturally.
The trade-off is that content the buyer never holds is content the buyer cannot search across, classify consistently, or analyse before the fact. A PunchOut item is invisible to the procurement system until it comes back in a cart. We compare the two models in detail in hosted catalog vs PunchOut, and explain the mechanics of the PunchOut round trip separately.
Contract or non-catalog forms
The third pattern is neither: a structured form tied to a contract, used for things that cannot be listed as items. Services, rate cards, and consumables ordered against a blanket agreement fall here. The employee fills in a constrained form rather than picking a SKU, and the resulting requisition still carries the right supplier, contract reference, and account coding.
This category is routinely forgotten in catalogue strategy, and it is often where the largest share of spend actually sits.
The file formats
Hosted catalogs arrive in a handful of formats, and knowing which is which saves a lot of confusion in supplier conversations.
- CIF (Catalog Interchange Format). A flat comma-separated format originally defined by Ariba. Still extremely common, particularly in North America. Simple, well understood, and limited: it handles a flat list of items with prices and classifications, and not much more.
- cXML catalog. An XML expression of catalogue content using the same protocol family as PunchOut. More expressive than CIF, supports richer attributes and hierarchies.
- BMEcat. The European standard, originating in Germany, maintained by BME. Considerably richer than CIF: multi-language descriptions, media attachments, product features, price tiers, and configurable relationships. Common across DACH and continental European supply bases.
- Spreadsheet templates. Not a standard at all, but overwhelmingly the most common real-world format for smaller suppliers. Every procurement platform ships an importer for its own template shape.
Alongside the format sits classification. UNSPSC is the most widely used taxonomy for procurement, with eCl@ss common in European industrial and technical categories. Consistent classification is what makes cross-supplier search and spend analysis possible; inconsistent classification is what makes a catalogue technically loaded but practically unusable.
What a catalog record actually needs
A minimum viable catalogue line carries more fields than most people expect:
- Supplier part number and, where it exists, the manufacturer part number
- A description an ordinary employee will recognise, not a warehouse code
- Unit of measure and, critically, the order quantity multiple
- Contract price, currency, and the validity period of that price
- Classification code
- Lead time
- Tax treatment
The unit of measure field deserves particular attention because it is the most common source of expensive errors. An item priced per box but ordered per piece produces an order for a hundred times what anyone intended, and the mistake usually surfaces at the loading dock rather than at approval.
Why coverage matters more than depth
The instinct when building catalogue strategy is to go deep: get every line from the largest supplier loaded and perfect. The better instinct is usually to go wide.
A category with no catalogue coverage at all sends every purchase down the free-text path, where price leakage and invoice exceptions originate. A category with rough but present coverage keeps the transaction structured even when the content is imperfect. Getting to partial coverage across most of the supply base moves more spend into a controlled path than getting to perfect coverage in one corner of it.
This is also why the long tail of suppliers matters disproportionately. The largest suppliers can afford to maintain a PunchOut site or produce a clean BMEcat file. Small regional suppliers, the ones behind a large share of operational spend in sectors like hospitality and facilities, usually cannot. Whatever the catalogue strategy is, it has to have an answer for them that does not involve a project per supplier.
Where this tends to break
Three failure modes recur across estates of every size.
The catalog is loaded but not searched. Employees cannot find items because descriptions were written for a warehouse system, not a human. The catalogue is technically present and functionally invisible.
The catalog is accurate at load and wrong at order. Prices change, the refresh cadence is quarterly, and the gap between catalogue price and invoice price becomes a permanent stream of AP exceptions.
The catalog covers the easy suppliers. The three largest suppliers are on PunchOut, everything else is free text, and the majority of transactions by count sit in the unstructured path even though the majority of spend by value does not.
Solving these is less about the procurement platform and more about the pipeline that gets supplier content in and keeps it current. That pipeline is what SupplierForge is built for: taking supplier content in whatever form a supplier can actually produce, and delivering it into the buyer’s existing procurement system in a state it can use. The deeper operational problem behind all three failure modes is covered in catalog management: why clean catalog data is hard.