Punchout

In practice

In large B2B and industrial buying, the purchasing team rarely wants to leave the system it already runs on: tools like SAP Ariba, Coupa, Jaggaer, or Oracle Procurement. A punchout connects your storefront to that system, so a buyer clicks out to your live catalog, adds items, and the cart is handed back to their procurement tool, where their normal approval and purchase-order process takes over.

The handoff runs on one of two established protocols: cXML PunchOut (originally from Ariba) or OCI (Open Catalog Interface, from SAP). A punchout setup request opens an authenticated session, the buyer shops your real-time catalog and pricing, and a punchout order message returns the cart. Because pricing and availability come from your live site, the buyer sees their contracted, customer-specific prices rather than a stale hosted price list.

For a distributor or manufacturer, punchout is often the price of admission to sell to a large account at all. Enterprise procurement teams mandate it because it keeps spend inside approved catalogs and captures clean purchase-order data. Missing it can quietly disqualify you from a buyer's approved-supplier list, no matter how good your catalog is.

The round trip is worth understanding, because every failure mode sits somewhere in it. The buyer clicks your name inside their procurement system, which sends a PunchOut Setup Request carrying their credentials and a return address. Your site authenticates that request and opens a session, usually already showing their contract pricing. They shop, and when they check out you don't take the order. You send a PunchOut Order Message back into their system, which becomes a requisition, goes through their approval chain, and returns to you later as a purchase order.

That last part surprises suppliers the first time. The cart handoff is not a sale. It becomes a requisition that still has to clear approval, and the purchase order that eventually arrives may differ from what left your site. Building your fulfilment process around the cart rather than the PO is a common and expensive early mistake.

There are two depths of integration, and buyers will ask which you support. Level 1 drops the user on your storefront home page and lets them search from there. Level 2 lets their system deep-link straight to a category or a specific item, so a buyer searching inside their procurement tool lands on the right page rather than your front door. Level 2 takes more work on your side because it means exposing your catalogue structure, and it is what larger buyers increasingly expect.

Contract pricing is usually the real reason the integration exists. A punchout session is authenticated, so it knows who is shopping, which means the prices shown can be that customer's negotiated prices rather than list. For a distributor with different pricing for a dozen accounts, that is the difference between a catalogue people use and one they work around by phoning your inside sales desk.

Product data is where these projects actually stall. Procurement systems expect classification, commonly UNSPSC codes, along with clean units of measure, consistent part numbering and predictable descriptions. If your product data is inconsistent, punchout exposes that immediately, because the buyer's system will reject or mis-file what it cannot parse. Most of the effort in a punchout project is data cleanup rather than integration work.

The other predictable friction is session behaviour. Procurement systems enforce timeouts, and a session that expires mid-basket usually loses the basket. cXML documents that fail validation get rejected silently from the buyer's perspective, so your team hears about it as a complaint rather than an error. Neither is hard to handle, but both need to be handled deliberately rather than discovered in production.

There are three ways to serve a procurement system and they are not interchangeable. Punchout keeps buyers in their system while shopping in yours, which suits catalogues that are large, configurable or priced per customer. A hosted catalogue means you send a price file the buyer loads into their system, which is simpler and fine for a stable, short list. EDI handles the transaction documents rather than the browsing, and often runs alongside either of the others.

Cost and effort scale with how tidy your data already is, not with the protocol. A supplier with a clean catalogue and an ecommerce platform that supports punchout natively is looking at a configuration exercise. A supplier whose product data lives across a spreadsheet, an ERP and a PDF is looking at a data project with an integration attached, and pretending otherwise is how these run over.

The honest test for whether you need it is commercial rather than technical. If a buyer has told you they require punchout to keep you on contract, the decision is made. If you are hoping it will attract new enterprise accounts on its own, it will not, because buyers do not go looking for suppliers by procurement integration. It removes a reason to drop you rather than creating a reason to choose you.

It is not the only way to serve procurement systems. A hosted catalog, where you send a price file the buyer loads into their system, is simpler but goes stale and hides your live inventory; punchout keeps the buyer on your real catalog. Most serious B2B ecommerce platforms support punchout natively or through a connector.

The practical question is not whether punchout is worth it in the abstract, but whether your largest accounts require it. If two or three of your biggest buyers run Ariba or Coupa, punchout is likely already the difference between being in their catalog and being a manual purchase order they place grudgingly.