OCI vs. cXML: Welcher Punchout-Standard passt zu Ihrem System?

Sie haben einen Lieferanten-Shop, der per Punchout an Ihr SAP, Ariba oder Coupa andocken soll – und stehen vor der Frage: OCI oder cXML? Die Entscheidung wirkt technisch trivial, hat aber direkte Folgen für Integrationsaufwand, Wartungslast und die Frage, welche Lieferanten Sie später ohne Friktion anbinden können. Kurz vorweg: Beide Standards leisten dasselbe Endergebnis – ein Warenkorb wird im Lieferantenshop zusammengestellt und an Ihr Bestellsystem zurückgegeben. Die Wege dorthin und die Implikationen für Ihre IT unterscheiden sich aber deutlich. Dieser Artikel ordnet beide Protokolle technisch ein, zeigt die Stolperfallen aus realen Integrationsprojekten und gibt eine klare Empfehlung pro Plattform.

Was ist Punchout? Kurzer Überblick

Unter Punchout (auch Punch-out, OCI-Call oder PunchOut Catalog) versteht man eine technische Brücke zwischen einem Bestellsystem (eProcurement, SRM, ERP) und dem Webshop eines Lieferanten. Der Anwender startet die Bestellung in seinem gewohnten Bestellwerkzeug, wird automatisch authentifiziert in den Lieferanten-Shop übergeben („ausgepuncht“), wählt dort Artikel und schickt den Warenkorb per definiertem Protokoll als Datenpaket zurück in das Bestellsystem. Der Vorteil gegenüber statischen Katalogen: Preise, Verfügbarkeiten und Konfigurationsoptionen sind immer aktuell, weil sie live aus dem Lieferantensystem stammen.

Für diesen Roundtrip haben sich zwei Standards durchgesetzt: das von SAP entwickelte OCI (Open Catalog Interface) und das aus dem Hause Ariba stammende cXML (commerce eXtensible Markup Language). Beide existieren seit Ende der 1990er Jahre, beide werden bis heute aktiv eingesetzt – und beide gehören mittlerweile zum SAP-Konzern, seit SAP Ariba 2012 übernommen hat (Wikipedia: cXML). Trotzdem konvergieren sie nicht; sie bleiben technisch grundsätzlich verschieden.

OCI im Detail (Open Catalog Interface)

OCI ist eine Spezifikation, die SAP ursprünglich für SAP Business-to-Business Procurement und später SAP SRM veröffentlicht hat. Sie ist als „Open“ deklariert, im Sinne von frei dokumentiert und implementierbar – die Spezifikation wird von SAP gepflegt und steht in den SAP-Hilfeportalen zum Download bereit (Wikipedia: Open Catalog Interface). OCI wird außer von SAP-Produkten auch von Microsoft Dynamics AX und einer Reihe europäischer Procurement-Suiten unterstützt.

Funktionsweise des OCI-Roundtrips

Der OCI-Aufruf läuft als klassische HTTPS-Form-Submission. Das Bestellsystem öffnet im Browser des Benutzers eine Sitzung gegen die OCI-Einstiegs-URL des Lieferanten und übermittelt dabei Parameter wie USERNAME, PASSWORD, HOOK_URL sowie häufig ~OkCode, ~Caller und kundenspezifische Felder (z. B. Kostenstelle, Bestellnummer, Sprache). Der Lieferantenshop prüft die Zugangsdaten, baut die Session auf und merkt sich die HOOK_URL – das ist die Adresse, an die der Warenkorb später zurückgepostet wird.

Hat der Einkaufende den Warenkorb fertig konfiguriert, löst der Shop einen HTML-Form-POST gegen die HOOK_URL aus. Die Nutzdaten sind keine XML-Struktur, sondern eine flache Liste von HTML-Formularfeldern, indiziert nach Position: NEW_ITEM-DESCRIPTION[1], NEW_ITEM-QUANTITY[1], NEW_ITEM-UNIT[1], NEW_ITEM-PRICE[1], NEW_ITEM-CURRENCY[1], NEW_ITEM-VENDORMAT[1] und so weiter. Jede Position erhält einen eigenen Index. Das hat zwei Konsequenzen: Erstens ist die Implementierung im Shop denkbar einfach – man baut ein HTML-Form, schickt es ab, fertig. Zweitens kann ein OCI-Roundtrip nur in einem aktiven Browserkontext stattfinden, denn er hängt am Form-Submit.

