Written by Nishiyama — Paddy & Water Inc. / Supply Chain

Detailed Functional Overview, EDI/API Integration, Customization Constraints, and ERP Connection Setup

July 2026

This document systematically explains SAP Ariba’s cloud procurement platform, covering the detailed functionality of each module, supplier-side EDI/API integration, constraints on additional development, the limits of configuration customization, and the procedures for connection setup with ERP (S/4HANA). Based on practical content drawn from publicly available SAP information, the SAP Community, and the SAP Help Portal, it is intended for use as a reference document for implementation design and operational design.

Chapter 1: The Product Structure of SAP Ariba

1-1 Overview of the Product Suite

SAP Ariba is not a single product but a suite made up of multiple SaaS modules. Each module is delivered as an independent cloud service, allowing organizations to adopt only the functionality they need. The suite as a whole is organized around the Source-to-Pay (S2P) framework, which covers everything end-to-end from upstream strategic sourcing to downstream payment processing.

Spend Analysis

▶

Sourcing

▶

Contracts

▶

SLP (Supplier Management)

▶

Buying

▶

Invoicing

Figure 1: SAP Ariba Source-to-Pay Process Flow

Category	Module	Key Functions	Process Segment
Strategic Sourcing (S2C)	SAP Ariba Spend Analysis	Spend data collection, UNSPSC classification, spend visualization, identification of cost-reduction opportunities	Source-to-Contract
Strategic Sourcing (S2C)	SAP Ariba Sourcing	RFI/RFQ/RFP, reverse auctions, award management, supplier evaluation	Source-to-Contract
Strategic Sourcing (S2C)	SAP Ariba Contracts	Contract workspaces, clause libraries, e-signature, milestone management	Source-to-Contract
Supplier Management	SAP Ariba SLP	Supplier registration, qualification, performance evaluation, scorecards	Supplier Lifecycle
Supplier Management	SAP Ariba Supplier Risk	Financial, geopolitical, and ESG risk monitoring, external data integration	Risk Management
Procurement & Payment (P2P)	SAP Ariba Guided Buying	Consumer e-commerce-style buying UI, channel guidance, forms, budget checks	Procure-to-Pay
Procurement & Payment (P2P)	SAP Ariba Buying & Invoicing	Purchase requisitions, purchase orders, goods receipt confirmation, 3-way match, payment instructions	Procure-to-Pay
Supply Chain Collaboration	SAP Ariba Supply Chain Collaboration	Demand forecast sharing, order confirmation, ASN, VMI/consignment	Supply Chain
Foundation	Ariba Network (ANID)	B2B procurement network (5+ million companies), cXML/EDI communication infrastructure	Network

1-2 Licensing Structure

Ariba licensing has a two-tier structure consisting of a “subscription fee (fixed annually)” and “Ariba Network transaction fees.” Buyer organizations use Ariba modules under a subscription contract with SAP, while network fees are charged separately based on the transaction volume (number of purchase orders and invoices) processed on the Ariba Network. Suppliers can participate on the network for free for up to roughly five transactions per year, but tiered charges apply once that threshold is exceeded.

⚠ The fact that costs are also incurred on the supplier side is a major change-management challenge in an Ariba rollout. Measures for handling small and medium-sized suppliers (cost-sharing, incentives) need to be built into the implementation plan.

Chapter 2: Detailed Functionality of Each Module

2-1 SAP Ariba Sourcing: Functional Detail

Types of RFx Events and Design Detail

RFx Type	Purpose	Legal Binding Force	Evaluation Method	Applicable Scenarios
RFI (Request for Information)	Market research, capability confirmation	None	Qualitative evaluation only	Exploring new items, market price research, investigating the capabilities of potential suppliers
RFQ (Request for Quotation)	Finalizing price, quantity, and lead time	Responses are valid quotes	Price-centric, monetary comparison	Items with fixed specifications, price competition for standard goods
RFP (Request for Proposal)	Comprehensive evaluation of price plus technical capability	Responses are treated as proposals	Weighted scoring (price + qualitative)	IT, consulting, complex procurement, and service procurement
Reverse Auction	Real-time price competition	The winning bid price forms the basis of the contract	Final bid price	Standard goods and commodities where price is the primary evaluation axis

Reverse Auctions: Detailed Configuration Parameters

• Bid disclosure method: choose from three modes — Open Bidding (the current lowest price is disclosed to all participants), Rank-only (only the participant’s own rank is displayed), or Blind (other companies’ information is not disclosed)

• Bid Decrement (forced bid improvement): set a minimum improvement margin (e.g., a bid cannot be placed unless it lowers the current lowest price by at least 1%) to drive genuine price competition

• Overtime Rules (extension rules): if a bid is placed just before the close (e.g., within the last two minutes), the auction is automatically extended (e.g., by three minutes) — a fairness feature designed to prevent “last-second sniping”

• Tie handling: rules for first-come priority or random selection when multiple suppliers submit the same bid amount can be configured in advance

• Monitoring: the host can monitor, in real time, all participants’ bidding status, timeline, and lowest-price trend

