Punchout and OCI Catalogs for B2B Procurement

Punchout describes an integration pattern in which a buyer, from within their procurement system, "punches out" into a supplier's online store with a single click, assembles a shopping cart there, and then automatically transfers that cart back into their own system. The crucial difference from a normal web-store visit: the buyer never really leaves their familiar purchasing environment. The order then runs through the customer's internal approval workflow, and only the released order is submitted to the supplier as a binding purchase order.

For the buyer, this has a clear advantage: they always see current product data, customer-specific prices, and real availability, instead of working with an outdated static catalog. For the supplier, a punchout connection means becoming part of the digital supplier list of large purchasing organizations -- and thus becoming eligible for automated orders in the first place. In many tenders, a working interface connection has become a must-have rather than a nice-to-have.

Punchout should be distinguished from the classic static catalog. With a static catalog, the supplier delivers its item data once or periodically as a file (for example in BMEcat format) to the procurement system, where it is stored locally and searched. This works for a manageable, rarely changing assortment. As soon as prices become differentiated, assortments large, and availability dynamic, however, the static catalog reaches its limits -- and punchout becomes the more sensible option.

The Open Catalog Interface (OCI) was developed by SAP and is by far the most widespread punchout standard in German-speaking markets, because many industrial and trading companies as well as public authorities use SAP-based procurement solutions (SAP). OCI is deliberately lightweight: data is transferred not via complex XML messages but via simple HTML form fields exchanged between the systems by HTTP POST (SAP OCI specification). This very simplicity helped OCI achieve its broad adoption. The German procurement association BME lists punchout and electronic catalogs as established building blocks of modern e-procurement processes (BME).

The flow begins with the so-called hook URL call. The procurement system calls an agreed URL of the supplier store, passing login credentials as well as a return address (the HOOK_URL). The store authenticates the buyer, assigns them to the correct customer account with the matching prices, and displays its catalog. When the buyer assembles their cart and clicks "transfer cart", the store sends the line items back to the HOOK_URL via predefined field names such as NEW_ITEM-DESCRIPTION, NEW_ITEM-PRICE, or NEW_ITEM-QUANTITY. The procurement system reads these fields and populates its purchase requisition.

Today, versions OCI 4.0 and OCI 5.0 are particularly relevant (SAP OCI specification). OCI 5.0 adds, among other things, a cleaner separation of validation and detail calls as well as additional fields for contract references. In practice, many customer systems still require OCI 4.0, so a connection should ideally serve both versions (project experience). Which fields are mandatory and which optional depends on the specific target system -- a binding field mapping with the customer's procurement team is therefore the most important first step in any OCI integration.

Regardless of the specific standard, every punchout session follows the same basic pattern. It is worth tracing the flow once in full, because all technical and organizational requirements can be derived from it. The following steps describe a typical session using cXML as an example, which is used by SAP Ariba and Coupa; the OCI flow runs analogously.

It is important to distinguish between the cart handover and the actual order. With punchout, only a cart proposal is initially returned -- not yet a purchase order. The binding order is created only after internal release at the customer and often runs through a separate ordering channel. This separation is deliberate, because large organizations must approve orders above certain value thresholds in multiple stages. A well-designed B2B portal accounts for these processes from the outset.

The greatest added value of punchout over the static catalog lies in personalization. As soon as the buyer arrives in the store via the punchout session, the store knows which customer they belong to -- and can display exactly the assortment, terms, and prices agreed for that customer. In B2B, these are often complex structures: framework-contract prices, volume-based tier pricing, customer-specific item numbers, and approved sub-assortments.

In practice, this means the punchout connection must be tightly interlocked with the store's price and customer logic. Customer-specific prices and tiers are a demanding topic in their own right -- how they can be modeled in Shopware is described in detail in our article on B2B price lists and tier pricing in Shopware. For the punchout session, it is crucial that the transferred prices exactly match the contractually agreed ones, because they flow unchecked into the customer's purchase requisition.

The assortment can also be controlled per customer. Some purchasing organizations only allow their buyers an approved subset of the supplier's assortment -- for example to avoid proliferation or to comply with compliance requirements. A well-implemented customer portal makes it possible to maintain such customer-specific catalogs centrally, instead of running a separate store instance for each customer. Customer part numbers should be translated in both directions, so the customer sees "their" number while the supplier ERP still receives its own leading item number.

Because sensitive pricing data and, ultimately, binding orders flow through the punchout session, securing the connection is a central concern. Germany's Federal Office for Information Security (BSI) recommends, in its IT-Grundschutz framework, consistently encrypted transmission and unambiguous authentication of communicating systems (BSI). For punchout, this concretely means: all communication runs over HTTPS with current TLS, and both sides authenticate via a shared secret or certificates.