OCI-Versionen: 3.0, 4.0, 5.0

In der Praxis sehen Sie heute drei Versionen im produktiven Einsatz. OCI 4.0 ist nach wie vor der meistverbreitete Stand und wird von praktisch jedem Lieferanten-Shop unterstützt, der den deutschen B2B-Markt bedient. Es deckt die klassischen Felder rund um NEW_ITEM-* ab. OCI 5.0 erweitert die Spezifikation um strukturierte Felder für Konfigurationsdaten, Anlagen, Lieferpläne und detaillierte Vertragsreferenzen – relevant vor allem dort, wo komplexe konfigurierbare Produkte (z. B. Maschinenbauteile, IT-Bundles) bestellt werden. Ältere SAP-SRM-Installationen sprechen oft noch OCI 3.0; das ist im Funktionsumfang reduziert, aber abwärtskompatibel.

Authentifizierung in OCI

OCI definiert in seiner Standardform keine kryptografische Authentifizierung. USERNAME und PASSWORD werden als HTTPS-POST-Felder übertragen und vom Shop geprüft. In der Praxis ergänzen seriöse Anbieter das mit zusätzlichen Sicherungen: IP-Whitelisting der Bestellsystem-Server, signierte HOOK_URL-Tokens, kurze Session-Lebensdauern und in manchen Installationen Client-Zertifikate. Wer OCI heute neu einführt, sollte zumindest auf TLS 1.2 oder höher bestehen und die HOOK_URL gegen Replay-Angriffe absichern, indem sie mit einer signierten Nonce verknüpft wird.

cXML im Detail (commerce eXtensible Markup Language)

cXML wurde 1999 von Ariba veröffentlicht und ist seit der Übernahme durch SAP im Jahr 2012 dort beheimatet; die Spezifikation wird weiterhin offen auf cxml.org gepflegt. Die aktuelle DTD-Version ist 1.2.069, zuletzt aktualisiert im Februar 2026 (cxml.org). Der Standard deckt weit mehr ab als nur Punchout: Auch Katalogtransfer, Bestellungen, Auftragsbestätigungen, Lieferavise und Rechnungen sind als Dokumenttypen definiert.

Funktionsweise des cXML-PunchOut-Roundtrips

Der cXML-Punchout ist zweistufig und nutzt XML statt HTML-Form-Feldern. Das Bestellsystem sendet zunächst per HTTPS POST einen PunchOutSetupRequest direkt – ohne Browser dazwischen – an den Endpoint des Lieferantenshops. Diese XML-Nachricht enthält eine Header-Sektion mit From, To und Sender-Elementen (jeweils mit Identity- und Credential-Einträgen) sowie einen Request-Body mit BuyerCookie, der den Sessionkontext markiert, und einer BrowserFormPost-URL – das cXML-Pendant zur OCI-HOOK_URL.

Der Shop antwortet synchron mit einem PunchOutSetupResponse, der unter anderem eine StartPage-URL liefert. Diese URL bekommt der Benutzer als Redirect; er navigiert dann tatsächlich im Shop und konfiguriert seinen Warenkorb. Beim Abschluss schickt der Shop einen PunchOutOrderMessage als XML-Dokument per HTTPS POST an die BrowserFormPost-URL zurück. Im Gegensatz zu OCI sind die Positionen strukturierte XML-Elemente (ItemIn mit ItemID, ItemDetail, UnitOfMeasure, UnitPrice etc.) – reicher modelliert, aber auch aufwendiger zu erzeugen und zu parsen.

Authentifizierung in cXML

cXML setzt auf Shared Secrets im XML-Header. In den Credential-Elementen werden Identity und SharedSecret als Klartext übertragen – geschützt allein durch die HTTPS-Transportverschlüsselung. Diese Methode ist robust, weil das Secret nie im Browserkontext landet (anders als OCI-Credentials, die im HTML-Form sichtbar werden können). Ergänzt wird das in Ariba-Konstellationen oft durch Profile-Requests, mit denen Lieferantenshop und Bestellsystem ihre Fähigkeiten beim ersten Kontakt aushandeln. Optional unterstützt cXML auch X.509-Client-Zertifikate.

