Punchout-Kataloge: OCI & cXML für B2B-Shopware-Shops

Wer im B2B-Geschäft 2026 einen Großkunden verlieren will, muss nur eines tun: ihn weiter per Fax, E-Mail oder telefonisch bestellen lassen. Professionelle Einkaufsabteilungen arbeiten längst aus ihrem ERP oder E-Procurement-System heraus und erwarten, dass Lieferanten sich nahtlos in diese Prozesse einklinken. Die Brücke zwischen Einkaufssystem und Lieferantenshop heißt Punchout – und die zwei Formate, die diese Brücke tragen, heißen OCI und cXML. In diesem Guide zeigen wir, wie Sie Ihren B2B-Shopware-Shop an SAP Ariba, Coupa, Onventis und andere Plattformen anbinden – technisch sauber, DSGVO-konform und wirtschaftlich sinnvoll.

Warum B2B-Käufer 2026 nicht mehr bestellen wie früher

Professionelle Einkaufsabteilungen bestellen heute aus dem eigenen System heraus: aus dem ERP, aus einer E-Procurement-Suite oder über einen angebundenen Marktplatz. Für Lieferanten verschiebt sich damit der entscheidende Berührungspunkt – weg von der Angebotsmail, hin zum Katalog, der im Einkaufssystem des Kunden sichtbar ist. Wer dort nicht auftaucht, steht bei der Bedarfsanforderung faktisch nicht zur Auswahl, auch wenn Sortiment und Preis stimmen.

Parallel dazu hat sich das Verhalten der Buyer verändert. Wer beruflich einkauft, erwartet dieselbe Selbstbedienung wie privat: Sortiment durchsuchen, Verfügbarkeit sehen, die eigenen Konditionen angezeigt bekommen und den Warenkorb ohne Rückfrage in den eigenen Genehmigungsprozess übergeben. Telefon und Fax bleiben für den Sonderfall – für die Abweichung, nicht für die Regel.

• Echtzeit-Verfügbarkeit gilt im Einkauf als Grundvoraussetzung, nicht als Komfortfunktion – ein Katalog ohne Bestandsangabe erzeugt Rückfragen statt Bestellungen
• Manuell abgetippte Bestellpositionen sind eine häufige Ursache für Reklamationen in der Auftragserfassung – jede Zeile, die ein Mensch überträgt, ist eine mögliche Fehlerquelle
• Kundenindividuelle Preise und Staffeln gehören in den Katalog des Buyers, nicht erst in die Auftragsbestätigung – sonst wird aus der Bestellung wieder eine Verhandlung

Unser Artikel zum B2B-Self-Service-Portal mit Shopware 6 beschreibt diese Basis-Erwartungen im Detail. Punchout ist dabei die nächste Ausbaustufe: Während ein Self-Service-Portal dem Buyer den direkten Weg in Ihren Shop öffnet, verbindet Punchout Ihren Shop nahtlos mit dem bereits bestehenden E-Procurement-System des Buyers – so, dass der Einkäufer nicht einmal merkt, dass er Ihr System betritt.

Was Punchout eigentlich ist (und wofür OCI/cXML stehen)

Der Begriff Punchout beschreibt technisch einen Vorgang, bei dem ein Einkäufer aus seinem eigenen E-Procurement-System heraus nicht etwa auf einen statischen Katalog klickt, sondern stattdessen live in den Webshop des Lieferanten „punchen“ – ihn also als eingebettete Katalogquelle nutzt. Der Buyer sieht dort kundenindividuelle Preise, aktuellen Bestand und sein tatsächliches Sortiment, füllt einen Warenkorb und sendet diesen per standardisiertem Protokoll zurück ins eigene Einkaufssystem. Dort durchläuft der Cart die hauseigenen Freigabe- und Budget-Workflows, bevor schließlich eine Bestellung an den Lieferanten zurückgeht.

