A punchout integration is the difference between winning a large enterprise account and watching that account go to a competitor whose storefront talks fluently to the customer’s procurement system. For distributors selling into Fortune 1000 companies, hospital systems, large universities, and government agencies, the punchout requirement is no longer optional. It is in the RFP, it is in the master agreement, and it is the gate that separates “we’d love to buy from you” from “we already buy from you.”
Adobe Commerce supports punchout integration for the three major procurement platforms: SAP Ariba, Coupa, and Oracle Procurement Cloud. The integration is well-understood, but the design choices and the protocol details determine whether the integration is a clean win or a six-month tarpit. Bemeir’s Adobe Commerce B2B team has shipped punchout integrations for distributors across industrial, foodservice, medical supply, and office products. Here is what actually matters.
What punchout actually does
A punchout is a procurement workflow where a buyer in the customer’s procurement system (Ariba, Coupa, Oracle) is “punched out” to the supplier’s storefront, shops there, fills a cart, and then “returns” that cart to their procurement system as a requisition for approval. The supplier’s storefront becomes a guided shopping experience inside the customer’s procurement workflow.
The buyer never logs into the distributor’s site with a username and password. The buyer never types a credit card. The buyer never sees a real checkout. What happens behind the scenes:
The procurement system sends an authenticated request to the distributor’s storefront with the buyer’s identity, company, and contract context. The storefront recognizes the request, opens a tailored shopping session with pricing and catalog visibility appropriate to that customer, lets the buyer add items to a cart, and then when the buyer clicks “submit,” packages the cart contents into a cXML or OCI-formatted response and posts it back to the procurement system. The procurement system receives that response, turns it into a requisition or purchase order, runs it through its internal approval workflow, and then either sends a purchase order back to the distributor as a real order or notifies the buyer that the order was rejected.
The customer gets the procurement controls they require. The distributor gets a real order with payment terms already established. The buyer gets a guided experience inside their normal procurement workflow. Everyone wins, but only if the integration is built correctly.
The protocols you have to support
The three major procurement platforms have settled on two protocols, with some platform-specific variations.
cXML (commerce XML). The most common protocol, used natively by SAP Ariba and supported by Coupa. cXML defines the authentication request (PunchOutSetupRequest), the shopping session (PunchOutSetupResponse), and the cart return (PunchOutOrderMessage). The official cXML specification is the authoritative reference, and most enterprise procurement systems implement it.
OCI (Open Catalog Interface). SAP’s older protocol, originally for SAP ERP and still in use by some large customers. OCI is simpler than cXML but less feature-rich. Some Oracle Procurement deployments also use OCI for legacy reasons.
Coupa’s PunchOut2Go. A managed service that brokers between Coupa and supplier storefronts. Some distributors connect to Coupa through PunchOut2Go rather than directly via cXML.
A distributor selling into a mix of large enterprise customers needs to support cXML at minimum. OCI support is occasionally required by specific customers and is usually scoped as a second-phase integration if needed.
What the three platforms expect
Each procurement platform has its own quirks. Understanding the differences up front prevents the most common integration failures.
| Capability | SAP Ariba | Coupa | Oracle Procurement |
|---|---|---|---|
| Primary protocol | cXML | cXML or PunchOut2Go | cXML, OCI fallback |
| Catalog presentation | Hosted (supplier) or Punchout | Hosted (supplier) or Punchout | Hosted or Punchout |
| UNSPSC code requirement | Strongly recommended | Required | Required |
| Tax handling | Supplier returns tax | Coupa often computes tax | Oracle often computes tax |
| Shipping method selection | Supplier returns shipping | Coupa can compute or accept supplier | Oracle often configures |
| Contract-aware pricing | Yes (cXML credential) | Yes (cXML credential) | Yes |
| Order confirmation route | PO via cXML or EDI | PO via cXML or Coupa CSP | PO via cXML or Oracle iSupplier |
The two details that bite distributors most often: UNSPSC code accuracy (Coupa and Oracle both validate UNSPSC codes against their internal taxonomy and will reject orders with codes they do not recognize), and tax handling (some procurement systems compute their own tax and want the supplier to not return tax in the cart response; others expect the supplier to be the tax authority). Both are integration design decisions that need to be confirmed per customer, not assumed.
How the integration sits on top of Adobe Commerce
Adobe Commerce does not ship punchout natively. The integration is built either with a third-party extension, with a custom Magento module, or with a middleware service that sits between Magento and the procurement platforms.
The three architectural approaches:
Magento extension. Several commercial Magento extensions add punchout support directly to Adobe Commerce. Mageworx, BSS Commerce, and Webkul publish punchout modules with varying degrees of cXML and OCI support. These are the fastest path to a working integration but typically support only the basic punchout flow and need customization for anything beyond standard PunchOutSetupRequest / PunchOutOrderMessage handling.
Custom Magento module. A custom module written specifically for the distributor’s customer mix. This is the highest-quality path because it can be tailored to the specific cXML credentials each customer expects, the tax and shipping handling each customer wants, and the catalog visibility rules per customer contract. It is also the most expensive to build and to maintain.
Middleware service. A standalone service (Node.js, Python, or Go) that receives cXML from the procurement platforms, talks to Magento over REST API or GraphQL, and returns cXML responses. This architecture isolates the punchout logic from the Magento codebase and makes it easier to support multiple procurement platforms and multiple cXML credential variations.
Our team typically recommends the middleware approach for distributors with five or more enterprise punchout customers because it scales better as new customers are added. For distributors with one or two punchout customers, a custom Magento module is usually the right starting point.
The catalog visibility decisions that matter
Punchout is not just authentication and cart return. It is a guided shopping experience that should respect the customer’s contract. Three catalog visibility decisions that need to be made for each customer:
Catalog scope. Does this customer see the full distributor catalog, or only a contract-defined subset? Some customers want their buyers to see only the SKUs covered under their negotiated contract. Others want the full catalog with the contract pricing applied.
Pricing display. Does the storefront show list pricing, contract pricing, or both? Most customers want contract pricing displayed prominently; some want to also see the list price for comparison; some want only the contract price with no reference to list.
Catalog metadata enrichment. What product metadata is required for the buyer to make a purchase decision? UNSPSC codes, ENERGY STAR certifications, GHS hazard codes, country of origin, MSDS sheets, technical specification PDFs: each customer’s procurement system expects different fields and will sometimes reject products without them.
These decisions are typically configured per customer in the punchout integration layer. Adobe Commerce B2B’s shared catalog and customer-group pricing model gives you the primitives to support this; the punchout integration is the glue that maps each customer’s procurement credentials to the right catalog scope and pricing tier.
Order routing after the punchout completes
After the buyer’s procurement system approves the requisition, a purchase order is sent back to the distributor. The order routing back into Adobe Commerce is the second half of the integration and is often under-scoped during planning.
The three common patterns:
cXML purchase order. The procurement system sends an OrderRequest cXML document back to the supplier. The supplier’s punchout integration receives this, validates it against the original cart, creates a Magento order with the correct customer, line items, pricing, and shipping address, and routes it to fulfillment. This is the cleanest pattern.
EDI purchase order. Some procurement systems send a standard EDI 850 purchase order instead of cXML. The supplier needs to be able to receive EDI 850 and convert it to a Magento order. EDI infrastructure is heavier than cXML and is usually only worth building if multiple customers send EDI.
Manual or email purchase order. Some smaller customers approve the requisition and then have the procurement system email the PO. This is the worst pattern because it loses the data integrity of the cart-to-order linkage and requires manual order entry. Avoid this by negotiating cXML or EDI delivery in the contract.
The Magento order created from the punchout PO needs to carry the customer’s PO number, the requisition number, the contract number, and the cost center as custom order attributes. These are required for the supplier’s invoice to be processed by the customer’s AP system. Without them, invoices get rejected and the supplier has to chase down what reference numbers they should have included.
Testing punchout integration before launch
Punchout integration testing has a sharp edge: the only way to fully test it is in the customer’s actual procurement environment. Sandbox environments exist (Ariba has a Test Realm, Coupa has a test environment, Oracle has a test instance) but they do not replicate every quirk of the customer’s production configuration.
The testing sequence that works:
First, end-to-end test in the procurement platform’s standard sandbox with sample cXML credentials. This catches the basic flow and the cXML formatting.
Second, end-to-end test in the customer’s procurement test environment with their actual credentials. This catches the customer-specific configuration (contract scope, approval routing, PO format).
Third, a controlled pilot with one or two real buyers placing real (but small) orders. This catches the operational edge cases (out-of-stock handling, partial shipment, returns).
Fourth, full production launch after the pilot demonstrates clean orders through the customer’s AP system.
Each step typically takes one to three weeks. Skipping the steps shortens the timeline but materially increases the chance of an integration that has to be reworked after launch because of a customer-specific issue that did not show up in sandbox.
What this looks like as an engagement
A first punchout integration for a distributor typically runs 8-14 weeks from contract to production, depending on whether the architecture is extension-based, custom module, or middleware. The variability is mostly driven by how many customer-specific configurations are in scope.
Bemeir’s team typically scopes the first integration end-to-end (Adobe Commerce module changes, middleware if needed, cXML configuration, customer onboarding flow, order routing), and then subsequent customer integrations are scoped per-customer at a smaller fraction of the first cost because the architecture is already in place.
For distributors who win two or three large enterprise accounts in a year that require punchout, the integration investment is typically paid back within the first year on revenue from those accounts alone. The cost of not having the integration in place when a major RFP comes through is much higher than the cost of building it before it is critical. The distributors who treat punchout as a strategic capability rather than a tactical project win the accounts.
