Punchout Catalogs: OCI & cXML for B2B Shopware Shops

If you want to lose a major B2B customer in 2026, there is an easy way: keep forcing them to order by fax, email or phone. Professional procurement teams have long been working out of their ERP or e-procurement systems and expect suppliers to plug seamlessly into those workflows. The bridge between the buyer's procurement system and the supplier's shop is called punchout – and the two formats carrying that bridge are OCI and cXML. In this guide we show how to connect your B2B Shopware shop to SAP Ariba, Coupa, Onventis and other platforms – in a technically clean, GDPR-friendly and economically sensible way.

Why B2B buyers in 2026 do not order the old way anymore

Professional procurement teams order out of their own systems today: out of the ERP, out of an e-procurement suite or via a connected marketplace. For suppliers the decisive touchpoint shifts – away from the quotation email and towards the catalog that is visible inside the customer purchasing system. If you are not there, you are effectively not on the shortlist when a requisition is raised, even when range and price are right.

Buyer behavior has changed in parallel. People who purchase professionally expect the same self-service they know privately: browse the range, see availability, get their own terms displayed and hand the cart over to their own approval process without asking anyone. Phone and fax remain the exception – for the edge case, not the standard.

• Real-time availability counts as a basic requirement in procurement, not as a nice-to-have – a catalog without stock data creates questions instead of orders
• Manually retyped order lines are a common cause of complaints in order entry – every line a human transfers is a possible source of error
• Customer-specific prices and volume tiers belong in the buyer catalog, not in the order confirmation – otherwise the order turns back into a negotiation

Our article on the B2B self-service portal with Shopware 6 describes these baseline expectations in detail. Punchout is the next evolution: while a self-service portal opens a direct path into your shop, punchout connects your shop seamlessly into the buyer's existing e-procurement system – so that the buyer does not even notice they are entering another system.

What punchout actually is (and what OCI/cXML stand for)

Technically, the term punchout describes a process where a buyer, from inside their own e-procurement system, does not click a static catalog but instead punches out live into the supplier's web shop – using it as an embedded catalog source. The buyer sees customer-specific pricing, current stock and their real assortment, fills a cart and sends that cart back to their own procurement system via a standardized protocol. There the cart goes through the internal approval and budget workflows before a final purchase order is actually sent to the supplier.

Behind the scenes, two dominant standards do the work: OCI (Open Catalog Interface) was originally developed by SAP and is the de facto standard for ERP-driven procurement in Europe and especially the DACH region. cXML (commerce eXtensible Markup Language) was pushed by Ariba and is widespread in North America and on platforms like Coupa and Oracle Procurement Cloud. Anyone running B2B internationally or across industries typically has to support both – a pure cXML or pure OCI stack is rarely enough.

The market is fragmented but not exotic: a single integration provider alone lists connections to more than 220 platforms – ERP systems and e-procurement solutions combined (TradeCentric). For suppliers that means: the number of possible counterparts is large, the number of protocols behind them is small. Anyone who handles OCI and cXML properly covers the majority of requests without starting from scratch for every platform.

OCI vs. cXML in direct comparison

Without understanding the differences, you cannot build a clean punchout strategy. The following table summarizes the real-world differences we see time and again in Shopware integrations:

The key practical difference: OCI transports cart data back through a classic HTML form, which is quick to implement but has limits with complex additional fields. cXML is structured, validatable and carries metadata such as delivery addresses, cost centers and tax data more cleanly – but in return needs proper schema handling and clear error management on both sides.

How a punchout transaction works technically

The flow shown above illustrates the four stations of a punchout process. In detail, every transaction runs through the following steps – regardless of whether OCI or cXML is used:

