What a continuous close is, and why to aim at zero days

Zero-day close is a direction. The median company takes eight days.¹

In August 2026 OpenAI’s chief financial officer, Sarah Friar, set out two ambitions for her own team: a zero-day close and a forecast that updates itself. In the same article she wrote, “We are still building toward both ambitions.”² I looked for a company reporting a zero-day close in production and found none. That’s a search result, nothing more, and a small, highly automated business may well get there first. So treat zero days as the bearing, and ask what a finance team can build on the way.

This part answers four questions. What a continuous close actually is. Who’s talking about it, and why an idea from 2001 is suddenly everywhere. Why the forecast, not the close, is the point. And why a finance team can now build one without a software budget: writing the code got cheap, and owning it did not.

Zero-day close is a direction. The median is eight days.

APQC, which benchmarks finance processes, puts the median monthly close at 8.0 days across 3,389 companies.¹ A smaller vendor survey of 100 finance professionals found 18% closing in one to three business days and 27% taking more than seven.³ The firms that sell faster closes quote days as well. Numeric, which makes close software, published an article asking whether a zero-day close is possible, and the controller it quotes says: “The golden mark is five to seven business days.”⁴

An honest close has a floor. Invoices arrive late, some estimates need judgement, and somebody has to sign. So the destination is less interesting than the direction. What matters is what you get before the close gets any shorter, and that’s the forecast.

What a continuous close actually is

The close doesn’t disappear. The scramble does.

The clearest description in print is Friar’s. The model behind her ambition connects “approved spending plans, general-ledger actuals, purchase orders, accruals, and transaction details in a continuously reconciled view”, with each variance traceable to the activity behind it.² In plain words, the loading, checking and explaining that a batch close saves for month end gets done a little every day.

The close itself stays. “The close does not disappear,” Friar writes. “What begins to disappear is the scramble to reconstruct the business after the period ends.”²

Batch against continuous

Here is the difference in one table. The left column is the batch close as it’s commonly run. The right column is the design this series describes.

Some teams already work this way with no software to speak of. One commenter in an r/FPandA thread on post-close analysis time wrote: “Doing it all month. Close BD4, variance meeting BD7.”⁵ What software changes is the effort of keeping that rhythm up.

Two closes: the statutory one keeps its timetable

This series is about the FP&A side, the management numbers that run the business. A mid-month view is a soft close, and a soft close trades accuracy for speed, which is why it doesn’t suit statements that outsiders rely on.⁶ So keep both. The continuous view runs the business, labelled provisional. Anything reported outside the company still comes from the statutory close, on the controller’s timetable. If that close gets shorter, it’s because the inputs arrive cleaner and the estimates are ready on the last night. A consequence, never the project.

Twenty-five years old, and suddenly everywhere

The idea isn’t new. In April 2001 Cisco’s chief financial officer, Larry Carter, published “Cisco’s Virtual Close” in Harvard Business Review.⁷ BlackLine announced “Continuous Accounting” in 2016.⁸ Then not much, for years.

Then a lot. In 2025 Numeric asked whether zero days was possible.⁴ An MIT Sloan and Stanford study of 79 small and mid-sized firms reported that accountants using generative AI cut 7.5 days off the monthly close; the data came from a provider of accounting AI software, which is worth knowing.⁹ In 2026 a consultancy reviewed NetSuite’s Autonomous Close and reported one customer moving from 10 to 15 days to 3 to 5, with estimates, provisions and approvals still human.¹⁰ BCG described an “AI-first finance function” and predicted leading organisations would be running one within two to five years.¹¹ And in August, OpenAI.²

Each vendor on that list sells the thing it describes, and each consultancy sells the advice. Allow for that and the pattern still holds. What changed between 2001 and 2026 wasn’t the idea. The inputs went digital: bank feeds, purchase order systems, electronic invoices. Then the cost of building the plumbing between them fell. The section after next is about that.

Why you’d want one: the forecast is the point

Sooner

Say your sales team signs a three-year contract on the 6th of the month. With a continuous view it reaches the forecast in days, not weeks, and something with a three-year tail gets a decision this week. Part 2 works that example through.

A faster accounting close wouldn’t buy you that. Cisco is the warning. Its finance chief wrote in 2001 that the company could close its books within hours. That same year it wrote off $2.2 billion of inventory, while competitors had started cutting their forecasts months earlier.¹² Closing fast and forecasting responsively turned out to be separate skills. The payoff of seeing events sooner is also argued far more often than it’s measured, so weigh it as reasoning.

Cheaper to question

Your team can probably list the questions it has stopped asking. Why did that line move? What happens to the year if this programme slips a quarter? Each can take hours or days to answer, so it waits for a quieter week. In the 2026 FP&A Trends Survey of 475 finance professionals, only 19% of teams said they could run a scenario in real time or within a single day. The survey is sponsored by OneStream, which sells planning software.¹³

Current numbers lower the price of a question in three ways. Nobody has to refresh anything first. Every figure already carries its source, so checking an answer is one click. And a question box sits on top, so asking takes a sentence. I found no count of the questions that never get asked. The case for them is an economist’s: when a technology makes something cheap, people use far more of it.¹⁴

