OCIInterface for electronic catalogue exchange in the procurement process
Procurement glossary · Updated · 7 min read
Also known as: Open Catalog Interface, SAP OCI, OCI standard, Punchout interface, catalogue interface
Short answer
- OCI (Open Catalog Interface) is a standard defined by SAP for exchanging catalogue data between e-procurement systems and supplier catalogues.
- The buyer switches to the supplier catalogue via punchout, selects items and transfers the basket back via HTTP POST with standardised fields.
- OCI reduces manual entry, lowers error rates and requires clean catalogue data as well as price reconciliation with framework agreements.
OCI stands for Open Catalog Interface, an interface defined by SAP for exchanging catalogue data between e-procurement systems and supplier catalogues. It enables buyers to switch directly from the shopping basket of their procurement system to a supplier's catalogue, select items there and transfer the basket back in a structured format. OCI thus connects the supplier's catalogue management with the customer's procurement logic and considerably reduces manual data entry effort.
Key facts
- OCI is a standard introduced by SAP for catalogue exchange in e-procurement systems and is also supported by other procurement solutions.
- The interface typically transfers shopping baskets via HTTP POST with predefined field names (OCI line items) between the buyer and supplier systems.
- OCI is a return transfer standard: it primarily governs how a shopping basket filled in the supplier catalogue is returned to the purchasing system.
- In practice, OCI processes single- and multi-line baskets with fields such as quantity, unit, price, plant and cost centre.
- OCI is closely related to cXML and other formats; the choice depends on the e-procurement system in use.
- Clean catalogue data and standardised item master records are a prerequisite for functioning OCI data exchange.
Contents
Definition: OCI
Open Catalog Interface (OCI) is an interface specification that defines the structured data transfer between an e-procurement system (punchout process) and an external supplier catalogue. From within their procurement software, the buyer navigates to the supplier's catalogue, selects items and transfers the completed shopping basket back into their system as a structured OCI message. The specification comprises defined field names, data types and transfer parameters.
Distinction from cXML and other formats
OCI is the established standard in the SAP environment, while cXML is widespread primarily among solutions such as Ariba. Both formats solve the same basic task – punchout catalogue exchange – but differ in field scope, extensibility and system support. Many supplier catalogue platforms offer both protocols in parallel, so buyers are not tied to a single format.
Position within the e-procurement process
OCI sits at the interface between catalogue management and order processing: after the return transfer of the basket, the typical steps are checking, purchase order creation, approval and order transmission. The quality of the OCI handover directly influences downstream delivery advice note (ASN) processing and invoice verification, because item number, quantity and price are taken from the catalogue into the purchase order.
How it works and technical fundamentals
The OCI process follows a defined pattern: when the catalogue is called up, the purchasing system passes context parameters such as user, callback URL and, where applicable, framework contract information. The supplier catalogue opens in the browser and the buyer selects items. During the return transfer, the catalogue sends the basket line items via HTTP POST with standardised OCI fields to the callback URL of the purchasing system.
Key OCI fields
Frequently used fields include NEW_ITEM-DESCRIPTION (item description), NEW_ITEM-QUANTITY (quantity), NEW_ITEM-UNIT (unit of measure), NEW_ITEM-PRICE (price), NEW_ITEM-CURRENCY, NEW_ITEM-VENDOR and NEW_ITEM-MATNR (material number). In addition, customer-specific fields such as cost centre, order text or contract number can be passed. The field scope is defined in the interface agreement between the partners.
Return transfer and basket processing
After the POST operation, the purchasing system generates a shopping basket or purchase requisition from the OCI line items. The buyer adds internal mandatory fields, checks prices and triggers the ordering process. With correctly maintained item master records, mapping to material numbers happens automatically, which makes catalogue management at the supplier a central quality factor. Incorrect units or missing prices otherwise lead to rework in the ordering process.
Benefits for buyers and suppliers
OCI considerably reduces the manual effort involved in item procurement and increases process reliability on both sides. Buyers order with up-to-date prices and availability directly from the supplier catalogue; suppliers gain loyalty and standardisation in the customer process.
Process efficiency on the buyer side
The greatest benefit lies in avoiding duplicate entry: items are maintained once in the catalogue and then flow into the purchase order without manual input. This shortens lead times, reduces error rates for quantities and prices and relieves the burden on specialist departments. For recurring requirements, OCI can be combined with a call-off contract or framework agreement, so that call-offs arise automatically from the catalogue process.
Benefits on the supplier side
Suppliers reach customers directly in the procurement system and increase the likelihood that catalogue-guided items are ordered instead of alternative sources. Current price lists and discount scales can be maintained centrally in catalogue management; changes take effect immediately for all punchout customers. In addition, catalogue transactions provide valuable data for slow-mover analysis and range management.
Limitations and practical constraints
OCI primarily covers catalogue and shopping basket transfer, not the full order communication: order transmission, delivery advice notes and invoice data often run via separate channels such as EDI. For complex configurations or services with a statement of work, the catalogue approach is only of limited suitability; asset/service orders or classic tendering processes are the better choice here.
Introduction and operational implementation
The introduction of an OCI connection is an IT and functional project with a clear division of roles: the buyer defines process requirements and mandatory fields, the supplier maintains catalogue data, and IT configures the interface. A structured approach reduces effort and safeguards data quality.
Typical project approach
In practice, the following sequence has proven successful: first the supplier's item master and price logic are reviewed, then the OCI field mapping is agreed and a test environment set up. After successful test transactions, the productive rollout follows, ideally starting with a high-turnover, simple range. Accompanying training for requisitioners increases acceptance.
Data quality and catalogue maintenance
Functioning catalogue exchange depends on consistent master data: unique item numbers, standardised units, correct currency and up-to-date prices. Missing or inconsistent data lead to mispostings and rework. Regular checks of catalogue data – similar to a discount scale check for terms – are therefore an integral part of day-to-day operations.
Interface agreement and governance
Field scope, transfer parameters, error handling and contact persons should be documented in a written interface agreement. Changes to the catalogue or field logic are managed through defined change processes, comparable to an Engineering Change Notice (ECN) in technology. This keeps the connection stable even during system updates on either side.
Risks, controls and compliance
Despite the automation, catalogue connections create specific risks that buyers should actively manage. These include data quality issues, unjustified price adjustments and requirements regarding data protection and confidentiality in data transfer.
Price and terms risks
Catalogue prices can change without the buyer immediately noticing. Controls include reconciling catalogue prices with contractual terms as well as regular spot checks at goods receipt. For framework contract call-offs, price binding from the call-off contract should be mapped in the catalogue or technically locked down.
Data protection and confidentiality
With punchout, the purchasing system transmits user and context data to external systems. Buyers should have the legal basis reviewed and clarify on a case-by-case basis whether a confidentiality level or a non-solicitation clause should be added to the framework agreement if suppliers gain insight into purchasing patterns and item data. Legal assessments are always case-dependent and must be reviewed by legal or data protection officers.
Supplier monitoring and exit strategies
An OCI connection creates technical dependence on the supplier. Buyers should consider exit scenarios and switching costs from the outset, for example through standardised catalogue formats and alternative sources of supply. Supplier financial risk from long-term exclusive connections can be limited through multi-sourcing strategies and regular audits – for instance under the contractual audit rights.
Current developments around OCI
The landscape of catalogue standards continues to evolve: alongside OCI and cXML, cloud-based marketplace connections, standardised API interfaces and AI-supported catalogue maintenance are gaining importance. Buyers should monitor these developments without hastily restructuring existing processes.
API-first and modern integration patterns
Many procurement solutions complement classic punchout standards with REST APIs that retrieve real-time availability, configurators or volume prices. Nevertheless, OCI remains the de facto standard in the SAP environment and is often used as a bridge to modern services. Anyone planning new connections should clarify whether the target system prefers OCI, cXML or an API.
Automated catalogue maintenance
Artificial intelligence increasingly supports the classification, translation and deduplication of catalogue data. For suppliers, the maintenance effort in catalogue management decreases; for buyers, the search accuracy for items improves. This increases the acceptance of catalogue-guided procurement and, indirectly, the utilisation of negotiated terms – a contribution to measurable cost avoidance.
Typical metrics
| Metric | Benchmark | Context |
|---|---|---|
| Catalogue price compliance | > 99 % | Proportion of catalogue prices that match contractual terms |
| Purchase requisition automation rate | > 95 % | Proportion of OCI shopping baskets without manual correction |
| Interface transfer error rate | < 1 % | Proportion of failed or incomplete shopping basket transfers |
| Catalogue update frequency | typically weekly to monthly | Frequency of price and range maintenance by the supplier |
| Lead time from basket to purchase order | typically < 1 working day | Time from the OCI return transfer to order approval |
Typical practical benchmarks – they vary by industry, part and contract.
Practical example
A mid-sized mechanical engineering company procures consumables, small parts and standard components via an SAP-based e-procurement system. Until now, buyers have entered items manually, which is error-prone and time-consuming. The buyer negotiates an OCI connection with a key supplier: the supplier catalogue is integrated into the procurement system via punchout, and price binding from the framework agreement is technically assured.
- Agreement of an interface specification with field mapping and a test environment before the productive rollout
- Starting with the high-turnover range (consumables), later extending to tools and standard components
- Reconciliation of catalogue prices with framework agreement terms through regular discount scale checks
- Connection of downstream processes (order transmission, delivery advice note processing (ASN)) for end-to-end automation
Conclusion
OCI is the field-proven standard for catalogue exchange between e-procurement systems and supplier catalogues and noticeably reduces manual data entry effort. The greatest benefit arises when catalogue data, price binding and downstream processes are consistently aligned with one another. Buyers should approach the introduction as a project with clear governance and actively manage risks such as data quality, price drift and dependence. Even as new integration patterns emerge with APIs, OCI remains the reliable choice in the SAP environment. Those who master the standard accelerate operational procurement without losing control over contracts and terms.
Frequently asked questions
What does OCI mean in the purchasing and e-procurement context?
OCI stands for Open Catalog Interface, a standard defined by SAP for catalogue exchange in punchout scenarios. A buyer switches from their procurement system to the supplier catalogue and transfers the shopping basket back in a structured format. Items, quantities and prices are thereby automatically transferred into the purchase order.
What is the difference between OCI and cXML?
OCI is the dominant standard in the SAP environment, while cXML is widespread among other e-procurement platforms. Both solve the same basic task – the return transfer of shopping baskets from supplier catalogues – but differ in field scope and system support. Many catalogue platforms support both formats in parallel.
How does an OCI connection work technically?
When opening the catalogue, the purchasing system passes context parameters such as user and callback URL. The buyer selects items in the supplier catalogue, which then returns the basket line items via HTTP POST with standardised OCI fields. The purchasing system generates a shopping basket or purchase requisition from this.
What advantages does OCI offer buyers?
OCI avoids duplicate data entry, reduces error rates for quantities and prices and speeds up the procurement process. Prices and availability come directly from the supplier catalogue, which also supports compliance with negotiated terms. In addition, framework agreements and delivery call-off processes can be better mapped in a catalogue-guided manner.
What risks are associated with an OCI connection?
Typical risks are undetected price changes, faulty master data and technical dependence on the supplier. Countermeasures include price comparisons against framework agreement terms, regular catalogue data checks and defined exit scenarios. Data protection and confidentiality of data transfer should be examined on a case-by-case basis.
What does an OCI connection cost for suppliers?
In practice, one-off set-up costs for interface development and catalogue creation typically arise, plus ongoing costs for catalogue maintenance. The amount depends on the size of the range, field complexity and the number of customers to be connected. Many suppliers offset the investment through higher order volumes from punchout customers.
