The use case: a contract signed on the 6th, on the forecast by the 8th

Say your sales team signs a three-year contract on the 6th of the month. When does your forecast find out?

If your reforecast is a monthly event that follows the accounting close, the answer is week six. The month has to end. The books close, and the median company takes eight days over that.¹ Then the forecast is rerun, and producing one takes eleven days at the median.² A deal that changes the next three years waits in someone’s inbox while the numbers that run the business carry on without it.

That’s a process, not a law of accounting. A forecast is a separate model, and someone could revise it on the 7th. It waits because producing one is slow and the calendar says once a month, after the actuals are final. Both reasons are fair. Neither is permanent.

This part runs the same month twice, then gives the honest account of which numbers can be current on the 8th and which can’t.

The setup

The company is fictional, a mid-sized distributor I’ll call Caldergate: a single entity, one currency, P&L only. Actuals live in an ERP, NetSuite in this example. Forecasts live in twelve Excel workbooks in a shared folder, built by different people and changing through the month. The budget was loaded once. The reforecast happens after each close.

Five roles: an analyst, an FP&A lead, a controller, the budget holders, a CFO. Roles, never names, because the design is about where decisions sit. What the team has today: an export, a variance workbook rebuilt every month, and a pack emailed after close.

The old way, on the calendar

Day 6: the contract is signed. Sales finance knows. The forecast workbook isn’t touched, because the reforecast is next month’s job and the actuals it would be built on are weeks away.

Days 31 to 38: the close. Everything is exported, tidied, mapped and tied. Then the reforecast cycle, then the pack, then the variance meeting. One practitioner in that r/FPandA thread described the window for analysis as “just one day, always a time crunch”.³

The forecast finds out in week six. By then the three-year decision has been made on a stale base, or not made at all, and the questions that came up along the way were never asked because the numbers were being rebuilt.

The calendar was built this way for reasons. You want final actuals to forecast from. Producing a forecast is expensive, so you batch it. Batching is rational when each run is dear. It stops being rational when the run is a nightly job.

The new way, the same month

Every night since day 1 the ledger has loaded and been checked. The page shows each line’s posted figure and, where the month hasn’t caught up yet, an estimate, labelled as one.

Day 7: someone in sales finance revises the forecast workbook and marks it submitted. That night the reader stores it as version 9 and works out what it changes against the approved baseline, version 7.

Morning of day 8: the page shows +£2.1m over three years, marked submitted, not approved. Friday: the controller approves it into the baseline or sends it back. Either way it’s logged, with the reason.

Everyone with a login sees the same page. Nobody emails a file. The design removes the wait after a person revises the workbook. It can’t make them revise it.

Every night, every week, at month end

Every night, with nobody watching

Five things happen in order.

1. Actuals in. A job pulls the general ledger. To begin with, a monthly export dropped in a folder will do. Posted rows can still change, so every open period is pulled again each night.
2. Forecasts in. Excel stays. Each workbook gets one extra tab in a fixed layout that a small program can read, and the owner’s model behind it doesn’t change. When the owner marks the workbook as submitted, that night’s run stores it as a new version.
3. Mapping. One table, owned by finance, says which ledger account and department belongs to which reporting line. Anything it doesn’t recognise goes to an exception queue and shows on an “Unmapped” line, so the totals still tie. A model may suggest where a new account belongs. A person decides.
4. Compute. Fixed, tested code calculates the estimates for what hasn’t posted, actuals against the budget phased to date, the variances, and what changed between one forecast version and the next. A line gets flagged once its variance passes a threshold set by its owner.
5. Explain. For each flagged line the code gathers the evidence: the transactions behind it, the purchase orders, last month’s commentary. A model drafts an explanation that cites them, and code checks that each cited transaction exists and each figure matches.

Nothing is re-keyed, and four checks block publishing: rows fetched equal rows stored, amounts tie to the trial balance, each workbook sums to its stated total, and every amount is mapped or shown as unmapped.

Every week, people do the judging

Analysts clear the exception queue. The FP&A lead reads the drafted explanations, corrects them and signs. The controller approves changes to the forecast baseline or sends them back. Each signature is tied to one run and one amount, so if the number later moves past its threshold the explanation shows as stale and waits for a new signature.

Month end keeps what needs an accountant

Accruals for what hasn’t arrived, provisions, anything unusual, and the final sign-off stay with people. Friar’s line covers it: “Finance validates the numbers, applies judgment, and owns the final sign-off.”⁴

Why some numbers can close early and some can’t

Posted, estimated, final

A current view can’t make an invoice arrive sooner. Much of what makes a month’s numbers true lands late, and some of it lands only because an accountant posts it at month end. If the page ignores that, cost lines look under budget until the invoices arrive, and nobody trusts it.

So each line carries three layers, and the page shows which one you’re looking at.

