Three?way match stalls in SAP Ariba and Oracle; exception center routed breaks with governed approvals

Overview

A biotech’s procure?to?pay flow generated frequent exceptions because three?way matches stalled and ownership for resolution was unclear. Invoices bounced between AP, buyers, and suppliers, while write?offs and manual matches were approved inconsistently. Intelligex implemented an exception center integrated with SAP Ariba and Oracle, routed issues to buyers or vendors using transparent rules, and required finance approvals for write?offs and manual overrides. Open exceptions declined, re?opened cases became uncommon, and cycle times through the match process improved—without changing Ariba, supplier portals, or Oracle Financials.

Client Profile

• Industry: Biotechnology (R&D, clinical operations, and manufacturing support)
• Company size (range): Multi?entity structure with centralized AP and distributed buying
• Stage: SAP Ariba for sourcing and P2P; Oracle Financials Cloud for ERP; three?way match managed with email and spreadsheets
• Department owner: Finance & Accounting (Accounts Payable and Controllership)
• Other stakeholders: Procurement, Site Operations, Lab and Clinical Functions, IT/Integrations, Supplier Management, Internal Audit, Quality/Compliance

The Challenge

Three?way match breaks surfaced daily: unit price or unit of measure differences, tax and freight treatment, partial receipts, duplicate invoices, and blanket PO drawdowns that fell outside tolerances. AP analysts worked exceptions by emailing buyers and suppliers and recording notes in individual trackers. Buyers focused on moving work forward and often approved ad hoc corrections or asked AP to force matches in the ERP. Suppliers resubmitted invoices with slight changes, creating version drift and rework.

Ownership was ambiguous. Some categories expected buyers to resolve quantity and receipt questions; others expected AP to drive supplier corrections. When shipments arrived before PO changes made it through approval, AP held invoices until buyers updated the PO, then retried the match. Credits, returns, and short shipments complicated close, and write?offs lacked consistent rationale or approvals. Aging reports listed exceptions without standardized reason codes or a clear route to resolution.

Audit and compliance pressures grew. Research and clinical categories carried tighter documentation needs, but artifacts lived in inboxes or supplier notes. During close, AP cleared backlogs with manual matches and adjustments that were hard to trace later. Leadership wanted a single, governed path that assigned owners, enforced tolerances, and captured approvals and evidence before entries posted.

Why It Was Happening

Root causes were fragmented workflows and ungoverned rules. SAP Ariba held POs and receipts; Oracle held invoices and posting rules; suppliers worked through portals or email; and exceptions were stitched together in spreadsheets. Matching tolerances, tax handling, and freight rules existed in documents, not in a shared engine. Identity mismatches—supplier names, site codes, or item masters—forced manual checks. Without a central queue, cases ping?ponged between teams with inconsistent outcomes.

Approvals for write?offs and manual matches lived in email threads, and reason codes were inconsistent. Metrics focused on volumes rather than on drivers, so recurring issues (like a supplier’s unit of measure practice or a category’s freight policy) were not addressed at the source.

The Solution

Intelligex delivered an exception center that sat between SAP Ariba and Oracle Financials. Exceptions were classified with standardized reason codes and routed automatically to buyers, suppliers, or AP based on policy. The service read PO, receipt, and invoice data, evaluated tolerances, tax and freight treatment, and receipt sufficiency, then produced suggested actions—request a corrected invoice, adjust the PO, complete a receipt, or propose a credit. Maker?checker approvals were required for write?offs and manual matches. Approved outcomes flowed back to Ariba or Oracle. Integrations leveraged SAP Ariba and Oracle Financials Cloud integration patterns.

• Integrations: PO, receipt, and supplier data from SAP Ariba; invoice and AP subledger data and posting outcomes in Oracle Financials Cloud; supplier communications via existing portal or email relay; notifications to collaboration tools.
• Exception classification: Standard reason codes for price variance, quantity/receipt mismatch, unit of measure, tax or freight handling, duplicate invoice, missing PO/receipt, and supplier identity conflicts.
• Routing rules: Buyer?owned for PO/receipt issues; supplier?owned for invoice corrections; AP?owned for duplicates, tax, freight, and posting controls; escalations based on category and dollar impact.
• Tolerance evaluation: Policy?based checks for price and quantity tolerances, freight adders, and tax treatment; effective?dated changes with approval logs.
• Action proposals: Suggested next steps and templates—PO change request, receipt completion reminders, supplier correction request, credit memo guidance—pre?filled with context and links.
• Approvals and governance: Maker?checker for write?offs and manual matches; reason codes and attachments required; segregation of duties enforced.
• Dashboards and SLA tracking: Exception aging, top suppliers/categories by break type, repeat offenders, and bottlenecks; SLA timers for buyer and supplier actions.
• Audit trail: Immutable logs for classifications, actions, communications, approvals, and postings; evidence packs downloadable by period.

Implementation

