AI Agents for Tax Teams: Capturing Positions and Evidence Now

AI agents for tax teams are most useful when they start with the record, not the return. The first practical step is to capture each tax position, the evidence behind it and the deadlines it depends on, in a structured form that a named person owns. Once that record exists, agents can gather, compare and flag, and more capable agents can later assist with analysis, while people keep every filing decision.

Key takeaways

• Start with a position register: one entry per tax position, with its stated basis, owner, reviewer and the date it was last confirmed.
• Attach evidence when it is created, not at year end, and record where each document came from.
• Treat deadlines as an observable record with named owners and escalation contacts, not as a personal calendar.
• Give agents read access and drafting rights first. Keep submissions, payments and changes to a position's status with people.
• Judge readiness by one test: can a reviewer trace any figure in a draft back to its source in a few minutes?

Why records come before reasoning

Tax work is a chain of claims. A deduction, a treatment of a credit or an intercompany assumption rests on facts, a document and a judgment someone made at a particular point in time. When an auditor, a new adviser or a finance leader asks about it later, the team needs the whole chain, not only the conclusion. Many teams rebuild that chain by searching email and shared drives, which is slow and fragile.

An agent can search too, but search over unstructured folders returns documents, not reasons. A more capable model will reason better over whatever material it is given, so the quality of the material matters now. Retrieval over well-labeled records, where each document is tied to the position it supports, is the difference between an agent that finds files and an agent that can explain why a position stands. The same discipline appears in procurement teams, where a quote is only useful when its supplier, date and terms stay attached to it.

What an agent should and should not do

Define one role before anything else. A useful first role is a reconciliation agent that reads the position register and the ledger extracts it is allowed to see, then produces a list of mismatches for a named reviewer. It can point out where a position has no supporting document, where a supporting document is older than the position's stated period, or where a ledger movement touches an area with an open question. It can also prepare schedules and memo templates with the evidence already placed.

It should not submit returns, sign anything, change a position's status or decide a treatment. Tax determinations depend on jurisdiction, professional responsibility and facts that a qualified person must weigh. The agent's output is a draft for that person. The NIST AI Risk Management Framework is a useful reference for this kind of boundary, because it asks organizations to govern AI use, map its risks and measure outputs against expectations before relying on them.

Capturing positions before they are questioned

Each position entry should say, in plain language, what the company has done or plans to do, and why. Record the basis the team relies on, the facts it assumed, the periods the position affects, the owner, the reviewer and the date the position was last confirmed. Add a status field with a short, fixed list of values, such as proposed, approved, filed and under review.

The status field is where human control is most visible. An agent can detect that a status has been stale for too long, or that a filed position has a document attached after its filing date, and raise that for review. It should not move the status itself. Keeping this rule explicit prevents a helpful tool from quietly turning a draft into a commitment.

Building the evidence file as work happens

Evidence is cheapest to collect at the moment it arrives. Use this checklist for every supporting document:

• A stable identifier for the document and the place where the original is kept.
• The date it was received and the person or system that provided it.
• The specific figure, fact or clause it supports, and the position entry it links to.
• Any assumption used to bridge a gap, marked as an assumption and linked to the reviewer who accepted it.
• The version history, so that a replaced document does not silently overwrite the one the position relied on.

When an agent pulls records from accounting software, document stores or import and export document flows, retries are common and can create duplicates. Stripe's documentation on idempotent requests shows a practical pattern: a request carries a key so that repeating it does not repeat its effect. Your evidence store should follow the same logic, so that a rerun of the agent updates an existing record rather than adding a second copy. Access also needs care. The OWASP authorization guidance recommends checking permissions on every request and granting only what a role needs. An agent working for a reviewer should see the reviewer's scope, not the whole finance archive.

Deadlines as a shared, observable record

Deadlines usually fail in the handoff, not in the calendar. Record each obligation with its period, its preparation steps, the evidence it requires, the owner of each step and an escalation contact who is not the same person. Make the record visible through a short weekly view that shows what is due, what is blocked by missing evidence and what changed since the last review.

Agents are well suited to monitoring this record and sending reminders at agreed intervals. They are not suited to deciding which rule applies. Deadlines depend on jurisdiction and on rules that can change, so each entry should cite the authority the team checked, and a person should confirm the calendar at a set cadence. The same structure supports treasury teams that track cash obligations against payment dates.

Illustrative scenario: a quarterly review

Illustrative scenario: a services company with a small tax team keeps its position register in a shared workbook. Each month, a reconciliation agent compares the register with the ledger extract it is permitted to read. It reports three kinds of change: a position with no document attached in the current period, an obligation due within the review window with no named preparer, and a ledger movement in an account linked to an open question. The tax manager reviews the list in a thirty-minute meeting, assigns follow-up and records each decision in the register. The agent never edits the status column, and it never contacts the external adviser. Over several cycles, the team's question shifts from where a document is to whether the position still holds.

How a managed setup keeps decisions with people

Be Human designs, implements and operates personalized AI infrastructure for companies, with agents that keep their identity, memory, channels, tools, permissions and operating context under human control. A first engagement defines one useful role, the memory and tools it needs, its approval boundaries and an observable success criterion, such as the share of flagged mismatches a reviewer confirms as real, measured on an agreed sample. Managed operations then cover monitoring, recurring evaluations of the agent's output against the register, permission reviews when staff or access change, incident response and controlled improvements to the agent's instructions and tools. Service is remote, in English and Portuguese. If you want to find the first task in your tax workflow that is worth handing to an agent, take the free Be Human AI diagnostic.

Frequently asked questions

Can an AI agent file a tax return on our behalf? A well-designed agent should not. Its useful work is to gather evidence, compare records, prepare drafts and flag gaps for a qualified reviewer. Submission and any change to a filed position should stay with a person who is accountable for the outcome.

What is a tax position register, and why do we need one before adding agents? It is a structured list of each position the company takes or relies on, with its basis, facts, owner, reviewer, status and last confirmation date. Agents need that structure to explain their output, because a folder of documents does not record why a position stands. Building it first also makes later evaluation possible.

Should we wait for more capable agents before we start? No. The records that help a future agent are the same records a reviewer needs today, including evidence linked to positions and deadlines with named owners. Starting now lets you test one narrow role, measure its output and learn where the boundaries should sit before any system gains more autonomy.

How do we protect sensitive financial data when agents read our records? Limit each agent to the data its role requires, check permissions on every request, and keep a log of what it accessed and produced. Data handling obligations depend on where your company and its data subjects are located, so review the approach with counsel and, for Brazilian personal data, with the guidance of the ANPD.

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