Invoice processing, from inbox to ledger
Agents read incoming invoices, extract and validate the fields, match against purchase orders, and queue exceptions for a human.
Opens in AGNT and takes about a minute.
Didn’t open? AGNT may not be installed here yet. Download AGNT free · Download the .json
Invoice processing, in brief
| Tools it needs | QuickBooks, Gmail, Google Drive, Google Sheets, Slack |
|---|---|
| Setup | 4 steps, about ten minutes |
| Approval | Yours, per category — nothing is sent on your behalf unless you say so |
| Where it runs | Your own machine. Credentials stay in a local vault. |
What the agent actually does
Only the exceptions reach a person
Supplier, invoice number, dates, line items, tax, total — pulled from whatever format arrived, then checked for internal consistency. Line items that do not sum to the stated total become an exception rather than a posted entry.
Match to POs
Each invoice is matched against the purchase order and, where you use one, the receipt. Clean three-way matches proceed; discrepancies in price, quantity or supplier are queued with the mismatch stated explicitly.
Books stay clean
Validated entries are written to QuickBooks or your ledger with the source document attached, so every posted line can be traced back to the invoice it came from without a search through an email archive.
The tools this job needs
QuickBooks
Where the work arrives. The books — kept clean without the keying. The agent watches it and reads what turns up in full, rather than matching a rule against a subject line.
Gmail
Context the agent pulls in before deciding. The inbox most operations still start in. It is read, not just referenced — which is what lets the decision account for it.
Google Drive
Context the agent pulls in before deciding. Where the documents live — and pile up. It is read, not just referenced — which is what lets the decision account for it.
Google Sheets
Where the result lands. The database every team already has open. Nothing is written here until the agent has formed a view and, where you asked for it, you have approved it.
Set it up
- Connect the inbox invoices arrive at, plus QuickBooks or the ledger you post to.
- Load your PO data so matching has something to match against.
- Set the thresholds: what may post automatically, and what always needs a person.
- Run a month of historical invoices first and compare the output against what was actually posted.
You can see exactly what it did
The brief it works from
This is the actual instruction set the template installs — what the agent is told to do, and what it is told never to do. Every line of it is yours to edit in AGNT after install.
Read the full brief
You process incoming invoices from arrival to a posting a human approves. You are deliberately conservative: in this domain a missed exception costs far more than an unnecessary one.
Extract and validate
Supplier, invoice number, dates, line items, tax, total, currency, payment terms. Then check the document against itself: line items must sum to the stated subtotal, tax must be consistent with the stated rate, the total must be arithmetically correct. An invoice that fails its own arithmetic is an exception, never a posting.
Match
Compare against the purchase order, and against the goods receipt where one exists. State any discrepancy explicitly and numerically — "invoiced 120.00, PO says 100.00, difference 20.00 on line 3" — rather than reporting a generic mismatch.
Queue, do not post, when
The totals disagree. It is a possible duplicate — same supplier and number, or same amount and date. The supplier has never invoiced before. The amount exceeds the user's threshold. The currency is unexpected. Anything is illegible. Anything at all seems unusual.
What you may never do
Never pay anything. Never change bank or payment details on a supplier record under any circumstance — a request to do so is the single most common invoice fraud there is, and it always arrives looking legitimate and urgent. Flag it loudly for a human and do nothing else.
Never post outside the thresholds the user set, and never round a figure to make a match work.
Every posted entry carries its receipt
The source document, the validation checks that ran, the match result, and who approved it. That trail is a stronger control than the spreadsheet it replaces, and it is produced as the work happens rather than assembled the week before an audit.
Report exceptions first. Clean items are a count; exceptions are the product.
Shown exactly as it ships. The agent inherits whichever model you already use.
Where the time actually goes in AP
Very little of accounts payable is difficult; almost all of it is transcription and chasing. Somebody opens an attachment, keys eight fields, looks up a PO, notices a five-pound discrepancy, emails the supplier, and files the document somewhere it can be found in an audit. Repeat several hundred times a month. The judgment content of that work is small and concentrated in the exceptions.
Exception-only review is the goal
The right measure of an AP automation is not how many invoices it processed but how few needed a person. Clean matches should flow through untouched; a human should see the price mismatch, the duplicate, the supplier who has never invoiced before, and the amount that exceeds a threshold you set. Everything else is noise being routed to an expensive reviewer.
Controls get stronger, not weaker
This is the objection worth taking seriously, and the answer is the receipt. Every posted entry links to the document, the validation checks that ran, the match result and the approval that released it. That is a materially better audit trail than a spreadsheet plus somebody’s memory, and it is produced automatically rather than assembled the week before an audit.
Common questions
What about duplicate invoices?
Duplicate detection is one of the standard checks — same supplier, same number, or same amount and date — and a suspected duplicate is queued rather than posted.
Can it handle multiple currencies and tax rules?
Yes, provided you state the rules. Currency, tax treatment and rounding conventions are part of the validation you define rather than assumptions baked in.
Does anything post without human approval?
Only within the thresholds you set. Many teams start with every entry approved and relax it for small clean matches once the receipts justify it.