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. A supplier who cannot be reached from inside that system becomes the exception somebody has to process by hand, and exceptions get designed out. Punchout is how you stay in the standard path.

Why this is harder than it sounds

Punchout is often described as a single integration. It is one integration per customer, and each corporate arrives with its own dialect: which standard and which version, which fields are mandatory on the returned basket, which unit-of-measure code list applies, whether they require a product classification such as eCl@ss or UNSPSC, how tax and currency are expected, and what their system does with a description longer than it likes. None of that is negotiable by you. The customer specifies; you comply.

Which is the first thing to internalise: the standard is decided by your customer. OCI comes from the SAP world and is the most common case in the German Mittelstand, with both OCI 4 and OCI 5 in active use. cXML comes from the Ariba world and covers more elaborate procurement flows. openTRANS covers the documents going back the other way: order, order response, dispatch advice, invoice. Being able to serve all of them means never having to reopen this discussion.

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 the customer's system does not recognise, a missing classification, a quantity that is not a whole number of the order unit: each is a rejected line rather than an ugly layout. The catalogue work behind a punchout is stricter than the catalogue work behind a shop, and it is the same catalogue.

Third, the schedule risk is not yours. Testing requires access to the customer's procurement test environment, and that means a slot in a corporate IT queue. Teams that promise a go-live date before that slot exists miss it, for reasons entirely outside their control.

Two smaller adjustments in thinking. Assortment is per contract. If you present your whole range to a punchout buyer, they will add articles their own system will refuse, and the complaint will land with you. And design barely matters here. The buyer sees your shop inside their procurement session, briefly, with one job. Search quality, speed and correct prices are everything; branding and marketing content are close to irrelevant.

The levers

Understand what the customer is asking for

What good looks like: before any configuration, you have written answers to a short list of questions: standard and version, authentication method, the URL they will call, the fields they require back, the unit and classification standards, whether they also want the order documents returned, and who on their side will test.

What it depends on: getting to their technical contact, not only their buyer. The buyer knows they want punchout; the systems team knows what that means.

1. Punchout explained
2. Integration patterns
3. Deciding your system of record

Get prices and assortment right for that customer

What good looks like: the buyer punches in and sees exactly the articles their frame contract covers, at exactly the conditions it names, including scales. If you cannot yet guarantee that, you have not started the punchout; you have started something else.

What it depends on: conditions being read from the system that maintains them, and assortment being controllable per customer rather than per storefront.

1. How pricing works
2. Price lists
3. Contract prices for a customer
4. Check which price a buyer sees
5. Organizations and Segments

Get the catalog data to procurement-system standard

What good looks like: every article that can appear in a punchout basket has a unit of measure with a valid code, a currency, a tax indication, a description within the length the customer accepts, and the classification they require. Nothing in that set is optional.

What it depends on: treating the procurement systems as their own channel with their own completeness rules, rather than assuming the web channel's rules are enough.

1. Channels, locales and completeness
2. Measurements and units
3. Attributes and attribute groups
4. Completeness and readiness
5. Data quality in practice

Set up, map and test the connection

What good looks like: the buyer clicks through from their system and is already authenticated. They build a basket, return it, and every line arrives with the fields their system expects. The subsequent order reaches you as a normal order and is processed like one.

What it depends on: test access on the customer's side and disciplined field mapping on yours. Expect two or three rounds of correction on the returned basket; that is normal.

1. Set up a punchout
2. Field mapping
3. Connect a system
4. The order lifecycle
5. Monitor your syncs and Common sync errors

A sensible order

Phase 1: one customer, all the way through. Take the customer who is asking loudest, get their specification in writing, fix their prices and assortment first, then build and test the connection into their test environment before their production one. The deliverable is more than a live connection: it is a template, a documented question list, a field mapping, and a test script you can reuse. Phase 1 depends on price determination being solved, which is why it is worth starting that before the customer even asks.

Phase 2: the second and third connection, turned into a routine. Each new customer follows the template: specification, assortment scope, price validation, mapping, test, go-live. By the third one, most of the work is validation rather than construction. This phase depends on Phase 1 having produced a written template rather than knowledge in one person's head, which is a decision you make during Phase 1.