Multi-Round Event Design

Ariba Sourcing supports event design using “Multi-Round” formats. Initial quotes can be collected from all participants in Round 1, and after scoring, only the top-ranked participants can be invited to Round 2 — achieving staged narrowing within a single event. Because evaluation criteria, the participant set, and the evaluation period can be configured individually for each round, this is well suited to the staged evaluation of large-scale procurement projects.

SAP Ariba Spend Analysis: Technical Detail

• Data collection targets: data from multiple sources — ERP purchase orders, expense reports (Concur), P-card data, invoices, and more — is aggregated through an ETL pipeline

• Automatic UNSPSC classification: AI automatically classifies free-text item descriptions and item codes into UNSPSC (United Nations Standard Products and Services Code, a four-level, eight-digit code). Classification accuracy determines the precision of spend analysis by item category

• Supplier normalization: variant naming (e.g., “SAP SE” / “SAP Japan” / the Japanese katakana rendering of “SAP Japan”) is consolidated as the same supplier. Full automation is difficult, and manual maintenance of the master supplier list is required

⚠ The accuracy of Spend Analysis data depends on the quality of the data sources. When integrating data from multiple ERPs, the plan needs to account for the greater ETL design and quality-management effort involved.

2-2 SAP Ariba Buying & Invoicing: P2P Detail

Guided Buying: Channel Guidance Design

• Channel Guidance: three stages can be configured depending on item category, amount, and organizational segment — “prioritize catalog guidance / direct to a procurement-department approval form / purchasing not allowed (policy-violation warning)”

• Forms Builder: forms for non-catalog items and service requests are designed via GUI drag-and-drop. Required fields, validation, and conditional branching can be configured (no scripting/coding required)

• Budget checks: integrates in real time with S/4HANA’s CO Availability Control to confirm remaining budget before approval. This assumes CIG integration is in place, and real-time performance is affected by synchronization latency with S/4HANA

• Approval Flow: multi-step approval rules based on attributes such as purchase amount, organization, item category, and cost center can be configured. Serial and parallel approvals, skip conditions, and escalation deadlines can all be set

Comparison of the Three Catalog Management Approaches

Catalog Type	Managed By	Update Frequency	Real-Time Inventory Reflection	Applicable Scenarios
Local catalog (CIF)	Buyer organization	Manual/batch	Not possible	Stable items with a small number of SKUs and fixed prices (consumables, standard parts)
Hosted catalog	Supplier (via the Ariba portal)	Updated by the supplier as needed	Not possible (static data)	Cases where the supplier can operate ongoing updates
PunchOut (external catalog)	Supplier’s e-commerce site	Real-time	Possible (directly references the e-commerce site’s inventory)	Large SKU counts, custom-configured items (PC build-to-order configurations, industrial equipment)

Note: Implementing PunchOut requires the supplier to build a cXML-enabled e-commerce site. Confirm the supplier’s technical capability and cost burden in advance, and plan to fall back to a hosted catalog where this is not feasible.

3-Way Match: Reconciliation Logic Detail

Three-way matching automatically reconciles, at the line-item level, the three documents “purchase order (PO), goods receipt (GR), and invoice.” Matching is evaluated along two axes: “quantity variance” and “price variance.”

Matching Axis	Matching Logic	Configurable Tolerance	Behavior on Variance
Quantity matching	OK if invoiced quantity ≤ GR quantity	N/A (an excess quantity is automatically rejected)	Any variance is automatically held → routed to a reviewer’s queue
Amount matching (price tolerance)	(invoiced unit price − PO unit price) / PO unit price × 100 falls within the tolerance	Can be configured individually by supplier, item category, or amount tier (e.g., within ±3% or ±¥1,000)	Exceeding the tolerance automatically holds the item → routed for reviewer approval

• 2-Way Match: for service procurement or prepayment invoices where no GR (goods receipt) occurs, 2-way matching, which reconciles against the PO alone, can be configured

• Non-PO invoices: invoices without a purchase order (utility bills, legal fees, etc.) are processed through a separate flow, in which the handler manually enters the account and cost center and then approves it

⚠ Once an invoice has been Approved in Ariba, it cannot be canceled or corrected within Ariba. The supplier must issue a credit memo, or the correction must be made as a journal entry on the S/4HANA side. This irreversibility of status is one of the constraints operations staff most need to be aware of.

2-3 SAP Ariba Contracts: Contract Management Detail

Contract Workspace Components

Component	Information Stored	Key Functions
Contract Header	Contract type, party information, term, contract amount, governing law, jurisdiction	Manages the contract’s basic attributes. Contract type can be set to, for example, “master purchase agreement, NDA, MSA, framework agreement”
Terms	Contract clause text, standard clauses, custom clauses	Standard clauses can be selected from a clause library, and custom clauses entered. Version-controlled, with support for multiple languages
Documents	Executed contract PDFs, amendments, attachments	Version control and access-rights control of documents. Automatically archives the final version once it has passed the approval workflow
Milestones (obligations)	Renewal deadlines, report submission deadlines, obligations	Sends an automatic email notification as a deadline approaches. Automatically creates a task for the responsible party
Approval Flow	Approvers, approval order, e-signature flow	Multi-step approval (Legal → manager → Finance) can be configured. Executes e-signatures via DocuSign/Adobe Sign integration

