In procurement, a punchout catalog is a live integration between your procurement system and a supplier’s online store. Employees start a purchase request in their procurement platform, “punch out” to shop the vendor’s website, and their cart details return automatically as a structured purchase request. Nobody copies item names, retypes prices, or attaches screenshots to an email.
You may also hear this called connected vendor purchasing, a punchout integration, vendor punchout, or catalog purchasing. The terms all describe the same thing: shopping a familiar vendor site while your procurement software keeps the purchase governed from request through payment.
Here is how a punchout catalog works step by step, the difference between Level 1 and Level 2 punchout, how punchout compares to hosted and internal catalogs, and why what happens after the cart returns matters most.
How does a punchout catalog work?
A punchout catalog connects two systems: your procurement platform and the supplier’s ecommerce site. Once a vendor is connected, the buying flow looks like this:
- Start in your procurement system. An employee opens a purchase request and selects a connected vendor, such as Uline.
- Punch out to the vendor site. The procurement system authenticates the user and redirects them to the supplier’s ecommerce site, often with company account pricing already applied.
- Shop like normal. The employee browses the vendor’s site the same way they would at home: search, product pages, cart.
- Return the cart. The employee checks out on the vendor’s site as usual. At checkout, the cart and all its line item details return to the procurement system as an itemized purchase request.
- Route for approval. The itemized request follows your standard approval workflows and budget checks.
- Generate the PO and complete the purchase. Once approved, a purchase order is created and sent to the vendor, and the purchase continues through invoice matching, payment, and the audit trail.
Here is what that looks like in practice. An office manager restocking shipping supplies opens a request, punches out to Uline, adds boxes and tape to the cart, and checks out. The cart lands back in the request, itemized. Their manager approves it, the PO goes out, and the invoice later matches against line items the vendor supplied itself.
The employee never places an unapproved order, and finance never learns about a purchase after the fact. Control starts before the cart becomes a commitment.
What data returns from a punchout cart
The practical value of a punchout catalog is data quality. When the cart transfers back, structured line item details come with it, typically including:
- Item name and description
- Vendor
- Quantity and unit of measure
- Unit rate
- Line amount
That same data carries forward into the purchase order, which makes downstream invoice matching in accounts payable much cleaner. When the invoice arrives, it matches against a PO built from the vendor’s own catalog data. The result is fewer exceptions, fewer price discrepancies, and less back and forth with requesters.
Punchout catalog levels: Level 1 vs Level 2
Punchout integrations come in two levels, and vendors support them to different degrees.
Level 1 punchout is the standard flow described above. The employee clicks the vendor from inside the procurement system, shops the vendor’s site, and returns the cart. All browsing happens on the supplier’s site.
Level 2 punchout adds item-level search. Product data from the supplier is indexed inside the procurement system, so employees can search for a specific item across connected vendors and then punch out directly to that product page. Level 2 makes cross-vendor comparison easier but requires deeper integration work from the supplier.
Level 1 is the more common setup, and for most mid-market teams it delivers the core value: familiar shopping, automatic cart return, and governed approvals.
Punchout vs hosted catalogs vs internal catalogs
Punchout is one of several catalog approaches in e-procurement. The right mix depends on your vendors and how often their products and prices change.
| Catalog type | How it works | Best for | Watch out for |
|---|---|---|---|
| Punchout catalog | Live integration to the supplier’s ecommerce site; cart returns to your system | Vendors with large, frequently changing ecommerce catalogs | Requires vendor support for punchout protocols |
| Hosted catalog | A static file of items and prices loaded into your procurement system | Small, stable catalogs with fixed contract pricing | Prices and items go stale; someone has to maintain the file |
| Internal catalog | A curated list your team builds and manages | Recurring purchases of a defined item set | Manual upkeep; limited selection |
Hosted catalogs work until the supplier changes prices. Punchout catalogs stay current because the employee is shopping the supplier’s live site, with availability and pricing pulled in real time.
Behind the scenes, most connections are cXML punchouts, built on the cXML protocol, an XML standard for exchanging procurement data. SAP environments often use OCI instead. Your team does not need to touch the protocol; it simply determines whether a given vendor can connect.
Benefits of punchout catalogs by role
Punchout removes a different headache for each team involved in purchasing.
Finance leaders get control before commitment. Vendor purchases flow through the same approvals and budget checks as every other request, so spend is visible before it happens.
Procurement teams get preferred vendor compliance without policing. Off-process buying is a real problem: The Hackett Group has found that about 29% of indirect spend is off-contract, as reported by Procurement Magazine. When the approved path is also the easiest path, employees stop buying around it, and maverick spend drops. Our maverick spend benchmarks show what good looks like as controls mature.
AP teams get cleaner inputs. Structured cart data means POs and invoices match, which cuts exception handling across the procure-to-pay process.
Controllers get an audit trail that starts at the request. Purchasing context is captured at the beginning and stays connected through PO, invoice, and payment, so nobody has to reconstruct it at close. That connected record is what makes audit prep faster for the controller’s office.
Requesters get to shop sites they already know. There is no new catalog interface to learn, and item details fill in on their own.
Punchout works vendor by vendor
Punchout connects one vendor at a time. Each integration depends on the supplier operating an ecommerce site that supports punchout protocols, plus setup, credentials, and testing between the two systems. That is why punchout coverage is strongest among large B2B suppliers with mature ecommerce operations. No platform connects to every vendor, so coverage claims are worth checking against your own vendor list.
That changes how punchout should be evaluated. The vendor count matters less than one question: are the vendors your teams actually buy from connected, and is there a path to add the ones that matter most?
Strong vendor management starts with knowing where your purchasing volume actually goes, which suppliers create the most manual work today, and which connections would remove the most friction. If you’re on Stampli, Stampli Deep Finance can answer those questions from your own AP data: where vendor spend concentrates and which suppliers drive the most manual work.
Unconnected vendors still have value. In a healthy punchout program, they are demand signals that shape which connections get built next.
Where punchout fits in procure-to-pay
A punchout catalog is a connection method, not a complete procurement process. What determines its value is everything that happens after the cart comes back.
Some tools stop at intake: they capture the request but leave the actual buying moment outside the system. Others start too late: AP-only platforms first see a purchase when the invoice arrives, after the spend is already committed. Punchout closes that gap by bringing the buying moment itself into the governed workflow, but only if the platform behind it connects the full chain: request, approval, budget check, PO, receipt, invoice match, payment, and audit trail.
That end-to-end connection is the difference between “we have punchout” and “our purchasing data is clean from cart to close.” If the cart data dies in a requisition that gets rekeyed into an ERP later, most of the benefit evaporates. Look for punchout that is native to a procure-to-pay platform and syncs with your ERP, whether that is NetSuite, Sage Intacct, or another system your accounting stack is built on.
Bring vendor shopping into your P2P workflow
Punchouts are a capability of Stampli Procurement, part of one connected Procure-to-Pay platform integrated with your ERP. Employees start a purchase request in Stampli, select a connected vendor such as Uline, shop that vendor’s site, and check out to return the itemized cart. From there, the purchase follows the same approvals, budgets, POs, invoice matching, payments, and audit trails as any other Stampli request.
We built punchouts in Stampli Procurement for finance-led teams that need control over spend before it is committed, without a heavy, separate procurement suite. Stampli Intelligence learns how your business works and executes the repetitive work. More than 2,000 customers trust Stampli to control complex finance workflows, and the platform has processed $390B+ in cumulative spend. Punchouts extend that control upstream to the moment an employee starts shopping.
Stampli evaluates additional vendor connections based on vendor capability, customer demand, and purchasing volume, so the vendor ecosystem grows around the suppliers customers actually use.
Purchasing should start inside the system, not get cleaned up later. Punchouts in Stampli Procurement give employees the vendor shopping experience they already know while finance keeps every purchase approved, documented, and audit-ready from request through payment.