Phase 3: the documents going back, and scale. Order response, dispatch advice and invoice returned electronically, so the whole cycle is machine-to-machine rather than only the basket. Add monitoring per connection and a defined re-test after any change on either side. This phase is where punchout stops being a sales concession and becomes an operating channel.

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.
• One assortment for every punchout customer. Frame contracts differ. Showing articles outside a customer's contract produces rejected lines and irritated buyers.
• Ignoring units and classification. These are the two fields that most often turn a working connection into rejected order lines, and both are catalogue work rather than integration work.
• No monitoring after go-live. A broken punchout is silent: the buyer does not report it, they select a different supplier from the same list. Treat an unexplained drop in punchout orders as an incident.
• Investing in the visual design of a punchout session. The buyer is there to find a part number and leave.

How you know it is working

• Live connections, named, with the standard and version for each. A punchout programme with no such list is not being managed.
• Orders per month and order lines per month, per connection. Per connection matters: a single broken customer disappears entirely inside a total.
• Rejected or corrected basket lines, per connection. The target is zero, and any recurring cause belongs in the catalogue backlog.
• Share of revenue arriving through punchout, tracked over time. This is the number that justifies further connections.
• Elapsed time from a customer's request to a live connection, measured for each one. It should fall sharply between the first and the third; if it does not, Phase 1 did not produce a reusable template.
• Catalog lines failing procurement-channel validation. Run the check before a customer's system does it for you; see Completeness and readiness.

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.

What you're building

A connection per corporate customer: their buyer starts in Ariba, Coupa or their SAP, lands in your storefront already logged in, sees only the assortment and the conditions their frame contract names, fills a basket and hands it back as a requisition in their own system. The resulting purchase order arrives as a normal order and goes to your ERP. Each connection is assembled from a punchout channel, credentials and a workflow; the documents going back (order response, dispatch advice, invoice) run through Integration Studio as well.

flowchart LR
  PROC["Customer's procurement system: Ariba, Coupa, SAP"]
  ERP["Your ERP"]
  subgraph CS["Commerce Studio"]
    CH["Channel: punchout, per customer"]
    ORG["Organizations and segments"]
    PR["Price lists: contract conditions"]
    P["Products: units, classification"]
    O["Orders"]
  end
  subgraph XS["Experience Studio"]
    SF["Storefront in the punchout session"]
  end
  subgraph IS["Integration Studio"]
    CRED["Credentials"]
    WF["Workflows: OCI / cXML round trip"]
    DOC["Workflows: order response, dispatch advice, invoice"]
  end
  PROC -- "punchout login" --> CRED
  CRED --> SF
  CH --> SF
  ORG --> SF
  PR --> SF
  P --> SF
  SF -- "basket returned" --> WF
  WF -- "requisition" --> PROC
  PROC -- "purchase order" --> WF
  WF --> O
  O --> ERP
  ERP -- "confirmation, dispatch, invoice" --> DOC
  DOC --> PROC
  ERP -- "conditions" --> PR

What you need

• The customer's written specification: standard, version, authentication, 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 the contacts who will punch in — Organizations
• A channel for that customer's assortment cut — Channels
• Completeness rules for the procurement channel: unit code, currency, 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 procurement test environment, with a date — Set up a punchout
• Order path and numbering agreed with whoever runs your ERP — The order lifecycle

Build it

1. Send the customer the question list and get the answers in writing, from their systems team — Punchout explained
2. Load their contract conditions and verify twenty articles against their last invoices — Check which price a buyer sees
3. Create the organization and the punching-in contacts — Organizations
4. Create a channel of type punchout for that customer and assign the contract assortment — Channels
5. Define the channel's completeness rules and run the check; fix units and classification first — Completeness and readiness
6. Store the customer's credentials and endpoint — Credentials
7. Build the punchout round trip: login, session, basket return — Set up a punchout
8. Map the returned basket fields to what their system requires — Field mapping
9. Test against their test environment; expect two or three correction rounds — Test an integration end to end
10. Take the first live purchase order through to the ERP and reconcile it line by line — Reconcile with your ERP
11. Write the template: question list, mapping, test script, in a place the next colleague finds — Connect a system
12. Put per-connection monitoring in place before the second customer — Monitor your syncs
13. Add the return documents: order response, dispatch advice, invoice — Build a workflow

Decisions you'll need to make

Related product areas

• Commerce Studio — Channels · Channel types · Organizations · Segments · Price lists · Measurements · Orders
• Experience Studio — Sites
• Integration Studio — Credentials · Workflows · Field mapping · Runs · Inbound webhooks