Imaginary example: a machine shop's accounts payable receives 72 invoices per month. The agent reads them all and stops four. This is not a flaw — it's the most important feature of the entire system. Today we build an invoice and receipt verification agent whose brake is designed, not accidental.
The figures are illustrative, not customer results. The problem is familiar: invoices come as attachments and scans, purchase orders are in the ERP, contract prices are in another table, and a human skims through them in a hurry. A regular chat answers a question. An agent has a goal, tools, and a termination condition — and it's the termination condition that decides: when can the agent move the issue forward and when must it stop.
Trigger: a new invoice arrives in accounts payable
The trigger is dull and precise: a new invoice arrives in the accounts payable email inbox. The agent's goal is to verify the invoice against the purchase order, contract price, and receipts and prepare it for approval — or stop and explain why. Copy this task brief: Verify the batch of invoices. Match each invoice to the purchase order and valid contract. Note deviations with sources. Do not approve anything yourself. If evidence is lacking, stop and transfer to a human.
The agent plans first, then reads the entire batch
Before the agent touches anything, it makes a plan: which fields to check, where to get the information from, and what the approval threshold is. Then it acts: reads scanned receipts as images and PDF invoices, extracts amounts, VAT rates, dates, and account numbers, retrieves the purchase order from the ERP and the contract price from the table. It processes the entire batch at once — invoices and their attachments in one run — and writes on each line where the figure came from.
Stop rules are absolute
Here is the core of the video. The agent has stop rules, and they are absolute. The amount exceeds the purchase order beyond the agreed tolerance, stop. The same receipt appears twice, stop. The supplier's account number is different from the registry, stop. The amount is unclear in the scan, stop. The VAT rate is missing, stop. In ambiguous cases, the agent does not guess or fill in the gap itself: it marks that the evidence is insufficient and leaves the invoice in the queue. No passwords are given to the agent, and personal data is kept to a minimum.
The human decides – the agent prepares
The agent never approves a payment. It prepares a decision proposal: invoice, attachments, reconciliation to the purchase order, reason for deviation, source reference, and suggested action. The human sees the exception queue — in this illustrative example, four invoices — and decides: approve, request further clarification, or return to the supplier. Routine proceeds without handling, but money doesn't move without a human.
Suitable when data is machine-readable
When is this suitable? When the number of invoices is so large that visual inspection begins to slip, and when purchase order and contract data are in machine-readable form. When not? If prices and approvals rely on human memory, the agent just moves the ambiguity forward faster. Implementation requires three things: written stop rules, agreed tolerances, and who can open a stopped invoice. A safe next step is one batch of invoices and one process description — not the entire accounting at once.
The inspector agent evaluates – and stops
The inspector agent is a separate entity with a different task: it doesn't look for errors in invoices but in the work output. It checks three things: does each figure have a traceable source, were stop rules followed, and were approval criteria met. Illustrative example: the worker agent had marked the invoice green, but the amount was unclear in the receipt scan — 148.00 or 148.80. The inspector doesn't deduce or guess, it returns: insufficient evidence, stop. The workflow is corrected so that an unclear scan figure never goes through automatically. The inspector operates on a fail-closed principle: if evidence, permissions, or criteria are insufficient, nothing is published.
Three takeaways. One: the agent's value is not in what it approves, but in what it stops — stop rules are written beforehand, not afterward. Two: humans retain decision-making power, the agent prepares and justifies. Three: a separate inspector agent checks sources and criteria and stops if the evidence is insufficient.
Exercise
Create a table with five fictional purchase invoices and one receipt (no real personal data, no passwords, invented amounts). Write a task brief for the agent following the video model, define three stop rules (e.g., amount exceeds purchase order, account number doesn't match, amount unclear in scan) and one approval criterion. Run the agent through the batch and include one intentional error. Then ask a separate inspector agent to check if each figure has a source and if the error was stopped. If the inspector doesn't find a deficiency, your criteria are too loose — tighten them and run again.
Checklist
- Each invoice line shows the source: where the amount, VAT rate, and account number were obtained.
- At least one stop rule was triggered by the intentional error, and the invoice remained in the human queue without approval.
- The inspector agent returned at least one deficiency or ambiguity in writing, and the workflow did not proceed automatically.
- No passwords or extra personal data were given to the agent — only the minimum required for the task.
- Each stopped invoice has a named person who can open and resolve it.
— Aino Pilvi, AI Specialist, Cloud Computing Oy
Questions? aino@cloudcomputing.fi | WhatsApp: +358 33 119 3196
