PunchOut
PunchOut catalog for Coupa
Coupa opens your store over cXML, takes the cart back as a requisition and sends the purchase order to your endpoint. Coupa sends only create and inspect sessions, keeps one BuyerCookie per user, wants an answer to every purchase order within 60 seconds and retries a 5XX five times. We build the endpoint, the session and the order intake on your existing store and run them.
What moves between Coupa and your store
Coupa's supplier documentation on PunchOut describes a cXML connection: the buyer clicks your logo under Shop Online, shops in your store and returns to Coupa with the cart as a requisition. Coupa sends the setup request straight to your endpoint, without a network in between. Everything on this page was checked against Coupa's current supplier documentation on October 3, 2026.
| Flow | Direction | cXML document |
|---|---|---|
| Session start | Coupa to your endpoint | PunchOutSetupRequest, answered with a PunchOutSetupResponse |
| Cart | your store to Coupa, through the browser | PunchOutOrderMessage |
| Purchase order | Coupa to your order endpoint | OrderRequest, answered within 60 seconds |
| Order confirmation | you to Coupa | ConfirmationRequest |
| Ship notice | you to Coupa | ShipNoticeRequest |
| Invoice | you to Coupa | InvoiceDetailRequest |
The first three are PunchOut. The last four are what make the order land without retyping on both sides. How the documents work in general is on cXML PunchOut; this page covers where Coupa sets its own rules.
What Coupa asks for at setup
The customer creates the PunchOut in their Coupa instance with data you supply. When the customer allows it, you can also enter it yourself under Configure Punchout on the Catalogs page of the Coupa Supplier Portal.
| Setting | Content |
|---|---|
| Name | how the PunchOut appears to users in Coupa |
| Logo | JPG or PNG, 150 x 50 pixels, shown under Shop Online |
| URL | your PunchOut endpoint |
| Buyer domain and identity | goes in From; usually DUNS or NetworkID |
| Supplier domain and identity | goes in To; usually DUNS or NetworkID |
| Shared secret | goes in Sender; if none is set, Coupa sends the word none |
| Protocol | always cxml |
Two sets are normal, one for the customer's test instance and one for production. The endpoint keeps them apart by the credentials and by deploymentMode.
Which system owns what
| Data | System of record | Direction | How it moves |
|---|---|---|---|
| Items, contract prices, availability | your ERP and store | shown to the buyer | read live during the session |
| Requisition, approval, cost accounting | Coupa | stays in Coupa | arrives as Distribution and Accounting segments on the order |
| PO number | Coupa | Coupa to ERP | orderID on the OrderRequest |
| Sales order, confirmed quantities | your ERP | ERP to Coupa | ConfirmationRequest after the order is booked |
| Shipment and tracking | your ERP or WMS | to Coupa | ShipNoticeRequest |
| Invoice | your ERP | to Coupa | InvoiceDetailRequest |
| Credentials | agreed between you | both | stored per connection and environment |
Where Coupa differs from the cXML reference
Coupa follows the cXML standard, with five rules a store built from the reference alone gets wrong:
| Rule at Coupa | cXML reference | Consequence for the store |
|---|---|---|
BuyerCookie is created at a user's first PunchOut and never changes for that user and site |
new in every session | the cookie cannot key a cart or detect a replayed request; the second session of the same user would be refused |
Operations create and inspect only |
create, edit, inspect |
no edit session to build; a quantity change starts a new create session |
payloadID at most 180 characters |
no length | generated IDs stay under 180 |
SupplierPartAuxiliaryID at most 765 characters |
no length | a cart reference fits; a serialized cart may not |
Purchase order types new and update, per Coupa's annotated sample |
new, update, delete |
an update replaces the earlier version of the order; delete does not appear in the sample |
Coupa's sample setup request shows what user data comes along: Extrinsic elements named FirstName, LastName, UniqueName, UserEmail, User and BusinessUnit, and a Contact with role endUser. The integration links the session to the customer account by the buyer identity in From and uses UserEmail for the contact on the order, when present.
Purchase orders from Coupa: 60 seconds and five retries
Coupa's cXML purchase order page sets two numbers. Every OrderRequest needs an answer within 60 seconds. A 2XX answer is success, a 4XX is an error that is not retried, and a 5XX is retried 5 times at 1-hour intervals.
The 60 seconds rule out booking the order in the ERP before answering. The integration stores the document, checks the payloadID and orderID against orders already accepted, queues it and answers 200. The ERP gets the sales order from the queue, at its own pace.
The retry window is shorter than in the cXML reference, which recommends 10 retries. Coupa posts PO 4500001234 at 2:10 AM and your endpoint is down for maintenance until 8:00. The retries run at 3:10, 4:10, 5:10, 6:10 and 7:10, five attempts in 5 hours, all before 8:00. The order then shows as a transmission failure on the cXML errors page of the customer's Coupa instance and reaches you only when someone there resends it. An integration that runs apart from the store's maintenance window keeps the endpoint up.
Purchase orders for suppliers enabled for PO collaboration arrive in DTD 1.2.056 with ControlKeys that say whether a confirmation is expected, per order or per line, with the value allowed or notAllowed.
Confirmations, ship notices and invoices back to Coupa
These go to the customer's instance, with the same credentials as for cXML invoicing and ship notices. Order confirmations post to https://<customer instance>.coupahost.com/cxml/order_confirmation_request in DTD 1.2.036 or later. The header type has to match the lines:
| Line 1 | Line 2 | Header type |
|---|---|---|
| accept | accept | accept |
| reject | reject | reject |
| accept | reject | detail |
| detail | detail | detail |
A header of accept over a rejected line is refused by Coupa. The integration derives the header type from the confirmed quantities the ERP reports per line. Ship notices use DTD 1.2.014 and invoices 1.2.020 according to Coupa's version table; an invoice with credentials Coupa does not recognize comes back as 401 Unauthorized, and cXML invoicing has to be switched on for your supplier record by the customer first.
When it goes wrong
| What happens | Where it shows | Cause and handling |
|---|---|---|
| Second PunchOut of a user is refused | buyer sees an error on clicking your logo | the store treated the unchanged BuyerCookie as a replay; the integration keys sessions on its own ID |
| Old cart reappears | buyer sees items from last week | the store keyed the cart on BuyerCookie; every create session starts empty |
| PO never arrives | transmission failure in the customer's Coupa | the endpoint was down for more than 5 hourly retries; the endpoint runs apart from the store |
| PO arrives twice | two sales orders | a retry after a lost answer; repeat payloadID and orderID are answered 200 and ignored |
| Confirmation refused | error from Coupa | header type does not match the line types |
| TLS handshake fails | transmission failure | the endpoint demands a client certificate the customer has not enabled for mutual TLS |
Each of these is in the integration's log with the document that caused it. The full list of what a store needs is on the supplier checklist, and how Coupa compares with SAP Business Network is on PunchOut for Ariba. The overview is on the PunchOut hub. Tell us which store platform you run.
Frequently asked questions
What do I give my customer to set up the PunchOut in Coupa?
A logo of 150 by 50 pixels in JPG or PNG, the PunchOut URL of your endpoint, your domain and identity, the customer's domain and identity (usually a DUNS number or a NetworkID) and a shared secret. Coupa's documentation says suppliers normally give two sets: one for testing and one for production.
Can the buyer change the quantity of a PunchOut line in Coupa?
Not by reopening the cart in your store. Coupa states that it supports create and inspect only, so your store never receives an edit session from Coupa. A buyer who wants a different quantity of your item starts a new create session, and an approver can look at a returned cart through inspect.
Does Coupa send the purchase order through the same endpoint?
It can be the same host, but it is a separate document with its own URL in the supplier settings. Coupa posts a cXML OrderRequest and expects a response within 60 seconds. The SupplierPartAuxiliaryID your cart sent, up to 765 characters, comes back on each order line.
Which cXML version does Coupa use?
Coupa lists one DTD version per document: 1.2.014 for the setup request and for purchase orders without PO collaboration, 1.2.056 for purchase orders with it, 1.2.036 or later for order confirmations, 1.2.014 for ship notices and 1.2.020 for invoices. The endpoint reads the version from the DOCTYPE line of each document.
Does Coupa support client certificates on the order endpoint?
Yes, as mutual TLS when the customer enables it on your supplier record. Coupa presents a certificate for cxml-supplier.coupahost.com, which Coupa renewed on February 10, 2026 for sandbox and February 12, 2026 for production. An older Coupa article still says client certificates are not supported; the current mutual TLS page replaces it.
Tell us what you need
Tell us which systems you use and what needs to work better. We reply personally within one working day. We help you define the work, then agree the price and timing before you commit.
- You know the price and the timeline before you commit to anything
- We work out the connection that takes the work off your hands
- We handle the build, hosting, monitoring and maintenance
- Your team has less information to retype and fewer discrepancies to chase