Punchout Catalog Explained: What Your Buyers’ Procurement Systems Need From You

A punchout catalog is a live session between your ecommerce storefront and a buyer’s procurement system, such as Coupa or SAP Ariba, that lets the buyer shop your site from inside their own software and return an order without leaving their approval workflow. The connection runs on a protocol, usually cXML, that passes specific documents back and forth in a fixed sequence. It is not a marketing feature but a compliance requirement set by your buyer’s procurement policy.

Distributors and manufacturers who sell into large accounts run into this the moment a customer’s procurement team mandates that all purchasing happen inside a system like Coupa, SAP Ariba, or Jaggaer. We see this constantly in industrial ecommerce, where a plant’s maintenance buyer has no authority to place an order outside the approved procurement platform, no matter how good your storefront looks. If that buyer cannot punch out to you, they cannot buy from you, regardless of price or relationship.

Most explanations of punchout catalogs stop at “a secure connection between two systems.” That tells an IT director nothing about what document arrives on their server, what it contains, or what has to be returned within seconds. This post names every document in the exchange, compares what Coupa, SAP Ariba, Jaggaer, and Oracle Procurement Cloud actually require before they will approve you, and gives real cost and timeline ranges so you can budget the project correctly the first time.

What Is a Punchout Catalog and Who Actually Asks for One?

A punchout catalog is a live, authenticated session, not a file. Unlike a hosted catalog upload, where you send a static price list once a quarter, punchout opens your actual storefront inside a frame the buyer’s procurement system controls, showing your live inventory and their negotiated contract pricing at the moment they shop.

The request rarely comes from your sales team. It comes from the buyer’s procurement or IT department, usually as a condition of staying an approved supplier. Large manufacturers, hospital systems, universities, and government agencies standardize on a small number of procurement platforms and require every supplier above a spend threshold to support punchout into that platform. If your customer’s accounts payable team has moved to three-way matching against a purchase order, a punchout is very often the mechanism that gets your products into that purchase order in the first place.

This matters for budgeting: you do not choose whether to build a punchout catalog based on your own roadmap. You build it because a named account requires it, and the account’s procurement system, not your product team, sets the technical requirements.

How Does a Punchout Catalog Session Work, Step by Step?

A punchout catalog session moves through a fixed sequence of named documents. Here are the 9 steps in the sequence, using Coupa as the buyer’s platform and cXML as the protocol, since this is the combination most suppliers meet first.

1. The buyer clicks your company inside Coupa. Their procurement portal shows a tile or link for your business, configured during supplier enablement.
2. Coupa sends a PunchOutSetupRequest to your punchout endpoint. This is an HTTP POST containing a shared secret credential, the buyer’s identity, and a return URL where the finished cart should be sent.
3. Your system authenticates the request and creates a session. If the shared secret is valid, you generate a temporary, authenticated session tied to that buyer.
4. You return a PunchOutSetupResponse containing a start URL. Coupa redirects the buyer’s browser to that URL, which opens your actual storefront, already authenticated, already showing that buyer’s contract pricing.
5. The buyer shops and builds a cart on your site. This is your real storefront. Nothing about the browsing experience is faked or simplified.
6. The buyer clicks “checkout” or “return to Coupa.” Instead of processing payment on your end, your storefront packages the cart contents into cXML.
7. Your site posts a PunchOutOrderMessage back to Coupa’s return URL. This document carries every line item, quantity, part number, unit of measure, and price the buyer selected.
8. Coupa turns the PunchOutOrderMessage into an internal requisition. The requisition enters the buyer’s own approval workflow, which you have no visibility into and no control over.
9. Once approved, Coupa issues a PurchaseOrderRequest to your order management endpoint. This is a real, legally binding order, formatted in cXML, that your system needs to accept and process like any other order.

Ten years ago, most of this ran on file transfers and manual reconciliation. Today, the entire exchange from click to purchase order can complete in under a minute, provided your endpoint responds fast enough and your session does not time out waiting on a slow pricing lookup.

Which Protocols Will You Be Asked to Support: cXML Punchout or OCI?

Two protocols cover almost every punchout request you will receive. cXML punchout, maintained by cxml.org and originally developed for Ariba, is the protocol behind the PunchOutSetupRequest, PunchOutOrderMessage, and PurchaseOrderRequest documents described above. SAP Ariba, Coupa, and Jaggaer all speak cXML punchout as their primary or default protocol, which makes it the one your development team should plan around first.

Open Catalog Interface, or OCI, is the other protocol you will meet, mostly from buyers running SAP-native procurement or older SAP SRM installations. OCI is simpler and older than cXML punchout. It works through a form-based HTTP POST rather than a structured XML document exchange, and it typically returns fewer fields per line item, which limits how much contract detail the buyer’s system captures automatically.

If your commerce platform is Adobe Commerce or Magento Open Source, neither supports cXML punchout or OCI natively. You will need a dedicated extension or a middleware layer such as PunchOut2Go to handle the session handshake and translate cart data into the correct document format. BigCommerce B2B Edition and Shopify Plus are in the same position: both need middleware, commonly PunchOut2Go or Alumio, since punchout is not part of either platform’s core commerce engine. 

What Does Your Buyer’s Procurement System Send You, and What Does It Expect Back?

