Archive | Upgrade to Premium | Sponsor

Hi {{FIRST_NAME|readers}},

When I published the piece on death by supplier punch-out catalogs a few weeks back, I wasn't expecting the volume of questions it generated.

The consistent theme: people recognized the problem immediately. Punch out catalogs are an easy fix to the wrong problem… They make catalog maintenance easier, but the requester user experience (UX) gets worse with each new catalog added…

The UX problem is real… But it's the surface layer. The deeper issue is structural/architectural.

Most organizations are running a 3+ track buying system where material master purchases, catalog spot buys, and free-text orders flow in parallel with no reconciliation between them.

Furthermore, almost nobody has the capability to surface existing inventory to a requester at the point of purchase before they buy something that's already on the shelf… 😥

The consequences are spend fragmentation and bloated inventories. Your spend analytics don't know that the same item bought four different ways is the same item. Your category strategies are built on an incomplete picture. Your savings model keeps underdelivering and nobody can explain why.

This week's Deep Dive goes there:

I hope this helps answer the questions that came up a few weeks ago. If you have more after reading, hit reply. I’m always happy to chat.

Onwards!

P.S. My good friend Tom Mills just launched a YouTube channel. 25+ years in procurement, 140K+ LinkedIn followers, now conquering video format. He’s tackling all the hot procurement topics one at a time. Check it out.

📰 In this week’s edition:

Note: Some of the content listed above is only available in the email version of this newsletter. Don’t miss out! Sign up for free to get the next edition.

Punch-out catalogs are one of those procurement ideas that sounds brilliant on paper. Set up a punch out catalog once, hand the catalog maintenance off to your vendors, and forget about it. No more internal teams manually updating price lists. No more stale hosted catalog data. Suppliers own their content, keep it current, and your buyers get a consumer-grade shopping experience.

What's not to love?

Well have I got news for you! Your requesters are bouncing between five different supplier websites. Each one looks different, works differently, and returns to your ERP with a different data structure. There's no way to search across suppliers in one place. There's no way to compare a Grainger price against a Fastenal price without opening two browser tabs. And when a requester gets frustrated enough, they skip the catalog entirely and reach for a P-Card or fire off a free-text order. This request, which you’re precisely trying to avoid with catalogs, lands on a procurement analyst's desk for manual intervention…

Meanwhile, your purchasing data is a disaster. The same physical item is being bought four different ways: through a material master in your ERP, through punch out catalog for one vendor, through a hosted catalog for another vendor, and through a free-text requisition when your requester is frustrated… And your spend analytics tools have no idea they're the same thing. Your category manager ends up building a sourcing strategy on spend data that's 60% complete at best. Your inventory team is ordering stock that's already in the warehouse because nobody can see stock levels at the point of purchase.

And the savings your catalog program was supposed to deliver? Nowhere to be found…. You can't enforce preferred supplier compliance when requesters have six different buying experiences and the path of least resistance is always "just buy it online and expense it."

This IS what mature, well-intentioned, enterprise grade punch out catalog programs actually look like in practice today. In many organizations, issues stem not from a failure of execution… But from a fundamental failure of architecture.

This article breaks down why the “punch out-first” catalog strategy has hit a structural ceiling and what a different architectural approach looks like when you build catalogs around the buyer, the supplier, procurement and shared data, not just maintenance convenience.

This Deep Dive in partnership with…

To understand the problem, you need to understand how we got here. Vendor catalog management has gone through three distinct iterations… Each one left a different structural scar on enterprise procurement.

The earliest e-procurement systems were simple: a supplier would give you a price list, you'd load it into your system, and buyers would shop against it. Clean. Centralized. Controllable.

The catch? Maintaining those price lists at scale is a nightmare. Someone on your team must chase suppliers to get new prices, update prices manually, regularly, and accurately. Spoiler alert: at scale, they never do. Outdated prices mean blocked invoices, delayed shipments, supplier disputes and angry finance teams.

OCI (Open Catalog Interface) punch out catalogs were the industry's answer to the maintenance problem. Instead of your team maintaining a price list, the supplier maintains their own catalog on their own website. Your requester "punches out" of the ERP requisition, shops in the supplier's environment, and a structured cart gets returned back into your system.

Price accuracy? Dramatically improved. Catalog freshness? Supplier's problem. Buyer experience? Consumer-grade. This felt like a genuine win (and for a lot of use cases, it was).

Two common variants emerged:

Furthermore, as you work your way down supplier lists, you quickly realize that only a handful of big suppliers support punch out catalogs, even today. Those smaller, specialized suppliers you rely on? They don’t have the IT maturity to provide a punch out… This means you still have to host and maintain pricing data in addition to your new punch outs. Your catalog program becomes more complex to manage. Not less.

As punch-out catalogs proliferated, procurement teams ended up with a three-track buying system running in parallel… And none of the three tracks knows what the others are doing.