Direkter Vergleich: OCI vs. cXML

Die folgende Tabelle fasst die wichtigsten Unterschiede zusammen. Sie ersetzt keine technische Spezifikation, hilft aber bei der ersten Einschätzung im Vorfeld eines Integrationsprojekts.

Welcher Standard passt zu Ihrem System?

Die Antwort hängt primär von Ihrer Procurement-Plattform ab, nicht von theoretischen Vorzügen des Protokolls. Wer in einer hybriden Landschaft arbeitet, sollte zudem darauf achten, dass der gewählte Lieferant beide Standards anbietet – sonst wird der nächste Plattformwechsel teuer.

SAP ERP / SAP S/4HANA mit klassischem SRM

Klassische SAP-SRM-Installationen sprechen nativ OCI 4.0. Wenn Sie hier nicht aus anderen Gründen cXML brauchen, ist OCI die unaufgeregte Wahl: einfach zu konfigurieren, vom SAP-Standard direkt unterstützt, vom Lieferanten praktisch immer angeboten. Achten Sie bei SRM 7.0-Stand auf die OCI-Customizing-Tabellen WS_PUNCHOUT und stellen Sie das Verbindungstesting über die Transaktion SE38 sicher.

SAP Ariba

Ariba ist die natürliche Heimat von cXML. Lieferanten, die sich an Ariba Network anbinden, müssen zwingend cXML implementieren – OCI ist hier nicht das Hauptintegrationsformat. Für reine Ariba-Buyer macht es deshalb keinen Sinn, OCI nur deshalb zu fordern, weil man es kennt. Für Lieferanten ist es umgekehrt aber sehr wohl ratsam, beide Standards bereitzustellen, weil viele Ariba-Kunden parallel SAP-SRM oder Drittsysteme einsetzen.

Coupa

Coupa setzt primär auf cXML und ist in dieser Hinsicht eng am Ariba-Vorbild orientiert. OCI wird unterstützt, ist aber zweitrangig. Wer als deutscher Mittelständler Coupa einführt, sollte vom Lieferanten cXML in der aktuellen DTD-Version verlangen und die PunchOutSetupRequest-Endpoints im Vorfeld testen.

JAGGAER, Onventis, Wallmedien (POOL4TOOL/SCConnect)

Die im DACH-Raum verbreiteten Procurement-Suiten unterstützen typischerweise beide Standards. JAGGAER und Onventis sind im deutschen Mittelstand stark vertreten und werden in der Praxis überwiegend per OCI angebunden – einfach, weil das Ökosystem der Lieferanten dort traditionell OCI spricht. Wenn Sie eine dieser Plattformen einführen, lassen Sie sich vom Anbieter eine Referenzliste angebundener Shops für beide Standards geben und entscheiden Sie auf Basis dieser Liste.

Microsoft Dynamics 365 / Dynamics AX

Dynamics AX hat OCI nativ unterstützt (Wikipedia: OCI), das Nachfolgeprodukt Dynamics 365 verlangt typischerweise eine Middleware oder ein Procurement-Add-on. In dieser Konstellation wird der Punchout meist über einen Konnektor abgebildet, der dem Lieferanten gegenüber OCI oder cXML spricht. Prüfen Sie zuerst, welches Format der Konnektor nativ erzeugt, bevor Sie dem Lieferanten Vorgaben machen.

Typische Integrationshürden in der Praxis

Unabhängig vom Standard tauchen in Punchout-Projekten immer wieder dieselben Probleme auf. Wer sie kennt, spart Wochen.

SSL-/TLS-Zertifikate und Trust-Chains

Sowohl OCI als auch cXML laufen ausschließlich über HTTPS. Das ist erst trivial, bis das Bestellsystem hinter einem alten Java-Stack oder einem benutzerdefinierten Truststore sitzt. Symptome: SSLHandshakeException, PKIX path building failed. Prüfen Sie früh, ob das Root-Zertifikat des Lieferanten-Endpoints (oft Let’s Encrypt, DigiCert, GlobalSign) im Truststore Ihres Procurement-Servers vorhanden ist. Bei SAP-SRM betrifft das die STRUST-Konfiguration.