Constraints of E-Signature Integration

Note: Ariba provides e-signatures through integration with DocuSign and Adobe Sign. Ariba itself has no native e-signature functionality; a separate DocuSign/Adobe Sign license is required. In Japan, confirm compliance with the Electronic Signature Act and the Electronic Bookkeeping Act.

Integration with S/4HANA Master Purchase Agreements

• Price and quantity terms decided through an award in Ariba are automatically linked to an S/4HANA master purchase agreement (Outline Agreement: LP/LPA)

• Subsequent purchase orders reference this master purchase agreement, so the “negotiated price” is applied automatically

⚠ Not all contract types are automatically linked to S/4HANA. Comprehensive framework agreements covering multiple items and service contracts may require individual mapping configuration in some cases.

2-4 SAP Ariba SLP: Supplier Lifecycle Management

Design of the Supplier Registration Template

• Registration questionnaire: collects company information (legal entity type, year founded, headcount), financial information, insurance certificates, quality certifications (e.g., ISO 9001), ESG information (CO2 emissions, labor safety standards, human rights policy), and bank account information through a structured form

• Attachment requirements: submission of documents such as ISO certificates, financial statements, and anti-corruption policy agreements can be set as mandatory conditions for registration

• Validity period settings: a resubmission cycle for registration information (e.g., requesting an information update every January) can be configured. A rule that automatically blocks purchase orders to suppliers with expired registrations can also be set

• Field visibility scope: viewing permissions for each field (all buyers / SLP administrators only / specific departments only) can be controlled at the field level

Scorecard Evaluation Design

KPI Category	Example KPIs	Data Acquisition Method	Configuration Notes
Quality	Defect rate, number of complaints, corrective-action completion rate	S/4HANA QM integration or manual entry in SLP	Automatic ingestion from S/4HANA requires CIG integration to be configured
Delivery	On-time delivery rate, shortage rate, lead time	Linked to S/4HANA MM goods-receipt data	Automatically comparing receipt date to PO due date requires data-mapping design
Cost	Price competitiveness (versus market price), contract unit-price compliance rate	Manual entry or linked to Spend Analysis	For KPIs that are hard to automate, design a periodic manual review flow
ESG	CO2 emissions, sustainability certifications, diversity indicators	SLP questionnaires, integration with external databases such as EcoVadis	Where external database coverage is low, supplement with the company’s own surveys

SAP Ariba Supplier Risk: Risk Monitoring

• Financial risk: continuously obtains financial-health scores by linking with credit research data from providers such as D&B (Dun & Bradstreet)

• Geopolitical risk: obtains political-stability levels, trade regulations, and sanctions risk for a supplier’s location countries from external data providers

• ESG risk: AI continuously screens news feeds for environmental-regulation violations and labor issues, triggering an automatic alert when negative news is detected

• BCP (business continuity) risk: visualizes the risk of procurement concentration in specific regions through a geographic concentration map

⚠ Small and medium-sized Japanese suppliers often have low coverage in external databases such as D&B. Supplementary operations through the company’s own surveys and questionnaires are needed. Supplier Risk returns “no data” for companies not covered by external databases, and a risk score is not calculated for them.

2-5 SAP Ariba Supply Chain Collaboration: Detail

Design Detail by Collaboration Scenario

Scenario	Functional Content	Prerequisite System	Constraints
Forecast Collaboration	A rolling demand forecast (e.g., 13 weeks ahead) is published to the supplier portal. Suppliers provide feedback on committed quantities and capacity constraints	SAP IBP or S/4HANA MRP	Integration with SAP IBP requires configuring the Outbound API; S/4HANA alone may require custom integration in some cases
Order Collaboration	Purchase orders, order changes, and cancellations are notified in real time. Suppliers return Confirm/Exception; an Exception triggers the approval flow	S/4HANA MM/PP	Assumes real-time response from the supplier. Automatic reminder settings are needed for suppliers who do not act on the portal
Ship Notice (ASN)	The supplier sends an ASN (item, quantity, lot number, ship date, expected delivery date) at the time of shipment, which is automatically linked to S/4HANA’s inbound delivery	S/4HANA WM/EWM	A mutual mapping table for item codes (buyer part number ↔ supplier part number) must be maintained; without it, item recognition on the ASN fails
VMI/Consignment Inventory Management	Manages the quantity of supplier-owned consigned inventory drawn down at the buyer’s warehouse. The supplier autonomously judges replenishment timing	S/4HANA MM (special stock management)	Integration design with S/4HANA’s consignment stock management is complex, and initial setup effort is significant

Chapter 3: Supplier-Side EDI and API Integration

The digital integration method with a supplier is selected based on the supplier’s technical capability, system environment, and transaction volume. Ariba supports four integration methods: “cXML, EDI (X12/EDIFACT), REST API, and manual portal entry.”

