AI Agents in Accounting: Tools and Approval Gates

What an AI agent in accounting is

An AI agent in accounting is a model that works in a loop: it reads data, chooses a tool, takes an action such as drafting a journal or a reminder email, then checks the result before its next step. It matters because that loop, not a single question and answer, is what lets AI agents in accounting handle multi-step work such as matching a receipt to three invoices or chasing an overdue customer.

Distinguish an agent from two things it is often confused with: a chatbot, which only answers in the same turn it is asked, and traditional automation such as RPA (robotic process automation), which follows a fixed script with no reasoning about what it finds. An agent sits between them: it plans a short sequence of steps, calls named tools with real inputs, and adapts when a step returns something unexpected, such as a mismatched amount or a supplier not on file. The examples below use accounts payable, accounts receivable and month-end work, but the same design choices, tools, permissions, approval gates and an audit trail, apply to any process an agent touches.

From a single prompt to a working loop

The loop has four repeating steps. First, the agent reads whatever it has been given access to, such as an invoice image, a bank statement line or a report. Second, it plans, deciding which tool answers the question or moves the task forward. Third, it acts, calling that tool with real inputs, for example a supplier name and an amount. Fourth, it observes the result and decides whether to stop, ask a person, or take another step. A chatbot only performs the second step, in words; an agent actually calls the tool and reacts to what comes back.

• Read: what invoice, statement line, ledger balance or report is in front of it
• Plan: which tool answers the question or moves the task forward
• Act: call that tool with real inputs, for example a supplier name and an amount
• Observe: check what the tool returned against what was expected
• Decide: stop, ask a person, or take one more step

Where agentic workflows already fit in accounting

Agentic workflows suit processes that repeat often, have clear rules most of the time, and produce a result a person can check quickly. Accounts payable, accounts receivable, bank and card reconciliation, and the steps of a month-end close are the processes most finance teams start with, because each one already has a checklist a human follows today; the agent follows the same checklist and calls out the exceptions. Our accounting-automation-with-ai guide sets out a fuller library of these recipes and how to read them; the list below is illustrative, not exhaustive.

• Accounts payable triage: reads an incoming bill, checks it against the purchase order and goods receipt, and flags a mismatch instead of coding it
• Accounts receivable follow-up: reviews the aged receivables report and drafts a reminder in the customer's own language for a human to send
• Bank and card matching: proposes a match between a statement line and an open item, or flags it as an exception when none fits
• Close-checklist orchestration: tracks which close tasks are done, chases the owner of an overdue one, and drafts variance commentary for review
• Report question-answering: reads a live report and answers a specific question about it, such as this week's sales by branch

Tools and permissions: designing what an agent can touch

The most important design decision is not which model to use but which tools the agent can call, and what each tool is allowed to do. A read tool only returns information, such as an account balance or an ageing report. A draft tool creates an object, such as a proposed journal or a customer email, that has no effect until a person approves it. Nothing above that, posting, paying, deleting, or changing master data such as a supplier's bank details, belongs in an agent's toolbox in most finance functions today.

Scope every tool to one identified person's own permissions rather than a powerful shared service account, so the agent can only see and do what that person could see and do by hand. Our guide on connecting Claude to an ERP through MCP sets out this read, draft, never post pattern for a ledger in more technical detail, including authentication, scopes and rate limits; the principle carries to any agent framework, not only MCP.

Human approval gates: keeping a person accountable

A human approval gate is the point in the workflow where a named person reviews an agent's proposed action and decides whether it goes ahead. It matters more for an agent than for a person entering data by hand, because an agent can repeat the same misjudgement across many transactions in the time a human would take to make one. A gate should show the reviewer what the agent read and why it decided what it did, not just the final number, so the reviewer is checking reasoning, not rubber-stamping an output.

Set the gate at the point of risk, not at the end of the process. A proposed accrual is safe to draft freely because it changes nothing until approved; a supplier bank-detail change should require two people to agree before an agent even drafts a message about it, because that data feeds a payment. Thresholds help: many finance teams route anything below a small, clearly communicated amount to routine approval and add a second reviewer above it, the same principle a manual journal-approval policy already uses.

Audit trail of agent actions

An audit trail of agent actions is the record that lets someone reconstruct, after the fact, what an agent read, what it proposed, who approved or rejected it, and why. Without it, an agentic workflow is a black box that happens to be fast; with it, an auditor assessing the control environment around automated processing, the kind of understanding ISA 315 (Revised 2019) asks for, has something concrete to test.

