The problem
The close finishes on day five and the commentary lands on day nine. By then the operations review has happened with a bare variance table, and the questions the narrative should have answered are next month's agenda items. The delay is rarely the writing itself. It is waiting on a controller who is also doing three other things.
Most teams write commentary the same way. Someone opens last month's file, keeps the sentences that still apply, and edits the rest. That works when the author knows the business and has time to check. It breaks in a heavy close, after a reorg, or when the usual author is on leave. Two reviewers then write two explanations for the same freight variance, and nobody can say which one is right.
Dropping a pasted table into a chat window does not fix this. The model cannot see your sign convention. It does not know that account 6410 is contract labor in one entity and outside services in another. It will explain a timing difference as a run-rate change with total confidence. A believable wrong sentence is worse than no sentence, because a tired reviewer will skim it and sign.
What a good solution looks like
AI agent for monthly finance commentary: a playbook starts from one rule. The agent writes prose about numbers it was handed, not numbers it produced. The variance table comes from your warehouse: actual, budget, prior month and latest forecast, by entity and cost center, with the period locked. The agent explains selected lines and says where the evidence runs out. Numbers the model types are numbers nobody checked.
Selection is a rule, not a judgment call. Use absolute and percentage thresholds together, because a big percentage on a small line is noise and a small percentage on revenue is not. Add a fixed list that always gets commentary: revenue, gross margin, headcount, cash, receivables past 60 days. Keep that list in a table with a named owner so it does not drift between closes.
Each selected line needs evidence, and evidence means tool calls. The agent queries general ledger detail for the account, pulls the largest transactions, checks headcount changes and open commitments, and reads last month's commentary to see whether the expected driver landed. It then drafts two to four sentences with the account codes and journal IDs it used, plus a confidence flag.
The draft goes to a review queue, not to the board pack. A named controller edits it in place and approves it, and the system keeps the approved version next to the draft with a diff. If the agent finds no driver, it says so and lists what it checked. That one behavior saves more review time than any prompt tweak.
How to build it
Start with three to five line items and run the agent in parallel for two closes. Pick lines with real variance activity and a known cause, so you can grade the drafts fairly. Do not start with the whole profit and loss statement. Two parallel closes will teach you more about quality than any demo.
Build the data layer first. You need a governed view for the variance table, a materiality table, and a mapping table for accounts, cost centers and entities. Give the agent a read-only warehouse role through an approved API, not a login that clicks through ERP screens. When an account is missing from the mapping, the run should fail loudly instead of guessing.
Write the commentary spec as a document, not a prompt you keep editing in a chat box. Cover section order, sentence caps per line, currency and unit formatting, how to phrase favorable versus unfavorable variances, and phrases that are banned because they carry no information, such as revenue was up due to strong performance. Do the formatting in code. The model should never decide whether a number is in thousands.
Then build the workflow around it. A review queue in Teams or Slack, an approval step tied to a person, a stored diff, a fallback template that ships the variance table if the run fails, token and time budgets with alerts, and full logging of inputs, tool calls and outputs. Record the model version in the log so you can explain a change in tone six weeks later.
Risks and how to manage them
The main risk is a confident wrong explanation. Require a source for every claim, let the agent say it does not know, and make each citation checkable in one click. A reviewer should be able to open the journal entry a sentence refers to without leaving the page.
Sign and unit errors come next. A variance shown as positive when it is unfavorable, or millions read as thousands, will embarrass the pack in front of the people who spot it fastest. Compute signs and units in SQL and format them in code. Put a few unit tests on the formatting layer and rerun them after every change.
Mappings go stale. Cost centers get renamed, entities get merged, and an account moves between operating expense and cost of sales. Give the mapping table an owner and a change log, and treat an unmapped account as a failed run rather than a warning. Fix the materiality table between quarters, not in the middle of a close.
Watch for automation bias and access creep. A reviewer who approves twenty drafts without a single edit is a signal, not a success. Run sample audits, rotate the reviewer, and track how much each draft changed. Keep the agent read-only and unable to send anything until a person approves it. Treat board-level commentary as restricted data with the same access rules as the numbers behind it.
How to measure success
Baseline the current process before you build. Record the hours from trial balance lock to first draft, the number of review rounds, the factual corrections per pack, and the reviewer minutes per section. Those four numbers are your comparison, and you can collect them for the last three closes without changing anything.
After launch, track draft acceptance: the share of approved drafts that needed no factual change. Add edit distance, time to first draft, escapes (wrong statements found after distribution), and cost per close in tokens and engineering hours. Acceptance rising while escapes stay at zero is the pattern you want. Acceptance rising while escapes climb means reviewers have stopped reading.
Use a short rubric on a fixed sample each month: accuracy, evidence, tone, usefulness. Score it with the controller, not from the agent's own logs. Judge the trend across three closes before you widen the scope, because a single close can be strange for reasons that have nothing to do with the software.
Put the success measure in writing before the build starts, with the number and the date. The AI agent build package from Cloudverg, at $19,500 fixed price, runs five to six weeks and includes one production workflow, approval gates, an evaluation set and a 30 day tuning window. An internal build or a small variance tool is a fair alternative. Choose based on who will own the mapping tables once the project is over.
Frequently asked questions
Can an AI agent write month-end variance commentary without a person?
It can draft it, and it should not publish it. A controller or finance lead needs to approve each section. The agent should cite the ledger evidence behind every claim so that approval takes minutes rather than a rewrite.
What data does an AI agent need for finance commentary?
A locked variance table with actuals, budget, prior month and forecast, general ledger detail for the selected lines, headcount and open commitments, the account and cost center mapping, and last month's approved commentary. Access should come through a read-only API role.
How do you test an AI agent for finance commentary?
Run it against your last twelve closes and have the controller score each draft for accuracy, evidence and usefulness. Count factual errors and edits per draft. Then repeat on two live closes before you widen the scope.