3-1 cXML (Commerce eXtensible Markup Language)

What Is cXML?

cXML (Commerce eXtensible Markup Language) is an XML standard for B2B transactions established by Ariba in 1999, and it continues to be used as the technical foundation of the Ariba Network today. Because it is an SAP-proprietary specification, it is not directly interoperable with other networks (such as Coupa or Jaggaer), and conversion is required for integration between them.

List of cXML Document Types

cXML Document	Direction	Content	Supplier-Side Requirement
PurchaseOrder	Buyer → Supplier	A formal purchase order containing item, quantity, unit price, delivery address, and payment terms	Provision of a cXML receiving endpoint (URL)
OrderConfirmation	Supplier → Buyer	Confirmation of order receipt, delivery-date response, price confirmation or correction	Implementation of cXML-sending capability
ShipNotice (ASN)	Supplier → Buyer	Shipment notice (item, quantity, lot, serial number, ship date, carrier)	cXML-sending capability, integration with the ERP’s shipment records
Invoice	Supplier → Buyer	Invoice containing the billed amount, tax, PO number, and line-item references	cXML-sending capability, or entry via the Ariba Network portal
StatusUpdateRequest	Supplier → Buyer	Status-update notification for orders and shipments	cXML-sending capability
PunchOutSetupRequest	Buyer → Supplier	Request to start a PunchOut (external catalog) session	The supplier’s e-commerce site must support cXML PunchOut
PunchOutOrderMessage	Supplier → Buyer	Returns items selected during PunchOut to the Ariba cart	cXML PunchOut implementation on the supplier’s e-commerce site

cXML Communication Specifications

• Protocol: cXML messages are sent via HTTPS (TLS 1.2 or higher) POST

• Authentication: SharedSecret (HMAC-based). The request header carries the NetworkID (ANID), sender, receiver, and SharedSecret

• Via the Ariba Network: messages are relayed along the path Buyer → Ariba Network → Supplier. Ariba, as the relay, handles receipt confirmation, retransmission management, and error notification

• Direct Connect: a method in which the supplier’s ERP system sends and receives cXML directly to and from the Ariba Network through the “Ariba Network Adapter.” Intended for large-scale suppliers

Note: cXML also requires the supplier to implement an endpoint (an HTTPS URL) and receiving processing (ingestion into their ERP). Because this represents a high technical bar for small suppliers, it is realistic to use it alongside manual entry into the Ariba portal depending on the supplier.

3-2 EDI (X12/EDIFACT) Integration

Ariba’s EDI Gateway Support

The Ariba Network offers not only cXML but also EDI gateway functionality that supports EDI (Electronic Data Interchange) standards (ANSI X12 and EDIFACT). Large suppliers with an existing EDI environment (EDI via a VAN) can connect to Ariba by leveraging their existing EDI infrastructure without migrating to cXML.

EDI Integration Methods and Configuration

Integration Method	Description	Applicable Suppliers	Configuration Requirements
Ariba Network EDI Gateway (direct)	The supplier’s EDI system sends and receives EDI files directly to and from the Ariba Network’s EDI endpoint	Large and mid-sized suppliers with EDI capability	Partner connection setup in the Ariba portal; configuration of the EDI destination URL and AS2 or FTPS
Via a VAN (Value Added Network)	The supplier connects to EDI via an existing VAN. The VAN and Ariba interconnect (VAN-to-VAN integration)	Suppliers already using an existing EDI VAN	VAN-to-VAN connection setup is required, arranged through Ariba support
Via an EDI converter such as SEEBURGER	A commercial EDI converter/middleware performs EDI ↔ cXML conversion to connect to Ariba	Suppliers that have EDI but find cXML support difficult	Mapping design on the converter side (EDI ↔ cXML conversion rules) is required

Constraints of EDI Integration

• EDI Mapping Analysis is essential: not all transaction types in an existing EDI setup are necessarily supported by Ariba. Industry-specific special EDI segments and loops can fall outside Ariba’s standard mapping

• Supported X12 transaction sets: the major sets — 850 (purchase order), 855 (order confirmation), 856 (ASN), and 810 (invoice) — are supported, but industry-specialized sets (e.g., EDI 840, Request for Quotation) may not be supported

⚠ A compatibility check via “EDI Mapping Analysis” is essential before EDI migration. Where special transactions are involved, either treat them as out of scope and switch to portal entry, or consider additional custom development (which is not supported).

3-3 Integration via REST API and SOAP API

SAP Ariba APIs Portal (developer.ariba.com)

SAP publishes its API catalog on developer.ariba.com (the Ariba APIs Portal). It can also be referenced through the SAP API Business Hub (api.sap.com). As of 2026, the API landscape is as follows.

REST API (OAuth 2.0 Authentication)

