Punchout-Kataloge erklärt: cXML, SAP OCI und der Rundweg ins ERP des Käufers

Ein Punchout-Katalog ist der Webshop eines Lieferanten, der aus dem Beschaffungssystem eines Käufers heraus geöffnet wird. Der Einkäufer nutzt Suche, Konfiguration und Vertragspreise des Lieferanten und schickt den Warenkorb dann an sein eigenes System zurück, wo er zur Bedarfsanforderung wird, die Freigabe durchläuft und als Bestellung zum Lieferanten zurückkommt. Eingekauft wird im Shop; Kontrolle, Budgets und Freigaben bleiben beim Käufer.

Dieser Artikel erklärt die beiden Protokolle, die diesen Rundweg tragen, cXML PunchOut und das Open Catalog Interface von SAP einschließlich Secure OCI, was ein Lieferantenshop umsetzen und absichern muss, wer Punchout verlangt, was ein Gateway im Vergleich zum Eigenbau kostet, wann Punchout das falsche Werkzeug ist, und eine Checkliste für den Livegang.

Welches Problem löst Punchout?

Er lässt große Käufer ihre Einkaufsregeln behalten und trotzdem den Shop des Lieferanten nutzen. Einkaufsabteilungen wollen, dass jeder Kauf über ihr eigenes System läuft, wegen Budgets, Kostenstellen und Freigaben, aber Katalog, Konfigurator und Vertragspreise des Lieferanten wollen sie nicht selbst pflegen. Punchout teilt die Arbeit: Der Lieferant betreibt das Einkaufserlebnis, das System des Käufers trifft die Entscheidung.

Deshalb taucht Punchout in Verträgen mit Großkunden und der öffentlichen Hand oft als Bedingung auf. Für den Lieferanten ändert sich, was „fertig“ bedeutet: Der Shop ist nicht mehr das Ende des Kaufs, sondern eine Station mitten im Prozess eines anderen, und jede Position im zurückgegebenen Warenkorb muss etwas sein, das das ERP des Käufers buchen kann.

Wie funktioniert der cXML-PunchOut-Rundweg?

Drei cXML-Nachrichten tragen ihn: Ein PunchOutSetupRequest und seine Antwort öffnen die Sitzung von Server zu Server, und eine PunchOutOrderMessage bringt den Warenkorb über den Browser des Nutzers zurück. cXML wird auf cxml.org gepflegt, aktuell in Version 1.2.071 vom August 2026, und deckt auch Kataloge, Bestellungen, Bestätigungen, Lieferavise und Rechnungen ab (cXML.org).

<cXML payloadID="1760600000.4711@buyer.example" timestamp="2026-10-08T09:12:00+02:00">
  <Header>
    <From><Credential domain="NetworkID"><Identity>BUYER-123</Identity></Credential></From>
    <To><Credential domain="DUNS"><Identity>SUPPLIER-456</Identity></Credential></To>
    <Sender>
      <Credential domain="NetworkID">
        <Identity>BUYER-123</Identity>
        <SharedSecret>…</SharedSecret>
      </Credential>
      <UserAgent>Procurement 2026</UserAgent>
    </Sender>
  </Header>
  <Request>
    <PunchOutSetupRequest operation="create">
      <BuyerCookie>8f3c1a…</BuyerCookie>
      <Extrinsic name="UserEmail">p.huber@buyer.example</Extrinsic>
      <BrowserFormPost><URL>https://procurement.buyer.example/punchout/return</URL></BrowserFormPost>
    </PunchOutSetupRequest>
  </Request>
</cXML>

• Setup-Anfrage: enthält operation="create", inspect oder edit, einen BuyerCookie, mit dem der Käufer den zurückkommenden Warenkorb dem Nutzer zuordnet, und die BrowserFormPost-URL, an die der Warenkorb gehen muss; Nutzerdaten kommen als Extrinsic-Elemente oder als Contact und unterscheiden sich je Beschaffungssystem (PunchOutCommerce).
• Setup-Antwort: ein Status 200 und eine StartPage-URL, die den Nutzer anmeldet. Ein bewährtes Muster ist, die Anfrage unter einer zufälligen Sitzungs-ID zu speichern, sie beim Eintreffen des Nutzers zu prüfen und unbenutzte IDs nach etwa fünf Minuten verfallen zu lassen.
• Warenkorb-Rückgabe: ein vom Browser an die BrowserFormPost-URL gesendetes HTML-Formular mit dem cXML in einem verdeckten Feld namens cXML-urlencoded. Die PunchOutOrderMessage muss den BuyerCookie zurückgeben, und jedes ItemIn trägt Menge, SupplierPartID, Stückpreis, Beschreibung und Mengeneinheit (PunchOutCommerce).