Hinter den Kulissen arbeiten zwei dominante Standards: OCI (Open Catalog Interface) wurde ursprünglich von SAP entwickelt und ist in Europa, insbesondere im deutschsprachigen Raum, der De-facto-Standard für ERP-getriebene Einkaufsprozesse. cXML (commerce eXtensible Markup Language) wurde von Ariba vorangetrieben und ist in Nordamerika sowie bei Plattformen wie Coupa und Oracle Procurement Cloud verbreitet. Wer international oder branchenübergreifend B2B betreibt, muss in der Praxis meistens beide unterstützen – ein reiner cXML- oder ein reiner OCI-Stack genügt selten.

Der Markt ist fragmentiert, aber keineswegs exotisch: Allein ein einzelner Integrationsanbieter weist eine Anbindung an über 220 Plattformen aus – ERP-Systeme und E-Procurement-Lösungen zusammengenommen (TradeCentric). Für Lieferanten heißt das: Die Zahl der möglichen Gegenstellen ist groß, die Zahl der Protokolle dahinter aber klein. Wer OCI und cXML sauber beherrscht, deckt den überwiegenden Teil der Anfragen ab, ohne für jede Plattform von vorn zu beginnen.

OCI vs. cXML im direkten Vergleich

Ohne die Unterschiede verstanden zu haben, lässt sich keine saubere Punchout-Strategie bauen. Die folgende Gegenüberstellung fasst die Praxis-Unterschiede zusammen, die bei Shopware-Anbindungen regelmäßig auftreten:

Der zentrale praktische Unterschied: OCI transportiert die Warenkorbdaten über ein klassisches HTML-Formular zurück, was schnell implementierbar ist, aber Limits bei komplexen Zusatzfeldern kennt. cXML hingegen ist strukturiert, validierbar und trägt Metadaten wie Lieferadressen, Kostenstellen und Steuerdaten sauberer – braucht dafür aber eine ordentliche Schema-Behandlung und klares Error-Handling auf beiden Seiten.

Wie ein Punchout-Vorgang technisch abläuft

Der oben abgebildete Flow zeigt die vier Stationen eines Punchout-Vorgangs. Im Detail läuft jede Transaktion in folgenden Schritten ab – unabhängig davon, ob OCI oder cXML verwendet wird:

1. Setup-Request: Der Einkäufer klickt in seinem E-Procurement-System (z. B. SAP Ariba, Coupa, Onventis) auf den Lieferanten-Katalog. Das System sendet eine authentifizierte Anfrage an den Shopware-Shop – bei OCI per Form-POST mit HOOK_URL, bei cXML als PunchOutSetupRequest-XML.
2. Authentifizierung und Session-Aufbau: Der Shop validiert die Credentials (bei cXML per SharedSecret, bei OCI meist Username/Passwort), identifiziert den Buyer, lädt dessen Kundengruppe, Kundenpreise und Kataloge und erzeugt ein einmaliges Session-Token.
3. User browses: Der Einkäufer wird per HTTP-Redirect (oder eingebettetem iframe) in den Shopware-Shop geführt. Er sieht das B2B-Sortiment mit seinen individuellen Konditionen – ohne zu merken, dass er ein anderes System betritt.
4. Cart-Zusammenstellung: Der Buyer legt Produkte in den Warenkorb wie in jedem anderen Shop. Er kann dabei Quick-Order per SKU, Staffelpreise, Budgets und alle B2B-Funktionen nutzen, sofern sie freigeschaltet sind – inklusive moderner Express-Checkout-Mechaniken für wiederkehrende Bestellungen.
5. PO-Return: Statt einer Bestellung löst der Checkout-Button einen Cart-Return aus – die Warenkorbdaten werden als HTML-Form-POST (OCI) bzw. als PunchOutOrderMessage-XML (cXML) zurück an die HOOK_URL geschickt.
6. Freigabe im Buyer-System: Im E-Procurement durchläuft der Cart die hauseigenen Workflows – Budget-Check, Kostenstellen-Zuweisung, Manager-Genehmigung. Erst nach diesem Prozess entsteht eine echte Bestellung.
7. OrderRequest an den Supplier: Die finale Bestellung läuft dann erneut an den Lieferanten zurück – typischerweise als cXML OrderRequest, EDI-Dokument oder direkt via ERP-Schnittstelle. Erst jetzt entsteht ein Verkaufsauftrag im ERP-System.