The result is three separate data streams for what are often the same physical goods, with no reconciliation happening between them.

Your ERP has a material master (a structured record of every item your organization officially procures, complete with characteristics, specifications, approved suppliers, and inventory positions). But your catalogs? They have no idea your material master exists. The catalog returns a supplier part number, a description, and a price. Your ERP receives it. And the two data worlds never truly connect. And free-text orders are even worse…

Most vendor catalog content is classified using UNSPSC (United Nations Standard Products and Services Code). In theory, this is a standard hierarchical taxonomy designed to categorize goods and services at a universal level.

The theory is elegant. The practice is painful.

UNSPSC codes are too coarse for meaningful materials management. A code like 31161500 tells you something is a "Hardware fastener”. It doesn't tell you whether it's an M8 hex bolt in stainless steel or a #10 wood screw in zinc. For commodity procurement and spend categorization? Perhaps adequate. For matching a catalog item to a specific material master record in your ERP? Nowhere close.

Your ERP uses characteristics (specific, structured attributes like length, width, color, etc.) to identify materials. UNSPSC codes don't bridge that gap.

Furthermore, as you try to consolidate your spend data across multiple geographies, from different source S2P Suites and ERP systems, from different business units, you realize that everyone is running with different versions of the UNSPSC… Why? The implementation teams used the latest codes that were in effect when they initially implemented each different purchasing system.

Given that UNSPSC codes are changed and updated by the United Nations at least once a year, but that nothing updates all of your systems leveraging previous code versions, the result is a mishmash of various generations of UNSPSC commodity codes you’re left to make sense of at the aggregate level…

These are the two reasons why organizations serious about spend classification always revert back to a custom, in-house commodity code taxonomy.

In addition to the classification problem, we need to be honest about catalog limitations. Your vendor punch-out catalog, no matter how good, cannot:

These aren't edge cases... They're the rule. And they compound every single day your organization is running a “punch-out-only” catalog strategy.

Think of it as the ground truth of your company’s material universe.

For organizations that deal in direct materials, MRO (Maintenance, Repair & Operations), or any category where item specifications actually matter, the material master isn't optional infrastructure… It's the backbone of procurement integrity.

When a purchase flows through the material master:

Remove any of these, and operational efficiency takes a hit. Which is precisely what's happening every time a requester punches out to a vendor catalog and buys there instead.

Here's where things get even uglier. In most enterprise procurement environments, you've got two populations buying the same physical items:

Both groups are buying the same bearing. The same reagent. The same filter cartridge. But because Group A is punching out and Group B is procuring formally, the spend data is captured in two completely different ways. The analytics sees two separate items. The warehouse sees duplicate stock. Finance sees two different prices for what is an functionally identical product.

The result? Spend fragmentation.

Nobody planned this. It emerged from an architecture that was never designed to bridge the two worlds.

Let's be concrete about what spend fragmentation actually costs:

This is the part that's genuinely counterintuitive: vendor punch-out catalogs don't create rogue spending. They legitimize it.

A requester using an approved, IT-sanctioned punch-out catalog isn't going off-system. They're doing exactly what the system allows… And that's the problem. The catalog looks compliant. It routes through your procurement system. It generates a PO. But the underlying purchase is completely disconnected from your inventory, your contracts, and your material master.

The subsequent spend fragmentation isn't a data quality problem you can patch with a spend normalization tool. Those tools work by finding and merging duplicates after the fact (after the inventory has been double-ordered, after the part has been purchased at different prices, after the category report has gone to the CPO).

The fix needs to happen at the point of purchase. This means the catalogs and the material masters need to coexist in the same system at the point of search to affect behavior before purchase.

Here's what happens to your category strategy when your spend data is fragmented:

None of this shows up on a dashboard as "fragmentation." It shows up as inexplicably bad sourcing outcomes and categories that never quite achieve the savings the model promised.

So what's the fix? The principle is straightforward: every item that a requester can buy through a vendor catalog needs to be linked, at the point of purchase, to its corresponding material master record in the ERP (when it exists).

Do that, and suddenly the purchase is visible to inventory management, compliant with contracted pricing, traceable in spend analytics, and part of the same data universe as every formal MRP-generated procurement transaction.

If you present this unified data to requesters at the point of search, all of a sudden better purchasing (or stock consumption) decisions get made automatically.

The problem? Doing this matching/mapping manually doesn't scale.

An enterprise might have anywhere from 20,000 to 200,000+ material master records. Across all its vendor catalogs, it might have access to millions of supplier SKUs. Mapping one to the other by hand is a project that takes months, breaks the moment a supplier updates their catalog, and requires a senior level of subject matter expertise that doesn't exist in a spreadsheet (knowing that manufacturer part number XYZ-4481 is the same as internal material M-00234).

This is exactly the kind of problem that breaks on people, not systems.