Zwei Details verursachen die meisten Produktionsfehler. Der zurückgegebene Warenkorb ist ein Angebot, keine Bestellung; die echte Bestellung kommt später als cXML-OrderRequest, und die SupplierPartAuxiliaryID, die Sie an jede Position hängen, muss auf dieser Bestellung unverändert zurückkommen, weil sie oft die einzige Verbindung zu einem konfigurierten Artikel oder Vertragspreis ist. Und der BuyerCookie ist keine Authentifizierung: Er läuft über den Lieferanten, Käufer sollten ihm bei der Rückgabe also nicht allein vertrauen, und Lieferanten dürfen nie Geheimnisse hineinlegen.

Wie funktioniert SAP OCI, einfach und sicher?

OCI ist ein Protokoll auf Basis von HTML-Formularen: SAP ruft die Katalog-URL mit Parametern auf, und der Katalog gibt den Warenkorb als verdeckte Formularfelder an eine Rücksprungadresse zurück. Der Aufruf enthält meist USERNAME und PASSWORD, die erforderliche HOOK_URL, an die der Warenkorb gehen muss, und ~TARGET für das Formularziel in gerahmten Sitzungen; Zugangsdaten gehören in einen POST-Body, denn ein GET legt sie in URLs und Logs offen (PunchOutCommerce).

<form method="post" action="{HOOK_URL from the launch request}" target="{~TARGET}">
  <input type="hidden" name="NEW_ITEM-DESCRIPTION[1]" value="Cable gland M20x1.5 IP68">
  <input type="hidden" name="NEW_ITEM-QUANTITY[1]"    value="50">
  <input type="hidden" name="NEW_ITEM-UNIT[1]"        value="PCE">
  <input type="hidden" name="NEW_ITEM-PRICE[1]"       value="1.84">
  <input type="hidden" name="NEW_ITEM-CURRENCY[1]"    value="EUR">
  <input type="hidden" name="NEW_ITEM-VENDORMAT[1]"   value="70.112.04">
  <button type="submit">Transfer cart</button>
</form>

Die Felder heißen NEW_ITEM-*, etwa DESCRIPTION, QUANTITY, UNIT, PRICE, CURRENCY, VENDORMAT und MANUFACTMAT, laut der technischen Dokumentation von Unite je auf 255 Zeichen begrenzt, benutzerdefinierte Felder auf bis zu 1.000 (Mercateo/Unite). Der Umfang zählt: Der OCI-RoundTrip deckt nur Katalog und Einkauf ab. Elektronische Bestellungen, Bestätigungen, Lieferavise und Rechnungen gehören nicht zur Spezifikation und laufen über andere Kanäle wie IDocs oder EDI.

Secure OCI nimmt die Zugangsdaten aus dem Browser. In der OCI-5.0-Spezifikation von SAP ruft das Beschaffungssystem zuerst von Server zu Server das Katalog-Backend auf, mit Parametern wie SECURE_AUTH_URL und der Funktion INITIALIZE, die eine SessionId und eine SessionTransmissionId liefert; der Browseraufruf trägt danach nur die Sitzungs-ID (SAP OCI 5.0). Zwei Einschränkungen: OCI 5.0 ist ein SRM-Dokument von 2012 und die neueste gefundene OCI-Spezifikation von SAP, und die aktuelle S/4HANA-Dokumentation für das Katalogszenario in der Instandhaltung nennt weiterhin nur OCI 3.0 und älter als unterstützt (SAP Help). Fragen Sie jeden Käufer, welche Version sein System aufruft.

Was muss der Lieferantenshop umsetzen?

