AI Invoice Intake With Human Approval: A Workflow Guide

An AI invoice processing workflow works best when the agent does the reading and checking, and a person makes the decision to record. The agent receives each invoice, extracts the fields, compares them with what the company already knows, and prepares a proposed entry with its evidence. Nothing reaches the accounting system until a named approver accepts, edits or rejects that proposal.

Key takeaways

• The agent reads, checks and proposes. A person approves. The accounting system is written to only after that approval.
• Every proposed field carries its evidence: where on the document it came from and which checks it passed or failed.
• Checks against vendor records, open orders and earlier invoices catch more problems than better extraction alone.
• Duplicates, changed bank details and instructions hidden inside documents are the risks to design for first.
• Judge the workflow by approver corrections, time to decision and correctly blocked items, not by how many invoices the agent touched.

Why keep a person between extraction and recording?

Invoices look like clerical work, which makes them tempting to automate from end to end. The difficulty is that the cost of a mistake is not spread evenly. Most invoices are routine. A few carry a wrong amount, a duplicate, a changed bank account or a vendor that should not be paid. An agent that records everything treats all of them the same way, and the expensive ones are exactly the ones nobody notices until money has moved.

It helps to separate two different acts. Extraction is a reading task, and language models are good at it. Recording is a commitment: once an entry is in the ledger and queued for payment, the company is acting on it. Reading can be fast and forgiving. Committing should be slow enough for someone accountable to look.

That is the approval boundary. The agent has no authority of its own. It prepares work, shows its reasoning and waits. The approver owns the decision, and the log shows who decided what and when. If your team later wants to loosen the boundary for a narrow, well-understood class of invoices, you can do that deliberately, with evidence, rather than discovering by accident that the agent was already doing it.

The intake channel matters too. If invoices arrive by email, the agent should work from a dedicated mailbox rather than a person's inbox. The guide on how to connect an AI agent to email without risking your inbox covers the permissions that make this safe.

What does the intake flow look like, step by step?

Here is a flow that fits most small and mid-sized finance teams. Adjust the names to your own systems, but keep the order.

• Step one, receive: invoices arrive through one door, such as a dedicated mailbox or shared folder that belongs to the agent's own account. One door means nothing is processed that you cannot see.
• Step two, preserve: the original file is stored unchanged, with sender and received time, before anything else happens. Every later field can be traced back to this copy.
• Step three, extract: the agent reads the document and fills a fixed set of fields: vendor, invoice number, dates, currency, line items, taxes, total, payment details. Anything it cannot find is marked as not found, never guessed.
• Step four, check: the agent runs the checks described in the next section against vendor records, open orders and previous invoices.
• Step five, sort: each invoice is labeled clean, needs attention or blocked, with the reason in plain words.
• Step six, propose: the agent drafts the entry, including suggested coding, and places it in a review queue. The accounting system has not been touched yet.
• Step seven, approve: a named person accepts, edits and accepts, rejects with a reason, or sends a question back.
• Step eight, record and log: only after approval is the entry written, exactly once, together with a record of who approved it and what was changed.

Two details deserve attention. First, the proposal and the recorded entry are different states, and the system should make it impossible to confuse them. Second, silence is never approval. If the approver is away, the item waits, reminds and, if your process allows, routes to a named backup. It does not expire into acceptance. Work that is half done should be saved with a clear status so it can resume, an idea explored in AI agent checkpoints and how to resume unfinished work.

Which checks should the agent run before a person sees the invoice?

The agent earns its place by doing the comparison work a person would otherwise repeat on every invoice. These checks are the core of the workflow:

• Vendor match: the name, tax identifier and address are compared with the vendor records. An unknown vendor goes to a person with no payment details pre-filled.
• Bank details: the account on the invoice is compared with the account on file. Any difference blocks the item and is flagged. The agent never updates bank details on its own.
• Duplicate detection: vendor, invoice number, amount and date are searched across recorded invoices and the current review queue.
• Arithmetic: line items, taxes and totals are recomputed, and the currency is confirmed.
• Order or contract match: where your company uses purchase orders or agreements, the invoice is matched to an open one, and quantity and price are compared with what was agreed.
• Dates and terms: the invoice date is plausible and the due date is consistent with the agreed payment terms.
• Completeness: every required field is present. Missing fields are listed, not filled in.

Where possible, run these checks with ordinary code and database lookups rather than asking the model to do them in its head. Arithmetic and duplicate searches have exact answers, and exact tools give exact results. The model's job is to read messy documents and explain what it found. The checks' job is to confront that reading with facts the company controls. For more on keeping model output grounded, see how to reduce AI hallucinations in business workflows.

One rule saves a great deal of trouble: a field marked not found is better than a field filled with a plausible guess. Approvers forgive a gap that is visible. They cannot forgive a wrong value that looks right.

What should the approver see on the review card?

The review card is where the workflow succeeds or fails in daily use. If the approver has to open three systems to understand one invoice, they will start approving by habit, and the boundary becomes decoration. A good card puts the decision in one place:

