Connect customer procurement via Punchout
Above a certain size, your customers' buyers do not visit supplier websites. They work in SAP Ariba, Coupa, JAGGAER, Onventis or an SAP ERP, because their organisation wants every euro of spend visible in one place and routed to suppliers with negotiated contracts. At the other end of the market, a heating installer orders from the trade software he writes his quotes in. In both cases a supplier who cannot be reached from inside that system becomes the exception somebody processes by hand, and exceptions get designed out. Punchout is how you stay on the standard path.
Why this is harder than it sounds
Punchout is often described as one integration. It is one integration per customer, and each arrives with its own dialect: which standard and version, which fields are mandatory on the returned cart, which unit-of-measure codes apply, whether a classification such as eCl@ss or UNSPSC is required, and what their system does with a description longer than it likes. The customer specifies; you comply.
The standard follows from the customer's system. OCI comes from the SAP world and is the most common case in the German Mittelstand, with OCI 4.0 and 5.0 both in use. cXML comes from Ariba and Coupa. IDS 2.5 is the trade-software standard of the German SHK and electrical trades. The Revenue Cloud serves all three.
The second reliable underestimate is data strictness. A web page renders imperfect data badly; a procurement system rejects it. A missing unit of measure, a unit code their system does not know, a missing classification: each is a rejected line. Third, the schedule is not yours. Testing needs the customer's test environment, which means a slot in their IT queue.
Know where the punchout ends. It carries the buyer in and the cart back out. The purchase order the customer's system creates from that cart reaches you afterwards, on whatever order path you agree with them; it does not come back through the punchout.
What you're building
A connection per customer: their buyer starts in Ariba, Coupa, SAP or their trade software, lands in your storefront already signed in, sees only the assortment and the conditions their contract names, fills a cart and hands it back. Each connection is a punchout channel for the assortment plus a punchout account under Procurement › Punchout for credentials, session, hand-back and field mapping. Every hand-back is kept as a transfer, so you can show what the customer's system received.
What you need
- The customer's written specification: standard, version, credentials, required fields, unit and classification codes, test contact — Punchout explained
- That customer's conditions readable from the ERP, scales included, and checked line by line — Contract prices for a customer
- The customer as an organization, with a contact who serves as the technical contact — Organizations
- A channel for that customer's assortment — Channels
- Completeness rules for the punchout channel: unit code, tax, description length, classification — Completeness and readiness
- Classification where the customer requires it (eCl@ss, ETIM, UNSPSC) — Classification standards
- A test slot in the customer's test environment, with a date — Set up a punchout
- An agreed path for the purchase order that follows the cart — The order lifecycle
Build it
- Send the customer the question list and get the answers in writing, from their systems team — Punchout explained
- Load their contract conditions and verify twenty articles against their last invoices — Check which price a buyer sees
- Create the organization and the technical contact — Organizations
- Create a channel of type PunchOut, close it, and assign the contract assortment — Channels
- Run the completeness check on the channel; fix units and classification first — Completeness and readiness
- Create the punchout account with protocol, channel, organization and credentials — Set up a punchout
- Check the returned fields against the customer's list; the standard mapping covers most systems, add account rows only where theirs deviates — Set up a punchout
- Probe the entry URL, send a test entry call, then enable the account — Set up a punchout
- Test against their test environment and compare each transfer with their requisition; expect two or three correction rounds — Test an integration end to end
- Take the first live purchase order through to the ERP and reconcile it with the transfer it came from — Reconcile with your ERP
- Write the template: question list, mapping deviations, test script, in a place the next colleague finds — Connect a system
Decisions you'll need to make
| Decision | The trade-off | Where most customers land |
|---|---|---|
| Prices: read live from the ERP, or maintained as price lists in the platform? | Live reading is exact and depends on the ERP answering during the session. Platform price lists are fast and need a disciplined sync, or they drift from the contract. | ERP-owned, synced into price lists on a short cadence, with the contract checked before go-live. The wrong answer is the spreadsheet. |
| One assortment for all punchout customers, or one channel per customer? | One assortment is less to maintain and shows articles outside each contract, which their system rejects. One channel per customer is exact and multiplies configuration. | One channel per customer. Frame contracts differ, and a rejected line lands on your desk. |
| Unknown buyers: fall back, refuse, or create? | Falling back to the technical contact always lets the buyer in, under one name. Refusing is strict and generates support calls. Creating gives every buyer their own contact and their own history. | Fall back for a first connection; switch to creating contacts once you want to see who buys. |
| Cost centres inside the punchout? | The customer's own system usually does the cost-centre booking. A cost centre restricted to the punchout account is useful only when you also run budgets for this customer. | Leave cost centres to the customer's system unless you have agreed otherwise — Cost centres. |
| Who owns the connection after go-live? | A named owner with a weekly look at sessions and refused entries costs an hour. No owner means the customer picks another supplier from the same list and nobody notices. | A named person per connection, with a drop in monthly carts treated as an incident. |
Common mistakes
- Starting with the protocol. OCI is the mechanical part. Start with the prices.
- Promising a go-live date before the customer's IT has given you a test slot. Their queue sets your schedule.
- Leaving the channel open. A fresh punchout channel inherits the tenant's visibility and can show the whole catalog.
- Ignoring units and classification. These two turn a working connection into rejected lines, and both are catalog work.
- No one watching after go-live. A broken punchout is silent: the buyer selects a different supplier from the same list. Refused entries and the transfer count per account tell you first.
How you know it is working
- Live accounts, named, with the protocol and version for each, all enabled and with a reachable entry URL.
- Transfers per month, per account. Per account matters: one broken customer disappears inside a total.
- Refused entries per account. Zero once live; a recurring reason is a configuration problem on one side.
- Rejected or corrected lines reported by the customer, per account. Any recurring cause belongs in the catalog backlog.
- Elapsed time from a customer's request to a live account. It should fall sharply between the first and the third connection.
Related goals
- Reach more customers: punchout reaches the accounts no amount of search visibility will.
- Publish a digital product catalog: the strict data work punchout depends on.
- Launch a B2B shop: the storefront the punchout session runs inside.
Related product areas
- Commerce Studio — Channels · Channel types · Organizations · Segments · Price lists · Measurements · Orders · Procurement › Punchout (accounts, sessions, refused entries, transfers, field mappings)
- Experience Studio — Sites