Read this first
Buying and Invoicing is not a screen. It is the document chain, and every module you bolt on inherits its rules.
Guided buying, Contracts, SLP and Supplier Risk all eventually deposit their output here: a requisition that has to price, a supplier that has to be transactable, a contract that has to be referenceable, an invoice that has to reconcile. Configure this layer badly and the symptom shows up somewhere else — a tile that produces a requisition nobody can approve, a contract that never reaches a purchase order.
The second thing worth internalising: Ariba does not post your invoice. It reconciles it and approves it, then hands it to the ERP. Most of the painful go-live incidents in this area are not Ariba configuration at all — they are documents that passed every Ariba check and then failed at the boundary, where nobody was watching a queue.
The build order
This order is not a preference. Each step is testable only once the one above it exists, and teams that start at step four because it is the visible one spend the rest of the project re-testing it.
| # | Layer | Why it sits here |
|---|---|---|
| 1 | Enterprise and ERP master data | Companies, purchasing units, accounting fields, suppliers, commodity codes, units of measure. Everything below inherits these; nothing above them can be tested without them. |
| 2 | Users, groups and permissions | Requesters, approvers, purchasing agents, exception handlers, AP. Group membership drives both what people see and where approval rules can route work. |
| 3 | Sourcing of prices: catalogs and contracts | Catalog content, PunchOut connections and contract price terms. Without them every requisition is a free-text line and every price is a variance waiting to happen. |
| 4 | Approval rules | Requisition, order, receipt and invoice reconciliation approval flows. Built after the group model, never before it. |
| 5 | Invoice exception types and tolerances | The matching rules. This is where AP policy becomes configuration. |
| 6 | Integration and document transmission | Order dispatch, receipt and invoice transmission to and from the ERP and SAP Business Network. |
| 7 | Supplier enablement | Trading relationships, transaction rules, PunchOut and catalog publication per supplier. Always the long pole in the plan. |
Master data and the ERP boundary
Decide, in writing, which system owns each object and which direction it moves. Suppliers, companies, accounting fields, commodity codes, units of measure and tax codes are almost always ERP-owned and loaded into Ariba. The moment two systems both believe they own one of these, you have a reconciliation problem that will be discovered by an invoice.
Then decide where goods receipt happens. One system of record. Receiving in both Ariba and the ERP without a clear master produces invoices that match in one system and not the other, and the investigation always costs more than the decision would have.
Answer before build
- Which system is the master for supplier records, and how are Ariba supplier IDs mapped to ERP vendor numbers?
- Which accounting fields are validated in Ariba, and which are only validated at ERP posting?
- Where does goods receipt happen — Ariba or the ERP?
- Which currencies, tax codes and units of measure are in scope on day one?
- Who monitors failed transmissions between Ariba and the ERP, and in which tool?
Requisitioning and catalogs
Every requisition line gets its price from somewhere: a hosted catalog, a PunchOut cart, a contract price term, or a person typing a number. The last one is the expensive one — free-text lines carry no agreed price, so they generate the price variances your AP team will spend their week on.
What to settle early
- Catalog coverage target per spend category, with an owner for content refresh.
- PunchOut connections tested end to end, including the return cart and its UOM and currency.
- Free-text policy: allowed, restricted to certain commodities, or routed through a buyer.
- Purchasing unit scoping, so a requester in one unit cannot order against another's content.
The catalog coverage test. Take the hundred highest-frequency purchases of last year and check how many can be bought from a catalog or contract price today. That number, not the module list, predicts how much manual work the go-live will create.
Approval rules
Approval rules are built on the group model, which is why the group model comes first. Rules that route to named individuals survive exactly until the first reorganisation; rules that route to groups survive it.
Four flows, not one
Requisition, purchase order, receipt and invoice reconciliation each have their own approval path. Teams routinely design the requisition flow in detail and leave the IR flow as an afterthought — then discover at go-live that exception approvals land on the requester, who has no basis to judge a tax variance.
Rule design tests
- Every rule routes to a group, and every group has at least two active members.
- Escalation exists for absence, and someone can name the escalation target.
- Approval thresholds match the written delegation of authority, in the same currency.
- Exception approvals route to handlers who can actually resolve that exception type.
- The flow is tested with a rejection and a resubmission, not only an approval.
Orders and receiving
The document chain below is the map to keep on the wall. Most production incidents are one hop in it failing quietly, and the fastest diagnosis is always to name the hop before touching configuration.
| Document | Direction | Notes |
|---|---|---|
| Requisition | Ariba | Created by requester or guided buying; approved before it becomes an order |
| Purchase order | Ariba to supplier / ERP | Transmitted to the supplier over SAP Business Network and, in most designs, replicated into the ERP |
| Order confirmation | Supplier to Ariba | Optional per transaction rules; a useful early signal that the PO reached a live account |
| Ship notice / ASN | Supplier to Ariba | Optional; drives receiving in some designs |
| Receipt | Ariba or ERP | Decide one system of record for goods receipt and stay with it — dual receiving is the most expensive reconciliation bug there is |
| Invoice | Supplier to Ariba | PO-based, contract-based, non-PO, or created by AP on the supplier's behalf where allowed |
| Invoice reconciliation | Ariba | Matching result plus exceptions; the object that gets approved |
| Payment / remittance | ERP to Ariba | Status returned so suppliers can see payment state without calling AP |
Set receipt requirements per commodity with the receiving reality in mind. Requiring a goods receipt for a service that nobody receipts is not a control — it is a permanent exception queue.
Invoicing channels
Decide which channels are open per supplier: PO-based invoices, contract-based invoices, non-PO invoices, and invoices created by AP on the supplier's behalf where your policy and local tax rules allow it. Each channel has a different control model, and the control model — not the channel — is what you are actually choosing.
Per-supplier transaction rules govern what a supplier may send: whether they can invoice above the PO quantity, add unplanned lines, change the tax, or invoice at all before a receipt exists. Suppliers with a track record and suppliers being onboarded this quarter should not share one rule set by accident.
Channel decisions to record
- Which suppliers may send non-PO invoices, and who approved that.
- Whether unplanned lines on a PO invoice are accepted, rejected, or accepted with an exception.
- Whether credit memos come through the same channel and who handles them.
- How paper and PDF invoices enter the process, if at all.
- Which tax determination is authoritative — supplier-supplied or system-calculated.
Reconciliation and exception tolerances
This is the section AP will live in. An invoice arrives, Ariba matches it against the purchase order and any receipts, and any difference outside tolerance becomes an exception on the invoice reconciliation document. The invoice is not rejected — it is held, and someone has to act.
| Exception | Raised when | Configuration note |
|---|---|---|
| Price variance | Invoice unit price differs from the PO or contract price | Set a tolerance in both percentage and absolute currency terms; a percentage alone behaves badly on very low and very high value lines |
| Quantity variance | Invoiced quantity exceeds the ordered or received quantity | Cheap to enforce strictly. Over-invoicing should stop, not route |
| Received quantity variance | Invoiced quantity exceeds what was receipted | Only meaningful if receiving discipline is real; if it is not, fix receiving before tightening this |
| Tax variance | Invoice tax differs from calculated or expected tax | Route to a tax-literate handler, not to the requester |
| Unit of measure mismatch | Invoice UOM differs from the PO UOM | Almost always master data, not supplier behaviour |
| Missing or blocked accounting | Accounting on the line is incomplete or invalid | Fails at the ERP boundary if it is allowed through; block it in Ariba |
| Duplicate invoice number | Same supplier and invoice number already received | Never auto-accept this one, whatever the amount |
The traps
Receipt-required set per commodity, not per policy
Requiring receipts on services with no receiving process guarantees a permanent queue of exceptions nobody owns
Tolerances copied from the demo tenant
Demo tolerances are generous by design. Production tolerances must match your AP delegation of authority in writing
Non-PO invoicing enabled by default
It bypasses PO and receipt controls, so it should be enabled per supplier and commodity with a named owner for the decision
Approval rules built before groups
Rules that point at ad-hoc individuals rather than groups become unmaintainable within one reorganisation
No unhappy-path test
Teams test a clean requisition to a clean invoice and go live. The first real exception then reaches an unstaffed queue
A useful sizing exercise before go-live: take last year's invoice population, apply your proposed tolerances on paper, and count how many would have raised an exception. If that number exceeds what your AP headcount can clear in a day, the tolerances are a staffing decision, not a control decision.
Pre-go-live checklist
Configuration
- Master data ownership documented per object, with direction of flow.
- One system of record chosen for goods receipt.
- Catalog and contract coverage measured against actual purchase frequency.
- Approval flows built for requisition, order, receipt and invoice reconciliation.
- Exception types and tolerances signed off by AP and finance, in writing.
- Transaction rules reviewed per supplier segment, not set globally by default.
Operations
- Every approval and exception queue has a named owner and a backup.
- Failed-transmission monitoring is assigned, with a named tool and a daily check.
- A full unhappy path is tested: variance, dispute, correction, resubmission, posting.
- Credit memo and duplicate invoice handling rehearsed before day one.
- Supplier enablement waves sequenced with the spend they carry, highest first.
- Cut-over plan covers in-flight requisitions, open POs and unmatched receipts.
Frequently asked questions
- What is SAP Ariba Buying and Invoicing?
- SAP Ariba Buying and Invoicing is the core procure-to-pay application: requisitioning against catalogs and contracts, approval flows, purchase orders sent to suppliers over SAP Business Network, receiving, and invoice reconciliation before the invoice is posted in the ERP. Guided buying is a front end on top of it, not a replacement for it.
- What is the difference between Buying and Invoicing and guided buying?
- Buying and Invoicing owns the transaction engine — requisitions, orders, receipts, invoice reconciliation documents, approval rules and accounting. Guided buying is a simplified requester experience that creates those same documents. If a requisition cannot be created in Buying and Invoicing because of missing master data, a policy or an approval rule, guided buying cannot create it either.
- What is an invoice reconciliation document in SAP Ariba?
- The invoice reconciliation (IR) document is the object Ariba creates when an invoice is matched against its purchase order and receipts. Exceptions raised during matching are attached to the IR, and the IR — not the invoice — is what exception handlers and approvers act on before the invoice can be released to the ERP for posting.
- Why does my Ariba invoice fail with an exception instead of posting?
- Because matching found a difference outside the tolerance configured for that exception type — commonly a price, quantity, tax or unit-of-measure variance, or a missing receipt on a receipt-required item. The invoice is not rejected; it is held on the invoice reconciliation document until the exception is accepted, disputed or the underlying document is corrected.
- Can suppliers send invoices without a purchase order in SAP Ariba?
- Yes, if you enable non-PO invoicing for that supplier and commodity. Treat it as a deliberate policy decision rather than a default: non-PO invoices skip PO and receipt matching, so the controls move entirely into approval rules and accounting validation.
- Does Ariba post the invoice or does the ERP?
- The ERP posts. Ariba reconciles and approves, then sends the reconciled invoice to the ERP through the integration layer, where the financial document is created. A green invoice in Ariba with no matching ERP document means the integration leg failed — check the transmission and the ERP-side error, not the Ariba approval flow.
Glossary
- Buying and Invoicing
- The core SAP Ariba procure-to-pay application covering requisitioning, ordering, receiving and invoice reconciliation
- IR document
- Invoice reconciliation document — the matching result and exception container that is routed for approval
- Exception type
- A configured category of matching difference, with its own tolerance and handling rules
- Tolerance
- The variance allowed before an exception is raised on an invoice line or header
- Non-PO invoice
- An invoice with no purchase order to match against; controlled by approval rules rather than matching
- Transaction rules
- Per-supplier and per-group rules governing what suppliers may send and what Ariba will accept
- PunchOut
- Catalog model where the requester shops on the supplier's site and returns a cart into the requisition
- Purchasing unit
- The organisational scoping object that decides which content, policies and rules apply to a requisition
- Accounting field
- An ERP-derived field, such as cost centre or GL account, validated on requisition and invoice lines