AI for FP&A: What Finance
AI Agents Actually Do
The arithmetic was never the expensive part. Explaining a movement, on every account rather than the eight you had time for, is where the FP&A month goes.
- What an FP&A agent does
- Where the FP&A month goes
- Where the numbers come from
- A worked budget vs actual
- Exceptions that break a variance run
- Thresholds and materiality
- What a person still approves
- Where it underperforms
- Forecasting and scenarios
- Asking the ledger a question
- How the FP&A cluster is organised
- Questions FP&A teams ask first
- An FP&A agent does four things. Query the ledger, split a movement into components that add back to the total, name the transactions behind each one, and draft the sentence a reviewer edits.
- The decomposition has to reconcile. A split that does not add back to the reported movement is wrong, and ChatFin fails it rather than pushing the difference into the residual.
- Accounting causes and operational causes are different answers. A released accrual and a reclass can be a quarter of a variance, and a commentary that calls the whole line an overspend is simply wrong.
- Thresholds decide what gets explained. An absolute floor, a percentage, a gross activity test for offsetting entries, and a stated residual for the tail.
- ChatFin reads through published interfaces such as SuiteQL, JD Edwards AIS and the Sage Intacct Web Services API, drafts against your approved prior wording, and posts nothing.
AI for FP&A means an agent that reads the ledger, decomposes a movement into components that reconcile to the total, names the transactions behind each one, and drafts the commentary a named reviewer approves. It does not build the plan, it does not decide what is material, and it does not post. ChatFin runs this against NetSuite, SAP, JD Edwards, Oracle Fusion, Sage Intacct and Dynamics 365 through published read interfaces rather than screen automation.
The reason this is worth automating is narrow. Working out that an account moved takes a second. Opening the account, sorting the postings, separating a rate change from a released accrual, and writing a sentence a reviewer will sign takes the back half of the FP&A cycle, which is why the last accounts in the pack get commentary written from memory.
What an FP&A agent actually does
Four jobs, and none of them is writing the plan. An FP&A agent pulls the ledger detail behind a number, splits a movement into components that add back to the total, names the transactions carrying each component, and drafts the sentence your reviewer edits. The judgement stays with the analyst. The lookups do not.
ChatFin runs these four against the ERP you already have, through governed read interfaces. It drafts. It does not publish, and it does not post.
Where the FP&A month actually goes
The arithmetic is free. Everything around it is not. A team closing a 40 account cost centre pack spends most of its cycle on three things that no planning tool removes, because they are data retrieval problems rather than modelling problems.
| Step | What it involves | Why a tool rarely helps |
|---|---|---|
| Getting the actuals | Extract, map to the plan structure, reconcile to the ledger | The plan hierarchy and the chart of accounts drift apart every year |
| Explaining the movements | Open the account, sort the postings, separate operational from accounting causes | The driver sits several layers below the variance |
| Writing it up | Turn the findings into sentences a reviewer will sign | Wording is inherited, not generated, and has to match last period |
The third step is the one that runs out of time, so the pack ships with commentary written from memory on the accounts nobody got to. That is the failure ChatFin was pointed at.
Where the numbers come from, by system
An FP&A agent is only as good as its read path. Every claim it makes has to trace to rows a person can open. These are the interfaces ChatFin reads through, and they are published interfaces rather than screen automation, which is why a screen change does not break them.
| System | Read path | What FP&A pulls |
|---|---|---|
| NetSuite | SuiteQL and SuiteTalk REST | A join across the transaction and transactionline records, plus saved searches |
| SAP ECC and S/4HANA | RFC enabled BAPIs and the ledger tables | ACDOCA line items behind FAGLL03, and the document headers above them |
| JD Edwards EnterpriseOne | Application Interface Services and Orchestrator | F0911 account ledger by account, document type and batch |
| Oracle Fusion | REST, with FBDI for file based loads | GL balances and journal lines, plus the subledger accounting entries |
| Sage Intacct | The Web Services API and the XML gateway | GL detail by dimension, which is where Intacct carries the plan structure |
| SAP Business One | The Service Layer over OData | Journal entries and business partner detail, the same on SQL Server and HANA |
ChatFin holds the mapping between the plan hierarchy and the chart of accounts as a versioned object rather than a spreadsheet on somebody's drive. When a cost centre is added mid year, the pack does not silently drop it.
Where a system has no governed read interface, ChatFin underperforms and says so. An agent reading through a screen scrape is a liability at quarter end.
A worked budget vs actual, 340,000 on one line
Contract labour, account 61200, west region. Budget 1,200,000 for the quarter. Actual 1,540,000. The pack says the line is 340,000 over and stops there. Here is what a decomposition puts in front of the reviewer instead.
| Component | Amount | Evidence a reviewer can open |
|---|---|---|
| Hours above plan | 184,000 | Timesheet postings, 2,300 hours against 1,850 planned |
| Rate above plan | 96,000 | Two vendors renegotiated in the prior quarter, new rate cards on file |
| Prior period accrual release | 78,000 | One journal, reversing an over accrual booked in the quarter before |
| Reclass in from account 61400 | 12,000 | A single correcting journal, both sides visible |
| Residual under threshold | negative 30,000 | Aggregated, 41 postings, none above 5,000 |
| Total | 340,000 | Adds back to the reported movement |
The reconciliation to 340,000 is the control. A decomposition that does not add back to the reported movement is wrong, and ChatFin fails it rather than rounding the difference into the residual.
The exceptions that break a naive variance run
Any tool can rank accounts by movement. The failures are the accounts a movement test never surfaces, and every controller has met all four.
ChatFin flags the last three as accounting causes and separates them from operational movement in the draft, because the reviewer needs to know which bucket a number sits in before deciding whether it matters.
Thresholds decide what gets explained
Set them once, version them, and review them at year end. A workable set has four parts, and the fourth is the one people forget.
An absolute floor
A cash amount below which a movement is not worth a sentence. It should differ by cost centre size rather than being one number for the whole company.
A percentage test
A share of the comparison balance, so a small account with a large proportional move still gets explained.
A gross activity test
Debits plus credits, for accounts where offsetting entries hide the movement. This is the test that catches the netting trap.
A stated residual
Everything below the thresholds, aggregated and shown as one figure with a count. Silence about the tail is how a pack loses a reviewer's trust.
What a person still approves
Everything that leaves the team. ChatFin drafts and a named reviewer signs, and the pack goes out under that reviewer's name rather than under the tool's.
| Stage | Agent | Person |
|---|---|---|
| Pull the detail behind a movement | Yes | No |
| Split the movement into components | Yes | Checks it adds back |
| Name the transactions behind each component | Yes | Opens a sample |
| Draft the narrative | Yes | Edits every sentence |
| Decide what is material | No | Yes |
| Sign the pack | No | Yes |
The line matters more than it looks. A fluent explanation nobody checked is worse than a blank cell, because a blank cell gets chased and a fluent wrong sentence does not. ChatFin is built so the reviewer sees the evidence next to the claim.
ChatFin keeps the approved wording from prior periods and drafts against it. Give it none in month one and the first draft reads generically. That is expected, and it improves as approved commentary accumulates.
Where an FP&A agent underperforms
Three situations, and it is better to know them before a pilot than after.
Forecasting and scenarios, where the agent stops
An agent is useful on the inputs to a forecast and weak on the judgement inside it. That split is worth being precise about, because it is where most FP&A pilots are oversold.
| Task | Agent | Why |
|---|---|---|
| Assemble the actuals baseline | Strong | It is a retrieval and mapping problem, and the evidence is in the ledger |
| Roll forward known contractual items | Strong | Rent, subscriptions and dated vendor agreements are documents it can read |
| Flag where actuals have already broken an assumption | Strong | It compares the assumption to posted activity and reports the gap |
| Build a driver tree for a new product line | Weak | There is no history to read, so it would be inventing the relationship |
| Choose a demand assumption | No | A commercial judgement, and it belongs to a person who owns the number |
| Decide which scenario goes to the board | No | That is the CFO's call and should never be a default |
A cash forecast makes the split obvious. ChatFin can pull open AP and AR by due date, apply the payment behaviour the ledger actually shows for each customer rather than the stated terms, and produce a 13 week position with every line traced to an open document. What it cannot do is know that the largest customer is about to renegotiate.
ChatFin reports the assumption it used and the rows behind it. Where an assumption is a judgement rather than an observation, it is labelled as one in the output so a reviewer does not inherit it by accident.
Asking the ledger a question in plain English
Natural language querying is the part of FP&A AI that demonstrates well and fails quietly. The question is easy. Knowing whether the answer is right is not.
The question is resolved against your own structures
West region has to mean the cost centres your hierarchy says it means, on the version of the hierarchy in force for that period. ChatFin resolves it against the mapping rather than guessing from an account description.
The query is shown, not hidden
The agent returns the filter it applied, the period, the ledger and the posting status. An answer with no visible query is an answer nobody can check.
Posted, unposted and reversed are separated
Most wrong answers in finance come from including a document class the asker did not mean. Parked SAP documents and unapproved journals are the usual two.
The row count is returned with the total
A total that looks right on 240 rows and should have been 2,400 is the failure that gets past a reviewer. The count is the cheapest control there is.
How the FP&A cluster is organised
Five hubs sit under this page, each with its own use cases. Four are live and linked below. The fifth is in build, so it is shown here rather than linked, because a link to a page that does not exist yet is worse than no link. Revenue analysis sits under the driver based hub here, and the accounting treatment behind those numbers is covered separately under AI for revenue accounting.
In build, FP&A KPI analysis
Natural language querying of finance data · KPI analysis
Questions FP&A teams ask first
What can an AI agent do in FP&A that a planning tool cannot?
Retrieval. A planning tool holds the model and reports the variance. It does not open the account, sort the postings and work out that 78,000 of a 340,000 movement is a released accrual from the prior period. ChatFin does that step, links each component to the document numbers behind it, and drafts the sentence a reviewer edits. The model stays where it is.
How do you stop an FP&A agent inventing an explanation?
Make it query before it writes, and make the split reconcile. The agent pulls the postings behind the movement, decomposes it into components that add back to the reported total, then assembles sentences from those rows. Where the detail does not support a claim about cause, the correct output is to report what moved, name the vendors and stop. ChatFin does that instead of filling the gap.
Which accounts should the agent explain?
Set thresholds once and version them. A workable set is an absolute floor that varies by cost centre size, a percentage test against the comparison balance, a gross activity test on debits plus credits for accounts where offsetting entries hide the movement, and named exclusions for accounts that swing by design. Everything below is aggregated into a stated residual with a count.
It does the forty lookups. Your analyst writes the sentence that ships.
ChatFin reads the movement on every account in scope, splits it into volume, rate, timing, reclass and residual components that reconcile to the total, and links each one to the journals and vouchers behind it.
It runs on the ERP you already have, through governed read interfaces, and it posts nothing. Where the detail is too thin to explain a movement, ChatFin says so rather than guessing.
Bring one month of account movements and the commentary your team wrote. The comparison takes an hour.
Book a demoSection photograph: a hand holding a pen pointing at a printed bar chart, sourced from Pexels and used under the Pexels licence.
All images are served from the Pexels content network. No third party product screenshots, vendor logos or licensed media are used on this page.
Bring last month's variance pack.
We will run the same accounts through ChatFin, show the decomposition behind each drafted sentence, and let your reviewer mark it up against what your team wrote.