Every buyer’s procurement system sends the same three documents, though the specific fields inside them vary by platform. The PunchOutSetupRequest arrives first and carries authentication credentials, the buyer’s identity, the browser’s user agent, and the return URL. Your endpoint has to validate the shared secret and respond within the timeout window the buyer’s system enforces, often five to ten seconds, (depending on your provider) or the session fails before the buyer sees your storefront.

Once the buyer builds a cart, your system sends back a PunchOutOrderMessage. This document has to carry accurate part numbers, quantities, units of measure, and pricing that matches what the buyer’s contract specifies, because the buyer’s procurement system will often reject or flag any mismatch during approval. Finally, the PurchaseOrderRequest that arrives after internal approval is a binding order your order management system needs to ingest automatically, since manual re-entry at this stage defeats the entire purpose of the integration.

What Do Coupa Punchout, SAP Ariba, and Jaggaer Require Before You Go Live?

Coupa punchout, SAP Ariba, and Jaggaer each maintain their own supplier enablement process, and none of the three will let you go live without completing it. Coupa punchout requires registration through the Coupa Supplier Portal, a DUNS number, and a validated test environment before production credentials are issued. SAP Ariba requires an Ariba Network account with its own AN ID, and enablement typically routes through Ariba’s supplier enablement team rather than the buyer directly. Jaggaer follows a similar pattern through its own supplier portal, generally with a shorter enablement window than SAP Ariba.

None of these timelines start until your development team has a working endpoint to test against. Budget the enablement window on top of your build time, not inside it.

A B2B Punchout Catalog Needs Contract Pricing, and That Pricing Lives in Your ERP

A b2b punchout catalog fails its most basic test the moment the price shown in the session does not match the buyer’s contract. Buyers negotiate customer-specific pricing, often at the item level, and that pricing has to be read live from your ERP at the moment the session opens, not duplicated or approximated in your storefront’s database.

This is the part of a b2b punchout catalog that actually costs money, because it is integration work, not commerce configuration. If your ERP is Epicor Prophet 21, contract pricing sits in customer-specific pricing tables that your punchout session needs to query in real time, and we walk through exactly how that connection works in our Epicor Prophet 21 and WooCommerce Integration guide. NetSuite OneWorld presents a related challenge for distributors with multiple subsidiaries, since pricing can vary by legal entity as well as by customer. Either way, the storefront cannot be the source of truth for price. 

Hosted Catalogs and Level 2 Punchout: When You Do Not Need Punchout at All

If you have one punchout buyer and less than roughly $250,000 in annual spend running through that account, do not build a full punchout catalog. The engineering cost and ongoing maintenance rarely justify the return at that volume. Send a hosted catalog file instead, using BMEcat, cXML catalog format, or a structured CSV that the buyer’s procurement system ingests on a schedule, or take orders through EDI 850 if the buyer already supports it.

Level 2 punchout is worth knowing about as a middle option. Instead of routing the buyer to your storefront’s home page, Level 2 punchout uses deep linking to send them directly to a specific product page, which shortens the session and reduces the amount of catalog logic your endpoint needs to handle. It still requires the same PunchOutSetupRequest and PunchOutOrderMessage exchange, so it is not free, but it is a smaller build than full punchout support. We go into more detail on when a lighter-weight buyer experience makes sense in our B2B ecommerce portal post, which covers the broader set of options between a static catalog and a full punchout session.

What Breaks After Launch, and How Do You Monitor It?

A punchout catalog that passed testing does not stay working on its own. Five failures account for most of the support tickets we see after go live:

1. Shared secret rotation breaks the handshake. Buyers rotate credentials periodically, and if your endpoint is not updated at the same time, every PunchOutSetupRequest fails silently.
2. ERP pricing queries time out. If your live pricing lookup is slow, the session can expire before the PunchOutSetupResponse returns, and the buyer sees an error instead of your storefront.
3. UNSPSC codes fall out of sync. New products added without correct classification get rejected or misrouted inside the buyer’s approval workflow.
4. PunchOutOrderMessage formatting drifts. A change to your storefront’s checkout logic can quietly alter tax fields or unit-of-measure formatting, causing the buyer’s system to reject the cart.
5. Multiple buyers hitting one endpoint create session conflicts. Without proper session isolation, a spike in traffic from one buyer can degrade the experience for another.

Machine-initiated buying is starting to touch this same territory. Emerging frameworks like the Agentic Commerce Protocol let AI agents shop and check out on a buyer’s behalf, using a session structure that echoes the setup, browse, and return pattern punchout has used for years. We are not calling this a replacement for punchout, only an observation that the handshake pattern is proving durable enough for a new generation of buyers, human or otherwise.

Where to Start If a Buyer Has Just Asked You for PunchOut

If a named account has just told you their procurement system requires a punchout catalog, start by identifying two things before writing any code: which platform they use (Coupa, SAP Ariba, Jaggaer, or Oracle Procurement Cloud), and where your contract pricing for that buyer currently lives. Those two answers determine almost everything else, from which protocol you build for to how much of the project is commerce work versus ERP integration work.

We run this as a short discovery with new clients: a call with the buyer’s enablement contact to confirm protocol and credentials, and a separate conversation with whoever owns your ERP data to confirm pricing can be queried live rather than exported by hand.