Einen Setup-Endpunkt, eine an die Setup-Anfrage gebundene Sitzung, eine Warenkorb-Rückgabe in beiden Formaten, wenn Sie beide Arten von Käufern bedienen, einen Bestell-Endpunkt für cXML und die Disziplin drumherum: Validierung, Fehlercodes, Logging und Datenqualität. Die meiste Arbeit steckt in Details, die Käufer erst bemerken, wenn sie scheitern.

• Statuscodes: 400 bei fehlendem oder nicht lesbarem Body, 401 bei ungültigem Absender oder Shared Secret und 500 bei unbehandelten Fehlern, als cXML-Status-Element.
• Sitzungsbindung: eine Setup-Anfrage, eine Sitzung, kurze Gültigkeit, und der BuyerCookie serverseitig gespeichert, damit der Warenkorb zur richtigen Bedarfsanforderung zurückkehrt.
• Kennungen: eindeutige payloadIDs auf jeder Nachricht und SupplierPartAuxiliaryID- oder VENDORMAT-Werte, die Ihr Bestellimport später auflösen kann.
• Artikeldatenqualität: Mengeneinheiten, Klassifikationscodes und Vertragsartikel, die das ERP des Käufers akzeptiert. Eine Position, die das ERP nicht buchen kann, wird zum Supportfall.
• Logging: Jedes ein- und ausgehende Dokument pro Sitzung aufbewahren, damit sich eine gescheiterte Bedarfsanforderung nachspielen und erklären lässt.

In mehr als zehn Jahren B2B-Commerce- und PIM-Arbeit mit Spryker und Pimcore habe ich erlebt, dass Punchout die Qualität der Katalogdaten, Einheiten, Artikelnummern, Vertragsartikel und Klassifikationscodes, in einen Fehler verwandelt, den der Kunde in seinem eigenen ERP sieht. Es ist ebenso ein PIM-Thema wie ein Protokollthema; die Datenseite behandelt der Pimcore-ERP-Delta-Sync. Konfigurierte Produkte sind ebenfalls ein häufiger Punchout-Fall, und die Konfiguratorregeln sind ein eigenes Problem, siehe Headless-Produktkonfiguratoren im B2B.

Wer verlangt Punchout?

Großkunden mit SAP Ariba, Coupa, Jaggaer oder Oracle Procurement, SAP-Kunden mit SRM- oder S/4HANA-Katalogen und öffentliche Auftraggeber über Marktplätze. Amazon Business ist ein guter Indikator dafür, wie verbreitet das ist: Es ist mit mehr als 200 E-Procurement-Systemen integriert, beschreibt Punchout als meist erste Integration und betreibt sowohl cXML- als auch OCI-Endpunkte (Amazon Business).

Seine Regeln für Lieferanten sind ein gutes Vorbild für die eigenen: Eine Nutzer-E-Mail ist in der Setup-Anfrage Pflicht, die zurückgegebene Supplier Part Auxiliary ID muss auf der Bestellung zurückkommen, Payload-IDs müssen eindeutig sein, nur neue Bestellungen werden unterstützt, und Bestellungen laufen vor dem Livegang in einem Testmodus (Amazon-Business-Integrationsleitfaden). „Level-2“-Punchout, bei dem das System des Käufers einen durchsuchbaren Index Ihrer Artikel hält und die Setup-Anfrage den Nutzer direkt auf eine Produktseite führt, ist Ariba- und Marktplatz-Terminologie und nicht Teil der OCI-Spezifikation.

Punchout selbst bauen oder ein Gateway kaufen?

Kaufen, wenn viele Käufer auf vielen Beschaffungssystemen schnell angebunden werden müssen; selbst bauen, wenn es wenige große Käufer auf bekannten Systemen gibt und ein Team das Protokoll verantworten kann. Ein Gateway verkauft fertige Anbindungen und die Eigenheiten je Käufer. TradeCentric, früher PunchOut2Go, veröffentlicht für Lieferanten Einstiegspreise von 15.000 bis 50.000 US-Dollar pro Jahr für die Mid-Market-Stufe bei drei Jahren Mindestlaufzeit, Enterprise auf Anfrage, und nennt Stand Oktober 2026 mehr als 220 ERP- und E-Procurement-Integrationen (TradeCentric).

