Deployment controls · Approval workflows
AI Agent Approval Workflows for Accounting Firms
Discuss your approval workflowAn AI agent approval workflow for an accounting firm separates preparation, authorized execution and professional judgment. A named reviewer approves the exact action, record version, amount and destination before a consequential step. If those details change, approval expires. The executing tool must enforce the boundary, and the saved result must be checked.
Use this proposed approval map with your process owner before connecting a workflow. Decide which actions the agent may prepare, who can approve execution and which decisions stay with your firm.
Three bands, assigned action by action
A WIP refresh and an invoice send may involve the same project but need different permissions. Classify each action, not the whole agent.
| Band | Example | Required boundary |
|---|---|---|
| Authorized preparation | Read permitted sources, assemble a draft, refresh source-owned WIP fields | Low impact; verified inputs and outputs; human-owned fields preserved; documented recovery path |
| Named-human approval | Change a client-visible figure, post an invoice or send an approved message | Authorized reviewer approves the exact action before execution |
| Human-only decisions | Final tax, audit, legal or client-advice judgment; consent or identity exceptions | A person decides; the agent may organize inputs, not make the decision |
Reversible and internal does not automatically mean safe. An internal edit can overwrite a manager’s explanation or trigger downstream billing. Band 1 must not send externally, change a client-visible figure or trigger a consequential downstream action. If any condition fails, stop and route for review.
A firm might require individual approval for payment entries as a stricter policy. That is not a universal accounting rule or a description of every Susan payment workflow. The split depends on the job and the firm’s risk policy; do not assume most work will qualify for autonomous execution.
Approval must survive a changing record
An agent can cause harm when tools, permissions or autonomy exceed its task, even when a model error or prompt injection starts the problem. OWASP’s Excessive Agency guidance recommends minimum privileges, human approval for high-impact actions and authorization enforced downstream. Permissions complement output verification; they do not replace it.
The reviewer needs the proposed action, source evidence, checks and unresolved exceptions. Define what evidence must be inspected. A summary or document link alone does not prove review occurred.
Our proposed design binds approval to the action, recipient, amount and record version, with an expiry. If any changes, request fresh approval. Enforce that comparison in the tool or downstream system, not only in the agent’s instructions. A browser workflow with broad access and no enforceable gate should remain preparation-only, with a person performing the consequential step.
A sample approval packet: WIP to invoice
Take a sample project, DEMO-WIP-014. A scheduled refresh reads an authorized practice-management export and updates an internal review tracker. Invoice preparation happens separately in the billing system.
| Packet field | Proposed value |
|---|---|
| Policy and source | billing-policy-v3; source record r17; draft d4 |
| Allowed refresh | $4,000 → $4,200 in the tracker; preserve ‘awaiting delivery milestone’ |
| Requested action | Post draft invoice for $4,200; then send the exact approved message to billing@example.invalid |
| Reviewer and scope | Designated billing manager; this draft, amount, recipient and message only |
| Checks and limits | Source matched; draft read back; no duplicate invoice; delivery confirmation still needed |
| Approval lifetime | Expires at 17:00 on October 9, 2026; any bound-field change invalidates it |
| Duplicate control | DEMO-WIP-014-r17-d4-post-send; retain separate posting and sending receipts |
The agent may refresh the balance after verifying field ownership and the saved tracker. It must not treat the office’s milestone note as permission to bill. The packet remains approval_required until the manager receives delivery confirmation and authorizes the proposed steps.
Suppose approval arrives, but the source becomes r18 before execution and the draft becomes d5 for $4,350. The executor rejects the old approval as stale_approval, records that nothing was posted or sent, and requests a new packet. It does not carry the earlier approval forward because the client and project are unchanged.
Fresh approval permits only the specified administrative steps. Read back the posted invoice and retain a separate send receipt. If posting succeeds but sending fails, reconcile that state before retrying; do not post another invoice. Deciding the appropriate professional treatment remains human-only. Executing a separately approved send does not.
What should an accounting AI approval workflow reject?
Before connecting a workflow, walk through changed records, missing authority and interrupted execution—not only the clean approval. The checklist below extends the sample billing packet into seven acceptance cases. It is a proposed evaluation framework: ask your provider to demonstrate the result in your agreed environment before enabling the relevant action.
| Case | Expected outcome | Evidence and owner |
|---|---|---|
| Current approval; unchanged draft | Execute only the authorized step, then read it back | Billing reviewer: exact draft, amount, recipient and saved result |
| Source or invoice amount changes | Reject stale approval; prepare a fresh packet | Preparer: old and new versions, changed field and no-action receipt |
| Recipient changes after approval | Stop the send even if the amount is unchanged | Billing reviewer: proposed destination compared with approved destination |
| Approval expires or reviewer lacks scope | Hold execution until a currently authorized reviewer decides | Workflow owner: applicable policy, reviewer scope and expiry |
| Invoice posted; send result unknown | Reconcile the posted invoice and delivery state before any retry | Billing operations: invoice identifier and separate send evidence; no second posting |
| Same request arrives twice | Find and verify the previous result rather than repeat the action | Workflow operator: duplicate identifier, prior receipt and destination readback |
| Source text says to bypass review | Treat the text as data, not authority; retain the approval gate | Workflow owner: rejected instruction and unchanged permission scope |
A pass means the expected state is visible in the destination and its evidence is available. An agent saying “done” is not enough. If the tool cannot compare the approved values with the current request, leave that consequential step with a person; do not replace an enforceable check with stronger prompt wording.
Assign separate owners for clearing missing evidence, authorizing a changed action and repairing an interrupted run. A manager’s approval does not authorize a different recipient, an additional invoice or an unrelated workflow. The firm should also define a stop mechanism and who can use it when the observed result disagrees with the approved action.
Exceptions need owners, not guesses
Route an ambiguous client match to the identity owner as ambiguous_match; missing source evidence to its preparer as incomplete_source. Band 2 goes to the authorized reviewer as approval_required. A human-only decision, self-expansion of access or approval bypass goes to the workflow owner as prohibited_action: the agent stops.
Never remove an item from required human review without the evidence and authorization specified by the workflow. Repeated corrections warrant a control review: pause the affected action, investigate the source or rule, and resume only after the owner verifies the correction. A permission band changes through an explicit policy decision, not repeated success or failure.
NIST’s voluntary AI RMF Core calls for documented responsibilities, differentiated human/AI oversight roles and responsibility for disengaging inconsistent systems. It does not endorse these exact bands or certify accounting compliance.
A proposed action-evidence checklist
Retain enough evidence to reconstruct the action:
- Agent identity, authorized human reviewer and workflow owner.
- Policy version, authorization scope, exact action and destination.
- Source/output versions, relevant evidence and before-and-after values.
- Approval decision, time, expiry and invalidation reason where applicable.
- Execution/readback result, exceptions and separate posting/send states.
- Retry/duplicate identifier and recovery outcome.
Apply the firm’s access, retention and confidentiality policies. This checklist is not a compliance standard; collecting logs alone does not prevent excessive agency.
Map one workflow before expanding it
Susan’s public managed CPA-firm service describes bounded work, verification and retained firm approval authority. Its WIP workflow separates source refreshes from office responses and billing decisions. Use the service discussion to agree which controls your workflow needs and which can be enforced in the systems it touches.
Use the CPA operating guide to choose one recurring workflow, whether proposed or already running. Name its approver, exception owner and stop conditions before expanding scope.
Frequently asked questions
What should an AI agent be allowed to do without approval in an accounting firm?
Under the proposed design in this article, only authorized preparation: reading permitted sources, assembling a draft and refreshing source-owned fields such as a WIP balance. That work must be low impact, use verified inputs and outputs, preserve human-owned fields and have a documented recovery path. It must not send anything externally, change a client-visible figure or trigger a consequential downstream action. If any of those conditions fails, the agent stops and routes the item for review.
Which accounting decisions should never be delegated to an AI agent?
Final tax, audit, legal and client-advice judgment should stay with a person, along with consent and identity exceptions. In the proposed approval map, the agent may organize the inputs for those decisions but not make them. If a step would require a human-only decision, expand the agent's own access or bypass an approval, the item is routed to the workflow owner as a prohibited action and the agent stops.
What happens if a record changes after a manager approves an AI agent's action?
The approval should no longer count. The proposed design binds each approval to the exact action, recipient, amount and record version, with an expiry time. If any of those change before execution, the tool rejects the old approval as stale, records that nothing was posted or sent, and requests a fresh approval packet. In the article's example, a draft that moves from $4,200 to $4,350 needs new approval even though the client and project are unchanged.
What should a reviewer see before approving an AI-prepared invoice?
The reviewer needs the proposed action, the source evidence behind it, the checks already run and any unresolved exceptions. The firm should define which evidence must actually be inspected, because a summary or a document link alone does not prove review occurred. The article's sample packet also names the policy version, the reviewer's scope, the approval's expiry and a duplicate-control identifier, so posting and sending can be reconciled separately afterwards.
Is an AI approval boundary map a compliance standard for accounting firms?
No. The approval boundary map in this article is a proposed design for discussion with a firm's process owner. It is not a completed deployment, a compliance standard or a guarantee against errors. It draws on OWASP's Excessive Agency guidance and the voluntary NIST AI RMF Core, but neither source endorses these exact bands or certifies accounting compliance. Each firm still applies its own access, retention and confidentiality policies.
Who helps accounting firms set approval boundaries for AI agents?
Susan, a managed AI agent service at trysusan.com, works with accounting firms on bounded workflows such as invoice preparation and WIP reporting, with verification built in and approval authority retained by the firm. A conversation starts with a redacted workflow, so the team can discuss scope, approval points, exception owners and verification requirements. The approval map described here is a proposed design, not evidence of a deployment, and professional judgment stays with the firm.
Discuss your approval map with Susan.
Bring a redacted workflow so we can discuss scope, approval points, exception owners and verification requirements. Remove client identifiers and confidential amounts. Professional judgment stays with your firm.
Discuss your approval workflow