API Group	Endpoint Overview	Authentication Method	Primary Use
Procurement APIs	CRUD operations on purchase requisitions, purchase orders, and invoices	OAuth 2.0 Application Key	Referencing/creating P2P objects from external systems (ERP, SCM)
Supplier Management APIs	Reading and updating supplier registration information and scorecard data	OAuth 2.0 Application Key	Real-time data synchronization with external credit-research systems
Ariba Network APIs	Sending and receiving purchase orders and invoices via the Ariba Network	OAuth 2.0 / cXML SharedSecret	Point-to-point connections as an alternative to EDI
Sourcing APIs	Referencing RFx events, responses, and award information	OAuth 2.0 Application Key	Exporting sourcing data to BI/analytics tools
Contracts APIs	Referencing contract workspaces and updating status	OAuth 2.0 Application Key	Integration with external CLM (Contract Lifecycle Management) systems

REST API Authentication Flow

Client (external system)

▶

OAuth 2.0 token acquisition

▶

Ariba API gateway

▶

Ariba backend (SaaS)

▶

Response (JSON)

Figure 2: Ariba REST API OAuth 2.0 Authentication Flow

• Step 1: the API consumer system sends its Application Key and Application Secret to the Ariba OAuth 2.0 endpoint to obtain an access token

• Step 2: the request is sent to the Ariba API endpoint with the access token attached in the Authorization header

• Step 3: the Ariba API gateway performs authentication verification and request processing, and returns a response in JSON format

• Token validity period: an issued token is valid for a set period (typically one hour); it must be reacquired once it expires

SOAP Web Service API

The SAP Ariba SOAP API is a web services API for exchanging RFx, contract, and supplier data in real time with ERP systems and the like. It is a WSDL-defined service that sends and receives SOAP messages over HTTP/HTTPS. Service specifications are published on the SAP Help Portal.

• Main SOAP services: Purchasing Document (purchase orders), Contract, Supplier Information, and Event (RFx events)

• Authentication: WS-Security (UsernameToken) or SSL certificate authentication

Note: REST API is the standard recommendation for new integrations. SOAP is intended for maintaining legacy integrations and continuing to use existing PI/PO integrations. SAP’s recommended policy is to choose REST API for new builds.

API Rate Limits and Handling Large Volumes of Data

⚠ The Ariba API has rate limits, and making a large number of API calls in a short period returns an HTTP 429 error. For bulk synchronization and batch integration of large data volumes, using CIG (IDoc/file-based) rather than the API is recommended. Using the API is appropriate for real-time lookups and sequential integration of small volumes of data.

Chapter 4: Additional Development and Customization Constraints

4-1 Basic Principles of SaaS Constraints

Because Ariba is delivered as SaaS (Software as a Service), it has fundamentally different extensibility limitations from ABAP customization in SAP ERP. As a characteristic of SaaS, “there is no access to the source code” and “SAP performs periodic upgrades,” so core modifications like ABAP custom code are structurally impossible by design. This is an intentional design choice made to ensure “upgrade safety.”

Category	Content	Implementation Method
✅ Configurable	Approval flows, workflow conditions, form fields, catalog display settings, notification messages, tolerances, tax settings, approval matrices	Configured via the Ariba administrator’s Configuration UI / Customization Manager
✅ Configurable	Adding sections/fields to registration questionnaires, adding custom fields (up to a limit), defining approval groups	Configured via the SLP administrator screen and the Guided Buying administrator screen
⚠ Possible with limitations (limited extension)	Complex conditional branching in custom forms, adding custom reports, complex logic in approval rules	Forms Builder / Reports Builder (GUI only, no scripting). Requirements that are too complex are limited by what combinations of GUI settings can achieve
❌ Not changeable (SaaS constraint)	Matching algorithms, status-transition logic, cXML communication specifications, the core UI structure, the data model, direct manipulation of database tables	Cannot be changed. A “fit-to-standard” approach, aligning business processes to Ariba’s standard functionality, is required
❌ Not changeable (SaaS constraint)	Adding ABAP custom code, implementing custom logic in a program	Ariba is a cloud application (non-ABAP). Embedding code is structurally impossible

4-2 Customization Manager (Configuration Management Tool)

The Ariba Customization Manager is a tool for managing configuration changes that a buyer organization’s administrator makes through the Configuration UI. It provides functionality for managing the change history, deploying to a test environment, and promoting to production.

Scope of Settings Manageable in Customization Manager

• Approval Flows: configuring multi-step approval rules based on conditions such as amount tier, organization, item category, and project code

• Custom Fields: adding custom fields to objects such as purchase orders, invoices, and events, specifying the field type (text, number, date, selection list, checkbox)

• Notification Templates: customizing the wording of email notifications such as approval requests, matching-error warnings, and deadline alerts

• Tax Code Mapping: managing the mapping table between Ariba tax codes and S/4HANA tax codes

• Organization Structure: registering and managing company codes, purchasing organizations, plants, and purchasing groups in Ariba

Limits on the Number of Custom Fields

