The Close Doesn't Have to Take Ten Days

It's day seven of close. The trial balance is close enough to final that finance leadership is starting to ask for numbers, but not close enough that anyone will commit to them in writing. Three reconciling items on the same bank account have been open since day two, because they depend on a vendor replying to an email that was sent, then sent again, then sent a third time with a slightly more urgent subject line. Two accruals need updating because the contracts behind them changed mid-quarter, and the person who'd know that is on the FP&A side, not accounting, so nobody flagged it. The controller has opened the same spreadsheet four times today, not because the math is hard, but because the answer depends on information that lives in someone else's inbox.

None of this is a crisis. It's just Tuesday. Every finance team we've sat with, from a single-entity SaaS company to a private-equity-backed rollup running three ERPs after two acquisitions, has some version of this week built permanently into its calendar. The specific accounts change. The pattern doesn't.

We're not in the business of replacing NetSuite, or Oracle, or BlackLine, or whatever close platform your team has already paid for, trained on, and built process around. Those systems are fine. They do what they were built to do: hold the ledger, run the checklist, store the workpapers.

What's missing isn't a system. It's the connective tissue between the systems your team already runs, the bank feed, the subledger, the vendor's inbox, the contract that changed, the prior-period comparison nobody has time to build fresh every month. That connective tissue is currently made of people: a senior accountant pulling a CSV from one portal and pasting it into another, a staff accountant rebuilding an accrual from a formula that lives only in their head, an AP lead typing the same follow-up email for the fortieth time this quarter. It is real, necessary, and almost entirely repetitive work, and it is exactly the kind of work a language model that can read your GL, reason about a variance, and write back into your ERP is good at.

That's the distinction that matters here, and it's worth being blunt about it: we don't build dashboards. A dashboard that tells you forty reconciling items are open is not meaningfully different from the spreadsheet you already have open. An agent that resolves thirty of those forty on its own, writes the clearing entries back to the ledger, and hands your team the ten that actually need a judgment call, that's a different category of tool entirely. Most of what's been sold to finance teams as "AI" in the last two years is the first thing wearing the marketing of the second.

Start with the close itself. It's been true for years, and remains true today, that most mid-market companies take somewhere north of a week to close their books, and multi-entity or PE-backed companies routinely run longer, especially in the months right after an acquisition closes and two charts of accounts have to start behaving like one. That number hasn't moved much industry-wide despite a decade of close-management software, because close software manages a checklist. It doesn't resolve the exceptions sitting on that checklist.

Layer onto that the accounting talent pipeline, which has been shrinking for the better part of a decade. Fewer students are entering accounting programs, fewer are sitting for the CPA exam, and the result isn't abstract, it's a controller who posts a req for a senior accountant or reconciliation analyst and watches it sit open for months, then finally fills it with someone who needs a full quarter just to learn the chart of accounts and the vendor quirks well enough to work independently. Every finance leader we talk to has a version of this story, and almost none of them think it's getting easier next year.

At the same time, the job itself has been redefined out from under the people doing it. Finance is being asked, correctly, to spend more time on forecasting, scenario planning, and being an actual partner to the business, not less. Nobody has removed the transactional volume to make room for that. The reconciliations, the recurring journal entries, the vendor chasing, all of it still has to happen every single month, and it still mostly happens by hand, which means the strategic work gets squeezed into whatever time is left after close, which in a bad month is not much time at all.

The tools finance teams have reached for to fix this have real, well-understood limits. Traditional RPA scripts a fixed sequence of clicks against a specific screen and breaks the moment a vendor portal changes its layout or a transaction doesn't match the exact pattern it was built for, which in finance is often. And a genuine share of mid-market and PE-backed companies are running two ERPs at once mid-migration, or reconciling entities that were never meant to talk to each other automatically, which turns every one of these problems from an occasional annoyance into a recurring monthly tax on the close.

What happens today: someone on the team pulls a bank statement, pulls the general ledger for the same period, and starts matching line by line. Most of it is genuinely mechanical, a deposit matches a receivable, a wire matches an invoice, done. But a meaningful chunk of every statement doesn't match cleanly on the first pass. A batched deposit represents four customer payments instead of one. A wire arrived two days before the invoice that explains it was even entered. A recurring vendor charge shows up under a slightly different description than last month. Each of these takes real time to run down, and the person running them down is usually your most experienced accountant, because junior staff don't yet have the pattern recognition to tell a timing difference from an actual discrepancy without asking someone.

What it looks like with an agent: the agent pulls the bank feed and the GL itself, on the same schedule your team already reconciles on, and runs the matching. Exact matches clear automatically and get written back to the ledger with no one touching them. Everything else, the batched deposit, the early wire, the renamed recurring charge, gets flagged with a proposed match and the reasoning behind it: which transactions it considered, why it thinks they tie together, and what confidence it has in that match. Your team reviews a short list of genuine judgment calls instead of the entire statement, and every item on that list already comes with the investigative legwork done.

