PunchOut is a mechanism that lets an employee leave their procurement system, shop on a supplier’s own website with contract pricing already applied, and have the finished cart delivered back into a requisition without retyping anything.
From the employee’s side it looks like a link. They click a supplier tile in their purchasing system, a supplier storefront opens, they add items, they hit a button that says something like “return cart”, and they land back where they started with the items populated. From the system’s side, a specific sequence of messages has been exchanged, and understanding that sequence is what makes PunchOut problems diagnosable.
Why PunchOut exists
The alternative to PunchOut is a hosted catalog: the supplier sends a file of their products and prices, and the buyer loads it into their procurement system. That works, and for many categories it is the right answer. But it has a structural weakness. The loaded file is a snapshot. Prices move, items get discontinued, new lines appear, and the buyer’s copy drifts out of date until someone refreshes it.
PunchOut removes the copy. The supplier keeps their catalogue where they already keep it, on their own site, where they already maintain it for their own commerce. The buyer never holds a stale version because the buyer never holds a version at all.
This is why PunchOut dominates in categories with large, volatile, or configurable assortments: office supplies, IT hardware, laboratory consumables, MRO, uniforms. A distributor with 200,000 SKUs and weekly price movement is not a good candidate for a flat file.
The round trip, step by step
The sequence has three messages. All three are cXML documents exchanged over HTTPS.
Step one: PunchOutSetupRequest
The employee clicks the supplier in their procurement system. The procurement system POSTs a PunchOutSetupRequest to a URL the supplier has provided.
This document carries the buyer’s identity credentials, a shared secret, an operation type of create, a BuyerCookie (an opaque token the buyer uses to match the eventual return to this specific session), and a BrowserFormPost URL, which is the address the supplier should send the finished cart back to.
Critically, this is a server-to-server call. The employee’s browser is not involved yet.
Step two: PunchOutSetupResponse
The supplier validates the credentials, creates a shopping session on their side, and responds with a PunchOutSetupResponse containing a single important field: a StartPage URL.
That URL is single-use and session-bound. It encodes who the buyer is, which contract applies, and which shopping session this is. The procurement system then redirects the employee’s browser to it.
Step three: PunchOutOrderMessage
The employee now shops on the supplier’s site. Because the session carries their identity, they see contract pricing, contracted assortment, and their own delivery locations rather than list prices and a generic storefront.
When they finish, the supplier’s site does not place an order. It posts a PunchOutOrderMessage back to the BrowserFormPost URL from step one, carrying the cart contents: part numbers, descriptions, quantities, unit prices, units of measure, and classification codes. The BuyerCookie comes back with it, so the procurement system knows which session this cart belongs to.
The procurement system turns that message into a requisition. Nothing has been ordered yet. The requisition still goes through the buyer’s own approval workflow, and only after approval does a purchase order get issued to the supplier by the normal channel.
That last point is the one most commonly misunderstood. PunchOut is a catalogue mechanism, not an ordering mechanism. The cart is a shopping list, not a commitment.
Level 1 and Level 2 PunchOut
Two variants are worth knowing.
Level 1 is the standard flow described above. The employee enters the supplier site at its home page and browses from there.
Level 2, sometimes called PunchOut Index or search-driven PunchOut, adds a searchable index of the supplier’s items inside the procurement system. The employee searches within their own system, sees supplier items in the results, and clicking one punches out directly to that item’s page rather than to the storefront home page.
Level 2 recovers much of what plain PunchOut gives up. Cross-supplier search works again, because the index is local, while pricing and availability stay live, because the transaction still routes through the supplier’s site. It costs more to set up, since the supplier now has to supply and maintain an index file as well as a storefront.
OCI, the other standard
cXML PunchOut is the dominant standard, originating with Ariba and now used across most procurement platforms. SAP systems commonly use a different mechanism called OCI (Open Catalog Interface).
OCI achieves the same outcome with a simpler mechanic: rather than exchanging XML documents, it passes parameters in an HTTP form post and returns the cart as a set of form fields. It is easier to implement and less expressive. Suppliers selling into a mixed European buyer base frequently need to support both.
A supplier who has built a cXML PunchOut has not automatically built an OCI one, and buyers evaluating supplier readiness should ask which specifically.
Where PunchOut goes wrong
The failure modes are consistent across implementations.
Credential and session errors. The most common support ticket. Shared secrets get rotated, identity domains are configured inconsistently between the two systems, and the setup request fails before the employee sees anything but an error page.
Unit of measure mismatches. The supplier returns a cart line priced per case while the buyer’s system interprets it per each. The requisition looks plausible and the delivery does not.
Missing classification. The returned cart lines carry no UNSPSC code, or carry the supplier’s internal category, so the resulting spend lands in an unclassified bucket and disappears from category reporting.
No return path. The employee abandons the cart or closes the tab, and the session ends without a PunchOutOrderMessage. The requisition never materialises and the employee assumes the system is broken.
Every supplier is a project. This is the structural one. Each PunchOut connection requires configuration on both sides, credentials exchanged, a test cycle, and ongoing maintenance. For a buyer with twenty strategic suppliers that is manageable. For a buyer whose operational spend runs across two hundred regional suppliers, it does not scale, and the long tail simply never gets connected.
That last problem is the one we work on. Rather than building and maintaining a separate PunchOut connection per supplier pair, SupplierForge sits between them so a supplier configures once and reaches many buyers, and a buyer connects once and reaches many suppliers. We describe that pattern in more detail in what is a PunchOut gateway.
If you want the layer underneath this, what is cXML covers the protocol carrying all three messages. If you are deciding whether PunchOut is the right model for a given category at all, hosted catalog vs PunchOut sets out the trade-off directly.