Object	Approximate Maximum Number of Custom Fields	Notes
Requisition/purchase order (header)	Roughly 25 fields (depending on the contract)	Additional fields may require a purchase through SAP’s Customer Engagement Executive (CEE)
Requisition/purchase order (line item)	Roughly 10 fields	Line-item field limits are strict; a minimal design is recommended
Supplier registration (SLP)	Relatively flexible number of questionnaire sections/questions (though there is a complexity ceiling)	Custom fields are not available for Knowledge Project and new supplier-architecture projects
Sourcing events	A relatively large number of custom evaluation-questionnaire questions is allowed	Too many questions increases the response burden on suppliers, raising the risk of lower participation rates

⚠ The number of custom fields that can be added is limited by contract terms as a service restriction. If additional fields are required, consult SAP’s Customer Engagement Executive (CEE) to confirm additional service fees.

4-3 Ariba Extensibility Framework: Extension Options

Where functional extension beyond Ariba’s standard configuration scope is required, a “side-by-side extension” approach leveraging SAP BTP (Business Technology Platform) is adopted. Rather than modifying Ariba’s core logic, this approach builds an independent application externally and integrates it with Ariba.

Extension Type	Description	Developer	Constraints
In-App Extension	Customizations that can be configured within Ariba’s admin UI (forms, approval flows, custom fields, etc.)	The customer’s administrator (no coding required)	Limited to the functional scope of the Configuration UI. Adding code logic is not possible
Side-by-Side Extension	An independent application built on SAP BTP using Node.js/Java, etc., integrated with Ariba via the REST API. Can also be embedded into the Ariba UI via an iFrame	Developers (customer/partner) with SAP BTP development skills	Cannot intervene in Ariba’s core processing. A separate BTP license is required
SAP Integration Suite integration	Building integration flows between Ariba and external systems using SAP BTP Integration Suite (formerly SAP CPI)	Certified Integration Suite developers	Used for integration scenarios not supported by CIG. Design and testing effort is significant

4-4 The Reality of “Outsourcing to SAP” for Additional Development

For requirements that exceed Ariba’s customization scope (such as changing matching logic, implementing new business rules, or major UI changes), the nature of SaaS means it is structurally impossible for customers or partners to implement custom code themselves. Where such requirements arise, the following approaches are available.

• [Recommended] Business process change (fit-to-standard): align the business process side with Ariba’s standard functionality. This is the lowest-cost option and offers the highest upgrade resilience

• [A realistic alternative] Substitute implementation via a side-by-side extension: build a BTP application outside standard Ariba and implement supplementary functionality via the API. Since Ariba’s core is not touched, this is safe

• [Requesting a feature from SAP (Product Enhancement Request)]: submit an enhancement request for standard functionality to SAP through the SAP Influence portal. If accepted, it will be provided as standard functionality in a future release — however, the timing of acceptance and implementation is uncertain, and this does not provide an immediate solution

• [Consulting SAP Professional Services]: for particular integration scenarios or complex configuration requirements, implementation can be requested from SAP Professional Services or an SAP-certified partner. However, changes to SaaS core logic are out of scope for such engagements; only optimal implementation within the configuration scope can be outsourced

⚠ A request to “modify Ariba’s source code to add custom logic” is, by the nature of a SaaS product, something no one — including SAP itself — can fulfill. Business requirements that cannot be met by Ariba’s standard functionality must be addressed through one of: ① a business process change, ② a BTP side-by-side extension, or ③ a future standard-functionality request.

Chapter 5: Connection Setup with ERP (S/4HANA)

5-1 Overview of the Integration Architecture

Integration between SAP Ariba and SAP S/4HANA is carried out via SAP’s standard “CIG (Cloud Integration Gateway).” CIG is an SAP-provided, managed integration middleware that runs on SAP BTP (Integration Suite), and in principle allows a buyer organization to achieve configuration-based integration without coding. Since 2024, migration has been progressing from the old CIG (file-based) to the new CIG (a managed gateway on SAP BTP Integration Suite: Managed Gateway for Spend Management and SAP Business Network).

Buyer Side	Integration Layer (SAP BTP)	Ariba Side
SAP S/4HANA (the ERP itself)	SAP Cloud Connector	▶	CIG (Managed Gateway) on SAP BTP	▶	SAP Ariba (SaaS)

Figure 3: SAP Ariba ↔ S/4HANA Integration Architecture (via CIG)

5-2 CIG Connection Setup Procedure Detail

Step 1: S/4HANA-Side Foundation Setup (Basis Team Work)

• Installing the CIG Add-on: install the CIG integration add-on on the S/4HANA on-premise system. This activates the UI (SAP GUI) for certificate management, port definitions, and integration-scenario settings. On the cloud version (S/4HANA Cloud Public Edition), no add-on is required and standard integration is provided out of the box

• Creating a logical system (BD54): create the logical system “ARIBACIG” in transaction BD54. Used as the logical name that identifies the connection between Ariba and S/4HANA

• Configuring an RFC destination (SM59): create an RFC destination of HTTP connection type in transaction SM59. Configure the URL, port, and authentication information for CIG (SAP BTP). Multiple RFC destinations are often created for different purposes, such as “Ariba Buyer Portal” and “Ariba Test System”

