PunchOut catalog: your customer buys from your store inside their procurement system

What a PunchOut catalog is

A PunchOut catalog is your own store, opened from inside your customer's procurement system. The buyer clicks your tile in Coupa, SAP Ariba or SAP, lands in your store already logged in, fills a cart and takes that cart back as a purchase requisition. Two things cross the line: a login from the procurement system to the store, and a cart from the store to the procurement system.

The alternative is a hosted catalog: a file with your items and prices that the customer loads into their own system. The file is as current as its last upload. A PunchOut session reads the store, so the price, the assortment and the availability are the ones the store has at that moment.

The other four flows on the integrations overview move data in the background. PunchOut is a session: a buyer is waiting at a browser and every step has to be right at the moment of the click. Two protocols carry it. cXML is the one Coupa and SAP Ariba use, and OCI is SAP's own. Each has a page: cXML PunchOut and OCI.

When your customer asks for PunchOut

The request comes from the procurement team of your customer, usually with a form. Coupa's supplier documentation lists what the form asks for: a logo of 150 by 50 pixels for the tile, the PunchOut URL of your store, an identity for each side (usually a DUNS number or a network ID) and a shared secret.

The URL is where the work is. It has to be an endpoint that accepts a cXML PunchOutSetupRequest, checks the shared secret and answers with a one-time address that logs this buyer in. The login page of a store does none of that. Behind the URL the store needs the contract prices of that customer, a checkout that sends the cart back, and a second endpoint when the buyer sends its purchase orders in cXML.

Buying organizations use PunchOut to keep spend inside their procurement system, where contract prices and approval apply. For a supplier it is often a condition in a tender or at a contract renewal. The full list of what the store needs, 38 items in six groups, is on the supplier checklist.

How a PunchOut order runs

A buyer at Bakker Installatie B.V., customer 10432 in your ERP, orders three items through the procurement system.

1. The buyer clicks your tile.
2. The procurement system sends a PunchOutSetupRequest to your endpoint, server to server. It carries the identity of the buying organization, the shared secret, a BuyerCookie and the return address in BrowserFormPost.
3. The endpoint checks the credentials, opens a session for customer 10432 and answers with a PunchOutSetupResponse that holds one start URL.
4. The procurement system sends the buyer's browser to that URL. No login form appears.
5. The buyer sees the assortment and the contract prices of their company and fills the cart: 3 lines, $1,468.75.
6. In place of the checkout, a transfer button posts the cart as a PunchOutOrderMessage through the buyer's browser to the return address.
7. The procurement system turns the cart into a requisition. Cost center, budget and approval are added there.
8. After approval the procurement system sends purchase order 4500001234 as an OrderRequest to your order endpoint.

Between step 6 and step 8 no order exists on your side. The cXML reference calls the transferred cart a quote: the supplier has not received a purchase order and cannot book the order yet. The requisition can be rejected, and a quantity cannot be changed in the procurement system. The buyer returns to the store in a new session with the operation edit, and the store reopens the cart. Whether stock is reserved at the cart transfer or at the purchase order is a rule that is set per customer.

What actually moves

No black box: these are the fields of one cart line, in both protocols.

The first line of the cart in cXML:

<ItemIn quantity="120">
  <ItemID>
    <SupplierPartID>10482</SupplierPartID>
    <SupplierPartAuxiliaryID>cart-7f3a91</SupplierPartAuxiliaryID>
  </ItemID>
  <ItemDetail>
    <UnitPrice><Money currency="USD">9.60</Money></UnitPrice>
    <Description xml:lang="en-US">Duplex receptacle 20 A, white</Description>
    <UnitOfMeasure>EA</UnitOfMeasure>
    <Classification domain="UNSPSC">39121406</Classification>
  </ItemDetail>
</ItemIn>

The whole cart of Bakker Installatie B.V.:

The header carries a Total of 1,152.00 + 298.00 + 18.75 = 1,468.75 USD. In cXML the total excludes tax and shipping; those go in their own Tax and Shipping elements. The same cart over OCI is one form with 3 lines of 7 fields each, 21 fields.

The $9.60 is the contract price of customer 10432 from the ERP, not the list price of $12.50. The session has to start as that customer, and the price in the cart is the price that lands in the requisition. How those prices reach the store is covered on per-customer catalogs and customer-specific pricing.

After the cart: orders, confirmations, ship notices, invoices

The session ends at the cart. What follows are documents, server to server, and each buyer decides which of them it requires.

The purchase order carries the order number of the buyer in orderID, a type of new, update or delete, and the SupplierPartAuxiliaryID of each line, so the order is matched to the cart it came from. Your endpoint answers with a status of 200. That status says the document was received and parsed. It says nothing about whether a line can ship. A backorder, a changed price or a rejected line goes back in a ConfirmationRequest, which has a type per case: accept, reject, detail, backordered and four more.