• Discovery: Mapped current three?way match flows, exception types, and category policies; inventoried Ariba and Oracle data fields and integration points; reviewed supplier behavior and common break patterns; gathered audit and compliance requirements, including documentation standards for sensitive categories.
• Design: Defined reason codes and routing logic; authored tolerance and tax/freight rules with effective dating; designed action templates and communication paths; specified maker?checker tiers for write?offs and manual matches; planned dashboards, SLA metrics, and audit exports.
• Build: Integrated Ariba PO/receipt and Oracle invoice/posting data; developed exception classification and routing services; implemented tolerance checks and action templates; configured approvals and evidence capture; assembled dashboards and notifications; set up email relay to suppliers where portal updates were insufficient.
• Testing/QA: Ran in shadow mode: classified live exceptions while teams continued current methods; compared suggested actions to historical resolutions; tuned routing, tolerances, and templates; piloted maker?checker approvals with AP and Procurement.
• Rollout: Enabled the exception center for selected categories and sites first; retained spreadsheet trackers as a controlled fallback; expanded coverage as resolution rates stabilized; enforced mandatory approvals for write?offs and manual matches after training.
• Training/hand?off: Delivered sessions for AP, buyers, and supplier management on reading cases, using templates, and approving actions; updated SOPs for supplier corrections, PO changes, and receipt practices; transferred ownership of rules, dashboards, and reason codes to Controllership and Procurement under change control.
• Human?in?the?loop review: Established a recurring forum to review repeat break types, supplier performance, and rule updates; decisions recorded with rationale and effective dates.

Results

Exceptions moved through a single, governed queue with clear owners. Buyers handled receipt and PO issues with pre?filled context, suppliers received structured correction requests, and AP resolved tax, freight, and duplicate cases using consistent rules. Write?offs and manual matches required approval with documented rationale, which reduced re?opened cases and untraceable adjustments.

Visibility improved across Finance and Procurement. Dashboards showed where breaks originated—by supplier, category, or site—and which actions cleared them. Recurring patterns drove corrective measures such as unit of measure normalization, vendor education on tax and freight lines, or category?specific tolerance updates. Ariba and Oracle remained the systems of record; the addition was a routed exception process and approval layer that stabilized the match cycle.

What Changed for the Team

• Before: Exceptions lived in spreadsheets and inboxes. After: A governed queue classified and routed cases with reason codes and SLAs.
• Before: Ownership for fixes was unclear. After: Buyer, supplier, or AP ownership was assigned by rule with pre?filled action templates.
• Before: Manual matches and write?offs were ad hoc. After: Maker?checker approvals enforced policy with evidence and rationale.
• Before: Suppliers resubmitted guesswork. After: Correction requests specified exact changes with links to PO, receipt, and invoice lines.
• Before: The same errors recurred. After: Dashboards highlighted repeat patterns to fix root causes and update tolerances.
• Before: Audit support was reconstructed. After: Every resolution and posting carried a traceable trail and period evidence pack.

Key Takeaways

• Centralize exception handling; classify and route three?way match breaks through one queue.
• Encode policy; tolerances and tax/freight rules should be effective?dated and finance?owned.
• Assign ownership by rule; buyers fix PO/receipt issues, suppliers correct invoices, AP handles posting controls.
• Require approvals for impact; maker?checker on write?offs and manual matches reduces rework and strengthens controls.
• Use templates and evidence; pre?filled actions speed resolution and create consistent documentation.
• Integrate, don’t replace; keep SAP Ariba and Oracle while adding a governed exception and approval layer.

FAQ

What tools did this integrate with? The exception center read POs, receipts, and supplier data from SAP Ariba and invoices and posting outcomes from Oracle Financials Cloud. Supplier communications flowed through the existing portal or an email relay. Dashboards used the client’s BI environment, and notifications went to collaboration tools.

How did you handle quality control and governance? Tolerance, tax, and freight rules lived under Finance change control with effective dates and rationale. Each exception carried standardized reason codes, owners, and actions. Write?offs and manual matches required maker?checker approvals with attachments. All classifications, communications, approvals, and postings were immutably logged and exportable by period.

How did you roll this out without disruption? The service ran in shadow mode first, classifying and proposing actions while teams continued current methods. Results were compared to historical resolutions and tuned. Rollout started with targeted categories and sites, expanding as stability grew. Spreadsheet trackers remained as a controlled fallback during early cycles.

How were suppliers involved without creating more back?and?forth? Supplier requests were generated from templates that specified the needed correction, referenced PO and receipt lines, and included guidance on tax and freight. Responses flowed through the portal or email relay and landed back on the case, reducing guesswork and re?submissions.

What types of exceptions were auto?cleared vs. routed? Cases within defined tolerances or with clear receipt updates were auto?cleared after verification, while price variances, unit of measure conflicts, missing receipts, duplicates, and tax/freight discrepancies were routed to the appropriate owner with proposed actions and due dates.

How did this help with audit and compliance? Each resolution included the policy rule applied, the action taken, evidence (PO, receipt, invoice), and approval where required. Period evidence packs were generated from the same logs and templates used operationally, simplifying audit requests and internal reviews.