Wo Punchout die Prozesskosten senkt

Punchout ist kein Selbstzweck, sondern zahlt auf beiden Seiten der Beschaffung ein. Auf der Buyer-Seite entfällt das Abtippen: Artikelnummer, Menge, Preis und Beschreibung kommen strukturiert aus dem Shop zurück und landen ohne Zwischenschritt in der Bedarfsanforderung. Auf der Lieferantenseite entfällt die manuelle Auftragserfassung, weil die Bestellung als strukturierte Nachricht ankommt statt als PDF im Postfach.

Die zweite Wirkung liegt hinter der Bestellung: Weil Positionen, Preise und Zusatzfelder wie Kostenstelle oder Projektnummer schon im Warenkorb stehen, entfallen Rückfragen zwischen Einkauf, Buchhaltung und Vertrieb. Abweichungen zwischen Bestellung, Lieferschein und Rechnung entstehen typischerweise dort, wo Daten ein zweites Mal von Hand erfasst werden – genau diese Stelle fällt im Punchout-Ablauf weg.

Für Lieferanten ist das ein Zeitvorteil, kein Zwang: Wer den Katalog früh bereitstellt, steht im Einkaufssystem, bevor überhaupt eine Anfrage herausgeht. Wer wartet, bekommt die Anbindung irgendwann als Anforderung aus einer Ausschreibung – dann mit fremdem Zeitplan, fremdem Format und ohne Spielraum bei den Zusatzfeldern.

Maverick Buying eindämmen mit Catalog-Compliance

Ein Treiber für Punchout-Projekte auf der Buyer-Seite ist die Eindämmung von Maverick Buying – also Bestellungen, die an den zentralen Einkaufsprozessen vorbei laufen und damit weder die verhandelten Konditionen nutzen noch die Compliance-Anforderungen erfüllen. Für den Einkauf ist das doppelt teuer: Die ausgehandelten Rabatte greifen nicht, und die Ausgabe taucht in keiner Auswertung an der erwarteten Stelle auf.

Ein Katalog im Einkaufssystem wirkt hier als stiller Lenker: Was im Punchout steht, ist freigegeben, preislich abgestimmt und buchhalterisch zugeordnet. Alles andere kostet den Einkäufer zusätzliche Schritte und zusätzliche Unterschriften. Compliance entsteht damit nicht über Vorschriften, sondern über den bequemeren Weg.

Technisch entscheidend ist, dass der Shopware-Shop nur die für diesen Buyer freigegebenen Produkte, Preise und Staffeln anzeigt. Dafür braucht es eine saubere Verknüpfung mit den B2B-Preisstrategien und einen klaren Produkt-Whitelist-Mechanismus. Ohne diese Komponenten wird ein Punchout-Katalog zum Compliance-Risiko – mit den richtigen Einstellungen wird er zur Durchsetzungshilfe für beide Seiten.

Punchout in Shopware 6 mit den B2B Components

Shopware liefert die B2B-Funktionen in den kostenpflichtigen Plänen als B2B Components aus, nicht in der Community Edition: Quick Order, Rollen- und Rechtemodell, Freigaben, Angebote, Bestelllisten und Budgets. Für Punchout ist das die natürliche Grundlage, weil der Buyer aus dem Einkaufssystem bereits als bekannter Kunde mit eigener Kundengruppe ankommt. Welche Bausteine in Ihrer Installation zur Verfügung stehen, hängt vom eingesetzten Shopware-Stand ab – das klären wir vor der Konzeption anhand der Release Notes des Herstellers.

