How to automate month-end close
A general ledger I use for teaching runs 3,137 journal entry lines across 18 months. Debits total $62,940,314.17. Credits total $62,939,314.17.
It is out by exactly $1,000, and one entry causes all of it. A pop-up event at Smorgasburg, posted by hand on 21 June 2025, cash debited $8,200 against sales credited $7,200.
Finding that by hand means scanning three thousand rows. Finding it with a query takes about four seconds. That gap is the entire argument for automating a close, and it is worth being precise about what it does and does not claim: automation did not stop the entry being posted wrong, and it will not stop the next one either.
Sort the tasks before you Automate any of them
The close is thirty or forty small jobs wearing a trench coat, and they are not equally worth automating. Before touching a tool, list every task in your close with an owner and a dependency, then put each one in a bucket.
| Bucket | Looks like | What to do |
|---|---|---|
| High touch, low value | Matching bank lines, chasing schedules, rekeying an export | Automate first. Hours out, no judgment lost |
| High value, repeatable | Standard journal entries, consolidations, the reporting pack | Automate second, with a review step in front of it |
| High stakes, judgment heavy | Accrual estimates, adjustments, the variance explanation | Leave manual, and protect the time you just freed up for these |
Most closes I have looked at automate the second bucket first, because it is the one that feels important. It is also the one where a mistake compounds. Start in the first bucket, where an error is visible immediately and costs you nothing.
Name the bottleneck out loud
Two questions get you most of the way. Which tasks are always late, and which tasks do you redo? The first points at a dependency problem, usually somebody upstream who has not sent you something. The second points at a data problem.
For me it was always reconciliation. Missing transactions, typos, numbers that would not tie. Naming it as the bottleneck rather than treating it as the weather is what made it worth fixing.
How I got out of reconciliation
One month I got stuck reconciling bank accounts by hand. It should have taken a few hours. It took two days of cross-checking balances that would not balance and hunting tiny errors through a spreadsheet with thousands of rows.
That was when I found Power Query. I set it to pull both sides, clean them, merge on the key and flag what did not match. The afternoon job became a 15-minute one, and it stayed a 15-minute one every month after that, which is the part that matters more than the first run.
It is still the easiest starting point I know for finance automation. No new software to buy, no code, and the thing you build is a repeatable query rather than a one-off cleanup you will do again next month.
What the reconciliation should look for
Matching is the easy half. The useful half is what a query catches that a person scanning rows does not.
Six months of bank data on that same coffee chain runs 5,857 transactions across four account types. Eighteen of them are exceptions, and the pattern in them is worth knowing because it repeats everywhere:
- A rent payment of $24,800 paid twice, because a check cleared after the ACH had already gone out.
- A vendor payment of $4,153 paid twice against the same invoice, fourteen days apart.
- A bank fee of $35 charged twice on the same day.
- A payroll run of $62,000 disbursed twice.
None of those is exotic. All four are duplicates, and duplicates are the single highest-yield thing to automate a check for, because they are trivially detectable by machine and genuinely hard to spot by eye in a long statement.
The deeper walkthrough of matching, exceptions and who owns each step lives on the reconciliation page. This one stays on the close as a whole.
The close automation triage
The AI library for finance teams
The three-bucket sort above as a worksheet, the duplicate checks worth running first, and the three controls to build back in. Free, and it lands in your inbox in about a minute.
The tools, and what each one is for
| Layer | Examples | What it removes |
|---|---|---|
| Ledger and consolidation | NetSuite, SAP, Oracle, Sage Intacct | Rekeying between subledgers and the GL |
| Spreadsheet automation | Power Query, Office Scripts, VBA | The clean-and-match work, without a new license |
| Orchestration | Power Automate, Zapier, n8n | Waiting. Reminders, approvals, handoffs between systems |
| Close management | FloQast, BlackLine, Numeric | The tracker. Who is done, what is blocked, what is signed off |
| Reporting | Power BI, Tableau, a refreshable Excel pack | The last-day scramble to build the deck |
You do not need all five. Most finance teams under about fifty people get the whole benefit from the second and third rows, and buy the fourth only when the close involves enough people that the spreadsheet tracker starts lying.
Where AI fits into a close
Two places, and they are narrower than the marketing suggests.
The first is explaining an exception. Give a model the unmatched lines, the subledger detail and the account structure, and it is good at proposing what a break probably is. On the $1,000 entry above it would tell you immediately that a two-line entry with unequal sides is a posting error rather than a timing difference, which is the question you had.
The second is drafting the commentary from a variance table, which is real time back as long as you keep the cause out of its hands. Variance analysis covers why that boundary matters.
Where it does not belong is anywhere that posts. A model that suggests a journal entry is useful. A model with permission to post one has removed the only control that was catching the errors, which puts you further back than you were.
Rolling it out without a mutiny
Automate one task, in one close, and let the result speak. The pitch that works is never efficiency, because nobody in finance believes efficiency claims. It is showing somebody the two days they will not spend again.
- Pick one high-touch, low-value task from the first bucket.
- Build it and run it alongside the manual version for one close. Both, in parallel.
- Compare the outputs line by line and fix what differs before you retire the manual one.
- Write down how it works, somewhere the next person will find it.
- Then pick the next task.
Step two is the one people skip and the one that keeps this from going badly. An automated close that has never been run against a known-good manual close is a process nobody can defend when the auditor asks.
The controls that have to survive
A manual close catches errors as a side effect of somebody touching every number. Automate it and that stops happening, so the checks have to be built back in deliberately.
Three of them do most of the work. Prove the ledger balances before anything downstream runs, because that $1,000 would have failed a two-line test on the day it was posted rather than being found in a review 14 months later. Compare row counts against the prior period on every extract, since a silently truncated file is the most common way an automated close goes quietly wrong. And keep a human sign-off on anything in the judgment bucket, recorded with a name against it.
Worth noticing who posted the broken entry, by the way. Of those 3,137 lines, 1,896 came from the accountant, 985 from automated payroll and point-of-sale imports, and only 256 were manual posts from store managers. Two of those 256 were the pop-up entry. The automated imports have not produced a single break in 18 months.
That is the real case for automating a close, and it is a quieter one than the time saving. Machines are not smarter than your team. They are just far more boring, and boring is what a ledger wants.
