AI for Bookkeeping: Receipt Intake and Reconciliation Queues

An AI agent can take over the repetitive front half of a bookkeeping service: collecting receipts, matching them to bank and card lines, and sorting what does not match into named exception queues. The safe version keeps the agent on preparation and review, so it drafts entries and explains its reasoning while a named reviewer is the only role that can post to the ledger. That split lets a bookkeeping firm move faster without giving software control of the books.

Key takeaways

• The agent prepares receipt and reconciliation work, and a named reviewer approves every posting.
• Exception queues with fixed names and owners make the work visible, reviewable and measurable.
• The agent's credentials should allow reading sources and writing drafts, never posting, voiding or changing bank rules.
• Each queue needs an owner, an age limit and a written rule for when an item escalates.
• Start with one client group and one bank or card feed, then expand only after the overrides are understood.

Why receipts and reconciliation suit an agent first

Receipts and bank reconciliation share three traits that make them a good first task. The inputs arrive constantly and in mixed form, the rules for most items are stable, and the exceptions are easy to see once someone writes them down. A well-scoped role removes the sorting and chasing that fills a bookkeeper's week, and leaves the judgment calls with the people who carry professional responsibility for the records.

Receipts arrive as photos, PDF attachments, forwarded emails and paper that someone meant to scan. Bank feeds produce lines with abbreviated descriptors that rarely match the vendor's name. Most matches are obvious once the vendor and amount agree, so the expensive work is the remainder: the duplicate, the partial payment, the transfer between accounts that looks like income, and the receipt with no matching line yet. That remainder is where an agent helps most. Teams that already work from exception lists in other operations will recognize the pattern, as described in AI Agents for Ecommerce Operations Beyond Customer Chat.

How intake and exception queues work

The workflow runs as a pipeline with a queue at each stage. Every queue has a fixed name, an owner and a rule for what moves an item out of it. The names should be clear enough that a reviewer, a client and an outside accountant can read the same list and mean the same thing.

• Awaiting extraction: a receipt is captured but its vendor, date, amount and tax are not yet read
• Low confidence: extracted fields fall below the threshold the client agreed to
• Unmatched bank lines: no receipt or ledger match exists within the agreed window
• Possible duplicates: two or more sources may describe the same purchase
• Needs client answer: a question only the business owner can settle, such as a personal or business split
• Ready for review: a draft entry exists with its source documents attached

Only the last queue feeds posting, and posting still belongs to a reviewer. Firms that handle shipping and customs papers apply the same discipline, building the record from sources and working the exception list, as covered in AI Agents for Import Export Companies: Documents and Status.

Where the agent's authority stops

Write down, before any setup, what the agent can read, what it can create and what it must never do. A practical boundary for bookkeeping looks like this: the agent reads receipts, bank feeds and the chart of accounts; it creates drafts, notes and questions to the client; it does not post, void, reclassify posted entries, change bank rules, release payments or alter tax settings.

Access decisions should come from that written policy, not from what the model judges it should do. The OWASP authorization guidance makes the general point that access must be enforced by the system outside the model. A reviewer's approval only means something if posting rights sit with the reviewer's own identity and the agent's credentials cannot reach the posting function at all.

Receipts are untrusted input. A scanned invoice or emailed PDF can contain text that tries to instruct the agent, for example to mark an amount as paid or to skip review. Treat document content as data to extract, never as instructions. The OWASP prompt injection prevention cheat sheet covers this class of risk and the controls that reduce it.

A step-by-step rollout plan

The first rollout should be narrow enough that a reviewer can check every output. This sequence keeps each step observable:

• Choose one client group with a stable chart of accounts and one bank or card feed.
• Write the queue definitions, owners and age limits on a single page the whole team can read.
• Set the agent's permissions to read sources and write drafts only, and confirm that posting rights are absent.
• Build a labeled sample of past receipts with known correct entries, and measure extraction against it before any live use.
• Run the agent in shadow mode, comparing its drafts with what the bookkeeper actually posted.
• Review every override and decide whether the rule, the vendor memory, the prompt or the client instruction was wrong.
• Turn on live queues for the approved client group only, and keep the shadow comparison running for new vendors.
• Expand to another client group or feed only after the override pattern is understood and written down.

Illustrative scenario: a duplicate card payment

Illustrative scenario, not a client case: a client pays a software subscription by card. The charge appears in the bank feed, the client forwards the e-receipt by email, and someone later uploads a photo of the paper copy to the shared folder. The agent sees three sources that could describe one purchase and places the group in the possible duplicates queue. It drafts a single entry, attaches all three documents and asks the client, through the approved channel, whether the subscription was billed twice. The reviewer confirms the duplicate, a human voids the extra draft, and the note records which document was kept as the primary source.

The safeguard behind this is the same principle payment platforms use. Stripe's guidance on idempotent requests describes how a repeated request should produce one effect, identified by a key. The ledger needs that property too: each draft carries a stable identifier built from the bank line and the source document, so a retry or a re-imported file cannot create a second posting.

Controls, audit trail and review cadence

Every draft should record its sources, the extracted fields with their confidence, the rule or vendor memory it used, when it was created, and who approved or rejected it. That record lets a reviewer, a client or an external accountant reconstruct a decision long after it was made. The useful model comes from observability practice: traces that show each step the agent took, measures such as queue age and override rate, and alerts when a queue grows past its limit.

Keep a fixed set of labeled receipts and rerun it after every change to prompts, rules or tools. That is how a controlled improvement is shown to be an improvement rather than a hope. In the weekly review, look at queue ages, reviewer overrides and any entry changed after posting. Repeated corrections on one vendor usually point to a missing rule, not a weak model. The same review habit fits AI for a Project Management Office: Status and Risk Reporting, where a single stale exception often matters more than the total count.

How Be Human runs this as a managed service

Be Human designs and operates this kind of agent as a managed service. The first engagement defines one useful role, the memory it needs (such as the client's chart of accounts, vendor rules and reviewer notes), the tools and their scoped permissions, the approval boundaries and an observable success criterion like queue age or override rate. Ongoing operation covers monitoring, recurring evaluations on sampled documents, maintenance when a bank feed or accounting integration changes, permission reviews, incident response when an entry is wrong, and controlled changes to rules. The work is remote and available in English and Portuguese.

If you want to find the first task in your operation worth handing to an agent, take the free Be Human AI diagnostic.

Frequently asked questions

Can an AI agent post journal entries without a reviewer? No, and it should not be given that permission. The agent drafts entries with attached sources and a stated confidence, then places them in a review queue. Posting rights belong to a named reviewer's identity, so the agent's credentials cannot reach the posting function.

Does this replace bookkeepers? No. The agent takes over the sorting, matching and chasing that consume time, so people spend more of their hours on exceptions that need judgment. Professional responsibility for the books stays with the firm and its reviewers. You control that division of work through the queue definitions and the permissions.

What access does the agent need to the books? It needs read access to the chart of accounts, the receipt intake folder and the bank or card feed for the agreed client group, plus permission to create drafts and notes. It should hold no permission to post, void or change bank rules. Access should be scoped per client and reviewed on a fixed schedule.

How do you know the drafts are accurate? You measure them. Build a labeled sample of past receipts with correct entries, run the agent against it before live use, and rerun it after every change. Track reviewer overrides over time, since repeated corrections on the same vendor show exactly where a rule is missing.

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