AP Invoice Processing & Exception Resolution - Projects

The business problem

Every Oracle ERP customer receives a steady stream of supplier invoices. Each must be validated against the supplier, purchase order, receipt, accounting, tax and approval rules before it can be paid.

Proposed solution

This flagship covers the whole Payables lifecycle in two connected workflows. Invoice Processing moves clean invoices from receipt to a validated Oracle invoice without manual keying. Exception Resolution investigates the invoices that stop on hold and resolves them or packages them for a decision.

The business value it targets: fewer manual touches, fewer errors, faster cycle times, fewer late-payment penalties and stronger controls.

Workflow

Receive Supplier Invoice
Extract Invoice Data
Validate Supplier Details
Match Purchase Order and Receipt
Perform Three-Way Match
Detect Discrepancies
Investigate Exceptions
Recommend Resolution
Obtain Human Approval
Update Oracle Records
Record Audit Trail

Agents and responsibilities

Part A: Invoice Processing (straight-through), getting clean invoices into Oracle with no manual entry

Intake & Extraction Agent: reads emailed PDFs, scans and e-invoices with multimodal Gemini or Claude vision. It extracts the supplier, invoice number, dates, currency, lines, tax and totals into a validated schema with field-level confidence; low-confidence fields go to review rather than being guessed.
Supplier & PO Agent: identifies the supplier and site from tax ID, remit-to address and bank details, then locates the purchase order and receipts. A change in supplier bank details is flagged as fraud risk.
Matching & Accounting Agent: performs a deterministic two-, three- or four-way match within tolerance. It defaults distributions and accounting from the PO, validates tax, and checks payment terms against policy.
Control checks: duplicate-invoice detection (same supplier and amount, fuzzy invoice-number match) and RAG over the AP policy. Clean invoices are created through the Payables invoice import and validated, with approval routed per the configured rules.

Part B: Exception Resolution (touchless investigation), clearing invoices that stop on hold

Hold Triage Agent: picks up invoices on price, quantity, receipt, tax or approval holds and classifies the true cause.
Investigation Agent: examines partial and late receipts, PO price changes, unit-of-measure mismatches and freight or miscellaneous charges, adding buyer and receiver context from Oracle.
Resolution Agent: releases holds that are within tolerance. Otherwise it requests a credit memo, drafts the supplier or buyer message, or routes the case to the buyer with a complete evidence pack.

Oracle ERP integration

Oracle objects: Invoices, lines and distributions, holds, purchase orders, receipts, suppliers and sites, payment terms; E-Business Suite AP_INVOICES_ALL, AP_INVOICE_LINES_ALL, AP_INVOICES_INTERFACE, AP_HOLDS_ALL, PO_LINES_ALL and RCV_TRANSACTIONS; Fusion REST resources and FBDI import.

Shared Oracle integration: a Python MCP server exposing typed read tools (Fusion Cloud REST resources, BI Publisher/OTBI reports, read-only SQL views for E-Business Suite) and a small set of write tools that execute only after human approval.

Technology stack

Project stack: Google ADK/Gemini and Claude Agent SDK/Claude (one workflow on two platforms) · CrewAI + MCP · OpenAI Agents SDK/GPT · Gemini and Claude vision

Orchestration: CrewAI crews define role-based agents, tasks and hand-offs. Oracle tools attach through CrewAI MCP server adapters, so every agent calls the same governed tool layer.
Agent runtimes: Claude Agent SDK with Claude is the primary build and reasoning runtime. It uses subagents for deep investigation, MCP for tool access, and pre-tool-use hooks that block any ERP write lacking an approval token. The same agents run on Google ADK with Gemini and OpenAI Agents SDK with GPT through a common model-adapter interface, switched by configuration.
Engineering: Python, Pydantic-validated agent outputs, a pytest scenario-evaluation harness comparing Claude, Gemini and GPT on accuracy, latency and cost, OpenTelemetry tracing and Docker, built in VS Code with Claude Code.

Controls and safeguards

The tolerance engine, not the model, decides what is in policy.
Agents never create payments.
A duplicate check runs before every release.
Anything out of tolerance needs human approval with evidence attached.
Grounding and control (shared platform): RAG over policies, contracts and approval matrices in Oracle Database 23ai AI Vector Search; a deterministic rule engine for tolerances, thresholds and SoD; an immutable audit log of evidence, tool calls, model, approver and outcome.

Validation plan

Scope: 300 invoices (clean, scanned, multi-line and foreign-currency) plus 120 exception scenarios, compared across Gemini, Claude and GPT.

Targets

Reference build in progress. The figures below are validation targets for the build, not measured results.

95%+ Header-field extraction accuracy
80%+ Straight-through processing of clean invoices
90%+ Correct root cause on exceptions
0 Out-of-tolerance releases or duplicate payments