What is cXML? The protocol behind PunchOut

cXML, short for commerce XML, is the message format most procurement systems use to talk to suppliers. If you have ever seen a PunchOut connection configured, or a supplier described as “cXML capable”, this is the specification underneath.

It was introduced by Ariba in 1999 and published as an open specification. Despite its age, and despite newer standards existing for parts of the same territory, it remains the practical lingua franca of B2B procurement integration, particularly for catalogue and ordering traffic in North America and increasingly worldwide.

The shape of a cXML document

Every cXML document has the same outer structure: an envelope carrying a header and exactly one payload.

<cXML payloadID="[email protected]"
      timestamp="2026-08-30T09:00:00+02:00">
  <Header>
    <From>
      <Credential domain="DUNS">
        <Identity>123456789</Identity>
      </Credential>
    </From>
    <To>
      <Credential domain="DUNS">
        <Identity>987654321</Identity>
      </Credential>
    </To>
    <Sender>
      <Credential domain="NetworkID">
        <Identity>buyer.example.com</Identity>
        <SharedSecret>...</SharedSecret>
      </Credential>
      <UserAgent>Buyer Procurement 5.2</UserAgent>
    </Sender>
  </Header>
  <Request>
    <!-- one specific request type goes here -->
  </Request>
</cXML>

Three parts of this are worth dwelling on, because they are where most integration problems live.

payloadID must be globally unique. The convention is a timestamp, a random component, and the sender’s domain. Receivers use it to detect duplicates, so a sender that reuses payload IDs will eventually have legitimate messages silently discarded.

The From, To and Sender triple is not redundant. From and To identify the trading parties. Sender identifies whoever is actually transmitting the message, which may be a third party operating on a party’s behalf. Getting this wrong is the single most common cause of authentication failures.

Credential domains must match on both sides. DUNS, NetworkID, AribaNetworkUserId and buyer-specific custom domains are all in use. A supplier configured to expect DUNS will reject a perfectly valid message that identifies the buyer by NetworkID, and the error text is rarely helpful about why.

The payload is one of three kinds: a Request (expects a response), a Response (answers one), or a Message (one-way, no response expected).

The message types that matter

A working procurement integration typically uses a small subset of the specification.

For catalogues and PunchOut:

• PunchOutSetupRequest and PunchOutSetupResponse open a shopping session and return the entry URL.
• PunchOutOrderMessage returns the finished cart to the buyer.

For ordering:

• OrderRequest carries a purchase order to the supplier. This is the document that creates the commitment.
• OrderResponse acknowledges receipt at the transport level.
• ConfirmationRequest is the supplier’s business-level answer: accepted, rejected, backordered, or accepted with changes to quantity, price, or delivery date.

For fulfilment and billing:

• ShipNoticeRequest is the advance dispatch advice.
• InvoiceDetailRequest is the invoice.
• StatusUpdateRequest communicates state changes on an existing document.

The order and invoice types are where cXML overlaps with older EDI territory, and where the choice between standards actually becomes a decision rather than a default.

How cXML compares to the alternatives

Against EDI. Classic EDI, meaning X12 in North America (850 for the order, 810 for the invoice) or EDIFACT in Europe (ORDERS, INVOIC), covers the same ordering and invoicing ground. EDI is older, more compact, deeply embedded in large-enterprise supply chains, and considerably harder to work with: positional segment formats, per-partner implementation guides, and value-added network intermediaries. cXML is verbose by comparison but readable, HTTP-native, and far cheaper to implement for a supplier who does not already have EDI infrastructure. The decisive difference is that EDI has no equivalent of PunchOut. Interactive catalogue shopping is simply outside its model.

Against PEPPOL and UBL. PEPPOL is the European four-corner network for exchanging structured business documents, using UBL as the document format and BIS Billing 3.0 as the invoice specification. Where cXML is a point-to-point protocol with bilaterally exchanged credentials, PEPPOL is a network with a directory, certified access points, and published validation rules. For invoicing under European mandates, PEPPOL is increasingly not optional. For catalogue and PunchOut traffic, it is not the relevant standard. Most European estates end up running both: cXML or OCI upstream for catalogues and orders, PEPPOL downstream for compliant invoicing. We cover that downstream picture in PEPPOL e-invoicing and the 2026 shift and the ViDA cascade.

Against OCI. SAP’s Open Catalog Interface solves the PunchOut problem specifically, using HTTP form parameters instead of XML documents. Simpler, less expressive, and widespread wherever SAP procurement is. A supplier selling into a mixed buyer base generally needs both.

Transport and versioning

cXML travels as an HTTPS POST with a content type of text/xml, or as a form post in the specific case of the browser-mediated PunchOut steps. There is no queueing semantics in the specification itself; reliability is whatever the two endpoints agree to build.

Versioning is declared by the DTD reference in the document prologue. Versions are broadly backward compatible, and most trading partners settle on whatever version both stacks support rather than tracking the latest release. In practice the version matters far less than the credential configuration and the field-level agreement about units of measure and classification codes.

The practical difficulty

None of the above is conceptually hard. The difficulty with cXML in real estates is entirely one of multiplicity.

Every buyer-supplier pair needs credentials agreed, endpoints exchanged, a test cycle run, unit-of-measure conventions aligned, and classification mapping decided. None of that is reusable across pairs, because the credentials, endpoints, and field conventions differ each time. A supplier connecting to thirty buyers does that thirty times, and maintains thirty configurations afterwards.

This is exactly the scaling problem that pushed the industry toward networks and gateways, and it is the problem SupplierForge addresses: a supplier configures their cXML capability once and becomes reachable by many buyers, rather than negotiating the same setup repeatedly. The pattern is described further in what is a PunchOut gateway, and the flow cXML actually carries is walked through in what is PunchOut.