What happens today: recurring accruals get rebuilt from scratch every period, even though the underlying logic rarely changes, because nobody has gotten around to templating them and the person who could just does the math again. Flux commentary, the explanation of why an account moved the way it did versus last period or budget, usually gets written last, under time pressure, often as a one-line placeholder that says "timing" because there's no time left in the day to actually investigate the movement. The close checklist itself lives in a close platform, but the checklist only tells you what's not done. It doesn't do any of the not-done work for you.

What it looks like with an agent: the agent pre-drafts recurring journal entries against the pattern from prior periods, flags anything that deviates meaningfully so a real change, a new contract, a rate change, a one-time item, gets caught rather than silently rolled forward. For flux, it pulls the current period against prior period and budget, drafts a first pass of the commentary explaining the movement in plain language, and routes it into the controller's review queue instead of leaving a blank template. The controller's job shifts from writing the first draft under a deadline to checking a draft that's already mostly right. The agent tracks all of this against your existing close checklist in whatever platform you already run, BlackLine, FloQast, or a spreadsheet, so nobody is maintaining a second system in parallel just to track the first one.

What happens today: someone requests a W-9 before year-end, follows up on an invoice that's missing a PO reference, and answers "when are we getting paid" for the fifth time this month, and almost none of it is templated because the ERP doesn't have a built-in workflow for chasing a vendor. It's necessary work, it's time-sensitive, especially around year-end documentation and audit season, and it falls to whoever on the team has the most patience for repetitive email, which in a lot of AP departments is effectively a full-time job by itself.

What it looks like with an agent: the agent monitors the vendor master for gaps, a missing W-9, missing remittance details, incomplete documentation, and sends the request itself, following up on an escalating schedule if nothing comes back. Payment status questions get answered by pulling the real status, amount, date, method, from the ERP and generating a specific reply instead of a form response. Collections follow a defined escalation path and only pull in a person when an account crosses a real threshold or a vendor disputes a balance, at which point the agent hands over the full history so the human isn't starting the investigation cold. Every message sent and every reply received gets logged back to the vendor record, so nothing gets double-sent, nothing gets dropped, and your team has a complete record without anyone having maintained it by hand.

The single most important decision in a project like this is where it lives. An agent that requires your team to log into a new tool to see what happened is a new tool your team has to check, which is one more screen, not one fewer. We build the workflow to read and write directly against the ERP and close platform you already run and to leave its work exactly where your team already looks for it, in the reconciliation, in the checklist, in the vendor record. If your team can't tell, from inside NetSuite or BlackLine, that an agent touched a given line, we haven't done the integration correctly.

Every workflow runs on a confidence threshold, and below that threshold it stops and asks instead of guessing. That's not a hedge, it's the actual point. Finance work has a real judgment layer, an unusual vendor relationship, an amount that's outside pattern for a defensible reason, a discrepancy that needs someone who knows the history of the account. The goal was never to remove that layer. It's to make sure the only things reaching a person are the things that actually need a person, with the matching candidates, the reasoning, and what's already been checked attached, so the decision takes thirty seconds instead of a half-hour investigation from zero.

Every finance team we've worked with assumed they knew where their time was going before we mapped it, and in most cases the actual biggest leak wasn't the one they complained about loudest. A team fixated on close-week chaos sometimes finds their real cost center is intercompany elimination eating three days a quarter. A team convinced their reconciliation process was the problem sometimes finds vendor follow-up is quietly consuming a full headcount. We build the highest-ROI workflow first, prove it against real numbers, and let that result earn the next one, rather than proposing a five-workflow roadmap before anyone has seen the first one work.

The most common failure mode isn't a technical one, it's scope creep dressed up as ambition: a team tries to automate the entire close on day one instead of the one workflow that's actually costing the most, and six months later nothing is fully live because everything is half-built. The second most common failure is the mirror image of the first, an off-the-shelf tool gets configured with generic matching rules that don't reflect the team's actual tolerance policy, so it either clears things it shouldn't or escalates so much that it becomes noise, and within a quarter nobody trusts its output enough to act on it without re-checking everything anyway.

The third, and the one that's easiest to miss until it's already happened, is building the workflow around this month's process instead of the tribal knowledge that actually governs it. Every finance team has exceptions that live only in a senior person's head, the customer who always pays two days late for a reason everyone's stopped questioning, the vendor whose invoices never match their PO for a benign, well-understood reason. An agent that doesn't know about those exceptions doesn't fail loudly, it just quietly generates a stream of false escalations that erode confidence in the whole system, right up until someone finally documents the exception it was missing.

You don't need to know which workflow to build first before you talk to us, that's what the audit is for. We sit down with whoever owns the close day to day, usually the controller, walk through the actual exception logs, the real close timeline, and the reconciliation process across whatever systems you run today, and come back with a specific, numbers-based view of where the time is actually going and what fixing it is worth on your books, not against an industry average.

Most teams are live with their first workflow within a few weeks of that conversation. There's no obligation attached to the audit itself, some teams take the findings and fix things internally. Most decide the math is worth automating once they see a real number attached to work they'd stopped noticing was expensive.