1. Setup request: The buyer clicks the supplier catalog inside their e-procurement system (for example SAP Ariba, Coupa, Onventis). That system sends an authenticated request to the Shopware shop – for OCI as a form POST with HOOK_URL, for cXML as a PunchOutSetupRequest XML document.
2. Authentication and session setup: The shop validates the credentials (SharedSecret for cXML, typically username/password for OCI), identifies the buyer, loads their customer group, customer pricing and assortment, and generates a one-time session token.
3. User browses: The buyer is redirected (or embedded via iframe) into the Shopware shop. They see the B2B assortment with their individual terms – without noticing they just entered another system.
4. Cart assembly: The buyer adds products to the cart like in any other shop. They can use quick order via SKU, volume pricing, budgets and all B2B features as long as these are enabled – including modern express checkout mechanics for recurring orders.
5. PO return: Instead of triggering an order, the checkout button triggers a cart return – the cart data is sent back to the HOOK_URL as an HTML form POST (OCI) or as a PunchOutOrderMessage XML (cXML).
6. Approval in the buyer system: Inside e-procurement the cart goes through the internal workflows – budget check, cost center assignment, manager approval. A real order only emerges after this process.
7. OrderRequest back to the supplier: The final order is then sent back to the supplier again – typically as a cXML OrderRequest, an EDI document or directly via ERP integration. Only at this point does a sales order appear in the ERP system.

Where punchout cuts process cost

Punchout is not an end in itself, it pays off on both sides of the procurement chain. On the buyer side the retyping disappears: article number, quantity, price and description come back from the shop in a structured form and land in the requisition without an intermediate step. On the supplier side manual order entry disappears, because the order arrives as a structured message instead of a PDF in a mailbox.

The second effect sits behind the order: because line items, prices and additional fields such as cost center or project number are already in the cart, the back-and-forth between procurement, accounting and sales falls away. Discrepancies between order, delivery note and invoice typically arise where data is entered by hand a second time – and that is exactly the step the punchout flow removes.

For suppliers this is a timing advantage, not an obligation: whoever provides the catalog early is in the purchasing system before a request even goes out. Whoever waits receives the integration at some point as a requirement out of a tender – with someone else timeline, someone else format and no room to negotiate the additional fields.

Curbing maverick buying through catalog compliance

One driver for punchout projects on the buyer side is containing maverick buying – orders that bypass the central procurement process and therefore neither use the negotiated terms nor meet compliance requirements. For procurement that is expensive twice over: the negotiated discounts do not apply, and the spend does not show up where the reporting expects it.

A catalog inside the purchasing system acts as a quiet steering mechanism: whatever sits in the punchout is approved, priced and assigned to an account. Everything else costs the buyer extra steps and extra signatures. Compliance is then created by the more convenient path, not by a policy document.

Technically the point is that the Shopware shop only shows products, prices and volume tiers released for that specific buyer. That requires a clean link to the B2B pricing strategies and a clear product whitelist mechanism. Without these, a punchout catalog becomes a compliance risk – with the right configuration it becomes an enforcement tool for both sides.

Punchout in Shopware 6 with the B2B Components

In its paid plans, not in the Community Edition, Shopware ships the B2B functions as B2B Components: quick order, role and permission model, approvals, quotes, order lists and budgets. For punchout that is the natural foundation, because the buyer arrives from the purchasing system as a known customer with their own customer group. Which building blocks are available in your installation depends on the Shopware release in use – we clarify that before the concept phase, against the vendor release notes.

That Shopware is taken seriously in B2B shows in an external assessment: in the Paradigm B2B Combine 2026 (Midmarket Edition) the system received 8 gold and 3 silver medals, and with that recognition in 11 of 12 evaluated categories (Shopware). The assessment covered 12 vendors across 12 categories against 38 weighted criteria (Shopware). For a punchout project that mainly means: the foundation carries, the actual work sits in the integration.

In practice, punchout in Shopware 6 cannot simply be turned on via a plugin – it is a layered topic: the setup request must be authenticated, the buyer must be mapped to a Shopware customer group, their session embedded in a URL and the cart return delivered via a dedicated endpoint. All of this happens on top of the existing Shopware APIs and can be implemented cleanly based on the B2B Components.

Integration with SAP, Microsoft Dynamics and ERP

A punchout flow does not end with the cart return. For the order to actually become economically real, the OrderRequest must flow cleanly into the ERP – and bidirectionally: prices and customer data from ERP to shop, orders and returns back from shop to ERP. Common systems in DACH include SAP Business One, Microsoft Dynamics 365 and JTL-Wawi for mid-size merchants.