• Posted. What is in the ledger tonight.
• Estimated. What is known but not yet posted, worked out by fixed code from records finance already keeps: open purchase orders, goods received and not yet invoiced, contracts with a schedule, a payroll run not yet booked.
• Final. What accounting posts at month end. It replaces the estimate.

The estimate is arithmetic on stated records, and the page shows its working. It’s only as good as those records. Accounting still owns every accrual: the view never posts a journal, and its estimate is a starting point for the accountant’s own number.

From purchase order to accrual: when each becomes known

Take the chain most cost lines travel. A purchase order is raised. Goods or a service arrive. The invoice comes in and posts. It gets paid. The question for a mid-month page is at which link the cost can be known, and the answer is different at each one.

At the order, the cost is a commitment. The amount may change and the timing is a guess, so an estimate built from open orders alone is weak, and the page should say so. At receipt, the cost is real whether or not the invoice has arrived. Goods received and not invoiced is the oldest accrual in the book, and it can be estimated every night from the receipts. At invoice, the ledger knows, and the estimate is replaced by the posting. Payment changes nothing on the P&L.

The month-end accrual journal is the formal version of what the page has been estimating since the receipt. It reverses the following month, and the page doesn’t flag the line again until the reversal is matched; otherwise every line would flag in the first week of every month.

Two things decide how good the mid-month number is, and both are habits upstream. Spend that never had a purchase order has nothing to estimate from, and stays understated until the invoice arrives. And orders that nobody receipts stay weak estimates: in the console sketch, freight carries fourteen of them, which is why its estimates miss by 6%. That part is a process to change, and worth asking for.

Other lines follow other records. Contracts with a schedule, like software, rent and support, are estimable from the schedule. Timesheet-driven costs from the timesheets. Payroll from the last run, adjusted for joiners and leavers, until the pay date.

What lands at month end, and why

Some numbers have no nightly version. Payroll posts on the pay date. Revenue recognition runs at close, so until then the page shows billings to date, marked as billings. Depreciation, allocations, FX revaluation and intercompany land when accounting runs them, so last month’s figure is carried forward and marked as such. Judgement provisions wait for the controller.

The page lists every line with what it’s waiting on and when that lands. Nobody has to remember.

The estimates are checked against what finally posts

At month end each estimate is compared with the posted figure. The gap, line by line, is the trust score for next month’s mid-month view, and it goes on the scorecard every month.

A pattern of gaps points upstream: receipts not raised, invoices held back until the last week, a contract schedule nobody updated. Finance teams already make these estimates by hand at month end, for payroll above all. The design makes them every night, from the same records, and labels them.

Submitted is not approved

Every submitted workbook becomes a version, and no version is ever overwritten, which is what makes “what changed since last Tuesday?” a question with an answer.

The approved baseline is a separate thing. It’s the forecast the business is planning against, and it moves only on a named role’s approval. Friar’s rule is the one to copy: “Every change to an approved baseline should require finance authorization.”⁴ Without that gate one event can whipsaw the number everyone plans to, and nobody can say which forecast a decision rested on.

Back to the contract. Version 9 on the 8th. Approved on Friday, with the reason logged: a three-year contract signed on the 6th. Baseline v9 from then. Version 7 kept, so “what was the business planning against in September?” also has an answer.

The questions this makes cheap

Cheaper questions need somewhere to be asked. A question box sits on the page and in the chat tool, and it reads the same computed tables and files as the page, nothing else.

A quick question, “Why is software over budget this month?”, gets a few sentences with a citation on every figure, read as the person asking. A worked question, “What does this contract do to the next three years?”, gets a memo. The agent gathers the contract terms, the forecast versions and the lines affected, asks the person to confirm any term it has read from a document, and calls the fixed calculations as tools. The memo gives the figures with their sources, its assumptions and what it couldn’t determine, and a person reviews it before anyone acts.

Two limits. A forecast’s logic lives in its workbook’s formulas, so a what-if only works where someone has written and tested a function for it; otherwise the honest answer is a memo naming the lines affected and asking the owner to rerun the workbook. And reliability. Uber built a finance agent on curated tables, with role-based permissions and tests against known-good queries, and its engineers still write that “it’s not 100% reliable and is prone to hallucination”.⁵ So the agent here never does arithmetic, code compares every number in an answer with the tool results, and an answer that fails isn’t shown.

What the team stops doing

Stage by stage, this is what the month gives back. Exporting, tidying and uploading by hand. Rebuilding the variance workbook. Writing first drafts in the days after close. Emailing packs. Saving questions for a quiet week.

One scope line, since this is the part people will forward. One entity, P&L, a design on paper. The statutory close keeps its timetable; what it gets from all this is cleaner inputs and estimates that were ready on the last night. Part 3 is how the nights, the gates and the log are built.

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.

Sources