Why close is broken at most SMBs
A clean month-end close takes five business days when software does the mechanical work and humans do the judgment work; it takes eight to fourteen when people do both. That is the whole story of this checklist. The dirty secret of month-end close is that almost nobody actually closes in the timeframe their finance leader claims. We've talked to dozens of controllers running 25-200 person companies, and the median real close — from period end to a finalized P&L that leadership can rely on — is somewhere between 8 and 14 business days. The "we close in 5 days" answer you hear at conferences is usually measuring something else: the day journal entries stop hitting, or the day the P&L looks roughly right.
The reason it takes that long isn't that accounting is hard. It's that the close process at most SMBs is a sequence of manual reconciliations chained together by emails, with a spreadsheet of "close tasks" that nobody updates in real time and a chart of accounts that grew like a vegetable garden. A clean five-business-day close is achievable — we run one ourselves — but it requires that you separate the work that humans should be doing (judgment, review, sign-off) from the work that software should already be doing (categorization, reconciliation, accrual templating, chasing).
This checklist assumes a Day 1 of the new month is the first business day after period end. So if you're closing May, Day -3 is the last Wednesday of May, and Day 5 is the fifth business day of June. Adjust as needed.
One non-obvious rule: the close starts before the period ends, not after. The single highest-leverage thing you can do to shorten close is move pre-close work to Day -3 and Day -2. Most teams don't.
Day -3 to Day -1: Pre-close prep
The last three business days of the month are not "still in the period." They're the start of close. The goal here is to make sure the period ends with as little dangling work as possible — open POs cleared, vendor bills entered, time sheets submitted, expense reports in.
Who owns it
Controller drives. AP clerk, AR clerk, and ops leads contribute. Department heads are on the hook for getting their expense reports and time approvals in.
| Task | Owner | Should be automated? |
|---|---|---|
| Send Day-3 reminder to all expense submitters and approvers | Controller | Yes — auto-fired by expense system |
| Confirm all bank feeds connected; clear any auth failures | Staff accountant | Yes — feeds should self-monitor and alert proactively |
| Pull list of open POs; chase vendors for missing invoices | AP clerk | Partial — system should flag POs without invoices >30 days |
| Review unbilled time / WIP; push project leads to submit | AR clerk / Project mgr | Partial — system should surface unbilled hours by client |
| Approve / reject pending expense reports backlog | Dept heads | No — judgment, but should be one-click |
| Run prelim P&L snapshot; flag obviously-wrong accounts | Controller | Yes — anomaly detection should run nightly |
| Confirm payroll cutoff and projected accruals with HR | Controller / HR | Yes — payroll system should push accrual data |
What "automated" looks like in practice: on Day -3, every expense approver gets a Slack/email nudge with a one-click link to their pending queue. Every bank connection that's at risk of failing has already raised a flag. The system has already pre-categorized 90%+ of bank transactions with a confidence score, and the controller is reviewing the <90% cohort, not the whole feed. In VeloLedger, AI-drafted bills (extracted from an email inbox, deduped, matched to the vendor and PO) and AI-coded bank lines land in the same one review queue, each with its confidence score and source PDF — so pre-close review is one place to look, not five. The rule underneath is constant: agents draft, humans post.
Day 1: Close kick-off and revenue cutoff
The period is over. The clock starts. Day 1 is about establishing the perimeter: making sure all the in-period transactions are in, and that the things that should hit this period actually hit this period (and not the next one).
Who owns it
Controller drives. AR clerk owns revenue recognition. AP clerk owns vendor bills. CFO or controller does the cutoff judgment calls.
| Task | Owner | Should be automated? |
|---|---|---|
| Lock period for non-finance users (read-only) | Controller | Yes — one click |
| Verify all sales invoices for prior month are issued | AR clerk | Partial — system should flag fulfilled-but-uninvoiced orders |
| Apply revenue recognition schedules (deferred revenue release) | AR clerk / Controller | Yes — should run from contract data; review only |
| Receive final vendor bills (cutoff: end of Day 1) | AP clerk | No — depends on vendors; chase as needed |
| Post AR / AP cutoff entries for goods shipped / received in period | Controller | Partial — system should propose; controller reviews |
| Pull aged AR report; identify potential bad debt candidates | AR clerk | Yes — report auto-runs |
| Reconcile credit card processor (Stripe / Square / etc.) settlements | Staff accountant | Yes — auto-matched at the deposit level |
The big trap on Day 1 is the cutoff. If a vendor ships you something on the 30th and you don't get the invoice until the 5th of the following month, that expense still belongs to the prior period. The same applies to revenue: if you fulfilled an order on the 31st, the revenue is yours even if the invoice goes out on the 2nd. Most SMBs get this wrong because nobody is watching for it. A good system should propose the cutoff entries automatically from your shipping or fulfillment data.
Day 2: AP, AR, and bank reconciliations
This is the heaviest day in the close, and it's where most teams lose two or three days they don't need to lose. Reconciliations are not creative work — they are matching games — and modern accounting platforms should be drafting most of the matching for your review before a human ever looks at it.
Who owns it
AP clerk, AR clerk, and staff accountant divide and conquer. Controller reviews exceptions only.
| Task | Owner | Should be automated? |
|---|---|---|
| Reconcile every bank account to the bank statement | Staff accountant | Yes — most matches drafted for review; humans focus on exceptions |
| Reconcile every credit card account | Staff accountant | Yes — same as bank |
| Confirm AP subledger ties to GL AP control account | AP clerk | Yes — auto-tied; flag if variance > $1 |
| Confirm AR subledger ties to GL AR control account | AR clerk | Yes — same as AP |
| Match payment processor deposits to bank deposits | Staff accountant | Yes — auto, with fee allocation |
| Reconcile intercompany balances (if multi-entity) | Controller | Yes — net-out should auto-propose |
| Investigate any unmatched bank items > threshold (e.g. $250) | Controller | No — investigation requires judgment |
| Document any reconciling items for audit trail | Staff accountant | Partial — system captures, human writes the note |
The right benchmark: if your bank reconciliation takes more than 30 minutes per account, your system is failing you. The matching algorithm should be doing the work. Humans should only see the exceptions queue — typically 1-3% of transactions — and resolve those. In VeloLedger this is one-click book-and-reconcile: the AI proposes the match, you approve, and the entry posts to a double-entry ledger where every line is balanced by construction and written to an immutable, hash-chained audit log.
Day 3: Accruals, prepaids, and other adjusting entries
This is the "thinking" day. The mechanical reconciliations are done; now it's about making sure the books reflect what actually happened economically in the period, not just what happened in cash.
Who owns it
Controller drives. Staff accountant executes recurring entries. Department heads provide inputs for accruals where needed (e.g. estimated commissions, bonus pool true-up).
| Task | Owner | Should be automated? |
|---|---|---|
| Post payroll accrual (for pay period spanning month-end) | Controller | Yes — drafted from HRIS data; review only |
| Post payroll-related accruals (PTO liability, employer taxes) | Controller | Yes — drafted from HRIS data |
| Run prepaid amortization (insurance, software, rent prepayments) | Staff accountant | Yes — auto-runs on schedule |
| Post fixed asset depreciation entries | Staff accountant | Yes — auto from asset register |
| Accrue expenses for goods/services received but not yet invoiced | Controller | Partial — system flags candidates from PO data |
| Calculate and accrue commission liabilities | Controller / Sales ops | Yes if commission rules are in the system |
| Estimate and accrue bonus pool changes | Controller / CFO | No — judgment call |
| Update bad debt reserve / allowance for doubtful accounts | Controller | Partial — system proposes from aging; controller adjusts |
| Sales tax accrual / liability calculation (US states, GST/HST/QST) | Controller | Yes — auto from transaction-level tax codes |
| Post lease amortization; check no lease periods are unposted (IFRS 16 / ASC 842) | Controller | Yes — engine posts ROU amortization and interest; close-readiness check flags any lease period still to post |
| Foreign exchange revaluation on foreign-currency balances | Staff accountant | Yes — auto at month-end rate |
If you're running on QuickBooks or a similar tool without proper schedule-based amortization, Day 3 can easily become Day 3, 4, and half of 5. The fix isn't to work harder — it's to set up the schedules once, in a system that respects them. Every recurring entry (depreciation, prepaid amortization, deferred revenue, lease accounting under ASC 842 / IFRS 16) should be on a schedule that the system runs automatically and that the controller reviews, not constructs.
Leases are the step most SMB tools ignore entirely — QuickBooks and Xero have no native lease sub-ledger, so IFRS 16 / ASC 842 amortization gets tracked in a side spreadsheet that nobody trusts. VeloLedger runs a native lease sub-ledger with an engine-posted ROU asset and lease liability (split current vs. non-current), and its month-end "lease periods to post" check surfaces any lease whose period hasn't been posted yet — so a forgotten lease can't silently understate your liabilities on the way into close.
Day 4: Review, variance analysis, and flux
The books are mechanically right. Now the question is: are they actually right? Day 4 is when the controller and CFO sit down with the preliminary P&L and balance sheet and ask "does this story make sense?"
Who owns it
Controller and CFO drive. Department heads asked to explain material variances in their area.
| Task | Owner | Should be automated? |
|---|---|---|
| Run preliminary P&L; compare actuals to budget and prior period | Controller | Yes — report auto-runs |
| Identify and explain all variances over threshold (e.g. >$5K or >10%) | Controller + dept heads | Partial — AI can draft commentary; humans validate |
| Balance sheet flux: identify any account with unusual movement | Controller | Yes — anomaly detection flags candidates |
| Confirm cash position ties to bank statements (proof of cash) | Staff accountant | Yes — auto |
| Review unusual journal entries posted during the period | Controller | Yes — system surfaces JEs above threshold or by unusual users |
| Re-run trial balance; confirm zero out-of-balance entries | Controller | Yes — auto and continuous |
| Confirm intercompany eliminations net to zero | Controller | Yes — auto in multi-entity |
| Draft preliminary close memo (narrative on the month) | Controller / CFO | Partial — AI can draft from variances; humans finalize |
The variance commentary is the single most automatable part of close that almost no team automates. "Marketing expense up $14K vs. last month, driven primarily by a $12K trade show invoice posted on the 18th" is a sentence that requires a human to write at most teams. It shouldn't. The system already knows the largest contributing journal entries to any variance and can draft the commentary in plain English. The controller's job is to validate it, not write it.
This is exactly where VeloLedger's review tooling earns its keep. An always-on anomaly scan runs before you sit down for Day 4: a deterministic engine finds the outliers (a balance-sheet account that moved unusually, a duplicate-looking bill, a margin that shifted), and the AI only ranks and explains what the engine already flagged — so the flag is auditable, not a black box. Inline analytical review puts actual-vs-budget and actual-vs-prior-period side by side with AI-drafted commentary you can accept or rewrite. And because VeloLedger is a draft→approve→post ledger, every entry the AI proposed during the month is a draft until a human approved it — the review seat is built into the architecture, not a policy you have to remember to enforce.
Day 5: Sign-off, close, and reporting
Final review, lock the period, distribute. If Days 1-4 went well, Day 5 is short.
Who owns it
CFO signs off. Controller executes the lock and distributes.
| Task | Owner | Should be automated? |
|---|---|---|
| CFO reviews final P&L, balance sheet, cash flow; approves close | CFO | No — sign-off is a human act |
| Hard-lock the period (no further postings — by human or agent — without explicit unlock) | Controller | Yes — one click; the lock is enforced server-side against every actor |
| Generate and distribute monthly reporting package to leadership | Controller | Yes — auto-distributed on schedule |
| Generate department / cost-center P&Ls for managers | Controller | Yes — auto-distributed |
| Generate KPI / metrics deck (revenue growth, gross margin, etc.) | Controller / FP&A | Yes — auto from GL data |
| Archive close binder (workpapers, reconciliations, JEs, memo) | Controller | Yes — auto-archived with audit trail |
| Schedule post-close retro (what slowed us down this month?) | Controller | No — but should be a habit |
The retro is the most underrated step. Most teams close, sigh in relief, and then encounter the same five problems next month. A 20-minute retro that captures "the Stripe reconciliation broke because they changed their export format" turns one bad month into one bad month, rather than a recurring drag for the next year.
What a modern close should feel like
If you're doing all of this in 5 business days, you're already ahead of most SMBs. If you're doing it in 8-10, the question worth asking isn't "how do my people work harder?" It's "what work is my software making my people do that it shouldn't?"
Run through the "Should be automated?" column above and count the rows where the answer is "Yes" but in your current setup the answer is "No, my team does it manually." Each of those is either a configuration gap (in a tool that could do it, but isn't), or a tooling gap (in a tool that simply can't).
The configuration gaps are usually solvable in an afternoon. The tooling gaps are why people switch ledgers.
One more thing on AI in close: a lot of vendors are now pitching "AI closing your books." Be skeptical. AI is good at drafting variance commentary, proposing journal entries, surfacing anomalies, and writing close memos. AI is not good — and should not be — at unilaterally posting entries, signing off the close, or making accrual judgments. The right model is AI as a fast junior, with a human controller in the review seat. In 2026 every competitor ships close-time AI agents; what none of them guarantee is that the agent can't write to the ledger. In VeloLedger that guarantee is architectural — the AI's tool surface simply has no post action, so "agents draft, humans post" is a property of the system, not a setting you can toggle off. We've written more on why the math itself is what makes this work.
Cut your close from 10 days to 5
VeloLedger automates the reconciliation, accruals, and variance commentary in this checklist. We'll show you exactly which steps disappear in a 15-minute demo.
Book a demoMonth-end close: frequently asked questions
How many days should a month-end close take?
A clean month-end close for a 25-200 person SMB should take about five business days: reconciliations on Days 1-2, accruals and adjusting entries on Day 3, review and variance analysis on Day 4, and sign-off plus reporting on Day 5. The median real-world close runs longer (roughly 8-14 business days) mainly because teams do manual reconciliation and categorization that modern software should already be drafting.
What is the difference between a soft close and a hard lock?
A soft close makes a period read-only for most users while finance finishes adjusting entries; a hard lock permanently prevents any further postings to the period without an explicit, logged unlock. In VeloLedger the hard lock is enforced server-side against every actor, including AI agents, so once a period is locked nothing — human or agent — can post into it by mistake.
Can AI close the books automatically?
AI can draft most of the close but should not finalize it. AI is well suited to categorizing bank lines, extracting bills, proposing journal entries, surfacing anomalies, and drafting variance commentary; sign-off, accrual estimates, and reserve judgments stay with a human controller. VeloLedger enforces this by construction — its AI agents can draft entries into a review queue but have no ability to post, so a person always approves before anything hits the ledger.
How does VeloLedger help with the IFRS 16 / ASC 842 lease step at close?
VeloLedger runs a native lease sub-ledger that engine-posts ROU asset amortization and lease-liability interest, split into current and non-current portions. Its month-end "lease periods to post" check flags any lease whose period has not yet been posted, so a forgotten lease can't quietly understate your liabilities before you sign off.
Which close tasks should be automated versus done by a human?
Automate the mechanical, rules-based work: bank and credit-card reconciliation, subledger-to-GL ties, depreciation and prepaid amortization, deferred revenue, lease amortization, FX revaluation, and anomaly detection. Keep the judgment work human: cutoff calls, reserve and bad-debt estimates, bonus accruals, the close memo, and final CFO sign-off. VeloLedger's "agents draft, humans post" model is designed around exactly this split.