OCI vs. cXML: Which Punchout Standard Suits Your System?

You have a supplier shop that needs to connect to your SAP, Ariba or Coupa via punchout – and you are facing the question: OCI or cXML? The decision seems technically trivial, but it has direct consequences for integration effort, maintenance burden and the question of which suppliers you will later be able to connect without friction. In short: both standards deliver the same end result – a basket is assembled in the supplier shop and returned to your ordering system. The routes to get there and the implications for your IT, however, differ considerably. This article puts both protocols into technical context, highlights the pitfalls from real integration projects and gives a clear recommendation per platform.

What is punchout? A brief overview

Punchout (also punch-out, OCI call or PunchOut catalogue) refers to a technical bridge between an ordering system (eProcurement, SRM, ERP) and a supplier's web shop. The user starts the order in their familiar ordering tool, is automatically authenticated and transferred to the supplier shop ("punched out"), selects items there and sends the basket back to the ordering system as a data package via a defined protocol. The advantage over static catalogues: prices, availability and configuration options are always up to date, because they come live from the supplier's system.

Two standards have established themselves for this round trip: OCI (Open Catalog Interface), developed by SAP, and cXML (commerce eXtensible Markup Language), which originated at Ariba. Both have existed since the late 1990s, both are still in active use today – and both now belong to the SAP group, since SAP acquired Ariba in 2012 (Wikipedia: cXML). Nevertheless, they are not converging; they remain fundamentally different from a technical point of view.

OCI in detail (Open Catalog Interface)

OCI is a specification that SAP originally published for SAP Business-to-Business Procurement and later SAP SRM. It is declared "Open" in the sense of being freely documented and implementable – the specification is maintained by SAP and is available for download in the SAP help portals (Wikipedia: Open Catalog Interface). Besides SAP products, OCI is also supported by Microsoft Dynamics AX and a number of European procurement suites.

How the OCI round trip works

The OCI call runs as a classic HTTPS form submission. The ordering system opens a session in the user's browser against the supplier's OCI entry URL, passing parameters such as USERNAME, PASSWORD, HOOK_URL and frequently ~OkCode, ~Caller and customer-specific fields (e.g. cost centre, order number, language). The supplier shop verifies the credentials, establishes the session and remembers the HOOK_URL – that is the address to which the basket will later be posted back.

Once the buyer has finished configuring the basket, the shop triggers an HTML form POST against the HOOK_URL. The payload is not an XML structure but a flat list of HTML form fields, indexed by line item: NEW_ITEM-DESCRIPTION[1], NEW_ITEM-QUANTITY[1], NEW_ITEM-UNIT[1], NEW_ITEM-PRICE[1], NEW_ITEM-CURRENCY[1], NEW_ITEM-VENDORMAT[1] and so on. Each line item receives its own index. This has two consequences: first, implementation in the shop is remarkably simple – you build an HTML form, submit it, done. Second, an OCI round trip can only take place in an active browser context, because it depends on the form submit.

OCI versions: 3.0, 4.0, 5.0

In practice, you will see three versions in productive use today. OCI 4.0 is still the most widespread version and is supported by practically every supplier shop serving the German B2B market. It covers the classic fields around NEW_ITEM-*. OCI 5.0 extends the specification with structured fields for configuration data, attachments, delivery schedules and detailed contract references – relevant above all where complex configurable products (e.g. machine components, IT bundles) are ordered. Older SAP SRM installations often still speak OCI 3.0; its feature set is reduced, but it is backwards compatible.

Authentication in OCI

In its standard form, OCI does not define any cryptographic authentication. USERNAME and PASSWORD are transmitted as HTTPS POST fields and verified by the shop. In practice, reputable providers supplement this with additional safeguards: IP whitelisting of the ordering system servers, signed HOOK_URL tokens, short session lifetimes and, in some installations, client certificates. Anyone introducing OCI today should at least insist on TLS 1.2 or higher and secure the HOOK_URL against replay attacks by linking it to a signed nonce.

cXML in detail (commerce eXtensible Markup Language)

cXML was published by Ariba in 1999 and has been at home at SAP since the 2012 acquisition; the specification continues to be maintained openly at cxml.org. The current DTD version is 1.2.069, last updated in February 2026 (cxml.org). The standard covers far more than just punchout: catalogue transfer, purchase orders, order confirmations, dispatch notifications and invoices are also defined as document types.

How the cXML PunchOut round trip works

The cXML punchout is two-stage and uses XML instead of HTML form fields. The ordering system first sends a PunchOutSetupRequest via HTTPS POST directly – without a browser in between – to the supplier shop's endpoint. This XML message contains a header section with From, To and Sender elements (each with identity and credential entries) as well as a request body with a BuyerCookie, which marks the session context, and a BrowserFormPost URL – the cXML counterpart to the OCI HOOK_URL.