With cXML, authentication is implemented via sender, From, and To credentials in the document header, supplemented by a shared secret (cXML standard). With OCI, login typically happens via username and password passed in the hook URL call -- which is why HTTPS is absolutely indispensable here, so that this data does not travel across the network in clear text (BSI). In both cases, session tokens should be valid only for a limited time and become invalid once the session is completed or expires.

Additional protective measures have proven their worth: IP whitelisting restricts the permitted senders to the known address ranges of the procurement systems, a signature check on returned carts prevents tampering, and dedicated logging of all punchout operations simplifies troubleshooting and meets documentation obligations. Because the buyers' personal data is processed, the punchout connection also belongs in the record of processing activities under the GDPR -- a point easily overlooked amid the technical enthusiasm.

Shopware in its open-source variant brings the building blocks needed for a punchout connection: a flexible plugin system, a REST and Store API, and an extensible concept for customer groups and prices. The punchout logic itself is usually implemented as a dedicated plugin that processes incoming setup requests, manages the session, and generates the cart handover in the respective format (OCI fields or cXML).

A typical entry point is a controller that receives the procurement system's hook URL. The following example sketches, in simplified form, how such a punchout login controller can be structured in a Shopware plugin -- the actual business logic (customer determination, price resolution, session handling) is deliberately omitted here.

The cart is then returned via a form posted to the HOOK_URL (OCI) or via a PunchOutOrderMessage sent to the browser form-post URL (cXML). It is important that each line item is fully described: item number, description, quantity, unit price, currency, unit of measure, and where applicable the customer item number. Missing or incorrectly formatted fields are the most common reason a cart does not arrive correctly in the procurement system. For interface integration, detailed logging of each transferred line item is therefore advisable.

The downstream processing of the actual order -- that is, the receipt of the released purchase order -- often runs via EDI or a cXML OrderRequest interface and ends up in the ERP. This closes the loop from catalog view through to order processing. We explore which architectural patterns suit such end-to-end integrations in our services around ERP connectivity and in the accompanying technical articles in the blog.

Punchout projects rarely fail on the fundamental technology, but on details in the interplay of the systems. A recurring problem is field mapping: if the procurement system expects a mandatory field that the store does not populate or populates differently, the cart arrives incomplete in the purchase requisition. In our experience this is the most common cause of failed initial connections (project experience). A binding mapping document agreed between supplier and the customer's procurement team prevents exactly that.

A second classic concerns price formats and units of measure. Different decimal places, deviating currency specifications, or confused units of measure (piece versus packaging unit) lead to discrepancies between the cart and the later order. Clear normalization of the data before handover helps here. Session timing is also tricky: if a session expires while the buyer is still browsing the catalog, the cart handover fails. Generously sized but still limited session lifetimes are a sensible compromise between convenience and security.

Finally, the testing effort is frequently underestimated. Each target system -- whether SAP Ariba, Coupa, or an in-house SRM -- behaves slightly differently. A punchout connection should therefore always be tested in a customer test environment before it goes live. Since the customers' procurement systems are usually not freely accessible, close coordination with the customer's IT during the test phase is critical to success. In our e-commerce consulting, we plan these coordination loops in from the start.

A punchout connection involves effort -- it pays off as soon as one or more major customers handle their orders through a central procurement system. Typical scenarios from such projects are shown in our references. The economic benefit arises on both sides: the customer saves manual entry steps and reduces maverick buying, while the supplier lowers its order-processing costs and ties the customer more closely to its assortment. Procurement studies regularly put the cost of a manually processed order at a clearly double-digit euro amount per order (Hackett Group) -- automation via punchout reduces this share considerably.

Punchout is also strategically relevant: according to Gartner, business customers are increasingly shifting budget to digital self-service channels, because a growing share of the younger buyer generation prefers digital ordering paths (Gartner). Suppliers that are not present in their customers' digital procurement processes risk being overlooked at the next supplier consolidation. The industry association Bitkom has pointed out for years that the digitization of business processes is a key competitive factor for the German mid-market (Bitkom).

The cost of a punchout connection depends heavily on the number of target systems to be connected and the complexity of the pricing and assortment logic. A first OCI connection to a single procurement system is manageable; with each additional system and each customer-specific peculiarity, the effort increases. As a rule, the investment amortizes through the manual handling saved and the additional order volume of the connected customers. A robust profitability calculation is best drawn up jointly in an initial consultation based on your specific customer structure.