Dass Shopware im B2B ernst genommen wird, zeigt eine externe Bewertung: Im Paradigm B2B Combine 2026 (Midmarket Edition) erhielt das System 8 Gold- und 3 Silbermedaillen und damit eine Auszeichnung in 11 von 12 bewerteten Kategorien (Shopware). Bewertet wurden dabei 12 Anbieter über 12 Kategorien anhand von 38 gewichteten Kriterien (Shopware). Für ein Punchout-Projekt heißt das vor allem: Die Basis trägt, die eigentliche Arbeit liegt in der Anbindung.

In der Praxis lässt sich Punchout in Shopware 6 nicht einfach per Plugin aktivieren – es ist ein mehrschichtiges Thema: Der Setup-Request muss authentifiziert werden, der Buyer muss einer Shopware-Kundengruppe zugeordnet, seine Session muss in einer URL eingebettet und schließlich der Cart-Return über einen dedizierten Endpoint ausgeliefert werden. All das passiert im Zusammenspiel mit den bestehenden Shopware-APIs und lässt sich auf der Basis der B2B Components sauber abbilden.

Integration mit SAP, Microsoft Dynamics und ERP

Ein Punchout-Flow endet nicht mit dem Cart-Return. Damit die Bestellung tatsächlich wirtschaftlich abgewickelt wird, muss die OrderRequest sauber ins ERP fließen – und zwar bidirektional: Preise und Kundendaten aus dem ERP in den Shop, Bestellungen und Retouren zurück ins ERP. Verbreitete Systeme im DACH-Raum sind dabei SAP Business One, Microsoft Dynamics 365 sowie JTL-Wawi für mittelständische Händler.

Die Realität ist dabei selten rosig: ERP-Integrationsprojekte im Mittelstand ziehen sich, weil Stammdaten, Preislogik und Freigabewege selten so sauber im System stehen, wie das Organigramm vermuten lässt. Für Dynamics 365 Finance & Operations gilt zudem, dass die Preisfindung für kundenspezifische B2B-Konditionen konfiguriert werden muss – mit dem Standard allein ist sie selten vollständig abgebildet, und genau diese Konditionen sollen im Punchout-Katalog erscheinen.

Hinzu kommt die E-Rechnungspflicht: Das Umsatzsteuergesetz definiert eine elektronische Rechnung als Rechnung, die in einem strukturierten elektronischen Format ausgestellt, übermittelt und empfangen wird und eine elektronische Verarbeitung ermöglicht (UStG § 14). Sind leistender Unternehmer und Leistungsempfänger im Inland ansässig, ist sie auszustellen (UStG § 14). Übergangsweise darf für Umsätze bis zum 31. Dezember 2026 weiter auf Papier abgerechnet werden, bei einem Vorjahresumsatz von höchstens 800.000 Euro sogar bis zum 31. Dezember 2027 (UStG § 27). Ein Punchout-Projekt ist damit oft der richtige Moment, die gesamte Lieferanten-Buyer-Kette durchzudenken – vom Katalog bis zur DATEV-Schnittstelle (Blog-Beitrag) in der Buchhaltung.

Top-E-Procurement-Plattformen in DACH

Wer im deutschsprachigen Raum B2B betreibt, stößt regelmäßig auf dieselben E-Procurement-Plattformen. Ein kurzer Überblick über die relevanten Systeme – als Orientierung, nicht als Empfehlung:

• SAP Ariba / SAP Business Network: Im DACH-Mittelstand und in Konzernen eine häufig anzutreffende Gegenstelle. OCI und cXML werden beide unterstützt.
• Coupa: Im Enterprise-Segment stark vertreten, die Anbindung läuft praktisch immer über cXML.
• JAGGAER: Verbreitet im öffentlichen Einkauf und in Konzernen mit komplexen Supplier-Netzwerken.
• Onventis (Stuttgart): Cloud-Einkaufsplattform mit Schwerpunkt im deutschen Mittelstand, in der Praxis meist OCI-geprägt.
• Unite / Mercateo: Als Aggregator oft die einfachste Einstiegsoption für Lieferanten ohne ERP-Punchout-Erfahrung.
• Oracle Procurement Cloud: Standardisierter cXML-Stack, in DACH vor allem in Tochtergesellschaften US-amerikanischer Konzerne vertreten.