IP-Whitelisting in beide Richtungen

Viele Lieferanten verlangen, dass die Bestellsystem-IPs whitegelistet werden. Umgekehrt sitzt der Lieferantenshop manchmal hinter einem WAF, der HOOK_URL-Callbacks blockiert. Clären Sie vor Go-Live in einem Netzwerkdokument, welche Adressen in welche Richtung erreichbar sein müssen – und ob Ihre HOOK_URL aus dem Internet überhaupt erreichbar ist, falls der Shop direkt zurückposten soll. Bei Bestellsystemen on-premises ist das oft nicht der Fall.

Session-Timeouts und HOOK_URL-Lebensdauer

Eine HOOK_URL bzw. BrowserFormPost-URL ist typischerweise nur 30 bis 60 Minuten gültig. Wer im Lieferantenshop länger stöbert – etwa weil er eine Sondersituation klären muss – bekommt beim Abschicken einen Fehler. Der Lieferantenshop sollte deshalb das verbleibende Session-Fenster sichtbar anzeigen oder die Session beim Inaktivitäts-Timeout sauber abbrechen statt stummen 500ern.

Encoding-Probleme beim Roundtrip

Klassiker Nummer eins: Umlaute und Sonderzeichen kommen im Bestellsystem als ? oder kaputten Bytes an. Ursache ist fast immer ein Encoding-Mismatch beim Form-Submit (OCI) oder bei der XML-Erzeugung (cXML, fehlende encoding="UTF-8"-Deklaration). Testen Sie explizit Artikel mit Umlauten, scharfem S und einem Bindestrich-Geviertstrich-Paar. Wer hier nicht aufpasst, hat später falsche Produktbezeichnungen in der Bestellung – und im schlimmsten Fall in der Rechnung.

Steuersatz, Währung und UoM

OCI 4.0 hat kein dezidiertes Feld für den Steuersatz. Manche Bestellsysteme erwarten den Bruttopreis, andere den Nettopreis. cXML ist hier expliziter, aber auch hier weichen Implementierungen ab. Definieren Sie im Integrations-Workshop: Welche Preis-Basis (netto/brutto)? Welche Währung? Welche UoM-Codes (UN/ECE Recommendation 20)? Ein einziger falscher UoM-Code im Lieferantenshop übersetzt sich nachgelagert in falsche Verbuchungen.

Mehrere Mandanten und Ship-To-Logik

Wer mehrere Standorte oder Buchungskreise hat, muss dem Lieferantenshop sagen, für welche Lieferadresse der Warenkorb gilt. OCI macht das meist über ein vom Kunden eingeführtes Custom-Feld; cXML kennt im PunchOutSetupRequest dedizierte ShipTo-Elemente. Wer das übersieht, bekommt Bestellungen ohne Standort-Zuordnung.

So bewerten Sie Lieferanten, die beide Standards anbieten

Wenn ein Lieferant – wie ein technischer Fachhändler für Lagertechnik – OCI und cXML unterstützt, sollten Sie das in der Lieferantenbewertung nicht als reine Checkbox abhaken. Prüfen Sie konkret:

• Welche OCI-Version wird zurückgeliefert? 4.0 ist Standard, 5.0 ist relevant, wenn Sie konfigurierbare Artikel mit Optionsstruktur einkaufen.
• Welche cXML-DTD-Version? Die aktuelle Spezifikation ist 1.2.069 (cxml.org); deutlich ältere Releases (z. B. 1.2.014) können funktionieren, lassen aber neuere Felder vermissen.
• Werden Custom Fields unterstützt? Kostenstelle, interne Bestellnummer, Projektkennung – diese Felder müssen durch den Roundtrip sauber zurückkommen.
• Wie wird die Session abgesichert? Fragen Sie nach Token-Signatur, HOOK_URL-Lebensdauer und IP-Whitelisting-Optionen.
• Wie sieht der Test- und Sandbox-Modus aus? Ein seriöser Lieferant stellt einen Test-Endpoint bereit, der echte Roundtrips erlaubt, ohne dass am Ende Echtbestellungen erzeugt werden.
• Was passiert beim Versionswechsel? Wer migriert wann auf eine neue OCI- oder cXML-Version? Gibt es Vorlaufzeiten?