The shop responds synchronously with a PunchOutSetupResponse, which among other things delivers a StartPage URL. The user receives this URL as a redirect; they then actually navigate the shop and configure their basket. On completion, the shop sends a PunchOutOrderMessage as an XML document via HTTPS POST back to the BrowserFormPost URL. In contrast to OCI, the line items are structured XML elements (ItemIn with ItemID, ItemDetail, UnitOfMeasure, UnitPrice etc.) – more richly modelled, but also more complex to generate and to parse.

Authentication in cXML

cXML relies on shared secrets in the XML header. In the Credential elements, Identity and SharedSecret are transmitted in plain text – protected solely by HTTPS transport encryption. This method is robust because the secret never ends up in the browser context (unlike OCI credentials, which can become visible in the HTML form). In Ariba constellations this is often supplemented by Profile requests, with which the supplier shop and ordering system negotiate their capabilities at first contact. Optionally, cXML also supports X.509 client certificates.

Direct comparison: OCI vs. cXML

The following table summarises the most important differences. It is no substitute for a technical specification, but it helps with an initial assessment ahead of an integration project.

Which standard suits your system?

The answer depends primarily on your procurement platform, not on theoretical merits of the protocol. Anyone working in a hybrid landscape should also make sure that the chosen supplier offers both standards – otherwise the next platform change will be expensive.

SAP ERP / SAP S/4HANA with classic SRM

Classic SAP SRM installations natively speak OCI 4.0. If you do not need cXML here for other reasons, OCI is the unexciting choice: easy to configure, directly supported by the SAP standard, practically always offered by the supplier. On SRM 7.0 systems, pay attention to the OCI customising tables WS_PUNCHOUT and ensure connection testing via transaction SE38.

SAP Ariba

Ariba is the natural home of cXML. Suppliers connecting to the Ariba Network are required to implement cXML – OCI is not the primary integration format here. For pure Ariba buyers it therefore makes no sense to demand OCI merely because it is familiar. Conversely, for suppliers it is very much advisable to provide both standards, because many Ariba customers run SAP SRM or third-party systems in parallel.

Coupa

Coupa relies primarily on cXML and in this respect is closely modelled on Ariba. OCI is supported, but secondary. A German mid-sized company introducing Coupa should demand cXML in the current DTD version from the supplier and test the PunchOutSetupRequest endpoints in advance.

JAGGAER, Onventis, Wallmedien (POOL4TOOL/SCConnect)

The procurement suites widespread in the DACH region typically support both standards. JAGGAER and Onventis are strongly represented in the German mid-market and in practice are predominantly connected via OCI – simply because the supplier ecosystem there traditionally speaks OCI. If you are introducing one of these platforms, ask the vendor for a reference list of connected shops for both standards and decide on the basis of that list.

Microsoft Dynamics 365 / Dynamics AX

Dynamics AX supported OCI natively (Wikipedia: OCI); the successor product Dynamics 365 typically requires middleware or a procurement add-on. In this constellation, the punchout is usually implemented via a connector that speaks OCI or cXML towards the supplier. First check which format the connector natively produces before setting requirements for the supplier.

Typical integration hurdles in practice

Regardless of the standard, the same problems come up again and again in punchout projects. Knowing them saves weeks.

SSL/TLS certificates and trust chains

