Automation exception handling in bookkeeping is the routine for everything the automation would not finish: statements it flagged and transaction lines it held back. Sort them by cause first, fix statement-level problems before line-level ones, record each fix in a short log, and change the rule or habit behind any exception that returns.
What counts as an automation exception in bookkeeping?
An automation exception in bookkeeping is any item the automation stopped on instead of completing. That covers a statement that failed its balance check, a file that could not be read or matched to a client, and a transaction line held back because no rule or past coding gave a confident account.
It helps to separate exceptions from ordinary review. Ordinary review is the planned look at finished work: scanning a categorized month before export, or sampling lines the rules handled. An exception is unfinished work. The automation has said, in effect, "I could not do this one." Mixing the two lists slows both down, because a sampled line that is fine looks the same on screen as a held line that needs a decision.
Exceptions come in two levels, and the level decides who can fix them and in what order:
- Statement level: the whole file has a problem. A failed balance check, an unreadable scan, a duplicate upload, a statement for the wrong client, or a gap where a month should be.
- Line level: the statement is fine, but individual transactions need a decision. An unknown payee, a vendor that could belong to two accounts, a deposit nobody has explained, a payment that should be split.
AutoBankConvert flags a statement whose opening balance plus transactions does not equal its closing balance instead of exporting it, and sends lines its rules are unsure about to a review queue with a suggested category. Those two outputs map directly onto the two levels. For a wider view of which steps a tool takes over and which stay with you, the overview of bank statement automation for bookkeepers sets out the whole pipeline.
Sorting automation exceptions by cause before fixing any
Sorting automation exceptions by cause means grouping every flagged statement and held line under the reason it stopped before you touch any of them. Ten lines held for the same unknown vendor are one decision, not ten. A sorted list also shows which causes are one-offs and which are habits.
A practical set of cause groups, in the order you will work them:
- Wrong or missing file: a duplicate, a statement filed under the wrong client, a missing month.
- Unreadable or incomplete statement: a poor scan, a cut-off page, a password-protected file.
- Balance failure: the statement read, but the arithmetic does not close.
- Unknown payee: a line with no rule and no history.
- Ambiguous payee: a known vendor that could belong to more than one account.
- Needs client input: a deposit or payment only the client can explain.
Sort by cause, then by client within each cause. That order lets you write one rule that clears a vendor across a client's whole month, or one message that asks a client several questions at once.
A tally of the groups is worth keeping. If most of a month's exceptions are unknown payees for a new client, the automation is working as intended and the rule set is still young. If most are balance failures, something upstream needs attention, usually scan quality or how files arrive.
Fix order for statement-level automation exceptions
Fix statement-level automation exceptions before any line-level ones, because a bad statement makes every line on it suspect. Within statement-level problems, settle which files you have first, then whether each one reads, then whether its balances close. Each step can make the next one disappear.
Wrong or missing files
Start by confirming the set of files. A duplicate statement doubles every transaction on it and can cause a balance chain to look broken. The guide to catching a duplicate bank statement upload explains how repeats are spotted. Then confirm nothing is missing: a closing balance that does not equal the next month's opening balance usually means a statement is absent, and missing bank statement detection across client months covers that check in detail. A statement filed under the wrong client is moved, not fixed.
Unreadable or incomplete statements
Next come files that could not be read well. A faint scan, a photo taken at an angle or a page cut off at the bottom all produce unreliable fields. The quickest fix is nearly always a better copy. Ask the client for the bank's downloaded PDF rather than trying to rescue a poor scan by hand.
Balance failures
Last at this level are statements that read but do not close. The size of the gap is the clue:
- A gap equal to one transaction amount points to a missed line, often at a page foot.
- A gap of twice an amount points to a debit read as a credit.
- A gap equal to a fee or interest figure points to an amount printed in a summary box rather than the transaction list.
Find the line, correct it, and rerun the check. Do not export a statement with a known gap and plan to fix it later.
Clearing line-level automation exceptions in a batch
Clear line-level automation exceptions by vendor rather than by date, and decide whether each fix is a rule or a one-off before you act. A vendor that will return deserves a rule. A one-time purchase gets coded by hand and nothing more, so the rule set stays readable.
The session below is one way to work a month's held lines for a client. Treat it as a pattern to adapt.
- Filter the held lines to one client and sort them by payee.
- For each payee that appears more than once, pick the account and decide: rule or no rule.
- Write the rules, then rerun categorization so lines the new rules cover drop out of the list.
- Code the remaining one-off purchases by hand.
- Gather everything that needs the client into one message.
- Note each fix in the exception log.
An example exception log
The log below shows one month for a fictional client. Every entry is an example.
| Item | Cause | Fix this month | Prevention |
|---|---|---|---|
| March checking statement | Balance failure, gap 48.00 | Added a fee line printed in a summary box | None needed, one-off layout |
| HARBOR CAFE 22 lines | Unknown payee | Rule: Meals | Rule now in place |
| HOME DEPOT 3 lines | Ambiguous payee | Two business, one personal | Ask client to use a separate card |
| Deposit 2,940.00 | Needs client input | Asked client | Client to send remittance notes |
| Card processor deposits | Totals differ from processor report | Matched to payouts net of fees | Record the fee split each month |
The last row is a common one. Card processor deposits rarely equal the totals on a processor's year-end form, because deposits arrive net of fees and refunds. The explainer on why 1099-K totals differ from bank deposits walks through the reconciling items, so you do not treat the difference as an error.
In AutoBankConvert, approving a line in the review queue teaches that client's rules, so the same vendor is categorized automatically the next month. That makes step 2 matter more: every approval is also a decision about the future.
Why does the same automation exception return every month?
The same automation exception returns every month when the fix treated the line and left the cause in place. Coding a held vendor by hand clears this month and guarantees next month's repeat. A returning exception is a signal that a rule, a file habit or a client habit still needs to change.
Check the prevention column of last month's log against this month's exceptions. Anything that appears in both is a candidate for a root-cause fix. Common patterns:
- A rule that never matches. The bank prints a store number or date inside the payee text, so an exact rule fails each month. Shorten the rule to the stable part of the name.
- A vendor that needs a condition. A payee used for two purposes needs an amount range or a debit or credit condition, not two competing rules.
- A file habit. A client who photographs paper statements will produce unreadable exceptions until they download the PDF instead.
- A client habit. Personal spending on a business card produces ambiguous lines every month until the client separates cards.
Some exceptions should return, and that is fine. A deposit only the client can explain will keep needing the client. The goal is not zero exceptions; it is a list where every item is a real decision rather than a repeat of last month's.
When an automation exception goes back to the client
An automation exception goes back to the client when the answer lives only in their records or their memory. Unexplained deposits, transfers to accounts you do not have statements for, missing statements and mixed personal spending all need the client. Guessing on these produces books that look finished and are wrong.
Send them in one batch, not one at a time. A single message that lists each question with its date, amount and payee text gets better answers than a stream of emails across the month. For each item, say what you need and why:
- "A deposit of 2,940.00 on March 14 from ONLINE TRANSFER 8812. Which account did this come from?"
- "Three purchases at the same hardware store. Which were for the business?"
- "We have checking statements through February. Please send March."
Set a date for replies and say what happens if none comes: an unexplained deposit might be posted to a suspense account and flagged in the month's report. Record which questions went out so you can chase the same ones next month if needed.
A clear routine makes month end calmer. Statements that close, lines that are either coded or waiting on a named question, and a log that shows what changed. If you want the flagging and holding done before you open the file, AutoBankConvert runs the balance check and the review queue as part of each batch.