What's needed is a matching engine that can read a supplier's catalog item (its description, part number, attributes, and specifications) and map it to the correct material master record automatically, at scale, and in a way that stays current as catalogs change.

Ideally, the system can also help you improve the quality of your material master information over time based on information in vendor catalogs at the point of purchase.

This is where AI becomes genuinely useful in procurement. Not in generating summaries or writing emails… but in doing the tedious, high-precision matching work that humans are bad at doing at scale.

Regardless of which solution you use, the main takeaway is that you need all the inventory, material and catalog data to exist in a single place to provide an optimal user experience that also maximizes compliance.

Let’s illustrate with an example.

Axiom's MarketMaterials module is built specifically to solve this architecture problem. It doesn’t replace your ERP or Source-to-Pay Suite. It sits in front of the “moment of purchase” and ensures every catalog transaction is connected to the right material master record before a line item ever hits your system.

It's one of four integrated modules in Axiom's Enterprise Sourcing and Tail Spend Platform. The other modules: MarketPlace (catalog sourcing), MarketSource (autonomous sourcing), and MarketPay (tail spend payment orchestration) work alongside it. But MarketMaterials is the module that closes the data loop for material-heavy businesses.

The architecture is a five-phase lifecycle:

Because in Axiom all catalog data lives in a single place, the matching engine can work at scale (across every supplier, every SKU, every material record) and stay current as catalogs are updated.

When you connect your material master to your vendor catalogs items, several things start working that couldn't work before.

Every purchase (whether it originates from vendor catalog data or a formal MRP-driven requisition) is now linked to the same central material record. Spend can truly be aggregated at the material level for the first time. You're not just seeing "what did we spend with Supplier X"… You're seeing "what did we spend on Material Y, across all suppliers, plants, systems and buying channels."

That's a fundamentally different (and far more actionable) answer to the question.

Category managers building sourcing strategies need accurate baseline data. When catalog spend and formal procurement spend are reconciled at the material level, the spend baseline is finally complete. Volume leverage is real. Preferred supplier compliance is measurable. Savings opportunities are sized correctly.

You stop negotiating with one hand behind your back.

When inventory is visible before purchase, over-ordering stops. When requesters can see all valid options at once, overpaying stops. When the buyer experience is unified (one search bar, all results) shadow purchasing channels dry up.

Compliance becomes a product of system design and user experience, not a reminder in a policy document and a quarterly “all hands” meeting.

The trajectory of procurement technology is toward tighter integration between the systems of record (ERP, material master, contracts) and the systems of engagement (catalogs, marketplace, intake, orchestration). For too long, those two layers have been kept separate (e.g. connected by an aging OCI standard that was good enough to pass a cart, but not good enough to share intelligence).

Most approaches to the fragmentation problem are remediation approaches: spend normalization, data enrichment, post-hoc classification, outsourcing... These patch the symptoms. A solution leveraging the principles described herein addresses the root cause by making the connection happen before the purchase… At the point of search, before any line item is generated.

That's a fundamentally different architecture. And it's why the results are structural rather than incremental.

The matching problem scales with catalog size. The larger your supplier network and the more SKUs you manage, the more intractable manual approaches become. AI-driven, characteristic-based matching scales in the opposite direction (the more data it has to work with, the better it performs).

Clean, connected material data is the foundation for the next generation of procurement capability: a self-improving, self-regulating content sourcing platform that can identify available stock, recommend alternatives, trigger reorders, and reduce unnecessary purchasing without human intervention.

You can't build autonomic procurement on fragmented data… And automated procurement has reached its limit.

Your vendor catalogs aren't the problem. The architecture behind them is.

OCI punch out catalogs solved for the wrong problem… It made buying easier and reduced data maintenance burdens but left the data connection to chance. The result is a parallel universe of spot-buy spend that your ERP can't see in detail, your inventory system can't plan around, and your category managers can't incorporate into their category strategies.

The material master is the missing link. Not because ERPs are perfect (they're most definitely not) but because the material master is where your organization's institutional knowledge about what you buy actually lives. It has the specifications, the BOM mappings, the approved suppliers, the contracted pricing, and the inventory logic. Your vendor catalog just has your prices… if even.

Connecting those two worlds (at the point of purchase, at scale, through AI-driven matching) is the architectural fix the industry has needed for a decade. Solutions like Axiom MarketMaterials are a concrete, deployable implementation of that principle.

Furthermore, once you start centralizing data, you can start improving the quality of your own material masters with vendor catalog data at evey purchase.

If your spend data has gaps you can't explain, if your category strategies keep underdelivering, or if your inventory team and your procurement team seem to be operating in separate realities… The explanation in this article is why... And a solution like Axiom is the fix.

Ready to see what connected material master and catalog data looks like in practice? Book a demo with the Axiom team at helloaxiom.ai