Somebody hands you a closed month and asks whether it's right.
They mean the answer, and they want it in a form they can put their name on.
So you open the accounting system and start clicking. Balance sheet, then the P&L, then back again. Twenty minutes later you say it looks fine, and you're probably right.
Nothing gets left behind. Nobody can check what you looked at. Next month the same twenty minutes starts from nothing.
A month-end review packet is what you make instead. Most of it is assembly, and assembly is the part a model is actually good at.
The packet is the deliverable. The looking is not.
What is a month-end review packet?
It's the file you hand a reviewer instead of your accounting system. Four inputs go in: the month's bank statement CSV, the credit card statement CSV, the trial balance export, and last month's closed balance sheet, plus the transaction detail behind any account you end up opening, pulled the same day as the trial balance. Four sections come out: what the packet covers, the exceptions with an amount and an account each, the corrections somebody has proposed and nobody has posted, and a signature line naming who reviewed it and what they read. This article works one through on a made-up landscaping client, where three exceptions worth $1,284.50, $312.00 and $950.00 turn up in three different places: one on the trial balance, one only after the bank statement is reconciled, and one in the detail behind a balance that merely looked large. Those numbers are invented for the example.
Key Takeaways
The packet is the deliverable - a review that lives in one person's head can't be signed by a second one, and next month it starts from nothing.
Four inputs, plus a fifth you pull only when a balance makes you look - bank CSV, card CSV and trial balance export for the month under review, the prior month's closed balance sheet, and the transaction detail behind any account you end up opening, pulled the same day as the trial balance.
An exception list is only as wide as the files you handed it - in the made-up landscaping file the $1,284.50 in Uncategorized Expense came off the trial balance, the $312.00 gap only appeared after the bank was reconciled, and the $950.00 owner draw was hiding in the detail behind a Repairs & Maintenance balance.
Every exception on the list is still a question - that invented $950.00 is either money the owner took for himself or an actual repair the business paid for, and no balance on the trial balance can tell you which.
Nothing in the packet is posted - proposed corrections stay proposed until somebody with the authority to post them says yes, in writing, on the packet.
The model assembles and people sign - it reads what you gave it and lists what doesn't fit, and everything after that list is a judgment somebody at your firm has to make and put their name to.
What goes into a month-end review packet, and the check that runs first
Four files, and a fifth you pull only when a balance makes you look.
The month's bank statement, exported as a CSV.
The credit card statement, same month.
The trial balance export, as of the last day of that month.
Last month's closed balance sheet, so the opening balances have something to tie back to.
The transaction detail behind any account you end up opening, pulled the same day as the trial balance, so it can't drift out from under you.
The first four you pull before you start. The fifth you pull during, and section one has to record it, or half your findings can't be reproduced by the person who signs.
That's the list for the made-up landscaping client this article uses throughout, and for a real one too. Cedar Hollow Landscaping LLC is invented for the example: a single-member LLC on cash-basis books, one checking account, one credit card, about forty transactions in June. Small enough to hold in your head, which is exactly why the packet feels unnecessary right up until somebody asks about a month you closed four months ago.
Run one check before you read anything. For each file, write down what it is and what period it covers, and don't start until every one reads complete. What that check is, how the page is laid out, and what to do with a file you can't re-pull, belongs to a separate piece, Catch missing inputs before review: prepare one traceable work packet.
One boundary before anything real goes near a model. Everything here runs on the invented Cedar Hollow file, which has no connection to any actual engagement. That's on purpose: you learn the shape without deciding anything about a client first. What your firm may send outside itself is a separate question, and one to settle with your own counsel before a real export leaves your machine.
Reading 18 made-up accounts for the 3 that don't fit
The made-up trial balance is eighteen lines. You can read it in ninety seconds. Reading it is the fast part.
The slow part is that only one of the three exceptions in the invented Cedar Hollow file finishes on the trial balance at all.
$1,284.50 in the made-up file's Uncategorized Expense. This one the trial balance hands you. Uncategorized is where a transaction lands when nobody decided, and a balance sitting in it at month end means decisions are outstanding. How many is a question the trial balance can't answer, because a trial balance carries balances and no transaction counts. Open the detail and in the invented file there are four of them, which makes it four questions with four possible answers: one could be a supplier nobody set up yet, one could be personal, one a duplicate, and one the annual insurance payment that belongs somewhere specific.
A $312.00 gap in the invented file between the books and the bank. No line on a trial balance announces this one. It comes out of the reconciliation: take the book cash balance, take out the payments and deposits that hadn't cleared by month end, and put what's left next to the closing balance on the bank statement CSV. A clean month lands on zero. In the made-up file it doesn't, because the same vendor payment was recorded twice, so the books show money leaving that never left the account and the book balance sits $312.00 low. Read the direction once the uncleared items are off the table. Books below bank points at something recorded that didn't happen, or a deposit the bank has and the books never captured. A bank fee nobody recorded runs the other way. The duplicate inflates an expense account too, and that balance is on the trial balance, but nothing on the sheet says a balance is doubled rather than merely large.
A $950.00 owner draw coded to Repairs & Maintenance, in the same invented file. The trial balance can't tell you this one either. It shows a Repairs & Maintenance balance and stops there. What it can do is make you look: on a made-up landscaping business running about forty transactions a month, a repairs line at that size is worth opening. The draw shows up in the detail behind it. Then two things are wrong at once. Repairs & Maintenance reads $950.00 higher than the invented business actually spent on repairs, so anybody reading the P&L for a trend gets a false one. And the draw account sits $950.00 light. Total equity still comes out right, which is exactly why nothing on the trial balance objects: the overstated expense and the understated draw cancel each other.
That's what bounds any exception list, including one a model builds. It works from the files you handed it. Give it a trial balance on its own and it can flag the first exception and point you at the third, and it will not name the second, because the bank statement was never in the room.
Inside its own file it has a gap that doesn't close either. If $600 of service revenue got booked to the wrong income account, and that $600 is invented for this example too, the trial balance still balances, both income accounts carry plausible balances, and no list says a word about it. Anything that was never recorded at all is invisible for the same reason.
What the packet says, section by section
Four sections, in the order somebody reads them.
Section one, what this covers. Every file by name, with the period each one covers, the number of accounts on the trial balance, and the accounts whose detail you had to pull. Anything missing or covering the wrong period gets written here, at the top, before a reviewer has read a single balance. Write the gaps first and a reviewer knows in ten seconds which balances to trust.
Section two, the exceptions. One line each: the amount, the account, what the balance appears to be, and the question it raises. Six lines for the made-up Cedar Hollow file if you split its uncategorized balance by transaction, three if you don't. A model will build the part of this it can see from the files you gave it, and this is the section you check hardest.
Section three, proposed corrections, none of them posted. From account, to account, amount, the reason, and the name of the person who has to answer a question before it can move. Keeping this separate from section two is the point of the whole exercise. A suggestion and an entry are different objects, and once they share a list nobody can tell later which was which.
Section four, the review. Who read it, when, which files they read, which exceptions they accepted as described, which ones they sent back, and which corrections they approved for posting.
The packet starts after the close checklist and the definition of done have already done their work. How the close gets there is in Get a reviewable monthly close: AI-assisted bookkeeping for small firms.
What the signature on a review packet actually says
This is where firms get nervous, and the fix is to be narrow about it.
The signature says: I read these files, I looked at these exceptions, I accepted these, I sent these back, and I approved these corrections to be posted. That's the whole scope. It is not a statement that the books are correct, and it should not be written as one. A reviewer who signs "reviewed and correct" has promised something nobody can deliver from a trial balance and a handful of exports.
Write the narrow version into the packet itself, above the signature line, so nobody has to remember it.
A packet somebody else can sign is a job you can eventually stop doing, which is the same problem as everything else that has to leave your desk before a firm grows.
Where a person still has to decide
Four decisions in the made-up Cedar Hollow packet, plus one that stands on every packet you ever build.
Which of the four invented uncategorized transactions is a business expense at all. Only the owner knows what he bought. A model looking at a vendor name and $1,284.50 in an invented file will produce a confident guess, and a guess posted to a client's books is worse than a blank.
Whether the invented $312.00 duplicate gets fixed in the closed period or the open one. That depends on whether the prior period is locked, whether statements already went to the client, and what your firm does about restating a month somebody has already seen. The accounting answer is the easy half. The firm policy is the part that decides it.
Whether the invented $950.00 was the owner taking money or the business paying for a repair. Two completely different entries. Same number, same account, same made-up file. The answer is in a conversation, not in the data.
Who's allowed to post any of it. In a lot of small firms the answer is whoever is holding the file at the time, which is how a proposed correction becomes a posted one with nobody deciding.
Then the standing one. When every line on the exception list looks reasonable, that's the moment the packet is most dangerous, because a list that reads clean feels like a check that passed. Who catches it when the tool is wrong, and what one wrong output costs you are questions your firm has to answer for itself.
Do this before Friday: build the packet once on the made-up landscaping numbers in this article, where being wrong costs nothing and the answers are already written down. Then save the empty skeleton into a client folder and do a real one next month-end, by hand from your own exports, before anything goes near a model.
What do you hand a reviewer today, instead of a packet? A file name and one sentence about what they do with it is enough of an answer.
The setup pack
None of this is finished. The skeleton assumes things about your accounts that you'll want to change on the first client you run it on.
The packet skeleton
Save it as a text file and copy it per client, per month. The bracketed parts are yours.
MONTH-END REVIEW PACKET
Client: Period:
Prepared by: Prepared on:
1. WHAT THIS COVERS
Files read, and the period each one covers:
- Bank statement export: [file name], covering [start] to [end]
- Card statement export: [file name], covering [start] to [end]
- Trial balance export: [file name], as of [date]
- Prior period closed balance sheet: [file name], as of [date]
- Transaction detail pulled for: [accounts], as of [date]
Accounts on the trial balance: [count]
Missing, or covering the wrong period:
[list here, or write NONE]
2. EXCEPTIONS
Nothing in this section is a correction.
- [amount] [account] - [what the balance shows] - [the question this raises, and who can answer it]
3. PROPOSED CORRECTIONS - NONE OF THESE ARE POSTED
- [amount] from [account] to [account] - [reason] - [who has to answer first]
No line in this section is entered anywhere until section 4 is signed.
4. REVIEW
Reviewed by: Date:
Files read: [section 1 list]
Exceptions accepted as described: [numbers]
Exceptions sent back for an answer: [numbers]
Corrections approved for posting: [numbers]
This signature records which files were read and which decisions were made.
It is not a statement that the books are correct.Section two, filled in with the three made-up Cedar Hollow exceptions:
2. EXCEPTIONS
- $1,284.50 Uncategorized Expense - four transactions with no category - what were these four? Owner
- $312.00 Cash - Operating - book balance low against the reconciled bank statement - a vendor payment looks recorded twice. Confirm against the bank CSV. Bookkeeper, then reviewer
- $950.00 Repairs & Maintenance - detail shows one payment to the owner - draw, or a repair the business paid for? OwnerThe exception log
One row per exception, kept in the same folder as the packet. Six columns, in this order: Exception, Amount, Where it shows, Traces to, Proposed, Posted.
Header row:
Exception Amount Where it shows Traces to Proposed PostedThe review checklist
One row per client per month. After the first month you stop working out what the columns should be and start filling them in.
The columns, in the order you work them: Client, Period, Packet file, Inputs complete, Periods match, Trial balance in balance, Uncategorized at zero, Bank cleared to statement, Card cleared to statement, Opening ties to prior close, Exceptions listed, Corrections proposed, Corrections approved by, Reviewed by, Review date, Sent to client.
As a header row you can paste straight into a spreadsheet:
Client Period Packet file Inputs complete Periods match Trial balance in balance Uncategorized at zero Bank cleared to statement Card cleared to statement Opening ties to prior close Exceptions listed Corrections proposed Corrections approved by Reviewed by Review date Sent to clientPacket file is the column that makes the row worth keeping. Without it the row says a packet was reviewed and nothing says which file. Periods match is the one people leave out: a yes or no on whether the current-month files cover the same month and the balance sheet is the close immediately before it.
The skeleton and the prompt wait for you to open them. The row keeps doing something while you don't.
One prompt
Read the exception list before you read the balances. This is the prompt that gives you one.
Before you paste anything: the trial balance for a real client carries that client's business in it. Practice on the made-up one in this article, where being wrong costs nothing.
And a word about what comes back. The failure you're watching for reads perfectly reasonable and belongs to a transaction the model never had in front of it. It works from the one file you pasted, so everything the reconciliation would have told you is out of reach. So is anything that nets to zero: if an amount went to the wrong account and the sheet still balances, there's nothing to flag. Nothing on that list goes into a packet in the words it came back in.
I'm a bookkeeper reviewing a closed month for a small business.
The sheet below is one month of ending balances and nothing else. It has no transactions in it, so anything you'd need a transaction to know, name instead of guessing.
Give me back one list. Each line: the amount, the account name, what the balance appears to be, and the question somebody would have to answer to settle it.
Flag at minimum:
- any holding or catch-all account carrying a balance
- any owner or equity account with a balance I'd have to explain
- any expense account whose balance looks large next to the rest of the sheet
- any account that should net to zero and doesn't
- any account you can't classify from its name alone
Where settling a line would need something you don't have, name what it needs.
Mark any line you'd want a person to check against a source document before it goes in a packet.
Where you're unsure, say so on the line instead of guessing.
Don't propose journal entries or tell me what to post. The list is the whole output.
[paste trial balance]If you paste that every month, it wants to be a file instead. Claude Code and Codex both document support for reusable instruction files. The shape is a folder with one markdown file in it called SKILL.md, carrying a few lines of metadata at the top and the instructions underneath, with a references folder beside it for anything long. Building one well, and testing it so a bad output gets caught before it reaches a packet, is its own piece of work, covered in Repeat a monthly-review step reliably: build one small firm skill.
Somebody has to ask the owner what he bought. Until that conversation happens the balance just moves forward a month, and the packet is where you write down that it hasn't happened yet.