Bei neuen Projekten raten wir dazu, mit dem System zu beginnen, das Ihr größter Buyer bereits einsetzt – meistens ergeben sich daraus die wirtschaftlich sinnvollsten Quick Wins. Wer bewusst neue Kundensegmente erschließen will, sollte dagegen mit Onventis oder SAP Business Network starten, da diese Plattformen im DACH-Mittelstand verbreitet sind.

Implementierung in 5 Schritten

Ein Punchout-Projekt lässt sich nicht im Wochentakt abwickeln, aber es ist auch kein Mammutprojekt. Die folgende Schritt-für-Schritt-Anleitung zeigt, wie wir es bei XICTRON typischerweise angehen:

1. Anforderungs-Workshop: Welche Buyer sind relevant? Welche Plattformen nutzen sie? Welche Artikel sollen im Katalog erscheinen? Welche Preise und Staffeln gelten? Welche Zusatzfelder (Kostenstellen, Projektnummern) muss der Cart-Return transportieren? Diese Phase ist entscheidend – Fehler hier ziehen sich durch das gesamte Projekt.
2. Prototyp und Format-Entscheidung: OCI oder cXML? Welche Version? Welche Authentifizierung? Wir bauen einen minimalen Prototyp mit dem größten Ziel-Buyer-System, um die Datenstrukturen zu validieren – bevor der Produktiv-Code entsteht.
3. Shopware-Anbindung und B2B Components Konfiguration: Kundengruppen anlegen, Preisregeln hinterlegen, Sortimente zuweisen, Session-Handling und SSO-Flow bauen. Die B2B Components von Shopware 6 bilden dafür die Basis – Custom-Development erfolgt nur gezielt für die Punchout-spezifischen Endpoints.
4. ERP-Bidirektion und OrderRequest: Die Verbindung zu SAP Business One, Microsoft Dynamics oder einem anderen ERP. Preise, Bestände und Kundendaten aus dem ERP, Bestellungen zurück ins ERP – je nach System sind das ein bis mehrere Schnittstellen.
5. End-to-End-Tests, Pilot und Rollout: Echte Testbestellungen mit einem Pilot-Buyer, Fehlerbilder und Edge Cases abfangen (z. B. Session-Timeout, doppelte Cart-Returns), dann schrittweises Ausrollen auf weitere Buyer.

Wie XICTRON Ihre B2B-Anbindung umsetzt

Als B2B-E-Commerce-Spezialisten mit Sitz in Niedersachsen begleiten wir Mittelständler und Konzerntöchter beim kompletten Weg von der Konzeption bis zum produktiven Punchout-Flow. Wir bringen sowohl die technische Expertise für Shopware-Integrationen mit – inklusive SAP, Microsoft Dynamics und anderer ERP-Systeme – als auch das Verständnis für die Einkaufsprozesse Ihrer Buyer.

Unser Ansatz bleibt dabei pragmatisch: Wir bauen keine Punchout-Lösungen für den Schaukasten, sondern für messbare Effizienzgewinne. Gut geplante Punchout-Projekte rechnen sich am ehesten, wenn auch die B2B-Preisstrategien, ERP-Prozesse und der Produktkonfigurator sauber aufeinander abgestimmt sind. Weitere strategische Aspekte – etwa wie Sie mit B2B-Digitalisierung im Vertrieb arbeiten – beleuchten wir in angrenzenden Artikeln.

Häufig gestellte Fragen

Punchout ist 2026 kein Nice-to-have mehr, sondern die Eintrittskarte in professionelle B2B-Einkaufsprozesse. Wer seinen Shopware-Shop sauber an OCI und cXML anbindet, wird für die Einkaufsabteilungen seiner Buyer leicht bestellbar – und gewinnt gleichzeitig Zeit in der eigenen Auftragserfassung. Wir unterstützen Sie bei allen Schritten, von der ersten Setup-Request bis zur produktiven OrderRequest.