The order query system worked. Teams were using it every day. Customer service wasn't navigating four screens any more. Sales could check commission data from their phone. Operations stopped calling colleagues for status updates. One deployment, three departments, daily use.
So the question became: what's next? The infrastructure was already there. The trust was already there. And there was a workflow sitting two steps away that had the same shape as the one we'd just solved — structured data, predictable queries, a high volume of manual steps that should be automatic.
Supplier invoice reconciliation. Here's what we're building.
The problem: manual invoice matching at scale
The client receives supplier invoices across multiple product lines. Each invoice needs to be matched against a purchase order — quantity, unit price, line items, delivery reference. When they match, the invoice moves to payment. When they don't, someone has to investigate.
At low volume, that's manageable. At scale, with dozens of suppliers and hundreds of invoices per month, it becomes a full-time job just to process the incoming stack — before anyone starts investigating the exceptions. The matching itself is mechanical: compare field A in the invoice against field B in the PO. Flag any line where the values differ by more than a threshold. Route flagged invoices to a human for review. Clear the rest.
This is exactly the kind of workflow AI agents are suited for. The rules are consistent. The data is structured. The exception cases are well-defined. The only reason a human is doing it today is that no one has built the automation layer yet.
The infrastructure underneath
The invoice reconciliation agent runs on the same core stack as the original ERP query layer — Claude for NLP, FastAPI for routing, Langgraph for orchestration, direct ERP API integration. For the full architecture of that deployment, see the case study. Here we focus on what's different: instead of answering a query about a record, this agent processes records automatically — matching, comparing, flagging, and routing without waiting for a human to initiate anything.
What we're adding: the invoice reconciliation agent
The agent operates as a background process. When an invoice arrives — via email attachment, supplier portal export, or direct API feed — the agent:
- Parses the invoice fields (supplier, PO reference, line items, quantities, unit prices, totals)
- Retrieves the matching purchase order from the ERP via the existing API integration
- Compares invoice lines against PO lines, field by field, with configurable tolerance thresholds
- Marks clean matches as cleared and queues them for payment processing
- Flags exceptions with a structured summary: which field diverged, by how much, and the raw values from both documents
- Routes exception flags to the appropriate reviewer via the existing WhatsApp/Teams interface
The reviewer receives a message: "Invoice INV-2847 from Supplier X has a unit price discrepancy on line 3: PO shows $14.20, invoice shows $15.80. Approve for payment, flag for dispute, or request clarification?" One response. The system handles the rest.
This is what we mean when we say one workflow changes how clients think about AI — it shifts the conversation from "what can AI do?" to "what should we automate next?"
Stack: same infrastructure, new skill layer
No new infrastructure is required. The existing deployment already handles authentication, ERP connectivity,
message routing, and orchestration. The invoice reconciliation agent adds one new Langgraph skill node —
InvoiceMatchSkill — that plugs into the same pipeline.
The only new integration is document ingestion — getting invoices from wherever they currently arrive (email, supplier portal, FTP) into the pipeline. That's the unsexy part of the build, and typically the most variable. Once it's in, the matching logic is consistent.
What changes for finance and operations
The finance team stops manually matching invoices. The ops team stops fielding supplier calls about payment status — the agent handles confirmation messages automatically for cleared invoices. The AP backlog shrinks. Exception handling becomes the job, not invoice processing.
The shift is structural: instead of a person spending 60% of their time on matching and 40% on exceptions, the agent handles the matching and the person focuses entirely on exceptions. That changes what the role looks like, and it changes what the team can handle without adding headcount.
This isn't a replacement for an accounts payable system. The ERP remains the system of record. Approved invoices still flow through the same payment process. What changes is the ingestion and triage layer — the part that currently requires a human to open each invoice, look up the PO, and decide if they match.
AskOps: the same conversational layer, extended
The order query system and the invoice reconciliation agent are both expressions of the same pattern: AskOps, IntelliconnectQ's conversational ERP interface. One deployment handles natural language queries. Another handles automated document processing. The infrastructure is the same. What changes is the skill being applied.
This is also why production deployments of this kind compound. Once one workflow is running on a shared infrastructure, the second costs a fraction of the first. The integration is already done. The trust is already established. The next deployment is a new skill node, not a new project.
For Dynamics 365 Business Central teams, AskOps is bundled into OpsGrid — our full decision intelligence layer for BC, currently in active beta.