AI Agents for FP&A: Forecasts With an Audit Trail Finance Owns

An AI agent for FP&A is a software worker that prepares planning work for the finance team: it pulls actuals, applies documented drivers, drafts forecast versions and writes variance explanations. The version worth building records the source, assumption and calculation behind every figure, and it never publishes a number that a named finance owner has not approved. Traceability is the core design requirement, and speed is a side effect.

Key takeaways

• Treat the agent as a preparer. It drafts, reconciles and explains, while finance reviews, adjusts and approves.
• Every forecast line should carry its source, its assumption, its calculation and its approver, so a reviewer can rebuild it without asking the agent.
• Keep assumptions in a register owned by people, not inside prompts. The agent reads the register and never edits it unprompted.
• Give the agent read access to source systems and write access only to a draft workspace. Publishing stays a human action.
• Start with one recurring cycle, such as monthly variance commentary, and measure it against a success criterion finance defines.

What does an AI agent for FP&A actually do?

In most finance teams the slow part of planning is not the modeling. It is the surrounding work: collecting actuals from several systems, checking that they tie to the ledger, chasing department leads for updated assumptions, rebuilding the same bridge from last month to this month, and writing the narrative that explains what moved. That surrounding work is repetitive, rule-bound and easy to get subtly wrong when people are rushed.

A planning agent is well suited to that layer. Typical responsibilities include:

• Collecting actuals and checking them against the closed ledger before anything is modeled.
• Applying the current driver assumptions to produce a draft forecast version.
• Comparing the draft to budget and to the prior forecast, and explaining the differences in plain language.
• Flagging inputs that look stale, inconsistent or outside an agreed range.
• Asking the right owner for a missing assumption and logging the answer.

Notice what is absent: deciding the assumption, approving the forecast, or sending it to the board. Those stay with finance. The agent's job is to make the analyst's review faster and better informed, not to replace the judgment that gives a forecast its credibility.

Why does a forecast need an audit trail?

A forecast is a set of claims about the future built on claims about the present. When a CFO, a lender or a board member asks why a line moved, the answer has to be something other than a plausible paragraph. Language models are good at producing plausible paragraphs, which is exactly the risk: an explanation can read well and still not match what the model actually did with the data.

An audit trail closes that gap. It separates what the agent retrieved, what it calculated and what a person decided. If the explanation says freight cost rose because of a rate change, the trail should show the rate sheet it read, the version of that sheet, the formula that applied it and the analyst who accepted the result. If any of those is missing, the explanation is a guess and should be labeled as one.

There is also a practical reason. Finance teams already live with review, sign-off and version control. An agent that fits that discipline gets adopted. An agent that produces numbers from an opaque process gets switched off the first time a figure cannot be defended in a meeting. The [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) frames this as governance and traceability applied across the lifecycle of an AI system, and a planning agent is a clear place to apply it.

What should every forecast line record?

Decide the record before you build the agent. A useful minimum for each forecast line looks like this:

• Value and unit, with the period it covers.
• Source references: the system, report or document each input came from, with a retrieval time and a version or snapshot identifier.
• Assumptions used, each pointing to an entry in the assumption register, with the owner and the date it was last confirmed.
• Calculation method: the formula or driver logic, stored as a reviewable definition rather than described in free text.
• Confidence note: whether the line is computed from closed actuals, a confirmed assumption or an agent estimate awaiting confirmation.
• Change history: what differs from the previous version and why.
• Reviewer and status: draft, in review, approved or rejected, with the name of the person who set that status.

