Table of Contents
What is the Open Catalog Interface (OCI)?
The Open Catalog Interface, or OCI, is a protocol developed by SAP that allows a buyer’s eProcurement system or ERP to connect directly to a supplier’s online catalog. This connection is dynamic and built specifically for B2B transactions, enabling buyers to browse supplier catalogs, build a cart, and transfer that data back into their procurement system automatically.
OCI is SAP’s native standard for this type of catalog connectivity. While cXML is the more widely used protocol across eProcurement platforms, OCI is supported primarily by SAP-based procurement systems and a handful of other compatible platforms.
What is OCI PunchOut?
OCI PunchOut is the process that enables a buyer’s eProcurement system to connect directly to a supplier’s online catalog, letting a user browse and shop, then automatically transfer the cart data back into the procurement system for approval and purchase order processing.
The supplier’s catalog is typically displayed as an iframe within the buyer’s procurement interface. When the buyer is ready to check out, the cart data flows back automatically without any manual re-entry.
Here’s the simplified buyer-to-supplier flow:
- A buyer logs into SAP SRM and selects an approved supplier.
- SAP SRM redirects them (via OCI) to the supplier’s eCommerce site.
- The buyer shops and builds a cart on the supplier’s site.
- The buyer initiates the “PunchOut” (checkout), and the cart data is sent back to SAP SRM.
- The requisition goes through any internal approval workflows before a purchase order is issued.
How OCI PunchOut Works: A Technical Open Catalog Interface Example
Each step of an OCI PunchOut process involves specific data being passed between the buyer’s procurement system and the supplier’s eCommerce platform. Here’s a breakdown of what’s happening at each stage.
Step 1: PunchOut Authentication
SAP SRM sends an authentication request to the supplier’s system. With OCI integrations, the data passed here is often minimal. In many cases it doesn’t include much user-identifying information. SAP SRM technically supports unique identifiers, but many implementations don’t use them, which creates challenges for tracking individual buyer activity.
A typical authentication payload includes:
HOOK_URL: https://acme_buyer.sap.com/oci
The HOOK_URL is the return address: it’s where the cart data will be sent once the buyer is done shopping.
Step 2: User Redirection
Once the supplier’s system authenticates the request, it returns a URL that redirects the buyer to the supplier’s eCommerce site. From the buyer’s perspective, they’re now browsing the supplier’s catalog, often within an iframe inside SAP SRM. They can search, browse, and add items just like they would on any eCommerce site.
Step 3: Cart Return
When the buyer is ready to transfer their cart back to SAP SRM, the supplier’s system posts the line item data to the HOOK_URL defined in Step 1. Each line item in the cart is passed as a set of parameters. A standard OCI cart return includes at least the following fields:
NEW_ITEM-DESCRIPTION[n]: Some Great Product Name
NEW_ITEM-MATGROUP[n]: 80141611 (UNSPSC code, varies by buyer)
NEW_ITEM-VENDORMAT[n]: 1234567 (Product SKU)
NEW_ITEM-QUANTITY[n]: 1
NEW_ITEM-PRICE[n]: 55.68
NEW_ITEM-UNIT[n]: EA (Unit of Measure, varies by buyer)
NEW_ITEM-CURRENCY[n]: USD
One important note: OCI supports up to 40 different data nodes, but most implementations use somewhere between 7 and 15. The specific fields required will vary from buyer to buyer, which is one reason why OCI integrations often need custom mapping.
Key Aspects of OCI PunchOut
Understanding the core mechanics of OCI helps set realistic expectations for implementation.
- SAP-native standard: OCI was built by SAP for SAP. It’s the default protocol for SAP SRM and is also supported by a few other eProcurement systems.
- HTTP POST or GET: OCI data is transmitted via HTTP_POST or HTTP_GET. POST is generally preferred. GET can cause issues with longer data strings. OCI 5.0 also introduced JSON support.
- Single-user login model: By default, OCI is set up with a shared username and password for an organization’s buyers. Multiple users logging in under the same credentials can cause session conflicts.
- Iframe-based display: The supplier’s catalog is typically rendered inside an iframe within SAP SRM. This creates security considerations, since many modern eCommerce platforms block iframes by default.
- 40 supported data nodes: OCI supports a wide range of fields, but only a subset are typically used. Required fields vary by buyer, which means custom mapping is almost always part of the setup process.
Ready to simplify your PunchOut connectivity?
Benefits of OCI PunchOut
When implemented correctly, OCI PunchOut delivers real value for both buyers and suppliers operating within SAP environments.
For Buyers
- Streamlined procurement: Buyers can shop directly from approved supplier catalogs without leaving SAP SRM, reducing manual data entry and the risk of errors.
- Real-time pricing and availability: Because the buyer is shopping live on the supplier’s eCommerce site, they see current inventory levels and pricing, including any buyer-specific pricing agreements.
- Faster requisition-to-order cycles: Cart data flows automatically back into SAP SRM, where it can move through approval workflows immediately.
- Compliance and spend visibility: Purchasing stays within the approved procurement system, making it easier to enforce preferred vendor agreements and track spend.
For Suppliers
- Direct access to buyer workflows: OCI PunchOut puts your catalog in front of buyers at the exact moment they’re ready to purchase, right inside the system they use every day.
- Reduced order errors: Automated data transfer means fewer transcription mistakes on orders compared to manual PO entry.
- Stronger buyer relationships: Offering a seamless PunchOut experience is increasingly a requirement for doing business with large enterprise buyers using SAP SRM.
Limitations of OCI PunchOut
OCI is a powerful standard, but it has real constraints that every implementation team should understand upfront.
Limited User Identification
SAP SRM OCI integrations often don’t pass detailed user information during authentication. This makes it difficult to track which specific buyer placed an order or personalize the catalog experience for individual users.
Single-User Login
OCI’s default setup uses shared credentials across an organization’s buyers. When multiple users are logged in at the same time, the system can get confused about who is who, leading to session conflicts, or Cart Collisions, and inaccurate reporting.
No Native PO or Invoice Automation
OCI PunchOut does not natively support automated purchase order transmission or invoice receipt on its own. By itself, OCI primarily supports the catalog shopping experience and cart return process.
TradeCentric helps suppliers extend OCI PunchOut by connecting the supplier’s eCommerce platform with the buyer’s procurement system. Through managed transaction mapping, document routing and cXML support, TradeCentric enables related procure-to-pay workflows, including PO automation, invoice automation and order acknowledgements.
iframe Security Restrictions
Modern eCommerce platforms frequently block iframe embedding for security reasons. For OCI PunchOut to work, security exceptions need to be explicitly configured on the supplier’s platform and sometimes within the buyer’s SAP environment as well.
POST vs. GET Transmission Issues
Choosing HTTP_GET over HTTP_POST can cause problems when cart data contains longer strings. HTTP_POST is strongly recommended, but this is a known stumbling block for implementations that aren’t carefully configured.
Limited Data Flexibility
Compared to cXML, OCI’s data model is less flexible. Suppliers with complex products (configurable furniture, custom PCs, promotional items) may run into limitations when trying to pass all the necessary product details through OCI’s standard fields.
Want to see what an OCI PunchOut integration could mean for your bottom line?
OCI vs. cXML: What’s the Difference?
Both OCI and cXML enable PunchOut catalog connectivity, but they’re built for different environments and have different capabilities.
| Feature | OCI | cXML |
|---|---|---|
| Primary Use | SAP SRM and select ERPs | Most eProcurement platforms |
| Data Flexibility | Limited | Highly flexible, customizable |
| User Logins | Single shared login | Multiple unique user logins |
| PO Automation | Not supported natively | Natively supported |
| Invoice Automation | Not supported natively | Natively supported |
| Level 2 PunchOut | Not supported | Supported where eProcurement allows |
| Data Format | HTTP POST/GET (JSON in OCI 5.0) | XML over HTTPS |
The bottom line: if your buyers are on SAP SRM, OCI is the standard you’ll need to support. If your buyers span multiple eProcurement platforms, you’ll likely need to support both.
How TradeCentric Supports OCI PunchOut
OCI integrations sound straightforward in theory, but in practice they involve a lot of moving parts: custom field mapping, authentication workarounds, session management, and ongoing maintenance as both buyer and supplier systems evolve.
TradeCentric is a PunchOut and eProcurement integration platform built specifically to simplify these connections. Here’s what that means for OCI:
- Solving the identity problem: TradeCentric has developed multiple approaches to handle the sparse user data that comes with SAP SRM OCI authentication. This helps suppliers track buyers and personalize experiences, even when OCI does not pass user identifiers natively.
- Custom field mapping: Every buyer has different field requirements. TradeCentric manages the mapping layer so your eCommerce platform does not have to be rebuilt for each new connection.
- Translating OCI into platform-ready formats: TradeCentric can translate OCI transaction data into formats your eCommerce platform can process, including cXML, JSON or other native system requirements. This helps suppliers support SAP SRM OCI buyers without building custom translation logic for every connection.
- Session conflict resolution: TradeCentric can configure OCI connections to support multiple simultaneous users, even under SAP’s single-login model.
- Ongoing support: Buyer requirements change. TradeCentric monitors and maintains your OCI connections so you’re not scrambling every time a buyer updates their system.
Ready to get your OCI PunchOut integration right the first time? TradeCentric connects suppliers and buyers through every major eProcurement standard. Reach out to our team to get started.
Frequently asked questions
OCI stands for Open Catalog Interface. It’s a protocol developed by SAP for connecting eProcurement systems like SAP SRM to supplier eCommerce catalogs.
Not exactly. Both OCI and cXML enable PunchOut catalog connectivity, but they’re different protocols. OCI is SAP’s native standard, primarily used with SAP SRM. cXML is an XML-based standard used by a much wider range of eProcurement platforms, with more flexibility and more native automation out of the box.
OCI is primarily used with SAP SRM (Supplier Relationship Management). Some other SAP-adjacent systems also support OCI, but it’s not as broadly adopted as cXML across non-SAP eProcurement platforms.
Yes, TradeCentric specializes in PunchOut integrations, including OCI, and has purpose-built solutions for the most common OCI challenges including authentication data gaps, multi-user session management, and custom field mapping. If you’re evaluating an OCI integration or troubleshooting an existing one, reach out to the TradeCentric team.

