What is PunchOut? The complete guide for suppliers

How PunchOut works

PunchOut connects two systems that were not designed to talk to each other: your buyer’s procurement system and your online store. Large organisations buy through eProcurement systems such as SAP Ariba, Coupa or SAP S/4HANA, where every purchase follows approval rules and lands in the right budget. Instead of copying your products into that system, they ask you for a PunchOut catalogue: a link that opens your store from inside their procurement system.

A PunchOut session has four steps:

1. Setup. A requisitioner clicks your catalogue in their procurement system. The system sends your side a setup request with credentials and a return address.
2. Shopping. Your store opens in their browser, already logged in with that customer’s role, with their catalogue and contract prices.
3. Cart return. The requisitioner fills the cart and clicks “return” (or “check out”). Instead of your checkout, the cart travels back to their procurement system as a structured message.
4. Approval and order. The cart goes through the buyer’s internal approval. Once approved, the purchase order is sent to you, and you process it like any other order.

For the buyer, your store becomes part of their purchasing process: they see your live prices and stock, and every order follows their rules. For you, orders arrive with the buyer’s purchase-order number and without data entry on either side.

PunchOut vs a static catalogue

Some buyers also ask suppliers for a static catalogue file (often a CIF or cXML index file) that is uploaded into their system. The two models are complementary:

If your range is small and stable, a file may be enough. If you sell thousands of products, configurable items or customer-specific prices, PunchOut is usually what buyers prefer.

The two protocols: cXML and OCI

Every PunchOut session speaks one of two protocols, and your buyer’s system decides which. cXML (Commerce eXtensible Markup Language) exchanges XML documents over HTTPS and is used by SAP Ariba, Coupa, Jaggaer, Ivalua, Oracle, Workday and most source-to-pay systems. It also carries the purchase order itself, as an OrderRequest. OCI (Open Catalog Interface) is SAP’s protocol, used by SAP S/4HANA, SRM and ECC: your store is opened with a HOOK_URL, and the cart goes back as HTML form fields named NEW_ITEM-*. The purchase order then reaches you through a separate channel.

Our guide cXML vs OCI compares the two message by message, with examples.

Why buyers ask for PunchOut

From the buyer’s side, PunchOut solves three problems at once. First, control: every purchase starts inside their procurement system, so it follows their approval rules, budgets and preferred suppliers. Second, accuracy: prices, product codes and descriptions come from your store, so nobody retypes them and invoices match orders. Third, convenience for the people who actually buy: they shop a real store, with search, filters and configurations, instead of a static list.

For a supplier, the request usually arrives with a deadline: a new contract, a framework agreement or a tender that lists PunchOut among the requirements. Suppliers who can answer quickly keep the customer; those who cannot are often moved to a competitor that can.

Who is involved

A PunchOut project touches several people on both sides. Knowing them early saves weeks:

Level 1 and Level 2 PunchOut

You may read about two levels of PunchOut. Level 1 opens your store at its home page: the buyer searches and browses there. Level 2 lets the buyer search in their own procurement system, where a short index of your products is loaded, and then opens your store directly on the chosen product or category. Level 2 needs a static index file as well as the live store, so ask your buyer which one they expect; most start with Level 1.

Which procurement systems use PunchOut

Practically all of them. SAP Ariba is the most common request we see from suppliers, followed by SAP via OCI and Coupa. Jaggaer, Ivalua, GEP SMART, Oracle, Workday and dozens of mid-market procure-to-pay tools support PunchOut too. See the full list of supported systems.

What your buyer will ask you

Your buyer’s procurement team usually sends supplier documentation or an onboarding email. Read it first: it lists exactly what they expect. Typically you will be asked for, or given:

• Credentials: for cXML, identities (for SAP Ariba, the Ariba Network ID or ANID of both companies) and a shared secret; for OCI, login parameters for your catalogue.
• URLs: the setup URL your side exposes and the return URL (cXML) or HOOK_URL (OCI) on their side.
• Catalogue rules: which products and prices this buyer should see, units of measure, and a classification standard (UNSPSC or ECLASS) at a given level.
• A test plan: a test environment and dates for their user acceptance test (UAT).
• Documents, in tenders and with large buyers: security and hosting information, a data processing agreement, references.

The answers differ per system; our pages for SAP Ariba, SAP OCI and Coupa list them in detail.

What changes in your store

PunchOut asks things of a store that normal web shoppers never do. These are the usual blockers:

• Opening inside another site. Many procurement systems show your store in a frame or a new window controlled by them. Security headers such as X-Frame-Options and cookies without SameSite=None; Secure break the session. See the iframe error guide.
• Logging in the right customer, so the buyer sees its own assortment and contract prices, without a password.
• Returning the cart instead of running your checkout, in the format the buyer’s system expects.
• Product data: units of measure mapped to the buyer’s codes, and a classification code on every product. See PunchOut categories.
• Receiving the order: importing the approved purchase order into your store.

A PunchOut plugin and gateway handle these in a standard way, so the store, theme and checkout you already have keep working for your other customers.

A realistic 30-day plan

The technical setup of a PunchOut connection on a supported platform takes hours, not weeks. What takes time is coordination with the buyer. A typical plan:

Your buyer’s test queue sets the final date: some procurement teams schedule UAT weeks ahead. Ask for the dates early, and if the deadline is close, consider having specialists set it up for you, for example with our Go-Live Assist service.

What PunchOut costs

There are three common ways to meet a PunchOut request, with very different cost profiles:

• A custom integration project built by a developer or agency for your store. You pay for development and testing for each protocol and buyer, and for maintenance whenever your platform or the buyer’s system changes.
• A service that charges per buyer, typically a monthly fee for each connected buyer plus setup fees. Cheap for one buyer, expensive as you add more.
• A plugin with a managed gateway such as PunchOut Rocket: a fixed annual price per site. PunchOut Rocket costs €1,950 per year for WooCommerce and €2,950 for Magento, PrestaShop, nopCommerce or the REST API, with up to 10 buyers included.

See pricing for the full price list and a comparison calculator.

Checklist before the buyer’s test

• Credentials and URLs for the test environment are configured and a test session works end to end.
• The buyer sees only the products and prices agreed in the contract.
• Every product in the buyer’s assortment has the classification code and unit of measure they require.
• A returned cart contains your product codes, prices, quantities and currency as the buyer expects.
• You know how the purchase order will reach you (cXML OrderRequest or another channel agreed with the buyer) and who processes it.
• You have a contact in the buyer’s team for the test day, and they have yours.

Common pitfalls

• Starting with the store before reading the buyer’s supplier documentation: it often contains field rules that change your setup.
• Testing only in the buyer’s production system: always ask for the test environment first.
• Forgetting units of measure and classification: carts are rejected when codes don’t match the buyer’s.
• Underestimating the buyer’s calendar: UAT slots can be weeks away. Book them as soon as you have credentials.
• Promising order confirmations, ship notices or invoices via cXML without the right add-on: confirmations and ship notices need the OC & ASN add-on, invoices are quoted on request.