Two habits keep this honest. First, the agent separates retrieved facts from inferred ones in its own output, so a reviewer sees at a glance which lines rest on documents and which rest on judgment. Second, the record is written by the system around the agent, not by the agent describing itself. Tracing in the style of [OpenTelemetry's observability concepts](https://opentelemetry.io/docs/concepts/observability-primer/), where each step emits a structured event, gives you a log you can query instead of a narrative you have to trust.

How does finance keep ownership of every number?

Ownership is a set of mechanisms, not a policy statement. The following controls make it concrete.

First, permissions. The agent reads from the ledger, the planning model and the assumption register using credentials scoped to read. It writes only to a draft area. It cannot post journal entries, change a published forecast or edit the register. The [OWASP authorization guidance](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) on least privilege and deny-by-default applies directly: grant the narrowest access that lets the role function, and review it on a schedule.

Second, approval boundaries. Define which actions the agent may take alone, which need a named reviewer and which it may never take. Drafting a variance note is alone. Changing a driver assumption needs the assumption owner. Publishing a forecast needs the finance lead.

Third, named owners per number. Every line in the forecast maps to a person in finance, and every assumption maps to a business owner. When the agent asks for a missing input, it asks that person and records the reply.

Fourth, independent checks. Reconciliation rules, such as totals that must tie to the ledger, run outside the agent. If a check fails, the draft is blocked and the failure is shown, not smoothed over.

Fifth, challenge by sampling. A reviewer periodically picks lines at random and rebuilds them from the trail. This is the same evidence-and-sample logic described in AI for an internal audit team, and it tells you whether the trail is real or decorative.

How do you build the first planning agent, step by step?

Start narrow. A single recurring cycle with clear inputs and a human reviewer teaches you more than a broad forecasting platform would.

• Step one: choose one cycle. Monthly variance commentary for one business unit is a common starting point because the inputs are closed actuals and the output is reviewable text.
• Step two: define the success criterion with finance. For example, the analyst accepts the draft with minor edits, and every statement in it links to a source. Write down what counts as a failure.
• Step three: inventory sources. List each system, report and document the cycle uses, who owns it and how the agent will read it. Prefer governed exports or read-only connections over screen scraping.
• Step four: build the assumption register. One row per driver, with an owner, a value, a rationale and a last-confirmed date. The agent retrieves from this register and cites it.
• Step five: set the approval boundaries and permissions described above, and test that the agent genuinely cannot cross them.
• Step six: write an evaluation set from past cycles, including cases where the correct behavior is to say the data is missing. Run it before launch and after every change, in the spirit of [Anthropic's guidance on evals for agents](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents).
• Step seven: run in shadow mode for a cycle or two. The agent drafts, the analyst works as usual, and you compare. Only then does the draft become the starting point.

A retrieval approach, where the agent looks up the current documents and register entries at run time, suits this work better than baking figures into the model, because the sources change every period and you need to cite them.

What does an illustrative variance cycle look like?

The following is an illustrative scenario, not a description of a real company.

A regional distributor closes its books and the planning agent starts its monthly run. It reads closed actuals for the logistics cost center and confirms they tie to the ledger. It then compares them to the prior forecast and finds that freight cost came in above plan.

The agent retrieves the carrier rate sheet that the forecast driver references and notices that the sheet in the shared folder is a newer version than the one the register cites. Instead of silently using the new one, it drafts two readings: one using the registered version and one using the newer sheet. It labels the first as confirmed and the second as pending confirmation, and it writes that the variance explanation depends on which sheet is correct.

It sends a question to the logistics manager, who owns the rate assumption, and logs the request. The manager confirms the newer sheet applies from the start of the period. The agent updates its draft, proposes a register change for the manager to approve, and writes the commentary with citations to the rate sheet version, the volume report and the formula.

The FP&A analyst opens the draft, rebuilds one line from the trail, changes a sentence that overstated certainty, and approves. The finance lead publishes. Every step is on the record, including the stale input that would otherwise have gone unnoticed.

How does Be Human run this after launch?

Be Human designs, implements and operates this kind of agent as personalized infrastructure. A first engagement defines the one planning role, the sources and register it needs, the permission and approval boundaries, and a success criterion finance can observe. After launch, managed operations cover monitoring of runs and traces, recurring evaluations against past cycles, maintenance of the connections to your ledger and planning tools, periodic permission review, incident response and controlled improvements. Finance keeps ownership of the numbers throughout, and nothing is published without a named approver.

For teams whose finance function also supports client work, the same design thinking appears in superintelligent agents for accounting firms, and the discipline of recurring, reviewable reporting is covered in AI agents for operations teams.

If you are unsure where to begin, take the free Be Human AI diagnostic to find the first task worth handing to an agent.

Frequently asked questions

Can an AI agent produce the forecast on its own? It can draft one, but finance should own the result. The agent prepares versions, explains variances and flags problems, while named people confirm assumptions and approve what gets published. This keeps accountability where it already sits and makes the output defensible.

How do I know the agent's explanations are not invented? Require each statement to cite a retrieved source or a stored calculation, and have the system around the agent record those citations rather than the agent describing itself. Then sample lines and rebuild them from the trail. Where the agent has no source, it should say so and mark the line as an estimate.

Which forecasting tools or models does this replace? Usually none. The agent works alongside your ledger, planning model and spreadsheets, reading from them and drafting into a controlled workspace. The statistical or driver-based logic stays in tools finance already trusts, and the agent handles the collection, checking and narrative around it.

What is a sensible first project? Pick one recurring cycle with closed inputs and a clear reviewer, such as monthly variance commentary for one unit. Define what an accepted draft looks like, run the agent in shadow mode for a cycle, and compare it with the analyst's own work before relying on it.

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