1 The situation
Bank data for a client was being brought into the working files by an AI-run import. The import looked clean. No error, no warning, a finished-looking file.
It had silently dropped 7 rows. A rare edge case in the step that removes duplicate lines had treated 7 real transactions as duplicates. The bank balance was understated by about $93K, and receivables by about $1.5K.
2 How it was caught
The reconciliation check would not go to zero. When the balance was set against an independent bank list, a gap remained, and our process does not allow anyone, person or AI, to move on while a check refuses to tie.
So the work stopped there. The gap was traced back to the import, row by row, until the 7 missing transactions were found.
3 What we did about it
We corrected both master files and recomputed every balance that depended on them. Nothing had gone out to the client on the wrong numbers.
Then the important part. We wrote the failure into the playbook as a mandatory step: after every import, the full date range is compared against the source, line by line. The same error cannot now pass unnoticed.
4Other errors the same discipline has caught
- A journal entry that would have double-counted a deferral, caught before it was posted.
- A tax engine that had restated its own data by about half, caught before anyone filed on it.
- Entries edited after a close was signed off, found by comparing the live ledger with what it said the week before.
5What the AI did, and what people did
The AI
- Ran the import and the reconciliation
- Refused to move on while the check did not tie
- Traced the gap back to the 7 missing rows
- Drafted the new playbook step
Our accountants
- Decided the work stops until the gap is explained
- Reviewed the correction to both master files
- Approved the new rule
- Own the numbers that go to the client