Both OCI and cXML run exclusively over HTTPS. That is only trivial until the ordering system sits behind an old Java stack or a custom truststore. Symptoms: SSLHandshakeException, PKIX path building failed. Check early whether the root certificate of the supplier endpoint (often Let's Encrypt, DigiCert, GlobalSign) is present in the truststore of your procurement server. With SAP SRM, this concerns the STRUST configuration.

IP whitelisting in both directions

Many suppliers require the ordering system IPs to be whitelisted. Conversely, the supplier shop sometimes sits behind a WAF that blocks HOOK_URL callbacks. Before go-live, clarify in a network document which addresses must be reachable in which direction – and whether your HOOK_URL is even reachable from the internet, in case the shop is to post back directly. With on-premises ordering systems this is often not the case.

Session timeouts and HOOK_URL lifetime

A HOOK_URL or BrowserFormPost URL is typically valid for only 30 to 60 minutes. Anyone browsing the supplier shop for longer – for instance because they need to clarify a special case – gets an error on submission. The supplier shop should therefore visibly display the remaining session window or cleanly terminate the session on inactivity timeout instead of silent 500 errors.

Encoding problems in the round trip

Classic number one: umlauts and special characters arrive in the ordering system as ? or broken bytes. The cause is almost always an encoding mismatch during the form submit (OCI) or in XML generation (cXML, missing encoding="UTF-8" declaration). Explicitly test items with umlauts, a sharp s and a hyphen/em-dash pair. Anyone not careful here will later have incorrect product descriptions in the order – and in the worst case in the invoice.

Tax rate, currency and UoM

OCI 4.0 has no dedicated field for the tax rate. Some ordering systems expect the gross price, others the net price. cXML is more explicit here, but implementations deviate here too. Define in the integration workshop: which price basis (net/gross)? Which currency? Which UoM codes (UN/ECE Recommendation 20)? A single wrong UoM code in the supplier shop translates downstream into incorrect postings.

Multiple clients and ship-to logic

Anyone with multiple sites or company codes must tell the supplier shop which delivery address the basket applies to. OCI usually does this via a custom field introduced by the customer; cXML has dedicated ShipTo elements in the PunchOutSetupRequest. Overlook this and you get orders without a site assignment.

How to evaluate suppliers that offer both standards

If a supplier – such as a technical specialist retailer for warehouse equipment – supports OCI and cXML, you should not treat this as a mere checkbox in your supplier evaluation. Specifically check:

• Which OCI version is returned? 4.0 is standard, 5.0 is relevant if you purchase configurable items with an options structure.
• Which cXML DTD version? The current specification is 1.2.069 (cxml.org); significantly older releases (e.g. 1.2.014) can work, but lack newer fields.
• Are custom fields supported? Cost centre, internal order number, project identifier – these fields must come back cleanly through the round trip.
• How is the session secured? Ask about token signing, HOOK_URL lifetime and IP whitelisting options.
• What do the test and sandbox modes look like? A reputable supplier provides a test endpoint that allows real round trips without generating real orders at the end.
• What happens when versions change? Who migrates to a new OCI or cXML version, and when? Are there lead times?

A good supplier has a written answer to each of these points. Anyone who evades them risks leaving you to struggle with half-baked implementations later in the integration project.

Frequently asked questions

Do I need both standards if I have several procurement systems?

If you work with corporate SAP SRM and mid-sized subsidiaries running Onventis, you should demand both standards from the supplier – the additional effort on the supplier side is manageable, the benefit for you is large. If you only use one system, the matching format is enough.

Is cXML "better" than OCI because it is newer and richer in data?

Not across the board. cXML is richer in data and cleanly XML-structured, which brings advantages with complex use cases. OCI, in turn, is easier to implement, more error-resistant in the browser round trip and more commonly encountered in Germany. For 80 % of warehouse equipment orders, OCI 4.0 is fully sufficient.

What does BMEcat have to do with this?

BMEcat is a static catalogue format for the XML-based exchange of entire product catalogues between suppliers and ordering systems. It solves a different problem from punchout: with BMEcat a catalogue is imported once; with punchout you start live in the supplier shop. Many companies combine both – BMEcat for the core range, punchout for the long tail and configurable products.

How secure is username/password in OCI in plain text?

As long as the connection runs over TLS 1.2 or higher, the credentials are encrypted in transit. The risk lies rather in browser logging and in the visibility of the HTML form source code. To avoid this, additionally use IP whitelisting and exchange the initial password for a short, signed session token.

What does a punchout integration project typically cost?

On the supplier side, a modern shop needs only a few person-days for the OCI connection; cXML tends to need 5–15 days, because a setup endpoint and an XML generator must additionally be built. On the buyer side, add configuration in SRM/Coupa/Ariba (typically 1–3 days), tests including round-trip validation and user training. Reliable figures, however, can only be given after concrete scoping.

What if my supplier does not offer punchout?

Then three alternatives remain: BMEcat catalogue import, manual ordering via the supplier portal with subsequent re-entry, or connection via a marketplace platform (Mercateo/Unite, Wucato, Conrad B2B) that in turn speaks punchout to the ordering system. The latter is often the most pragmatic route when only a single supplier is missing.

Conclusion

OCI and cXML solve the same problem with two very different philosophies: OCI is lean, browser-centric and de facto ubiquitous in Germany; cXML is data-rich, system-to-system oriented and mandatory as soon as Ariba is involved. If you run SAP SRM or classic DACH procurement suites, OCI 4.0 is the safe choice without debate. If you operate in an Ariba or Coupa world, there is no way around cXML. Suppliers who master both standards make your life easier in the long run – check this during the evaluation rather than only in the integration workshop. And regardless of the standard, plan time for the invisible items: TLS truststores, encoding, session lifetimes. That is exactly where 80 % of the delays in a punchout rollout arise.