Say your sales team signs a three-year contract on the 6th of the month. In a lot of finance teams the forecast finds out in week six, after the books close and the reforecast is rerun. Nothing in accounting requires that wait. It’s a calendar choice, and the calendar can be changed.
This series is about the alternative: a continuous close for FP&A, where the month’s numbers are loaded, checked and explained a little every night, a forecast change counts the day it’s submitted, and the accounting close is left with what actually needs an accountant. Three parts: what the idea is and why to aim at it, one FP&A month worked through old way and new, and how the thing is built.
The basis throughout: it can be built with mainstream AI tools and a web page, and owned by the finance team itself, provided the team runs it with a handful of controls. It is a design on paper, not a system that has run; it claims no results and quotes no costs of mine.
The series
- What a continuous close is, and why to aim at zero days · Zero-day close is a direction nobody has reached, and the right one to steer by. What a continuous close actually is, who is talking about it after twenty-five years, why the forecast is the point, and why a finance team can now build one without a software budget: writing the code got cheap, owning it did not. · about 9 minutes
- The use case: a contract signed on the 6th, on the forecast by the 8th · One FP&A month, twice. A contract that reaches the forecast in week six the old way and on the morning of the 8th the new way. Which numbers can close early, which must wait for month end, and the chain from purchase order to accrual that decides it. · about 11 minutes
- How to build it: small processes, one log, approvals where people already are · Small processes that tick all night, one log that nothing is ever deleted from, people at the gates, approvals taken in Slack or email and logged, and a console that is only a view over the log. Drawn, not described. · about 12 minutes
Also in the series
- Questions I asked · the questions I kept asking while designing this, answered in full with their own figures: where the forecast lives, the two closes, why actuals load nightly, exception queues, estimates, idempotency. It grows.
- The close console · an interactive sketch of the dashboard: close debt, what the month is waiting for, the queue, the log. Fictional data; try the queue.
- Build, control and evidence notes · the appendix: the nightly load in detail, the benchmark tables, the question-box rules, access and its workarounds, sixteen failure modes, the go-live gate.
What this series claims, and what it doesn’t
- One FP&A cycle: actuals against budget and forecast, explained, for a single entity, one currency, P&L only.
- It doesn’t shorten the statutory accounting close. Journals, reconciliations and accruals stay with the controller, on the controller’s timetable. A shorter close may follow from cleaner inputs; it’s a consequence, never the project.
- “Cheap” means no software licence and no development team. It’s paid for in discipline: a test month, a second reviewer, a release record, a run record, access in the data, a named owner on the alert. Part 1 shows the evidence for both halves.
- A design on paper: not run, no results, and no costs, build times or ROI of mine. Where I’m reasoning and where I have evidence, each part says which.
This is part of a series explaining AI and the systems around it for finance people, in their own language. I build AI systems for finance teams; the series is what I’ve learned doing it. This one is a design on paper, not a system I have run.