Start With One Recurring Report
Monday morning, an FP&A analyst opens last month's actuals export, screenshots the variance dashboard, and pastes both into a chat window with the same prompt: summarize what changed and why. The model answers fluently. Nothing about the close changes. The screenshot stays the artifact of record, the variance gets re-explained from memory in the Tuesday meeting, and next month the same analyst does the same paste, because nothing about the loop moved.
That is the real starting condition for AI in most finance teams right now, and it explains why so many pilots stall at "interesting demo." The enemy belief is not that AI cannot help with reporting. It is the belief that helping requires a bigger move first: pick the perfect agent platform, connect every system at once, or paste last month's entire pack into chat before AI earns a seat at the close.
It does not.
Connect the report read-only. Then run it on a clock.
That is the whole first move, and it is small enough to finish this week.
What the Screenshot Actually Costs
The obvious complaint about the screenshot-and-paste ritual is that it is manual. The quieter cost: every time the report gets rebuilt from an export, the review standard resets with it. Nobody wrote down what "good" looks like for this report, so whoever reads it re-derives the standard from memory, out loud, in the meeting. Make Your Work Easier to Review called that the first AI skill: designing the work so someone can judge it in minutes instead of rebuilding it from scratch. A recurring report is the cleanest place to apply that skill, because the standard barely changes from one cycle to the next. Write it once. Reuse it every time the report runs.
Agentic Performance Management Starts at the Data Layer already made the deeper architectural case: an agent is only as useful as the layer it is allowed to touch. If it only ever sees an exported screenshot, it becomes a faster summarizer of a number that was already stale before the export finished. This piece is the walkthrough for that argument: how one team wires one report to a real source, instead of asking a model to be clever about a copy of a copy.
The Recurring Report Ladder
Call it the Recurring Report Ladder, seven rungs. It is the first concrete version of the loop Stop Counting Tasks. Start Closing Loops. already argued for: work that closes on its own instead of waiting for someone to notice it is done. You only need to climb one rung at a time.
- Pick one report that already repeats
- Write the review standard
- Connect the source
- Lock it read-only and bind SSO
- Run it once with a human review
- Put it on a clock
- Stack skills, plugins, and the next report
Rungs 1 and 2: Pick the Report, Write the Standard
Do not pick a new report. Pick the one that already exists on a schedule: the monthly budget-vs-actuals variance pack, the weekly pipeline-to-forecast check, the biweekly headcount and spend summary. This walkthrough uses the budget-vs-actuals pack, since most finance teams already have one and its shape rarely changes: it repeats, the inputs are already known, and the only thing missing is a live connection instead of an export.
Before anything gets connected, the analyst writes the standard in one sentence: the pack explains every variance over a set threshold with a named driver, and a VP can approve it without a follow-up question. That sentence expands into five must-have sections: the period covered, actual versus plan side by side, a named driver for every variance over the threshold, an open-questions line, and a named owner who signs off before the pack moves up the chain. Make Your Work Easier to Review called this the first AI skill; rung two is that skill applied to one document.
The standard also names how the pack usually goes wrong: the wrong period gets pulled, a definition drifts (marketing counts a renewal as new revenue, finance does not), or a variance clears the threshold with no driver at all. Good looks like a one-line driver for every material variance, one a VP could repeat back in the hallway, an open-questions line that is empty or genuinely open, and the owner's name on it. Not good looks like a driver that restates the number instead of explaining it, a period mismatch nobody caught, or no owner at all, so the pack gets approved by momentum instead of anyone actually checking, which is worse than an honestly incomplete pack because it reads as reviewed when nobody actually reviewed it. Skip this rung, and every future run inherits the exact problem the screenshot had: nobody can tell if it is right except by rereading the whole thing end to end.
Rung 3: Connect the Source
The report needs one live connection to the system that actually holds the numbers, not a copy of them. There are three ways to make that connection, and the right one depends on what already exists, not on which sounds most sophisticated.
The first path: use an existing MCP. In 2026, the default way an agent tool reaches a system it does not own is MCP, the Model Context Protocol, and a growing number of source systems already ship a server for it. If the ERP, CRM, or planning tool behind the budget-vs-actuals pack already has one, connect to it and this rung is done.
The second path: write a thin custom MCP. If the source does not ship one, a small wrapper in front of it, the ERP, the CRM, the warehouse, even a spreadsheet API, does the same job: it exposes a handful of query tools, get actuals for a period, get plan for a period, get driver notes, instead of a wide-open API surface. Microsoft's Dynamics 365 ERP MCP is an attributed example, not a product to buy for this report: every request travels through as an authenticated user, not an anonymous database bridge, governed by the app's own security model.
The third path, and the one to prefer once available, is the database or governed warehouse directly. Once actuals, pipeline, headcount, and spend already land in one governed store, one read-only connection covers the entire reporting surface, this report and the next five. The database is the ultimate path because it is the union of every source system you would otherwise connect one at a time. Until that store exists, connect the one source this report needs and let the rest of the consolidation catch up.
Whichever path the analyst takes, the actual ask to IT or security is one sentence: a read-only identity, scoped to only the tables or views this report needs, with no write tools attached at all. That is a smaller, more answerable request than "give the AI access to the ERP," and it is what turns rung four from a policy debate into a checkbox.
Rung 4: Lock It Read-Only and Bind SSO
The two objections here are accidental writes and prompt injection, both fair. The operator answer to both is the same: make the connection read-only, and bind it to the identity your company already trusts.
Read-only means the MCP server only exposes query and fetch tools, nothing that creates, updates, or deletes. There is no write path for a bad instruction or a compromised prompt to travel down. Microsoft 365 Copilot's federated connectors already default to this pattern: read-only tools, authenticated through Microsoft Entra SSO or OAuth 2.0, data staying in the source system instead of copied into the chat product.
Binding to SSO means the report runs as a real identity your company already governs, Microsoft Entra or whatever the work identity provider is, not a shared service account with a password in a Slack message. Microsoft's 2026 MCP security guidance treats every MCP server as an OAuth resource server: OAuth 2.1 with PKCE, least-privilege scopes, an identity-aware gateway, and Entra Agent ID to govern the whole class of agents touching that data, not just one connection. Prompt injection and over-scoped tools are the two risks that guidance names as live, not theoretical; read-only plus SSO is the boring, available answer to both. It is a configuration choice you make before the first run, not a research project you fund after the second incident.
Rung 5: Run It Once With a Human Review
Read-only protects the source system. It does not protect the report. A read-only connection can still pull the wrong period, apply a definition the team does not use, or attach a driver that restates the number instead of explaining it. None of that is a write problem. It is a review problem, which rung two exists to catch.
On the first run, someone who already knows the pack reads the whole thing against the standard from rung two, tougher than a normal review, because this run decides whether the connection is trustworthy going forward. Four checks, every time: is the period right, does every driver use the team's actual definitions instead of a plausible-sounding substitute, does every variance over the threshold have a driver that would survive a follow-up question, and could a VP sign off on this pack in the few minutes the standard promised. A pass on all four earns the report its place on a clock. A miss on any one means the connection or the prompt needs a fix before rung six, not a note to keep an eye on it. This is the one rung that stays fully human, on purpose, every time the report's shape changes.
Rung 6: Put It on a Clock
Once the first run holds up, the report runs itself on the schedule it already had, and someone specific owns that schedule, the same way someone owns the close calendar. For a monthly pack, on a clock means one thing: it runs once the books close for the period, not on a fixed calendar date that might land before the numbers are final, and it lands in the same shared place every time, same folder, same channel, same recipient list.
Stay generic about which scheduler does the running: whatever your team already uses, Copilot Studio, Claude's scheduled tasks, Cursor's scheduled agents, or a cron job hitting the same MCP connection. The product does not matter. What matters is what happens when the connection fails, because it eventually will: the schedule owner gets a clear failure notice instead of a silently missing pack, and the fallback is the old export process.
Review moves from every run to a spot check only after several consecutive runs pass rung five's four checks without a miss. The trigger for going back to full review stays simple: any month the source system changes, the account structure changes, or a number looks off, review that run in full before trusting the next one.
Rung 7: Stack Skills, Plugins, and the Next Report
Scale Your Top 1% argued that expertise scales as a skill before it scales as a fleet, and that centralizing judgment comes before automating consequences. A read-only, scheduled report does not break that order: it is not automating a consequence, it is automating a look. Once the loop is live, three different things can stack on top of it, and they are not the same move.
Skill. The review standard from rung two, written down and loadable, so any analyst who runs the pack applies the same bar the first reviewer did. This is the cheapest stack, and the one to do first: it costs a document, not a connection.
Plugin, or a small add-on. A thin extra step once the loop is trustworthy, not a new platform: drop the finished pack in the shared folder automatically, email the exception list to whoever owes a driver, post the variances that cleared the threshold into the channel where the close conversation already happens.
Scheduled routine. The clock from rung six is the first routine. The next ones should be exception-only, not a second full pack: an alert when a variance clears a threshold between runs, a reminder when an owner has not signed off in time, a flag when the connection itself needs attention.
Skills get stacked after the loop exists, not instead of it. The one exception: if the standard from rung two is still tribal, sitting in one analyst's head instead of on paper, write that down as a skill first. A read-only feed into an undefined standard just delivers confusion faster.
Once one report is live, the next move is not a new platform. It is the same seven rungs against the next report that already repeats, the pipeline forecast, the headcount plan, the vendor spend summary, each adding a node to the same governed connection.
The Loop, Not the Chat
Stop Asking AI Questions. Give It Work to Finish. argued that the useful unit of AI work is the finished artifact, not the chat answer. A recurring report pushes that further: it only counts as finished if it can run again next month without anyone reopening a chat window. A summary living inside one conversation is not a report. It is a one-time favor. The report becomes real the moment it survives past the conversation that produced it.
This Week
Five actions, one sentence each, all inside one normal week.
- Monday: Pick the one report that already repeats, and write its standard in one sentence.
- Tuesday: List the must-have sections, the failure modes, and the named owner for that report.
- Wednesday: Ask IT or security for a read-only identity, scoped to only the tables or views this report needs.
- Thursday: Run the report once, and review it against the standard, tougher than a normal pass.
- Friday: Put it on the clock, name who owns the schedule, and decide what happens if the connection fails.
That is the whole ladder, minus rung seven. Stacking a skill, a plugin, or a routine on top of a report that has not run once yet is planning ahead of evidence, not leverage.
Beginner's Mind Is Refusing the Platform Tour
Every finance team facing this decision gets offered the same tour: a platform demo, a roadmap deck, a list of forty connectors, a promise that the real value shows up once everything is wired together at once. Beginner's mind, in this context, means refusing that tour on purpose. One live loop, wired to one real source, reviewed once by a human and run on a clock, teaches more about what AI can do for the close than any slide showing forty theoretical integrations.
Staying naive about risk is not the same as staying naive about leverage. Read-only is how you get both at once, a connection with no write path for a bad instruction to travel down, and a report that compounds every time it runs. Chat summaries of last month's pack do not change the close. A live, reviewable, scheduled report does. Teams that stay in paste-the-spreadsheet mode will keep paying for intelligence and still start every Monday from a screenshot.
Reflection Point
Which report do you already produce every week or month that still starts from an export?