Invoice Exception Resolution & Month-End Close
A three-way match exception between a purchase order, receipt, and invoice lands in the AP queue two days before close. Resolving it today means bouncing between the ERP, procurement, a ticket, and email — then doing it again for every similar exception, every month.
The Goal
What you'd actually type to Dendr AI
Natural-language input
“Resolve the invoice mismatch on PO-48213 and clear the AP exception before month-end close.”
The Ecosystem
Agents & MCP servers orchestrated
ERP / Financials
Oracle Fusion Financials
Illustrative vendor
Source of invoice and GL data; posts the resolved entry.
Procurement
Oracle Procurement Cloud
Illustrative vendor
Source of PO and receipt data for the three-way match.
Exception ticketing
ServiceNow
Illustrative vendor
Creates and tracks the AP exception record and approval.
Payment
Banking / payment rails
MCP server
Releases or holds the adjusted payment.
Collaboration
Slack
Illustrative vendor
Notifies the AP team and controller in real time.
Communication
SMTP / Graph MCP
Sends the resolution notice to the vendor.
How It Works
How the Dynamic Planner builds the chain
The Intent Engine structures the goal above into an intent graph. The Dynamic Planner grounds each step against the live Agent Capability Graph and assembles the coordination path at request time — no one pre-authored this exact sequence.
Pull invoice detail and match status from Oracle Financials.
Pull PO and receipt detail from Oracle Procurement Cloud to identify the mismatch cause.
Compute the resolution (quantity, price, or receipt adjustment) against configured tolerance rules.
Open an AP exception record in ServiceNow, tagged to the controller's review queue.
On approval, post the adjusting entry back to Oracle Financials.
Release the payment instruction to the payment agent, or hold it if still out of tolerance.
Notify the AP team in Slack and send the vendor a resolution email.
Semantic Routing in Action
The right agent, every time
The tag erp.financials.invoice.read matches Oracle Financials exactly — no ambiguity, no semantic guessing.
The tag ticketing.exception.create is domain-filtered to the internal finance-ops registry, so it routes to ServiceNow and never to a customer-support ticketing agent sharing the same generic tag.
If two payment agents are registered, the router semantically tie-breaks on currency and settlement-time metadata rather than picking arbitrarily.
Approve Once. Use Anytime.
Chain-level authorization, reused on every run
- The controller reviews and authorizes the “AP exception resolution” plan pattern once, at the chain level — covering read, ticket-create, post, and pay in a single approval.
- Every subsequent mismatch that fits the pattern runs automatically under that same authorization, with only the PO number and dollar amounts changing.
- If the pattern itself needs to change (e.g., add a tax-review step), that's a structural edit to intent, which routes back through the Review Gate before it can run.
Dynamic Replanning & Resilience
What happens when reality doesn't match the happy path
If Oracle Financials is mid-maintenance-window, the planner detects the unreachable node during grounding and queues the chain rather than posting against stale data.
If the mismatch amount exceeds tolerance for auto-resolution, the planner reroutes the ServiceNow ticket to a senior approver tier instead of auto-posting.
Business Outcome
What the finance team gets
AP exceptions clear in hours instead of spanning multiple close cycles.
Controllers approve a pattern once instead of re-approving every recurring exception.
Every resolved exception carries a signed, append-only record — audit- and SOX-ready without extra reporting work.
Related
More from Financial Services
See how finance teams close faster with Dendr AI.
Get a demo and see the AP exception chain run against your own registered agents.
Oracle, ServiceNow, and Slack are referenced above as illustrative, recognizable examples of the enterprise systems Dendr AI can orchestrate through A2A, MCP, vendor adapters, or OpenAPI manifests. These are reference architectures, not case studies of named customers, and do not imply a partnership, integration certification, or endorsement by those vendors.