The trial balance on your screen is dated the 2nd.
It opens, it's the right client, nothing obviously wrong with it. You read it and write up what you found.
Four days later somebody asks why cash moved. It moved because the file got pulled before the last days of the month posted, and a few accounts changed after. You reviewed a month that no longer exists.
Nothing on the file warned you, and closing that gap is what a traceable work packet is for. The file carried a date, and that date was the day somebody exported it. The period it covers is a separate fact, and it's inside the file.
It starts with a distinction nobody gets taught. A missing input is loud. You go looking for it, it isn't there, you ask, you wait. Annoying and honest. An input that covers the wrong days is quiet. It arrives, it opens, it looks finished, and it fails at the end of your work, where the cost is highest.
Every close checklist ever written checks for the loud one.
There's a second gap underneath that, and it costs more. Most checklists never say what "traceable" means, so nobody can tell whether a packet is traceable or not. It has one testable definition. Every number in the review points back to a file and a line somebody else can open. If a number only points back to what you remember deciding, it isn't traceable, and the next person who asks about it is going to redo it.
What is a traceable work packet?
A traceable work packet is the set of inputs a month's review needs, checked before the review starts, every number in it pointing back to a file and a line. Four inputs: the bank statement CSV, the credit card statement CSV, the trial balance export, and the prior month's closed balance sheet. Each gets a row on the packet manifest, a page recording the period it covers, the date you pulled it, the number it has to agree with, and one of three statuses: complete, missing, or wrong period. Nothing gets reviewed until all four read complete. A fifth, the transaction detail behind any account you end up opening, pulled the same day as the trial balance, arrives during the review rather than before it. In a made-up landscaping client's June books, the made-up practice case used here, that check surfaces a $312.00 bank difference before anybody starts reading.
Key Takeaways
The fourth input is the one that gets skipped - it's the prior month's closed balance sheet, and it's the only file that proves the month started where the last one ended.
Missing announces itself and wrong period doesn't - a file pulled before the month finished posting opens fine, reads fine, and moves after you're done.
Read the period out of the file itself - the first and last dates inside the export are the period. The file name is whatever you typed when you saved it.
Traceable has one test - every number points back to a file and a line somebody else can open, or it isn't traceable.
Proposed and posted are different columns - in the made-up Cedar Hollow month, a synthetic $950.00 owner draw sitting in Repairs & Maintenance stays a proposal until somebody with the authority to post it says so.
The check finds inputs, not errors - it tells you the packet is complete and covers the right days. It doesn't tell you the books are right, and nothing here promises that.
The four inputs a month's review needs
Every month's review runs on four files. Three of them are exports and the fourth is last month's finished statement.
The bank statement CSV. It's the outside record. Everything in the books that touched cash has to exist here too, and its ending balance is what the reconciliation lands on. Without it you're checking the books against themselves, which they will always pass.
The credit card statement CSV. Same job, different account. The made-up Cedar Hollow set has one card, which makes it easy. On a client with four cards this is where packets quietly go short, because three arrive and one doesn't and the trial balance still adds up.
The trial balance export. The whole month on one page, and the file every exception gets found in. The made-up Cedar Hollow trial balance has 18 accounts, and all three of its planted problems are visible on it once you know what you're reading for.
The prior month's closed balance sheet. This is the one people skip, and it's the only file that can prove the month started where the last one ended. If last month closed with one cash balance and this month opens with a different one, something reopened behind you. You want to know that before you spend a day inside the month. On a client you've just taken on it might not exist in a form anybody trusts yet, and that's its own project. Write "missing" on the row anyway. A packet that admits the gap is worth more than one that starts by assuming the month opened clean.
Four files. That's the entire pre-review input list for a small client like the made-up Cedar Hollow one, cash basis, one checking account, one card, roughly 40 transactions a month. A bigger client has more of the first two and never more of the last two.
There is a fifth, and it is not on the manifest when this check runs. The transaction detail behind any account you end up opening, pulled the same day as the trial balance, arrives during the review rather than before it, because until somebody opens a balance nobody knows which account it is. The review packet records it in its own first section when it shows up.
This article starts the moment those four files are supposed to be in your hands. Where they come from before that is the capture and triage workflow that produces them, and it runs across the whole month.
Missing is loud, wrong period is quiet
Three checks separate the two failures. None of them needs anything you don't already have open.
Read the period inside the file. Open the CSV and look at the first and the last transaction date in it. That's the period. The file name is whatever you typed. A file called checking-jun.csv in the made-up Cedar Hollow folder that actually starts on the 3rd is a file missing two days, and it will reconcile short, and the two days are the last place you'll think to look.
Compare the pull date to your cutoff. Anything arriving on a feed can post after you've exported, so an export pulled on the 1st or the 2nd is a draft of the month. Pick one cutoff date and write it at the top of the page. The cutoff in this article is the 10th of the month after the one under review: pulled on or after the 10th, the file stands; pulled earlier, pull it again before you read a number off it. One date, used the same way on every file and every client, is what makes the check something a person or a piece of software can run identically.
Tie both numbers. The first tie is last month's closing balances against this month's opening. That one catches a period somebody reopened. The second tie is the bank file's ending balance against the books' cash. That one catches a difference. In the made-up Cedar Hollow packet the second tie comes out $312.00 apart, all of it synthetic, and that difference is exactly what the review exists to explain.
The first two take under a minute each. The third takes about two.
What a traceable work packet actually means
Traceable means every number in the review points back to a file and a line. A file name and a row number. A folder isn't one of those, and neither is "the bank feed." Somebody who wasn't in the room opens it and sees the same thing you saw.
Take the three problems planted in the made-up Cedar Hollow month.
Uncategorized Expense holds a made-up $1,284.50 across four transactions. The untraceable write-up says "uncategorized needs cleanup." The traceable one names all four rows: checking-jun.csv rows 9, 17, 26 and 38, all made up, each with its amount, its payee, and a proposed account beside it.
The bank difference is $312.00, also made up, and it comes from a vendor payment recorded twice. A write-up that says only "recon off by 312" leaves the next person rebuilding the whole reconciliation to work out which made-up rows you meant. Write both book entries out, name the single payment at row 22 of that same made-up file, and add one sentence saying which of the two entries you propose to remove, and they can check it in about a minute.
The owner draw is $950.00, made up as well, sitting in Repairs & Maintenance. Untraceable: "reclass owner draw." Traceable: row 31 of the made-up checking file, the account it's in now, the account you propose, and a blank column recording whether it got posted and who decided.
That last column carries more weight than it looks like it does. A packet that mixes what you proposed with what you posted can't be checked by anybody, because there's no way to tell which numbers moved and which ones are still suggestions. Two columns, and a review a stranger can pick up is what you're handing over. The Posted column takes four words: yes or no, the date, a name.
The packet check, before anybody opens the books
Here's where it sits in a month. We ask for everything on the 5th and we aim to have every client closed by the 20th. The packet check goes right after the 10th, before anybody opens a set of books, because that's the only place in the month where finding a bad input is free. The cutoff is the 10th: a file has to be pulled on or after the 10th of the month after the one under review, because the 5th is the day you ask, and feeds keep posting for days after that.
The check itself is a page. Six columns, four rows, one row per input. Each row records the period the file actually covers, the day you pulled it, the number it has to agree with, and a status. Three statuses, and only three: complete, missing, wrong period. Anything you're unsure about isn't complete.
Then the rule that makes the page worth having: nothing gets reviewed until all four rows read complete. A partial packet gets a partial review, and a partial review is one somebody does twice.
Sometimes you can't re-pull. A client sent a PDF, a portal aged the export out, whatever it is. The row still reads wrong period and the exception log gets a line saying why. The status is a fact about the file.
The first time you do this you're writing the page, so it takes a while. After that you're filling one in, and for a client the size of the made-up Cedar Hollow one that's a few minutes.
Where this check goes next
The check is deliberately boring, because a boring check is one a piece of software can run the same way every month without you watching it.
That makes it a good job for a skill. Same four inputs, same three statuses, same two ties, same cutoff date. You'd hand it the file names and their dates and get the manifest back with a status on every row. Until you build one, the page in the setup pack does the same job by hand.
A skill, in the hosts that document them, is a plain text file. There's a short block at the top naming it and saying when it should be used, and instructions under that in ordinary sentences. It sits in a folder the host reads. Claude Code and Codex both document packaging skills that way. That's documented host support and not a test result of ours, and none of it has been run against your setup.
Every packet shown in this article is made up, including the one the check runs on. The wider article this one sits under is the monthly close itself, Get a reviewable monthly close: AI-assisted bookkeeping for small firms. The one that takes a checked packet and produces the actual review comes after it: Produce a month-end review packet from your trial balance, with AI assistance.
One boundary before you go build any of it. The four files in this article are made up and so is the client in them. Whether your own client exports can go into a tool at all is your firm's decision and your own counsel's, and it's a question about what leaves the building rather than one this page can answer for you.
Do this week
Pick the client whose close you'd least like to hand to somebody else, and write the manifest page for that one client. Four rows, six columns, the file names from your own folder.
One question
How many months back do you have to go before you hit one where the trial balance came out on the 2nd?
The setup pack
Copy what follows into your own files and change the names. Every sample row below is made up, and so is the client in it.
The packet manifest
One page per client per month. Six columns:
Input - which of the four it is
File name - exactly as you saved it
Period covered - the first and last date inside the file, not the month you meant
Pulled on - the day you exported it
Ties to - the number this file has to agree with, and what it agrees with
Status - complete, missing, or wrong period
Paste this header row into a sheet. There are tabs between the columns, so it lands in six cells.
Input File name Period covered Pulled on Ties to StatusHere it is filled in for the made-up Cedar Hollow month, with made-up file names and dates. The cutoff in this sample is the 10th of the month after the one under review, so look at the third row. That's the point of the page.
Bank statement CSV checking-jun.csv Jun 1 to Jun 30 Jul 11 Ending balance vs books cash complete
Credit card CSV card-jun.csv Jun 1 to Jun 30 Jul 11 Ending balance vs books card liability complete
Trial balance trial-balance-jun.csv Jun 1 to Jun 30 Jul 2 18 accounts, opening vs May close wrong period
Prior month close balance-sheet-may-closed.pdf closes May 31 Jun 22 Closing balances vs June opening completeThe folder
One folder per client per month, and the same six names inside it every month, so next month is a copy with the dates changed. The client name below is made up.
cedar-hollow/
jun/
checking-jun.csv
card-jun.csv
trial-balance-jun.csv
balance-sheet-may-closed.pdf
manifest.txt
exceptions.txtThe wrong-period check
Three lines. Run them in order, on every file, before any row on the manifest gets a status.
1. Open the file. Write down the first and the last date inside it.
Those two dates are the period. Ignore the file name.
2. Compare the pull date to your cutoff, the 10th of the month after the one
under review
unless your firm sets a different one. Pulled on or after it, the file
stands. Pulled before it, pull again.
3. Tie both numbers. Last month's closing balances to this month's opening,
and the bank file's ending balance to the books' cash.The exception log
One row per exception, in the same folder as the manifest. Six columns again:
Exception - one sentence on what you found
Amount - the figure exactly as it appears in the file
Where it shows - the account or the reconciliation
Traces to - file name and row number
Proposed - what you'd do about it, in one sentence
Posted - yes or no, the date, and who decided
Same six columns wherever this log turns up. The skeleton to paste, header row and all, is in "Produce a month-end review packet from your trial balance, with AI assistance."
Filled in with the three made-up problems planted in the made-up Cedar Hollow month, columns in that order:
Four transactions never categorized 1284.50 Uncategorized Expense checking-jun.csv rows 9, 17, 26, 38 One account proposed per row, listed on the log no
Vendor payment recorded twice 312.00 Bank reconciliation checking-jun.csv row 22 Remove the second entry no
Owner money coded as a repair 950.00 Repairs & Maintenance checking-jun.csv row 31 Reclass to Owner Draw noA prompt for the comparison part
Four file names and their dates. No transactions, nothing from inside the books.
Most of the manifest is transcription. The one part that takes real attention is comparing four sets of header dates against one cutoff, and that comparison is identical every month, which is what makes it worth handing over. This does that part. Nothing else.
It will get some of them wrong, which is why each line it returns carries a file name and a date. You open that file. The file settles it, and that's the only reason the sentence above it is worth reading.
I'm checking whether a month's bookkeeping inputs are complete before anybody
reviews them. Below are the file names and dates for four export files. There
are no transactions here and nothing from inside the books.
Month under review: [month]
File 1, bank statement: [name], first date inside it [date], last date inside
it [date], pulled on [date]
File 2, credit card statement: [name], first date inside it [date], last date
inside it [date], pulled on [date]
File 3, trial balance: [name], period it covers [date] to [date], pulled on
[date]
File 4, prior month close: [name], the month it closes [date], pulled on [date]
The lines above are the whole input. Where a line is absent, write
"not given" and move on.
My cutoff is the 10th of the month after the one under review. A file
pulled on or after that date stands. A file pulled before it does not.
Give me one status per file, using only these three words: complete, missing,
wrong period.
Under every file you did not mark complete, give me three things:
- the exact reason, naming the date that made you say it
- what I should do about it, in one sentence
- which of the two ties that file was supposed to answer
Then name any of the four inputs that has no line above it at all.
Finish with one line telling me to open each file you flagged and read
the dates myself before I change anything.
Don't tell me anything about the books. You haven't seen them.The reviewer's start checklist
Whoever opens the packet ticks this before reading a single number. If any line fails, the packet goes back and nothing gets reviewed.
[ ] All four inputs present, one row each on the manifest
[ ] Every Period covered read out of the file itself
[ ] Every file pulled on or after the cutoff date at the top of the page
[ ] Opening balances tie to last month's closed statement
[ ] Bank ending balance tied to the books, any difference written down
[ ] Exception log exists, one row per exception
[ ] Every exception row names a file and a line
[ ] Posted column filled on every row, even when every answer is no
[ ] Nothing sitting in Proposed has already been postedOne page per client. The person who opens it next starts reading instead of asking you.