Punchout and OCI: Your Shop Inside Your Customers' Procurement System

The term punchout describes the process by which a buyer "punches out" of their own procurement system directly into an external supplier's shop. There they browse the catalogue, add items to their cart and return to their system — the populated cart is automatically handed back as a structured data record. The procurement system can then immediately convert the transferred line items into a purchase requisition (PR) or a purchase order (PO).

OCI (Open Catalog Interface) is the most widely used punchout standard in Germany and the DACH region, originally developed by SAP. cXML (Commerce Extensible Markup Language) is the corresponding international standard, used primarily in the US and on platforms such as Ariba, Coupa and Jaggaer. Both standards define how the start parameters (URL, credentials, session token) are passed from the procurement system to the shop and in what format the cart is returned. We support both protocols fully and choose the appropriate one based on your customer's requirements.

On paper, punchout sounds straightforward. In practice, a reliable implementation requires the precise interplay of a Shopware plugin, session management, pricing logic and cart serialization. The following overview covers all six stages of a typical OCI punchout transaction and what happens technically at each step.

A punchout integration consists of several technical layers that must be tightly coordinated. We take responsibility for the complete implementation — from Shopware plugin development and protocol configuration to the acceptance test with your customer's actual procurement system. The following is the complete service scope.

Punchout, EDI and a classic B2B customer portal are three different ways to digitize ordering processes with business customers. Which channel is right for which customer depends on the customer's system landscape, order volume and contractual agreements. In practice, all three channels are often active simultaneously — different customers use different access routes.

A successful punchout implementation requires both your Shopware shop and your customer's procurement system to meet certain prerequisites. On the shop side, our punchout plugin handles the entire protocol processing. On the customer side, we need access to the configuration interface of the procurement system or cooperation with the customer's IT team. From project experience, coordinating with the customer's IT team typically takes three to six weeks when all parties are actively engaged.

Punchout is rarely a standalone project. For the cart return to contain correct prices and up-to-date product master data, the punchout catalogue must be fed by the same data sources as your regular B2B portal. This means the punchout pricing logic and the portal pricing logic share the same ERP connector. Only then can you be certain that a buyer sees the same price in the punchout catalogue as in the direct customer portal.

At the same time, orders placed via punchout flow into the same order processing pipeline as all other sales channels. The ERP receives the order regardless of whether the buyer ordered via punchout, through the portal, by EDI or by phone. This cross-channel consistency is a central quality criterion of professional B2B integrations. As part of our interface development, we ensure that all order channels operate on the same data foundation.