Understanding the Ariba Buying Requisition-to-Order Process
Introduces the core purpose of SAP Ariba Buying and walks through the end-to-end requisition-to-purchase-order flow that every consultant must understand before touching configuration.
Explanation
SAP Ariba Buying is the procurement module within the SAP Ariba Cloud Integration suite that lets employees create purchase requisitions, route them for approval, and convert them into purchase orders that are transmitted to suppliers. It exists because organizations need a controlled, auditable way for non-procurement staff to buy goods and services without bypassing negotiated contracts, preferred suppliers, or budget controls. Before diving into configuration, a consultant must understand the functional shape of the process: a requisitioner (often called a 'shopper') logs into the Ariba Buying and Invoicing or Ariba Buying solution, searches catalogs or creates a non-catalog line item, and submits a shopping cart. That cart becomes a requisition once submitted. The requisition then flows through an approval process defined by approval flow rules, which can be based on dollar thresholds, commodity codes, cost centers, or organizational hierarchy. Ariba's approval engine evaluates these rules at submission time and generates a dynamic approval chain. Once fully approved, the requisition is converted into one or more purchase orders. Order splitting can occur based on supplier, ship-to location, or accounting distribution differences within a single cart. The resulting PO is then transmitted to the supplier through one of several channels: cXML via SAP Business Network, EDI, fax, or email, depending on how the supplier is enabled. Understanding this flow matters because every downstream activity -- catalog design, approval configuration, integration mapping -- exists to serve this core loop. A beginner consultant should be able to trace a requisition from cart creation through approval to PO transmission and explain why each step exists. It's also important to understand the distinction between Ariba Buying (procurement-focused, often paired with a separate invoicing or ERP-based invoicing process) and Ariba Buying and Invoicing (which bundles invoice reconciliation in the same cloud tenant). Deployment context varies: some customers run Ariba Buying integrated with an on-premise ECC or S/4HANA system for financial postings and goods receipt, while others use the fully cloud Buying and Invoicing bundle with lighter ERP touchpoints. The requisition object itself carries header data (requester, need-by date, ship-to, business unit) and line-item data (commodity, quantity, price, accounting split). Each line can source from a catalog item, a contract, a punch-out session, or be entered manually as non-catalog. This flexibility is powerful but also a common source of governance problems if catalogs and contracts aren't well maintained, because requisitioners will default to non-catalog free text when catalog content is poor, undermining spend visibility. Finally, understanding the master data dependencies is essential: users, approval hierarchies, commodity codes, cost centers/accounting codes, and supplier records must all be loaded and synchronized (often from the ERP) before the Buying process can function correctly. A beginner should recognize that Ariba Buying is not a standalone island -- it depends heavily on upstream master data quality and downstream ERP integration for a complete transaction lifecycle.
Real project scenario
On a mid-size manufacturing client's Ariba Buying rollout, the project team spent the first two weeks purely mapping the requisition-to-PO flow against the client's existing paper-based purchase request process. This exercise revealed that the client had three different informal approval paths depending on plant location, which had to be reconciled into a single configurable approval flow before any catalog or integration work could begin, avoiding costly rework later.
Common mistakes
• Assuming Ariba Buying works standalone without dependency on ERP master data such as cost centers and GL accounts • Confusing Ariba Buying with Ariba Buying and Invoicing when scoping a project, leading to missed invoicing requirements • Underestimating how much requisitioners will bypass catalogs if catalog content is incomplete, resulting in poor spend visibility • Not distinguishing between requisition approval and PO approval when explaining the flow to business stakeholders
Best practices
• Always map the client's current purchasing process before configuring approval flows or catalogs • Clarify early whether the engagement is Ariba Buying alone or Buying and Invoicing bundled • Validate that master data feeds (users, cost centers, commodity codes) are scheduled and tested before UAT begins • Document the requisition lifecycle diagram as a reference artifact for both functional and technical teams
Interview angle
Interviewers commonly ask candidates to explain the requisition-to-PO lifecycle in their own words and to identify where order splitting or approval routing decisions occur; being able to clearly narrate the flow and its master data dependencies signals real hands-on experience versus theoretical knowledge.