• The original document beside the extracted fields, so the person can verify by eye.
• For each field, where it was found and a plain statement of certainty: found clearly, found but ambiguous, or not found.
• The result of every check: passed, failed or not applicable, with the failing detail spelled out.
• The proposed coding, with the reason and the earlier invoice it was based on.
• One recommended action, with the reasons behind it.
• The available responses: approve, edit and approve, reject with a reason, or ask a question.

The card should let a person decide in a short read. If the clean cases take effort, the card is carrying too much. If the blocked cases take no effort, the card is hiding too much.

Decide in advance, in writing, who approves what. Finance can set thresholds in your own terms: new vendors, unusual coding, or larger invoices may need a second person. Keep these rules in a document the agent can read and the team can change. When something falls outside the rules or the agent cannot tell, the right move is to pass on the decision with context rather than a pile of attachments, which is the principle behind human escalation for AI agents.

An illustrative scenario: one clean invoice, one blocked

This is an illustrative scenario, not a real case. A small distribution company receives two invoices in the same morning.

The first is from a utility the company has paid many times. The agent extracts the fields, finds the vendor and the account unchanged, confirms the totals, sees no duplicate and proposes the usual coding. The card is marked clean. The approver compares the figures with the document, and approves in moments.

The second is from a packaging supplier. The vendor matches and the order matches, and the arithmetic is correct. But the bank account on the invoice differs from the account on file, and the email asks the company to use the new details from now on. The agent marks the card blocked, states the reason in one sentence, and proposes no payment details. The approver contacts the supplier using the phone number already on file, not the one printed on the invoice. The supplier says it sent no such change. The approver rejects the item, notes why, and the incident goes to whoever manages vendor security.

The value of the workflow shows in both outcomes. The routine invoice moved quickly, and the risky one stopped before anyone acted on it.

How do you protect the flow from bad documents and duplicate entries?

Three protections belong in the design from the first day.

First, treat the content of every invoice as data, never as instructions. A document can contain text such as a request to ignore the rules or to send a payment elsewhere. The agent must read it as a field to extract, not a command to follow. The OWASP prompt injection prevention cheat sheet describes the defensive patterns, and the article on prompt injection in business documents explains what to protect in a finance setting. The review boundary is itself a defense: even if a document misleads the agent, a person sees the result before it counts.

Second, give the agent the smallest permissions that let it work. It can read the intake mailbox and write to a review queue. It cannot write to the ledger, change vendor records or release payments. Only the approval step carries the ledger permission, and it carries it for that one entry. The OWASP authorization cheat sheet recommends deny by default and least privilege, and those principles map directly onto this design. Giving the agent its own identity, separate from any employee, also keeps the audit trail honest.

Third, make recording safe to repeat. Networks fail and steps are retried. If a retry creates a second entry, you have built a duplicate generator. The common remedy is an idempotency key: a unique identifier, for example built from the vendor and invoice number, so a repeated request is recognized as the same one. Stripe's documentation on idempotent requests shows how a provider defines this behavior, and the same idea applies to your own write step.

Keeping the design simple helps with all three. Anthropic's guidance on building effective agents favors the simplest structure that does the job, with points where a human can step in. An intake workflow with fixed steps and one approval gate fits that advice well.

How do you know it is working, and how does Be Human run it?

Before going live, run the agent in shadow mode on a set of past invoices that your team has already processed. Compare its proposals with what people actually recorded, and look closely at the disagreements. Some will be agent errors, and some will turn out to be inconsistencies in your own past coding, which is useful to learn.

Once live, watch a few signals:

• How often approvers edit each field, since a field that is edited often needs attention.
• Time from arrival to decision, including time spent waiting for a person.
• Blocked items, and whether the blocks were justified.
• Duplicates and changed bank details caught before recording.
• Items stuck without an approver response.

Define what good looks like before you start, as described in how to define success criteria for an AI agent pilot, and weigh results honestly using how to measure AI workflow ROI without hype.

Be Human designs, implements and operates this kind of workflow as one defined role. The first engagement sets the role of invoice intake, the memory and tools it needs (vendor records, order data, the intake channel), the approval boundaries, and an observable success criterion. Managed operations can then include monitoring, recurring evaluations, integration maintenance, permission review and incident response, with changes made in a controlled way. The agent keeps its own identity and accounts, and the company keeps control of who approves.

Frequently asked questions

Can the agent approve small or routine invoices by itself? It can, but that should be a later and deliberate decision, not the starting point. Begin with a person approving everything, collect evidence about which invoice types are consistently correct, and then define a narrow class with written rules, an owner and a regular review. Anything outside that class still goes to a person.

Does the agent need access to our accounting system? It needs less than most teams expect. For reading and checking it needs read access to vendor records and order data, and write access only to a review queue. The ledger permission should sit with the approval step, so the agent proposes and the approved action records.

What happens when the approver is away? The item waits in the queue with its status visible, reminders go out, and a named backup can take over if your process defines one. The agent never treats silence as approval. Good practice is to agree on a maximum waiting time and what happens when it passes.

Where should we start if our invoices are messy? Start with one source and one invoice type, such as recurring invoices from a handful of known vendors, and prove the flow there. The guide on choosing your first AI workflow explains how to keep the first scope small enough to evaluate. Add vendors and exceptions once the checks and the review card are working.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.