Punchout Catalog: What It Is and How PunchOut Ordering Works
Jul 13, 2026
Jul 13, 2026
Convert a purchase order to Excel, CSV, or JSON
Submit your purchase orders
Drop documents here, or click to file
Up to 50 files per batch
Uploading...
A punchout catalog is a supplier's own web store, connected to a buyer's procurement system so the buyer can "punch out" to it, shop with their contracted pricing, and send the finished cart back as a requisition. Nothing is typed twice. The buyer stays inside their approval workflow, and the supplier keeps control of their catalog, pricing, and product data. The connection is almost always built on cXML, a purchasing XML standard originally published by Ariba and now used across Coupa, SAP Ariba, Jaggaer, Oracle, and Workday.
Punchout gets talked about as if it were exotic. It is not. If you have ever ordered office supplies from inside your company's purchasing system and found yourself on what looked like the vendor's real website, with your negotiated prices, and then landed back in a requisition screen with the cart already filled in, you have used a punchout catalog.
There are four moves in a punchout session, and they happen in a few seconds.
The requisition then runs the normal approval route. Once approved, it becomes a purchase order, which is transmitted to the supplier, usually as a cXML OrderRequest or an EDI 850.
The important thing to understand is that a punchout session does not place an order. It only builds a cart and hands it back. The order is placed later, by the buyer's system, after approval. Suppliers who assume the punchout cart is a sale get a nasty surprise.
Buyers choose between two ways of getting supplier products into their procurement system, and the choice usually comes down to how often the catalog changes.
| Punchout catalog | Hosted catalog | |
|---|---|---|
| Where the products live | On the supplier's website | Uploaded into the buyer's system |
| Who maintains it | The supplier, continuously | The buyer, from supplier files |
| Price and stock accuracy | Live, at the moment of shopping | As accurate as the last upload |
| Catalog size it suits | Large, deep, configurable products | Small, stable lists |
| Product configurators | Supported, on the supplier's site | Not supported |
| Setup effort | An integration project on both sides | A spreadsheet upload |
| Search across suppliers | No, you shop one site at a time | Yes, one search covers all catalogs |
A hosted catalog wins on cross-supplier search: a buyer can search "nitrile gloves" once and compare three vendors. Punchout wins on everything to do with freshness and depth. Most mature procurement teams run both, using hosted catalogs for a short list of stable, commodity items and punchout for suppliers like Grainger, Fastenal, Dell, Staples, or CDW whose catalogs are enormous and change constantly.
Neither side gets punchout for free, and this is where the honest arithmetic matters.
On the supplier side, you need a punchout-capable storefront: something that can receive a PunchOutSetupRequest, authenticate it, show customer-specific pricing, and post a valid cXML cart back. If your e-commerce platform supports it natively, this is configuration. If it does not, you are either buying a punchout provider's service or building it. Then every single buyer is its own onboarding: credentials, a test cycle in the buyer's sandbox, UNSPSC mapping, and a go-live.
On the buyer side, each supplier connection is a configuration and testing project too. Procurement teams typically budget days per supplier, not hours, and that is why punchout is reserved for suppliers with real annual spend behind them.
The practical threshold most teams land on: punchout is worth it when the supplier is a top-tier vendor with recurring, high-frequency ordering. For the long tail of suppliers you buy from occasionally, the setup cost never pays back. That tail is exactly the population covered in tail spend management, and it is why punchout alone never gets a company to full catalog coverage.
This is the part most punchout articles skip. Even in companies with a mature eProcurement program, punchout and EDI typically cover a minority of the supplier base by count, while covering most of the spend. The rest of your vendors, often hundreds of them, still send purchase orders, order acknowledgments, and confirmations as PDFs attached to email.
Those documents still have to become data. Somebody reads the PDF and types the PO number, the supplier, the dates, and every line item into the system, or the order simply never gets tracked properly. That is the manual gap sitting underneath every clean punchout diagram, and it is worth measuring before you assume punchout has solved your order flow.
The way out is not to force every small supplier onto cXML, because they will not do it and you cannot make them. It is to automate the capture side instead: read the PDF with AI, extract the header and the full line-item table, and push structured data into the same system the punchout carts land in. Our purchase order PDF to Excel converter does that in one step, and teams wiring it into an eProcurement or ERP workflow use the purchase order API. If the systems on either side of that flow do not speak to each other natively, this is the kind of gap a general integration layer that connects apps, APIs, and databases is built to bridge.
These three terms get used interchangeably and they should not be.
A very common real-world setup is punchout for shopping, then EDI 850 for the actual purchase order transmission, because the buyer's system speaks cXML to the storefront and X12 to the supplier's order desk. There is nothing contradictory about that. They are different layers.
In procurement, a punchout catalog is a supplier catalog that a buyer accesses by leaving their purchasing system and entering the supplier's website through an authenticated session. The buyer shops with contract pricing, and the completed cart is transmitted back into the buyer's system as a requisition for approval. It keeps the supplier's catalog current without the buyer maintaining any product data.
Standard punchout, sometimes called Level 1, sends the buyer to the supplier's homepage or a general landing page. Level 2 punchout lets the buyer search within their own procurement system and land directly on a specific product or search-result page on the supplier's site. Level 2 requires the supplier to also provide an index file of their products, so the buyer's system knows what exists before punching out.
They solve different problems, so having one does not remove the need for the other. EDI transmits transactions you have already decided on: the purchase order, the acknowledgment, the invoice. Punchout is about the step before that, letting a buyer browse a live catalog and build an accurate cart. If your buyers know exactly what part numbers they want, EDI alone may be enough. If they need to browse, configure, or check live stock, punchout adds something EDI cannot.
For a supplier whose storefront already supports cXML punchout, connecting a new buyer typically takes days to a few weeks, most of it spent in the buyer's test environment validating credentials, pricing, and UNSPSC codes. Building punchout capability from scratch on a storefront that lacks it is a much larger project. Neither side should plan around a same-week go-live.
Punchout catalogs are excellent at what they do: they keep supplier catalogs accurate, they preserve contract pricing, and they get clean, coded line items into a requisition without anyone retyping a part number. They are also an integration project per supplier, which means they will always cover your biggest vendors and never your long tail.
So the sensible target is not "punchout everything." It is punchout for the vendors where the spend justifies it, and automated document capture for everyone else, so the PDFs from the other two hundred suppliers become structured data instead of manual typing. Once you can measure both halves, you can see your real order flow. Related reading: the procure-to-pay process, purchase requisition vs purchase order, and purchase order data for procurement leaders.
Z tej samej rodziny narzędzi