Reality is not always pretty: mid-market ERP integration projects drag on because master data, pricing logic and approval paths rarely sit in the system as cleanly as the org chart suggests. For Dynamics 365 Finance & Operations it is also true that pricing for customer-specific B2B terms has to be configured – the standard alone rarely covers it completely, and those are exactly the terms that need to appear in the punchout catalog.

On top of this comes the mandatory e-invoice in Germany: the German VAT Act defines an electronic invoice as an invoice issued, transmitted and received in a structured electronic format that allows electronic processing (UStG § 14). Where supplier and recipient are both established in Germany, it has to be issued that way (UStG § 14). As a transition, invoices for turnover up to 31 December 2026 may still be issued on paper, and with a previous-year turnover of no more than 800,000 euros even up to 31 December 2027 (UStG § 27). A punchout project is therefore often the right moment to rethink the entire supplier-buyer chain – from the catalog all the way to the DATEV interface (blog article) in accounting.

Top e-procurement platforms in DACH

Anyone doing B2B in the German-speaking region will come across the same e-procurement platforms repeatedly. A short overview of the relevant systems – as orientation, not as a recommendation:

• SAP Ariba / SAP Business Network: A counterpart frequently encountered in DACH mid-market companies and corporations. Both OCI and cXML are supported.
• Coupa: Strongly represented in the enterprise segment, integration runs via cXML in practice.
• JAGGAER: Widespread in public procurement and in corporations with complex supplier networks.
• Onventis (Stuttgart): Cloud procurement platform focused on German mid-market companies, in practice mostly OCI-driven.
• Unite / Mercateo: As an aggregator often the simplest entry option for suppliers without ERP punchout experience.
• Oracle Procurement Cloud: Standardized cXML stack, in DACH mostly present in subsidiaries of US corporations.

For new projects we recommend starting with the system your largest buyer already uses – this usually yields the most economically valuable quick wins. If you want to open up new customer segments deliberately, starting with Onventis or SAP Business Network is a safer bet, as those platforms are widespread in the DACH mid-market.

Implementation in 5 steps

A punchout project cannot be done in a week, but it is also not a mammoth project. The following step-by-step outline shows how we typically approach it at XICTRON:

1. Requirements workshop: Which buyers are relevant? Which platforms do they use? Which articles should appear in the catalog? Which prices and volume tiers apply? Which additional fields (cost centers, project numbers) does the cart return have to carry? This phase is decisive – mistakes here propagate through the entire project.
2. Prototype and format decision: OCI or cXML? Which version? Which authentication? We build a minimal prototype with the largest target buyer system to validate data structures – before any production code is written.
3. Shopware integration and B2B Components configuration: Create customer groups, set up pricing rules, assign assortments, build session handling and SSO flow. The B2B Components in Shopware 6 form the foundation – custom development only happens in targeted places for punchout-specific endpoints.
4. Bidirectional ERP and OrderRequest: The connection to SAP Business One, Microsoft Dynamics or another ERP. Prices, stock and customer data from ERP, orders back into ERP – depending on the system this is one to several interfaces.
5. End-to-end testing, pilot and rollout: Real test orders with a pilot buyer, catching edge cases (such as session timeout, duplicate cart returns), then gradual rollout to additional buyers.

How XICTRON implements your B2B integration

As B2B e-commerce specialists based in Lower Saxony, we guide mid-market companies and corporate subsidiaries through the entire path from concept to a production-grade punchout flow. We bring both the technical expertise for Shopware integrations – including SAP, Microsoft Dynamics and other ERP systems – and an understanding of the procurement processes on the buyer side.

Our approach stays pragmatic: we do not build punchout solutions for a showcase, but for measurable efficiency gains. Well-planned punchout projects are most likely to pay off when the B2B pricing strategies, ERP processes and the product configurator are tuned properly together. Further strategic aspects – for example how you work on B2B digitalization in sales – are covered in our adjacent articles.

Frequently asked questions

In 2026, punchout is no longer a nice-to-have – it is the entry ticket into professional B2B procurement processes. Anyone who connects their Shopware shop cleanly to OCI and cXML becomes easy to order from for their buyers' procurement teams – and at the same time gains time in their own order entry. We support you through every step, from the first setup request to the productive OrderRequest.