Counted per order: setup request, setup response, cart, purchase order, confirmation, ship notice and invoice are 7 documents. A customer that places 40 orders a month produces 40 x 7 = 280 documents, and 3 x 40 = 120 of them are generated on your side from ERP data. An order that ships in two parts adds a second ship notice and usually a second invoice: 9.

A buyer that requires ship notices matches the invoice against the purchase order and the shipment. An invoice without the PO number, or one that arrives before the ship notice, waits in a manual queue at the buyer. The order itself goes into your store or ERP through the orders flow.

OCI stops at the cart. The order, the confirmation, the ship notice and the invoice are outside SAP's specification. With an OCI buyer the order arrives as a cXML document, as EDI or as a PDF by email.

What goes wrong quietly

A PunchOut connection rarely raises an error on your side. The buyer sees an empty screen or a rejected cart and calls their own administrator.

The last row follows from the retry rule in the cXML reference. A status in the 400 range is permanent and is not retried. A status in the 500 range, or no valid cXML answer at all, is transient: the reference recommends 10 retries, one per hour. A retried document keeps its payloadID. An order endpoint that stores every payloadID and orderID it has accepted answers a repeat with 200 and creates nothing.

Throughput and limits

The buyer waits on two answers: the setup response and the response to the purchase order. Everything else is queued. A purchase order is answered as soon as it is stored, and goes to the ERP from the queue. An ERP that is unreachable delays the order; it does not lose it, and the buyer's system does not start retrying.

Sources: the cXML reference guide and Coupa's supplier documentation linked above, and SAP's OCI 5.0 specification, checked on October 3, 2026.

Field lengths decide the mapping. A store description of 56 characters does not fit the 40 of NEW_ITEM-DESCRIPTION, and cutting it at 40 gives two lines that read the same. Per item the integration sends a short description that was written for that length, or the first 40 characters when none exists, and logs which lines were cut.

cXML or OCI

The procurement system of your customer decides the protocol.

For the store the difference is small. The login, the session per customer and the transfer button are the same; the packaging of the cart differs. A supplier with one Coupa customer and one SAP customer runs both on the same store. The comparison per part is in cXML vs OCI, and the index file behind Level 2 in the CIF catalog.

You stay in control

A new buyer starts with a test session against their test instance. The cart goes to the test address of the procurement system, no real requisition is created, and you see per field what was sent. The connection moves to production after approval by you and by the administrator at the buyer.

• Mapping per buyer. Buyer A wants UNSPSC in Classification, buyer B its own commodity codes and a lead time per line.
• Exclusions. Items a customer may not order through PunchOut do not appear in its session.
• Overrides. A fixed unit code or a fixed 40-character description for an item that would be cut.
• A log per session. Which organization started it, which lines went back, what was cut, which purchase order followed. A cart without a purchase order stays visible.

The controls are the same as in the other flows: dry run and approval.

Which procurement systems

• Coupa. cXML. The buyer creates the PunchOut with your URL, both identities and the shared secret, and Coupa sends the setup request straight to your endpoint. See PunchOut for Coupa.
• SAP Ariba. cXML through SAP Business Network. The network verifies the buyer, looks up your URL and puts your own shared secret in Sender before it forwards the request. See PunchOut for Ariba.
• SAP SRM. OCI, with the 34 NEW_ITEM fields of SAP's specification. See PunchOut for SAP.
• Jaggaer, Ivalua, Oracle, Workday, GEP and Basware. Ask the administrator at the buyer for a sample setup request: it shows the protocol and the fields that system sends. cXML leaves user data to Extrinsic elements whose names each buying organization configures, so no two setups read the same. The element by element walk-through is in the PunchOutSetupRequest.

Which store platforms

Every platform needs the same three things: a session that starts without a login form, the prices of that customer, and a transfer in place of the checkout. The execution differs. Two examples: a Shopify storefront sends X-Frame-Options: DENY and loads in no frame at all, and Magento sets x-frame-options in env.php with the default SAMEORIGIN.

• PunchOut on Shopify, Magento, WooCommerce and BigCommerce: what changes per platform.
• A custom store: the integration gets its own login address and reads the cart through the API or the database of the store.

Keeping it working

A PunchOut connection works on the day it goes live and fails later. The buyer rotates the shared secret and every setup request gets a 401. A theme update removes the transfer button. The procurement system starts sending the user's email under another Extrinsic name. A new item has a unit the buyer's system does not know.

None of these raises an alarm in the store. We monitor each session: a failed login is in the log at the moment it happens, a cart that was cut or rejected is listed with the field that caused it, and the fix is ours to make when a buyer's system changes.

Tell us which procurement system your customer uses and which platform your store runs on, and you get a concrete answer on what that combination needs.