Buyer adding items to an online procurement shopping cart
Purchasing Operations — Reference

Punchout Catalog: Definition, Process & Best Practices

By Fredrik Filipsson
Published February 2, 2026
Updated March 13, 2026
Reading time 11 min

What a Punchout Catalog Is

A punchout catalog is a connection that lets a buyer shop on a supplier's own e-commerce website directly from inside their procurement system. The buyer "punches out" from the procurement tool to the supplier's site, builds a shopping cart with live pricing and availability, and then returns that cart to the procurement system, where it becomes a requisition that flows through normal approval. It gives employees the familiar feel of online shopping while keeping every purchase on-contract and under procurement control.

The problem punchout solves is a real tension. Suppliers have rich, constantly changing catalogs — thousands of configurable products with real-time pricing — that are impractical to copy into a procurement system. Buyers want that full experience; procurement wants control. Punchout resolves it by sending the buyer out to shop on the supplier site, then bringing a clean, contract-priced cart back into the controlled purchase order workflow.

Key Takeaways

  • Shop out, control in. Buyers shop the supplier's live site; the cart returns as a controlled requisition.
  • Live, contract-specific data. Punchout shows real-time pricing and availability, negotiated for your account.
  • cXML is the standard. Most punchout runs on cXML; OCI is the SAP-associated alternative.
  • Best for big, dynamic catalogs. Hosted catalogs suit small, stable lists; punchout suits large, changing ones.
  • It drives adoption. A good shopping experience raises catalog use and cuts maverick spend.

How a Punchout Catalog Works

The punchout flow is a sequence of automated messages between your procurement system and the supplier's site. Step by step:

  1. Select the supplier. The buyer clicks a punchout supplier inside the procurement system.
  2. Punchout setup request. The procurement system sends a secure request that identifies the buyer and organisation, and logs the buyer into the supplier site automatically.
  3. Shop on the supplier site. The buyer browses the supplier's full catalog with live, account-specific pricing and stock.
  4. Return the cart. At checkout, instead of placing an order, the supplier site sends the cart back to the procurement system as a requisition.
  5. Approve and convert. The requisition routes through approval; once approved it becomes a purchase order sent electronically to the supplier.
  6. Fulfil and invoice. The supplier ships and invoices against the PO, ready for matching.

Crucially, the buyer never actually places the order on the supplier site — the cart is just a structured list of items and prices handed back for approval. That single design choice is what preserves procurement control while keeping the shopping experience intact. The returned requisition feeds the same downstream controls as any other order, including the three-way match against PO and receipt covered in our guide to invoice and AP automation tools.

Punchout vs Hosted Catalog

The two ways to put supplier products in front of buyers are hosted catalogs and punchout catalogs, and the choice depends on the nature of the catalog.

DimensionHosted catalogPunchout catalog
Where products liveInside procurement systemOn supplier's website
PricingLoaded periodicallyLive, real-time
Best forSmall, stable product listsLarge, changing catalogs
Configurable productsHardNative
Maintenance burdenOn buyer to updateOn supplier's site
Setup effortLowModerate (integration)

Many organisations use both: hosted catalogs for a handful of simple, high-frequency items, and punchout for large suppliers whose catalogs are too big or dynamic to host. The decision is really about who maintains the data — with punchout, the supplier keeps their own catalog current, which removes a substantial maintenance burden from the procurement team and is a big part of why punchout drives better catalog adoption.

"Punchout's quiet genius is that the supplier maintains the catalog, not you. The buyer gets a live storefront, procurement gets a clean requisition, and nobody is hand-updating a spreadsheet of 40,000 SKUs."

cXML vs OCI: The Punchout Standards

Punchout relies on agreed message formats so the procurement system and supplier site can talk. Two standards dominate:

cXML (commerce XML) is the most widely used. It defines the punchout setup request that starts a session and the punchout order message that returns the cart. The large majority of suppliers and procurement platforms support cXML, which makes it the default choice for most new connections.

OCI (Open Catalog Interface) is an alternative most associated with SAP environments. If your ERP and procurement layer are SAP-centric, OCI may be the native path; otherwise cXML is usually simpler. The practical advice is to confirm which standard both your procurement platform and the supplier support before scoping the integration, because a mismatch turns a routine setup into a custom project.

Why Companies Use Punchout Catalogs

Punchout earns its integration cost through a combination of control and adoption benefits:

  • On-contract pricing. Buyers see the rates negotiated for their account, so purchases stay on-contract by default.
  • Higher catalog adoption. A real shopping experience means employees actually use the approved channel instead of going rogue.
  • Lower maverick spend. Easy compliant buying is the most effective control against off-contract purchasing — a core goal of procurement compliance.
  • Clean purchase orders. Structured cart data produces accurate POs, improving downstream matching.
  • Less data maintenance. The supplier keeps their catalog current, not your team.

The adoption point is the one teams underestimate. A procurement system only delivers savings if people buy through it; punchout makes the compliant channel the pleasant one, which is why it consistently lifts catalog usage and reduces the off-contract leakage that erodes negotiated value.

See How Buying Tools Compare

Punchout is one piece of the operational buying stack. Explore the platforms that orchestrate it.

Punchout Setup Best Practices

A punchout connection is straightforward when both sides support the same standard, and painful when they do not. To keep setup clean:

  1. Confirm the standard early. Verify both your platform and the supplier support cXML (or OCI) before scoping.
  2. Test the round trip. Validate the full flow — setup request, shopping, cart return, and PO transmission — in a sandbox before go-live.
  3. Map the data. Ensure unit-of-measure, part numbers, and pricing fields return cleanly so requisitions and POs are accurate.
  4. Prioritise high-volume suppliers. Connect the suppliers where catalog size and order frequency justify the integration first.
  5. Plan for maintenance. Agree who updates connection credentials and handles supplier-site changes that could break the link.