• Who: the identified user the agent acted on behalf of, and which agent or workflow ran
• What: the tool called, the inputs and the proposed output
• When: the timestamp of the proposal and of the decision
• Outcome: approved, rejected or escalated, with the reviewer's name and reason
• Link: the record this created in the source system, so the trail is traceable end to end

Worked example: an accounts-receivable agent, checked

An accounts-receivable agent reviews the aged receivables report on a Monday morning. It finds a EUR 15,000 receipt that does not match any single open invoice from that customer, and proposes allocating it against two open invoices of EUR 9,200 and EUR 5,800; 9,200 plus 5,800 equals 15,000, so the allocation clears the receipt exactly. It also finds a second customer, 96 days overdue on a EUR 640 invoice against a EUR 2,000 credit limit, and drafts a reminder in the customer's own language that cites the invoice number and due date.

The reviewer checks both. The allocation is correct and matches the bank statement, so she approves it. The reminder cites the wrong due date, copied from a related invoice rather than the overdue one, so she corrects the date before sending it, a reminder that an agent's citation is only as good as the document it was pointed at. A third suggestion, writing off a EUR 3,400 balance from a customer now 210 days overdue, is not actioned: company policy requires a director's sign-off above EUR 1,000, so the agent's role stops at flagging the balance and drafting a supporting note, and the write-off itself goes to the director as a normal approval, not as an agent action to confirm.

Where an agent should never act alone

Some actions should sit outside any agent's permissions altogether, whatever the model or the vendor, because the cost of a single wrong action is high and often hard to reverse.

• Executing a payment, or changing a supplier's or employee's bank details
• Filing a tax return or a statutory report with an authority
• Posting an entry above the business's materiality threshold without a named approver
• Changing a customer's credit limit or approving a write-off without the sign-off the credit policy requires
• Making a decision with a legal or similarly significant effect on a person, such as declining credit, based solely on automated processing, a case Article 22 of the GDPR gives the person a right to object to
• Approving its own proposal, which recreates the management-override risk ISA 240 asks auditors to watch for, whoever performs it

Governance: who owns each agent

Treat an agent the way a well-run control environment, the first component of the COSO Internal Control framework, treats a new process: someone in the business, not only IT, owns it, understands what it can and cannot do, and is accountable for its exceptions. Before an agent goes live, assess what could go wrong if it is confidently wrong, not only if it fails outright, since a wrong-but-plausible proposal is the harder failure mode to catch.

A useful structure, echoing the govern, map, measure and manage functions of the NIST AI Risk Management Framework, is to write down what the agent is for, what could go wrong, how you will know it is working, and who acts on a problem, before the first live run rather than after. Review the log of approvals and rejections regularly: a pattern of frequent correction on one kind of proposal is a sign the tool, the data it reads, or its instructions need to change, not that the reviewer is being too strict.

A staged rollout for finance teams

Start narrow and add capability only once the previous stage is trusted, rather than deploying a broad agent on day one.

• Stage one, read-only: the agent answers questions from live reports; nothing it does can be wrong in a way that costs money
• Stage two, draft with approval: the agent proposes journals, allocations, reminders or commentary that a named person approves, corrects or rejects
• Stage three, narrow low-risk automation: only fully reversible, low-value, well-understood steps run without a per-instance approval, such as sending a reminder from a template a person already approved
• At every stage, keep the audit trail on, review a sample of approvals for quality, and revisit the tool list before adding a new one

Agents in Skyline Nexus ERP today

Skyline Nexus ERP's in-app AI assistant already works inside a version of this pattern: it answers how-to questions from the ERP's own help library, in the user's own language, and checks that the help page it cites actually exists and was retrieved for that question before showing an AI answer rather than a plain search result. Asking it about a live figure, such as today's sales or this month's supplier dues, returns the real number from one of eight whitelisted, permission-checked reports, scoped to the user's own business and locations; the model itself never writes a query, it only picks which of the eight reports was asked for.

The content behind the assistant is itself built on a draft-then-review gate: administrators see AI-drafted help pages and unanswered questions in a dedicated cockpit, and a page is published only after a person reviews it, the same approval-gate principle this guide describes, applied to help content rather than accounting entries. An MCP server lets Claude Desktop and other MCP clients call the same eight live figures, plus help search, read-only, through a personal token. An agent that drafts journals, AR allocations or dunning emails for approval inside Skyline Nexus ERP, the kind of workflow set out above, is being rolled out on the roadmap; ask us for your go-live date.