The number on my CV that draws the most questions is the close: month-end cut from 12 working days to under 8 hours. People assume there’s a trick in it, or an exaggeration. There’s neither. There is a list, and the list is boring, which is the most useful thing about it.
The setting: an AIM/NASDAQ-listed, clinical-stage biotech. I built their planning platform in Anaplan from scratch, end-to-end FP&A for drug-discovery portfolios, and the close rebuild came with it. Reforecasting went from a week to a day in the same programme. The team was small, the scrutiny was not.
Where 12 days actually go
A 12-day close is rarely 12 days of accounting. Long closes everywhere share the same shape: most of the elapsed time is numbers in transit. Someone requests an export from the ERP. The export arrives, the columns get tidied, the file gets loaded. Something doesn’t tie, so the export gets requested again. Headcount arrives from the HR systems on their own separate loop. Consolidation happens in workbooks, and the workbooks have to wait for everything else. The actual accounting judgment, the accruals and the cut-off calls, sits inside a few of those days. The rest is logistics.
That’s worth saying plainly, because the fix follows from the diagnosis. None of what took the close from 12 days to 8 hours made anyone a faster accountant. It removed the transit.
The list
The data stopped travelling by hand. Actuals from NetSuite via SuiteAnalytics, headcount from the HRIS (two of them at the time, HiBob and BambooHR), warehouse data from Snowflake, all landing in the model as scheduled batch loads through CloudWorks and the REST APIs. The loads run through the close itself, overnight, so the model is current when the team logs in. Nobody exports, tidies or uploads anything.
Batch, note, not real time. That was a choice, not a limitation. You don’t need real time for monthly actuals reporting; you need the numbers reliably there every morning of the close. Overnight batch delivers that, and it’s simpler to run and to audit than a streaming connection nobody asked for.
flowchart LR
N[NetSuite<br/>actuals] --> C[Scheduled loads<br/>CloudWorks + REST, overnight]
W[HRIS headcount<br/>HiBob + BambooHR] --> C
S[Snowflake<br/>warehouse data] --> C
C --> A[Anaplan<br/>consolidation and reporting]
A --> X[Exports to the<br/>analytics stack]Consolidation moved inside the model. The workbook layer between the ledger and the reporting was retired. Once the loads land, the model rolls the entities and portfolios up itself, the same way every month, with the logic in one governed place instead of in linked spreadsheets.
The real world went in as hierarchies. This is the thing Anaplan is actually for, and it deserves its own paragraph. A ledger gives you flat lists: an expense line, a cost centre, a period. Flat lists can tell you what was spent. They can’t tell you what the spending was for. So the estate was built as a rollup that mirrors how the business actually thinks about itself: expense lines into phases, phases into projects, projects into project types, project types into project partners, partners into portfolios. Every number that lands from the ledger climbs that structure on its own, which means the close produces answers at every level at once. The board asks about a portfolio, the programme lead asks about a phase, and both are reading the same governed numbers, one rollup apart.
The same structure is what makes complex scenarios tractable. Slip a phase by six months, or move a programme between partners, and everything above it restates itself: project, portfolio, P&L. In workbooks that’s a rebuild; in a hierarchy it’s an input. It’s a large part of why reforecasting fell from a week to a day.
The team never leaves the model. A complete UX, so review, adjustments and reporting all happen in Anaplan. This mattered more than it sounds. Every system boundary a number crosses during close is a queue, a version risk and a place to lose an evening.
The dull guards that keep it true. A security model with proper roles, selective access and Dynamic Cell Access, so month-end has segregation of duties rather than a shared login and good intentions. A size and performance strategy, so the model is still fast in month 30 with real volumes in it. Training and handover, so the finance team runs the close themselves. It only counts as an 8-hour close if it’s still one after I’ve left the building.
One definition, for honesty: by close I mean the mechanical close, from ledger close to consolidated actuals reported and ready for review. The judgment work, reviewing the result and explaining it, is what the recovered days are for. Compressing that was never the goal. Protecting it was.
What this has to do with AI
Nothing, and that’s the point of putting it first in this series. There is no AI anywhere in that close chain. It’s pipes, scheduling and model design, and it removed roughly 11 of the 12 days on its own.
I write elsewhere on this site about AI for finance teams, and I build AI systems around exactly these estates: commentary drafted from the variance detail, questions answered from the pack with the source attached. All of it works better on top of a close like this one, because the numbers arrive governed, on time and in one place. The order matters. Automate the transit first, then put intelligence on top. Teams that reach for AI while the actuals still travel by email are decorating a bottleneck.
What I’d tell your CFO
If your close runs long, time where the days go before buying anything. Ours went to data in transit, and I’d bet most of yours does too. Scheduled loads, consolidation in one governed model and a team that never has to leave it took this close from 12 days to 8 hours, with no AI involved. The technology is mature and the pattern repeats. Then, once the numbers move themselves, the interesting layer goes on top.
This is the first post in a strand about Anaplan estates: the automation, data pipelines and AI that wrap around a planning model. I’m a Master Anaplanner with eight years of builds behind me; the strand is what they taught me.