Ein guter Lieferant hat zu jedem dieser Punkte eine schriftliche Antwort. Wer ausweicht, riskiert, dass Sie später im Integrationsprojekt mit halbgaren Implementierungen kämpfen.

Häufige Fragen

Brauche ich beide Standards, wenn ich mehrere Procurement-Systeme habe?

Wenn Sie mit Konzern-SAP-SRM und Mittelstandstöchtern mit Onventis arbeiten, sollten Sie vom Lieferanten beide Standards verlangen – der Mehraufwand auf Lieferantenseite ist überschaubar, der Nutzen für Sie groß. Wenn Sie nur ein System einsetzen, reicht das passende Format.

Ist cXML „besser“ als OCI, weil neuer und datenreicher?

Nicht pauschal. cXML ist datenreicher und sauber XML-strukturiert, was bei komplexen Ausprägungen Vorteile bringt. OCI ist dafür einfacher zu implementieren, fehlerresistenter im Browser-Roundtrip und in Deutschland häufiger anzutreffen. Für 80 % der Lagertechnik-Bestellungen reicht OCI 4.0 voll aus.

Was hat BMEcat damit zu tun?

BMEcat ist ein statisches Katalogformat für den XML-basierten Austausch ganzer Produktkataloge zwischen Lieferanten und Bestellsystemen. Es löst ein anderes Problem als Punchout: Bei BMEcat wird einmal ein Katalog importiert; bei Punchout wird live im Lieferantenshop gestartet. Viele Unternehmen kombinieren beides – BMEcat für das Kernsortiment, Punchout für den Long Tail und konfigurierbare Produkte.

Wie sicher ist Username/Passwort in OCI im Klartext?

Solange die Verbindung über TLS 1.2 oder höher läuft, sind die Credentials während des Transports verschlüsselt. Das Risiko liegt eher beim Browser-Logging und in der HTML-Form-Quelltext-Sichtbarkeit. Wer das vermeiden will, nutzt zusätzlich IP-Whitelisting und tauscht das Initialpasswort gegen ein kurzes, signiertes Session-Token aus.

Was kostet ein Punchout-Integrationsprojekt typischerweise?

Auf Lieferantenseite reichen bei einem modernen Shop wenige Personentage für die OCI-Anbindung; cXML braucht eher 5–15 Tage, weil zusätzlich Setup-Endpoint und XML-Generator gebaut werden. Auf Käuferseite kommen Konfiguration im SRM/Coupa/Ariba (typisch 1–3 Tage), Tests inkl. Roundtrip-Validierung und User-Schulung dazu. Belastbare Zahlen lassen sich aber nur nach einem konkreten Scoping nennen.

Was, wenn mein Lieferant keinen Punchout anbietet?

Dann bleiben drei Alternativen: BMEcat-Katalog-Import, manuelle Bestellung über das Lieferantenportal mit anschließender Nacherfassung, oder die Anbindung über eine Marktplatzplattform (Mercateo/Unite, Wucato, Conrad B2B), die ihrerseits Punchout zum Bestellsystem spricht. Letzteres ist häufig der pragmatischste Weg, wenn nur ein einzelner Lieferant fehlt.

Fazit

OCI und cXML lösen dasselbe Problem mit zwei sehr unterschiedlichen Philosophien: OCI ist schlank, browser-zentriert und in Deutschland faktisch überall anzutreffen; cXML ist datenreich, system-zu-system-orientiert und Pflicht, sobald Ariba im Spiel ist. Wer SAP SRM oder klassische DACH-Procurement-Suiten betreibt, fährt mit OCI 4.0 ohne Diskussion gut. Wer in einer Ariba- oder Coupa-Welt unterwegs ist, kommt an cXML nicht vorbei. Lieferanten, die beide Standards beherrschen, machen Ihnen das Leben langfristig leichter – prüfen Sie das in der Bewertung statt erst im Integrationsworkshop. Und planen Sie unabhängig vom Standard Zeit für die unsichtbaren Punkte ein: TLS-Truststores, Encoding, Session-Lebensdauer. Genau dort entstehen 80 % der Verzögerungen im Punchout-Rollout.