Punchout sits within the broader operational buying layer, alongside requisitioning, receiving, and invoice matching. If you are designing that layer end to end, our walkthrough of the source-to-pay process shows where punchout fits, and the independent AP automation straight-through-rate benchmark is a companion data set on how clean upstream PO data — which punchout improves — lifts downstream automation rates.

Limitations and When Not to Use Punchout

Punchout is powerful but not free, and it is not the right answer for every supplier. The integration carries setup and maintenance cost, so connecting a supplier you order from twice a year rarely pays back. For small, stable product lists a hosted catalog is simpler and cheaper. Punchout also depends on the supplier maintaining a capable e-commerce site and supporting the punchout standard — not every vendor, particularly smaller or specialised ones, can offer it.

There are failure modes to plan for as well. Because punchout depends on a live connection to the supplier's site, an outage on their side or an expired credential breaks the buying path until it is fixed. Data-mapping mismatches — units of measure, part numbers, or currency that do not translate cleanly — can produce requisitions that need manual correction. None of these are reasons to avoid punchout, but they are reasons to connect deliberately: prioritise high-volume suppliers, test thoroughly, and assign clear ownership for keeping connections healthy. For the long tail of low-frequency suppliers, a card-based or hosted approach is usually the better fit.

Building the Business Case for Punchout

Because punchout carries real setup and maintenance cost, it pays to justify each connection deliberately rather than connecting suppliers indiscriminately. The economics hinge on three variables: the order volume with the supplier, the size and volatility of their catalog, and the level of off-contract leakage you are trying to recover. A high-volume supplier with a large, frequently changing catalog and a history of maverick buying is the textbook punchout candidate; a low-volume supplier with a short, stable list usually is not.

The benefits to weigh against the integration cost fall into three buckets. There is hard savings from keeping spend on-contract that would otherwise leak to list pricing. There is efficiency from eliminating manual catalog maintenance and from cleaner purchase orders that match more reliably downstream. And there is risk and data value from the improved spend visibility a controlled channel produces. When those add up against the setup effort for a given supplier, punchout is worth it — and when they do not, a hosted catalog or card-based approach is the more sensible choice. Running this calculation supplier by supplier, the way you would weigh any procurement investment in our procurement system evaluation, keeps the program focused on connections that actually pay back.

Punchout, Catalog Adoption, and Maverick Spend

The strategic reason punchout matters more than its technical mechanics suggest is its effect on behaviour. Every procurement leader knows that a buying system only delivers savings if people actually use it, and the most common reason employees go off-contract is that the compliant channel is slower or clunkier than just ordering directly from a supplier's website. Punchout removes that excuse by making the compliant channel be the supplier's website — the same shopping experience the employee would have used anyway, only now wrapped in approval and contract pricing.

That is why punchout is consistently associated with higher catalog adoption and lower maverick spend. It aligns the easy path with the compliant path, which is the single most effective lever in procurement compliance. The benefit compounds: more buying flowing through the controlled channel means cleaner spend data, more accurate analytics, and a stronger position for the next sourcing cycle. In that sense punchout is not just an operational convenience — it is a compliance and data-quality investment disguised as a catalog feature.

How AI Is Changing Catalog Buying

The catalog experience is itself evolving as AI enters operational buying. Conversational and guided-buying interfaces increasingly sit in front of catalogs and punchout connections, helping a requester describe what they need in plain language and routing them to the right compliant source — whether that is a hosted item, a punchout supplier, or a new sourcing request. This reduces the burden on the requester to know which catalog to use, which is often where compliance breaks down.

For procurement teams, the practical takeaway is that punchout remains the connective tissue underneath these newer interfaces, not a technology being replaced by them. The standards and flow described here continue to carry the transaction; AI simply makes finding the right catalog easier. Our independent vendor landscape and market map tracks how guided-buying and intake capabilities are bundling with traditional catalog management, so you can see which platforms genuinely modernise the buying experience versus which rebrand the same workflow.

Frequently Asked Questions

What is a punchout catalog?

A punchout catalog lets a buyer shop on a supplier's e-commerce site from within their procurement system. The buyer punches out to the supplier site, builds a cart with live pricing, and returns it to the procurement system as a requisition for approval. It preserves the rich supplier shopping experience while keeping procurement controls.

How does a punchout catalog work?

The procurement system sends a secure punchout setup request that logs the buyer into the supplier site. The buyer shops, then checks out — the cart is returned to the procurement system as a requisition rather than an order. After approval, a purchase order is sent to the supplier electronically. The exchange uses standards such as cXML or OCI.

What is the difference between a punchout catalog and a hosted catalog?

A hosted catalog stores supplier products and prices inside the procurement system, so buyers shop locally. A punchout catalog sends buyers to the supplier's live site and brings the cart back. Hosted catalogs suit stable, simple lists; punchout suits large, frequently changing catalogs with configurable products and real-time pricing.

What is cXML punchout?

cXML (commerce XML) is the most widely used punchout standard. It defines the messages exchanged — the setup request that starts a session and the order message that returns the cart. OCI (Open Catalog Interface) is an alternative associated with SAP. Most major suppliers and procurement platforms support cXML.

Why do companies use punchout catalogs?

To give employees a familiar shopping experience while keeping spend on-contract and controlled. Punchout shows live contract pricing, routes purchases through approvals, and creates clean POs automatically. This raises catalog adoption, reduces maverick spend, and lowers the effort of maintaining product data in the procurement system.