Review & approvals

Review is not a step bolted onto the end. It’s where the process is actually controlled: every case arrives with its source data, what the agent did, and why — and someone decides. Nothing critical leaves the system without an approval.

​

Statuses

A case moves through a lifecycle you can filter and report on: Needs review is the interesting one. It is not a failure state — it’s the agent declining to decide something it can’t decide safely. See honest uncertainty below.

​

Assignment

Cases can be assigned to people, so a queue is a queue and not a shared mailbox nobody owns.

• Assign a case to a reviewer.
• Assigned to me — a reviewer’s working list.
• Unassigned — everything nobody has picked up. Filter on it so cases don’t sit unclaimed.

Combine with status filters for the views your team actually works from: Needs review · Unassigned is where a controller starts their morning.

​

What a case shows

Open a case and you get the evidence, not a verdict:

• Source document — the original file, alongside the result.
• Input data — what came in: the payload, the file references, the trigger.
• Output fields — the structured result the agent produced.
• Reasoning — what the agent concluded and why, in its own words.
• The actions taken — the queries it ran, the files it read and wrote, the emails it drafted.
• References — the master-data records it matched against, so you can check the match rather than trust it.

A reviewer’s job is to check the reasoning against the source, not to redo the work.

​

Comments

Reviewers comment on a case — with @-mentions to pull in a colleague and attachments where they help. Comments aren’t just a paper trail. The agent reads them. A rejection that names the rule (“we never ship express to AT”) becomes something the agent can apply and, later, propose as an SOP change through the improvement loop.

​

Approval gates

Some actions wait for a human by design:

• Outbound communication — an email the agent drafted is a draft until someone approves it.
• Critical pushes — writing a result back into a connected system of record.

The agent does the work up to the gate: the reply is written, the fields are filled, the case is ready. A person’s decision is the last step, not the whole job. Your ERP stays the system of record. Nothing posts, pays, or leaves without an approval.

​

Agentic approval mode

Once a process is stable, having a person confirm every clean case stops being control and starts being throughput cost. Turn on Auto Review on the reconcile table and a second agent — an approval agent — checks each result before it reaches a human. It sees the agent’s output and its reasoning, checks them against the SOP, and looks for duplicates already in the table. Then it decides: It defaults to Needs review when it isn’t sure, and attaches a one-line comment saying why. You keep the exceptions; it clears the routine.

​

Honest uncertainty

When the agent can’t resolve something safely, it says so and shows its work:

Two candidate customers match “Meridian Handels” at postal code 8010 — customer 40118 (Meridian Handels GmbH, Ostbahnstrasse 14) and customer 40233 (Meridian Handels GmbH, Ostbahnstrasse 14a). The order carries no VAT ID or contact email to distinguish them. Flagged with both candidates.

That case gets Needs review with the candidates listed. No customer number was invented. This is the system working. An agent that guesses to keep its automation rate up is worse than useless in a finance process — the wrong answer costs more than the missing one. Cases that stay flagged are telling you where your procedure is genuinely ambiguous, which is exactly the input the improvement loop needs.