Eine Eigenlösung braucht ehrlich gesagt einen Setup-Endpunkt je Protokoll, Sitzungsverwaltung, Warenkorb-Serialisierung in zwei Formaten, einen Bestellimport, gehärtetes XML-Parsing, Testkonten je Käufer und jemanden, der antwortet, wenn das Einkaufsteam eines Käufers ein Feldmapping ändert. Vergleichen Sie diese laufende Verantwortung mit dem Gateway-Preis für die Zahl an Käufern, die Sie in drei Jahren erwarten, nicht in diesem Jahr.

Egal wie Sie sich entscheiden: Halten Sie die Protokollschicht vom Shop-Kern getrennt. Der Shop sollte eine saubere interne API für „Sitzung für diesen Käufer-Nutzer starten“, „diesen Warenkorb serialisieren“ und „diese Bestellung importieren“ anbieten, und die cXML- oder OCI-Adapter oder das Gateway sitzen außerhalb davon. So erreicht eine Änderung im Beschaffungssystem eines Käufers nicht Ihren Checkout-Code, und ein späterer Wechsel zwischen Eigenbau und Kauf wird ein abgegrenztes Projekt statt einer Neuentwicklung.

Wann ist Punchout das falsche Werkzeug?

Braucht der Käufer nur Ihre Artikel und Preise in seinem System, kann eine gehostete Katalogdatei genügen; tauschen Sie bereits Bestellungen mit einem bekannten Partner aus, ist eine API- oder EDI-Anbindung einfacher. Punchout ist ein Sitzungs- und Bedienprotokoll, kein Datenmodell; es repariert keine Produktdaten und fügt einen Browserschritt hinzu, der in der Umgebung des Käufers funktionieren muss, inklusive gerahmter Sitzungen und ihres Cookie-Verhaltens in aktuellen Browsern.

Agentenprotokolle sind die andere Grenze. UCP, ACP und AP2 setzen einen Software-Agenten voraus, der im Auftrag von jemandem einkauft, mit anderen Nutzdaten und anderer Governance; Punchout setzt einen Menschen im ERP des Käufers voraus. Beides kann nebeneinander bestehen, und der Vergleich steht im Leitfaden zu UCP, ACP und AP2 und in Agentic-Commerce-Readiness für B2B-Shops, wo Punchout als heute unterstützter Weg für Großkunden gilt.

Eine Checkliste für den Punchout-Livegang

1. Ein Testkonto im Beschaffungssystem des Käufers und Zugangsdaten je Käufer besorgen.
2. Beispiel-Payloads für create, edit und inspect und für jedes käuferspezifische Extrinsic sammeln.
3. Die Warenkorb-Rückgabe End-to-End in einem echten Browser testen; ich skripte diesen Rundweg mit Playwright MCP, denn der Formular-POST im Browser ist der Teil, den Unit-Tests nicht abdecken.
4. Prüfen, dass SupplierPartAuxiliaryID oder VENDORMAT bis in die Bestellung und Ihren Bestellimport erhalten bleibt.
5. Fehlerübungen durchspielen: falsches Shared Secret, abgelaufene Sitzung, fehlerhaftes XML, ein DOCTYPE im Payload.
6. Setup-Latenz, gescheiterte Warenkorb-Rückgaben und Bestellungen mit unbekannten Artikeln überwachen.
7. Mit einem Abnahmetest beim Käufer abschließen, der eine echte Bedarfsanforderung durch die Freigabe bringt.

Wenn Sie einem B2B-Shop Punchout hinzufügen oder zwischen Gateway und eigener Schicht entscheiden, sehen Sie sich meine B2B-E-Commerce-Arbeit an.

Quellen

1. cXML.org (cXML 1.2.071)
2. PunchOutCommerce: cXML PunchOutSetupRequest
3. PunchOutCommerce: cXML PunchOutOrderMessage
4. PunchOutCommerce: OCI RoundTrip
5. SAP: Open Catalog Interface 5.0
6. SAP Help: OCI catalogs in S/4HANA Plant Maintenance
7. Mercateo/Unite: technical information on the OCI interface
8. Amazon Business: punchout integration instructions
9. Amazon Business: punchout
10. TradeCentric: pricing
11. OWASP: XML External Entity Prevention Cheat Sheet