The statements went out. Two days later the client writes back with one question about one number, and it's a fair question.
So you open the file. Then the bank statement. Then a vendor bill from the middle of the month, because something about it was odd.
Forty minutes later you've got the answer. Nothing was wrong. The entries were right and the month tied. What was missing is the part that lets somebody else check the work, and that's where AI-assisted bookkeeping earns its keep.
The job isn't making the books right. It's making them checkable.
A model reads the month's exports and hands back a list of what to look at. Amount, account, and where the number came from, on every line. A person decides every one of them and posts every one of them. That list, graded against a standard you wrote before the run, is what turns a finished close into a reviewable one.
Nothing in this article comes from a client file. I can't show you a page of our work, and I'm not the CPA at the firm where I'm a partner. Everything below runs on a set of books I made up, and I'll say so every time a number shows up.
What is AI-assisted bookkeeping in a monthly close?
It means a model reads the month's exports and returns a list of exceptions. Four files go in: the bank statement CSV, the credit card statement CSV, the trial balance export, and the prior month's closed balance sheet, and a fifth you pull only when a balance makes you look: the transaction detail behind any account you end up opening, pulled the same day as the trial balance. One list comes out, with an amount, an account and a source on each line, graded against a review standard you wrote first. On the made-up practice books used here, an invented landscaping company with 18 accounts, that list surfaces three planted problems: $1,284.50 in Uncategorized Expense across four transactions, a $312.00 bank reconciliation difference, and a $950.00 owner draw coded to Repairs & Maintenance. Every one of those numbers is invented. The model proposes. It never decides and never posts.
Key Takeaways
Reviewable means somebody else can check it without redoing it - a written standard, an exception list, and a source on every line, sitting there before anyone asks.
The model's job is the list, never the ledger - it reads exports and proposes what to look at, and a person posts every entry and owns every call.
Four files in, one list out - bank CSV, card CSV, trial balance export, last month's closed balance sheet, and a fifth you pull only when a balance makes you look, the transaction detail behind any account you end up opening, pulled the same day as the trial balance. A missing one gets named in writing before anything runs.
Write the standard before the run - graded afterwards, a standard is just a description of whatever the model happened to say.
Plant the answers in your practice month - the made-up books in this article hide $1,284.50, $312.00 and $950.00 on purpose, all three invented, so you can measure what a run missed instead of admiring what it found.
Practice on made-up books, not a client's - this is firm-operations material and not accounting, tax or legal advice, and a review packet isn't an audit.
What AI-assisted bookkeeping actually does at month end
Start with what a model does well on this kind of work. It sorts routine transactions. It drafts words somebody was going to write anyway. It reads a pile of something and tells you what's in it. That list, and the four questions worth asking about any of it, came out of the AI issue and none of it has changed. One ability gets added here, because the review layer runs on it: a model will compare two documents and report where they disagree.
Almost everything sold into this profession points those abilities at the ledger. Categorize, match, post. That half you can buy from somebody.
The job that runs on the same abilities and rarely gets packaged is the other one. Read four exports, compare them against a written standard, and draft the list of what doesn't match. Every other kind of professional work has a name for that output. It's a review packet, and bookkeeping is one of the few places it gets rebuilt from memory every month instead of produced.
Now the other side of that boundary, and none of it is a close call.
It doesn't post. Nothing it produces reaches a ledger without a person typing it in, and a workflow that closes that gap is a different workflow than this one.
It doesn't reconcile. It can tell you two numbers differ by $312.00 on the made-up books below and it can guess why. Whether that guess is right is a question about one specific duplicated bill, and the bill is the evidence. Ask what document proves the explanation. If the answer is the model's own sentence, you're holding a hypothesis.
It doesn't decide. Owner draw or repair is a call, and calls belong to the person whose name is on the work. Anywhere an account changes without a person choosing, something decided.
It doesn't promise. There's no accuracy number in this article, because a run that returns three of three planted problems on invented books has told you about those books and nothing about yours. Any figure that doesn't name what it was measured on is that same run wearing a percentage.
Reviewable means a second person can check it
A done list somebody else can tick proves the steps happened. Checking the numbers behind those ticks is a separate job, and today it means opening the file again. That second gap is the one this closes.
Closing it takes three artifacts, and most firms already have the first.
A written standard. The conditions the month has to meet, in words somebody can tick. "Reconciled" fails that test, because everyone agrees with it and nobody can check it. A usable version reads: every bank and card account reconciles to a statement, and any difference is zero or explained in one sentence.
The close checklist from the workflow issue is where this starts, and it sits one layer below. That checklist says the close is done. The standard says what somebody reviewing the close is entitled to see.
An exception list with a source on every line. Everything that failed a condition, with the amount, the account name as it actually appears in the trial balance, and the file and row where the number lives. A reviewer who has to go find the number is doing the close again, which is how review turns into a thing that gets skipped in March.
A signature and a date. Initials against the standard and the day it was worked. A review nobody signed is a review nobody can prove happened, including to yourself in eight months when it matters.
A review packet is an internal work product, and its whole purpose is making a second pair of eyes cheap enough to use every month. What you're allowed to put into any tool alongside real client records is a separate question with real rules behind it, and that one goes to your own counsel rather than to an article.
The files a review runs on, and the check that runs before anything else
A review can only see what you hand it. Four files, and a fifth you pull only when a balance makes you look.
The bank statement CSV for the month. The credit card statement CSV for the same month. The trial balance export as of the last day of that month. And the prior month's closed balance sheet, which is the one that gets left out. The fifth is the transaction detail behind any account you end up opening, pulled the same day as the trial balance, and it arrives during the review rather than before it.
That fourth file earns its place because it's the only one that says where the month started. Without it a run can tell you the numbers are internally consistent and still miss that the opening cash never matched what you closed with last time.
Then a check that takes twenty seconds and saves you a whole review of the wrong month. Are all four here, do all four cover the same period, and does the trial balance date match the last day of the statements. A model will review a bad stack without complaint, and which way a packet fails is the subject of a separate piece, Catch missing inputs before review: prepare one traceable work packet.
Say what's missing in writing, before the review runs, not in a comment afterwards. The packet check in the setup pack below is that sentence, pre-written. Where those four files come from, what each one has to agree with, and what to do when a client can't produce one at all, all belong to that piece.
Write the review standard before the model sees anything
The order matters more than the wording.
Written first, a standard is a test. Written afterwards it becomes a description of whatever came back, and the condition you forgot will never announce itself, because nothing failed it. You'll read a clean list and feel good about a month that was never checked against the thing you didn't think of.
A condition is written well when somebody who wasn't in the file can tick it or fail it without asking you a question. Put each one through three tests. It names an account or a number. It has exactly one outcome. And somebody who has never seen this client can fail it with only the exports in front of them.
A small firm's close needs about ten firm-level conditions, and then each client gets a short block of its own: the account they always get wrong, the thing you've already fixed twice. Start with six and let the next two months tell you the rest.
There's a practical reason this has to be an artifact instead of a habit. We ask for everything on the 5th and we aim to have every client closed by the 20th. That window is where a review layer either fits or it doesn't. A review that depends on somebody being fresh stops happening late in the window. A list somebody ticks survives a tired afternoon, which is the entire argument for writing it down.
A worked example on a made-up set of books
Cedar Hollow Landscaping LLC doesn't exist. I invented it for this article, and everything below about it is invented too.
The made-up company is a single-member LLC on the cash basis with one checking account, one credit card, and about 40 transactions a month. The invented period under review is June. Its invented trial balance has 18 accounts.
Problems are planted in those made-up books on purpose, which means the answers exist before any run does. All three amounts are invented: $1,284.50 sitting in Uncategorized Expense and made of four transactions, a bank reconciliation difference of $312.00 caused by a vendor payment recorded twice, and a $950.00 owner draw coded to Repairs & Maintenance.
A run over those made-up files returns something shaped like the list below, formatted the way the standard asks for it. Every figure in it is invented along with the company.
EXCEPTIONS - Cedar Hollow Landscaping LLC (made-up practice books) - June
1 Uncategorized Expense 1,284.50 TB row 14
4 transactions, largest 612.00 on the 14th
Condition failed: "The uncategorized account balance is zero at period end."
2 Bank reconciliation 312.00 Bank CSV vs TB row 3
Cleared 18,442.19, book 18,754.19
Condition failed: "Every bank and card account reconciles to a statement."
3 Repairs & Maintenance 950.00 TB row 11, Bank CSV row 22
Single payment, description "TRANSFER TO OWNER"
Condition failed: "Owner activity posts to owner accounts only."
4 Advertising 1,100.00 TB row 7
Up against the prior month's closed balance sheet, under threshold
Condition failed: none. Flagged as a variance for the preparer.The first three lines are the planted problems. That's what a working run looks like on those made-up books, and it isn't an accuracy claim, because the books were built to contain exactly those three things.
Now take condition 2 out of the standard. Line 1 never appears. The $1,284.50 stays where it is on the made-up books, nobody gets told about it, and what's left reads exactly as tidy and exactly as confident as the list above. That's silent omission, and there is nothing on the page to see it with. The only reason it's visible here is that the answers were planted before the standard was written.
Line 4 is the more interesting one. Nothing failed. Advertising just moved, and on an invented landscaping company in June, moving is what advertising does. The list flags it anyway, because a variance against the prior month's closed balance sheet costs almost nothing to compute and it's sometimes the only warning you get before a real problem. A reviewer reads line 4, thinks "summer," and moves on in about eight seconds. That's the correct price for that line.
Line 3 is where a run goes half wrong, and the way it goes wrong is the thing to watch for. A likely proposed fix on those made-up books is to recode the $950.00 to Owner's Equity. That's the wrong account for a draw in this invented chart, which has a Draws account sitting two rows away. The exception is real and useful, and the remedy attached to it is confident and wrong in exactly the same voice as the three lines above it.
Building the full packet, including the answer key that says what a good run should have caught, is its own job, covered in Produce a month-end review packet from your trial balance, with AI assistance.
Where it gets things wrong
A run fails in ways that mostly don't announce themselves. Only the first of these is loud.
The confident wrong remedy. Line 3 above. A correct finding arrives carrying an incorrect fix, and both come with the same certainty. This is what costs you when somebody works the list straight down without opening the chart of accounts.
Silent omission. The exception it never mentioned. Nothing on the page tells you something is missing, which is why the practice month has planted answers in it. A run that hands back two of the three problems you planted has told you something the page itself never would have.
Arithmetic that reads right. Totals that look plausible and don't add. Check the ones a conclusion depends on. If a difference of $312.00 on those made-up books is the entire finding, subtract the two balances yourself. It takes four seconds and it occasionally saves a very embarrassing email.
Invented account names. A model that can't find the right account will sometimes name one that sounds like it belongs in your chart. Any account cited on an exception line has to exist in the trial balance you handed over. That's a search anybody at the firm can run, and it can be somebody else's job.
The plausible reconciliation. The expensive one. A walk from one number to another with reasonable steps, where a single step is made up, reading exactly like a correct walk. The defense is structural: every step names a file and a row, or the step doesn't count. A step with no address is a sentence somebody wrote.
A run is still worth having with all five of those in it. What you're handed is a starting list where every line carries its own address, and that's a good thing to open on a morning late in the close.
Where this runs
You can do all of this by pasting into a chat window, and for one client that's fine. It stops being fine somewhere around the fourth, because you'll type a slightly different instruction every time and the months stop being comparable to each other.
The fix is to put the instruction in a file the tool reads on its own, so the same standard runs the same way without anybody retyping it.
Two products document a way to do that. Claude Code reads its instructions from a skill file kept in a folder of its own. That file is called SKILL.md: a short header carries a description (and usually a name), and the rest is plain instructions.
Codex reads a standing-instruction file named AGENTS.md that sits alongside the work.
That's documented host support, and it's the whole reason those two get named here. Nothing of mine has been tested on your machine, your plan or your operating system, and I'd rather say so than imply otherwise. Other hosts exist, none of them are tested here, and I won't list them as though they were.
Turning your review standard into one of those files raises two questions worth their own article: how you know the file is actually being read on a given run, and what happens to the months you already closed when the standard changes. That article is Repeat a monthly-review step reliably: build one small firm skill.
Whether any of it is worth building is the capacity question, and it answers itself: a close only you can check is a job that never leaves your desk.
Do this week
Block half an hour. Most of it is typing.
Open a blank file and write six conditions your close has to meet. Six, not ten, because you'll write the other four next month once you know which ones you missed. Then invent a client. Any name, any month, and put two problems in the books on purpose so you know what's in there. Run your six conditions over it and see whether both come back.
If you've only got ten minutes, write the six conditions and stop. The standard is the part that keeps working, and it works whether or not a model ever reads it.
One question
Write your six conditions first, because this only makes sense once they exist.
Then keep going past six and stop at the first condition you can't finish writing. Which one is it, and what makes it unfinishable?
The setup pack
The bracketed parts are the only decisions left in what follows.
The packet check
This runs before anything else touches the files. The line that gets skipped is the fourth.
[ ] Bank statement CSV present, period end matches the month I'm reviewing
[ ] Credit card statement CSV present, same period
[ ] Trial balance export present, dated the last day of that same period
[ ] Prior month's CLOSED balance sheet present. Closed, not current.
[ ] All four cover the same month. If one doesn't, stop and name which one.
[ ] Anything missing is written down before the review starts, not afterThe review standard
One file for the firm, not one per client. Client-specific conditions go at the bottom under the client's name. Plain words, because the person ticking them is not always going to be you.
REVIEW STANDARD - monthly close
Last updated: [date]
A month is reviewable when all of these are true and each one has a name
and a date beside it.
Conditions 1, 2, 3, 5, 6 and 10 restate what a close checklist already
covers. They are repeated here so a reviewer never has to open a second
document. Conditions 4, 7, 8 and 9 exist only because somebody other
than the preparer has to be able to check this.
1. Every bank and card account reconciles to a statement, and any
difference is zero or explained in one sentence.
2. The uncategorized account balance is zero at period end.
3. No holding, suspense or clearing account carries a balance without a
written explanation.
4. Owner activity posts to owner accounts only. No owner item sits in an
expense account.
5. AR and AP agings tie to the balance sheet.
6. Payroll clears to the payroll report and posts to the period it
belongs to.
7. Opening balances match the prior month's closed balance sheet, line
for line.
8. Every account that moved more than [your threshold] against the prior
month has a one-line reason.
9. Every exception raised this month is cleared, or carried forward with
a named owner and a date.
10. The prior period is locked.
Client-specific, [client name]:
- [condition]
- [condition]
Reviewed by: ______________ Date: __________The exception log
One row per exception, kept in the same folder as the month's packet. Six columns, in this order: Exception, Amount, Where it shows, Traces to, Proposed, Posted. The Exception cell is where the condition that failed gets written out in a sentence, which is what ties the log back to the standard above. The skeleton lives in "Produce a month-end review packet from your trial balance, with AI assistance," and it is the same six columns everywhere.
Keep the logs where you can read a few months side by side. A line you write three months running has stopped being an exception and become a condition you haven't added to the standard yet.
The prompt
This one is useless until the standard exists. Without it there's nothing to grade anything against, and you get back a summary of a month you already had.
You already know what's in your practice month, because you put it there. The line worth staring at is the one you didn't plant. Nothing on that list is true because it's on the list, and the three you planted are the only reason you can tell the difference.
I'm reviewing a month of bookkeeping for a small company. I'm going to
give you the month's files and a written standard. I want a list of
exceptions, not a finished close.
Files:
1. Bank statement CSV for the month
2. Credit card statement CSV for the same month
3. Trial balance export as of the last day of that month
4. The prior month's closed balance sheet
5. The transaction detail behind any account you end up opening, pulled
the same day as the trial balance. Ask for it if you need it; it is
not in the first four.
[paste or attach the files]
Standard:
[paste your review standard here]
For every condition in the standard that this month fails, give me one
numbered line with:
- the condition it failed, quoted from the standard
- the account name exactly as it appears in the trial balance
- the amount
- the file and the row where I can see the number myself
- a proposed fix, and how confident you are in it, said plainly
Then a second short list: anything that did not fail a condition but moved
enough against the prior month that a person should look at it, and why.
Rules for you:
- Don't infer anything about this company from its name or its industry.
The files and the standard are the only facts in play. Where a
figure is absent, write "not in the files" and carry on.
- Never name an account that doesn't appear in the trial balance.
- Show the arithmetic for any difference you report. Both numbers and the
subtraction.
- Don't connect to anything, don't open anything, and don't write journal
entries. I post my own entries.
- If a condition can't be tested from these files, put it under "couldn't
test" and say which file would let you test it.The reviewer checklist
The person ticking this should not be the person who did the close. If it has to be the same person, do it in a different sitting, with the standard open and the accounting file shut.
[ ] Packet check done. All four files, same period.
[ ] Every condition in the standard has a tick or a named exception
[ ] Every exception line names a file and a row, and I opened one at random
[ ] Every account named in an exception exists in the trial balance
[ ] Any arithmetic the conclusion rests on, added again by hand
[ ] Opening balances match the prior month's closed balance sheet
[ ] Proposed fixes read against the chart of accounts, not accepted as written
[ ] Anything carried forward has an owner and a next month beside it
[ ] Signed and datedCondition one takes about a minute to write. The other nine are that same minute, nine more times, and after that the file exists whether or not you were feeling careful the day it mattered.