More accurate, by design

Speed usually costs accuracy. Two things push the other way here, and neither needs AI. Nothing gets typed twice: in one controlled experiment, entries checked by eye had about thirty times the errors of entries typed twice and compared.¹⁵ And every load is checked the night it lands, so an error is a day old when someone finds it. Treat accuracy as a design aim all the same. I found no published error rates from before and after a change like this.

Why now: writing the code got cheap

Look at what the design actually needs. A reader for the forecast workbooks. Four checks. The estimates for what hasn’t posted. The variance arithmetic. A month of known answers to test against. These are small programs, and until recently writing them meant a developer, a project, and a budget line most finance teams never got.

The tools are mainstream now, and none of them needs a licence you don’t already have: an AI coding assistant, a scripting language, a database, a scheduler, a web page behind your company sign-in, and the chat tool your team already lives in. Part 3 draws the whole thing. No product in it is the hero.

The evidence that writing got cheap is reasonably strong, and specific about who gains. In three field experiments covering 4,867 developers, those given an AI assistant completed about 26% more tasks, and the least experienced gained most; two of the six authors work at Microsoft.¹⁶ A 2026 meta-analysis of 23 studies found a moderate effect that shrinks in enterprise and open-source settings.¹⁷ At the other end, METR’s 2025 trial found experienced developers in mature codebases were 19% slower with AI tools while believing they were faster, and its 2026 follow-up, with 57 developers, found no clear effect either way and called the measure a poor proxy for real productivity.^{18 19} Read together: the gain is largest for newcomers and new work, smallest for experts in old code. A finance team building its own small programs is the first case.

Finance people are already doing it. In OpenAI’s 2026 study of how its tools are used at work, engineering tasks made up about a fifth of the occupation-specific requests from finance users.²⁰ Friar describes a colleague who had never coded building a forecasting tool, and says “the people who understand the problem can now shape the solution”.² Her team has engineers on tap, which most finance teams don’t. The point survives: the person who knows which formula is right can now write the program that applies it.

What didn’t get cheap: owning it

Maintenance has been the larger part of software cost for as long as anyone has measured it. Robert Glass put it at 40 to 80 percent of the total, 60 on average, with enhancement about 60% of that and corrections about 17%.²¹ That was 2001. Nothing in the studies above measures it falling.

The delivery data points the other way. DORA’s 2024 report found that for every 25% increase in AI adoption, delivery throughput fell 1.5% and stability fell 7.2%; its 2025 report, with around 5,000 respondents and 90% of them using AI, still found stability going the wrong way.^{22 23} In Stack Overflow’s 2025 survey of 49,009 developers, 66% said AI answers were “almost right, but not quite”.²⁴ Vendor studies, disclosed as such, say the same with bigger numbers: review time up 91% across one analytics firm’s customers, duplicated code rising in another’s data, security vulnerabilities in 45% of the coding tasks a third set its models.^{25 26 27}

Finance has its own record here, with no AI involved at all. A review of the field audits found errors in 94% of the spreadsheets studied.²⁸ Another study found wrong results in 43 of 50 in everyday use.²⁹ In 2018 a listed drinks wholesaler lost £5.2m to what the Guardian described as “a spreadsheet arithmetic error made by a member of its finance team”.³⁰ A finance team that builds with an AI assistant inherits that record unless it runs differently from how it runs spreadsheets.

One writer argues the owning costs are falling too: “the cost of reviewing, fixing and operating it is following, and I’m assuming it gets there.”³¹ Maybe. No data shows it yet, and the data that exists points the other way.

So “cheap” means something precise. No licence. No development team. The price is discipline: a month of known answers the code has to reproduce before every release, a second reviewer on every change, a release record, a run record for every night, access enforced in the data, and a named person who hears when a run fails. A finance team that builds its own hasn’t escaped the dev team. It has become a small one, and runs like one. Part 3 shows what that looks like, and it’s less than it sounds.

Build, buy or hire

A rule, then. Build where the process is bounded, the inputs are yours, the output can be tested against known answers, and an owner is named. Variance commentary, mid-month estimates, forecast versions: build. Buy the system of record. BCG’s guardrail for finance teams writing their own software is that such apps “do not replace the system of record”, and that’s right; the ledger is bought, not built.³² Hire, or borrow from IT, for anything that must run unattended for other people or face the outside world: a customer-facing statement run, anything that files externally.

COSO’s stance on model output carries over to finance-built code: treat it “as claims requiring validation”.³³ An accountancy firm writing on the same subject says that once a tool proves useful it should be handed to a developer to rebuild properly.³⁴ This series says finance can own production if it runs the controls, and shows them.

What this series covers

Part 2 takes one FP&A month through the old way and the new, down to which numbers can be current on the 8th and which must wait for month end. Part 3 draws the build: the processes, the log, the gates, the approval card in Slack, the console. The appendix holds the detail, and the console sketch lets you try the queue.

What it doesn’t claim: results, costs, hours, or a shorter statutory close. Where it reasons and where it has evidence, it 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.

Sources