• Importing the SSL certificate (STRUST): import Ariba’s SSL certificate (the CIG server certificate) into S/4HANA’s “SSL Client Standard” certificate repository via transaction STRUST. This sets up server-certificate trust for HTTPS communication. Managing the certificate’s expiration date is important, since expiration causes a connection outage

• Configuring the IDoc partner profile (WE20): define the partner profile used for IDoc transfer in WE20. Configure the outbound partner type, message type, and RFC destination

Step 2: Configuring SAP Cloud Connector

SAP Cloud Connector is a reverse proxy for securely connecting an S/4HANA on-premise system to SAP BTP (CIG). It is installed within the on-premise network and enables access from the BTP side to S/4HANA across the firewall.

• Installing Cloud Connector: install it on a Linux/Windows server on the same network as the S/4HANA server

• Connecting to the BTP subaccount: connect via the Cloud Connector’s web UI (default: https://localhost:8443) by entering the BTP subaccount’s region, account name, and user credentials

• Configuring backend-system (S/4HANA) mapping: register the S/4HANA host and port in Cloud Connector, and whitelist the resources (RFC destinations, URLs) that can be accessed from CIG

• Redundancy: in production, it is recommended to run Cloud Connector in a master/shadow two-instance configuration for redundancy, eliminating a single point of failure

Step 3: Integration Project Configuration in CIG (Managed Gateway)

After S/4HANA and Cloud Connector are configured, the integration project is configured on the CIG (the managed gateway on SAP BTP) side.

• Creating an integration project: create a project in the CIG admin screen, specifying the “target Ariba solution (Buying/Invoicing, Sourcing, etc.),” “ERP system type (S/4HANA On-Premise/Cloud),” and “backend connection to use (RFC destination)”

• Selecting integration scenarios: enable the data flows to be used (purchase-order transfer, goods-receipt integration, invoice matching, etc.). Click “Activate” for each scenario

• Mapping configuration: configure the mapping between S/4HANA’s organizational structure (company code, purchasing organization, purchasing group) and Ariba’s organizational structure. Define mapping rules for account-assignment categories (cost center, internal order, WBS element, etc.)

• Integration test (connection test): run “Connection Test” from the CIG admin screen to verify the connection between S/4HANA and CIG

Step 4: Ariba Tenant Configuration

• Configuring the Ariba realm: register the endpoint URL and authentication information for the CIG connection on the Ariba tenant

• Purchasing organization mapping: map Ariba’s Procurement Unit to the S/4HANA purchasing organization

• Approval group configuration: associate S/4HANA organizational units with Ariba approval groups

5-3 Key Integration Scenarios and Specifications

Integration Scenario	Direction	S/4HANA-Side Technology	CIG-Side Processing	Notes
Vendor master synchronization	S/4HANA → Ariba	DEBMAS (IDoc) or BAPI_VENDOR_GET	Receives IDoc → generates/updates the Ariba supplier record	Deletion only “inactivates” the record. Because it is a batch synchronization, there is a delay before it takes effect
Item master synchronization	S/4HANA → Ariba	MATMAS (IDoc)	Receives IDoc → generates the item master in Ariba	Assumes the item codes match between Ariba and S/4HANA
Requisition-to-purchase-order transfer	Ariba → S/4HANA	BAPI_PO_CREATE1 or PO_CREATE (IDoc)	Converts an approved Ariba requisition into a purchase order and transfers it	Mapping design for account-assignment categories (K/P/F, etc.) is the most critical item
Goods-receipt integration (GR)	S/4HANA → Ariba	MBGMCR (IDoc) or GOODS_MOVEMENT_CREATE	Reflects goods-receipt data in the Ariba purchase order’s receipt confirmation	Minimizing GR integration latency is important for 3-way matching
Invoice posting	Ariba → S/4HANA	MIRO/LIV (via proxy) or INVOIC (IDoc)	Posts an approved Ariba invoice into S/4HANA’s LIV	Tax-code mapping and payment-terms mapping must be designed in advance
Master purchase agreement generation	Ariba → S/4HANA	BAPI_CONTRACT_CREATE	Generates an S/4HANA master purchase agreement (Outline Agreement) from Ariba award information	Not all contract types are supported; service contracts should be confirmed separately

5-4 CIG Error Handling and Monitoring

• CIG Monitoring: message-transfer status can be monitored in real time from the CIG admin screen on SAP BTP. Error status, error details, and a retry function are provided

• Common errors and remedies: the majority of errors involve mismatched supplier codes (unsynchronized between S/4HANA and Ariba), missing tax-code mappings, an unconfigured account-assignment category, and unfilled required IDoc fields

• Alert configuration: configure an automatic email notification when errors exceed a threshold, to prevent overlooking batch-processing errors

• SAP support via SAP for Me: when contacting SAP support about a CIG connection error, collecting the information required by SAP Note 3043644 in advance (realm name, integration project name, the process ID of the error message, etc.) leads to a faster resolution when raising the inquiry

Chapter 6: Technical Detail of the Ariba Network (ANID)

6-1 ANID and Supplier Account Types

Each supplier has a unique identifier called an ANID (Ariba Network ID) on the Ariba Network. Transactions between buyer and supplier are established through a network connection between ANIDs. There are multiple supplier account types, differing in functionality and cost.

Account Type	Cost	Functionality Provided	Constraints
Standard (formerly Supplier Lite)	Free (up to a certain number of transactions)	Basic functionality for receiving purchase orders, confirming orders, and sending invoices; manual operation via the Ariba portal	No EDI integration, no API integration, no PunchOut, no invoice format customization, no advanced portal management features
Enterprise (formerly the paid version)	Volume-based usage fee depending on transaction volume	EDI integration, API integration, PunchOut support, advanced supplier-portal management, multi-site management, invoice template customization	An annual cost burden is incurred on the supplier side (ranging roughly from several hundred thousand to several million yen depending on transaction volume and functionality)

⚠ PunchOut (external catalog connection) requires Enterprise or higher. Where a buyer requires PunchOut from a supplier, the supplier must have an Enterprise contract, so the design needs to take the resulting cost burden on the supplier into account.

6-2 Supplier Connection Options (Choosing a Technical Approach)

Supplier ERP (SAP, Oracle, etc.)

▶

EDI / API / cXML conversion

▶

Ariba Network (ANID gateway)

▶

Buyer’s Ariba Tenant

Figure 4: Connection Flow from a Supplier to the Ariba Network (Multiple Routes)

Connection Method	Technology	Supplier-Side Requirement	Applicable Scenarios
Manual entry via the Ariba portal	Web browser operation	Internet access only	Small suppliers, suppliers with limited IT capability, or low transaction volumes
Direct cXML connection	cXML over HTTPS	Implementation of a cXML send/receive endpoint, integration with the ERP	Mid-sized to large suppliers with an ERP system (SAP, Oracle, etc.)
Via an EDI gateway	X12/EDIFACT EDI (AS2, SFTP)	Leveraging an existing EDI system, or a contract with an EDI service provider	Large suppliers with an existing EDI environment
Converters such as SEEBURGER / OpenText	EDI/cXML conversion middleware	A converter product license	Suppliers with an EDI system that does not support cXML
Ariba Network Adapter (for SAP ERP)	SAP Ariba Network Adapter (add-on)	Add-on installation on the SAP system	Suppliers running SAP systems who want to use standard integration

Chapter 7: Rollout Design and Change Management

7-1 Phased Rollout Approach

Attempting to implement all of SAP Ariba’s functionality at once causes change management, technical configuration, and supplier onboarding to occur simultaneously, making the effort unmanageable. The following phased rollout approach is a realistic pattern for success.

Phase	Approximate Duration	Target Modules	Milestone
Phase 1: Foundation building	Up to 6 months	CIG integration setup, Spend Analysis, SLP (basic registration)	Completion of master-data synchronization with S/4HANA; completion of Ariba registration for key suppliers (the top 20)
Phase 2: P2P automation	6-12 months	Guided Buying, Buying & Invoicing, Ariba Network onboarding	Electronic ordering and electronic invoice matching operational for major suppliers. 3-way match automation rate of 70% or higher
Phase 3: Strategic sourcing	12-24 months	Sourcing (RFQ/RFP/auctions), Contracts, Supplier Risk	50% or more of the annual procurement categories run through Ariba sourcing. SLP risk scores established for all suppliers
Phase 4: Supply chain collaboration and AI	24 months and beyond	Supply Chain Collaboration, advanced Spend Analysis, Joule AI	Demand forecast sharing, ASN automation, AI-driven spend-optimization proposals

7-2 Practical Points for Supplier Onboarding

• Setting priorities: target major suppliers first (the roughly 20% of suppliers accounting for the top 80% of spend), and address the long tail in stages

• Participation incentives: for suppliers reluctant to bear the cost, a combined approach is effective — “the buyer covers the Lite transaction fee” and “notify suppliers, as a documented policy, that orders cannot be placed without participation”

• Response by IT capability: large suppliers capable of EDI/API integration → connect via EDI/cXML; suppliers proficient with portal operation → hosted catalog/portal entry; suppliers with low IT capability → hands-on training and a help desk

• Onboarding rate target: set 100% onboarding of key suppliers (the top 20) by the end of Phase 1 as the first KPI

Summary: What Ariba Implementation Can and Cannot Do

Category	Content
✅ What it can do	Digital procurement, electronic ordering, and electronic invoice matching using the 5-million-plus-company Ariba Network; visualization and governance of the entire S2P process; configuration-based approval-workflow design; strategic sourcing via RFx/auctions; ESG supplier management; S/4HANA integration via CIG
⚠ Possible with conditions	Adding custom fields (within the limit), conditional branching in forms (complex logic is limited by the GUI), BTP extension via side-by-side applications, supplier integration via EDI/API (Enterprise or higher)
❌ What it cannot do	Adding ABAP custom code, changing matching algorithms, changing the core UI structure, extending the data model beyond the SaaS standard, implementing business logic through custom code

(This document was prepared based on the SAP Help Portal, the SAP Community, and publicly available SAP materials (2025-2026).)