# The Bank Statement Review Queue: What Lands There and Why

- Author: AutoBankConvert (https://www.autobankconvert.com)
- Published: 2026-07-13
- Updated: 2026-07-13
- Category: Statement automation
- Canonical: https://www.autobankconvert.com/blog/bank-statement-review-queue

> What lands in a bank statement review queue after automated conversion, why each line was held back, and how to clear the queue quickly for every client.
A bank statement review queue holds the converted lines that automation would not post on its own: a vendor with no rule yet, a payee that fits two accounts, an odd amount, or a statement whose balances did not tie. Each item waits with a suggested category. You clear it by working causes in order, not lines top to bottom.

## What kinds of lines land in a bank statement review queue?

A bank statement review queue collects two kinds of items: single transactions the categorization step could not place with certainty, and whole statements that failed a check during conversion. The first kind is routine and appears every month. The second kind is rarer and blocks everything below it, so it deserves attention first.

Line-level holds usually fall into a handful of groups:

- **New vendors.** The client paid someone for the first time, so no rule and no past coding exist for that payee.
- **Shared vendors.** A marketplace, a warehouse club or a fuel card that the client uses for several purposes. The same payee can belong in supplies one week and in owner draws the next.
- **Conflicting signals.** A rule says one account, but the client's history for that payee says another. The tool cannot pick a winner, so it asks.
- **Odd amounts.** A familiar vendor at five times its usual charge, or a credit from a vendor that normally only bills.
- **Transfers and payments.** Money moving between the client's own accounts, or a card payment, which belongs on the balance sheet rather than in income or expense.

Statement-level holds are different in nature. They mean the converted file itself is in doubt, usually because the opening balance plus the transactions did not equal the closing balance. Until that gap is explained, categorizing the lines inside that statement is wasted effort, because one of them may be missing or doubled.

## Reading the reason behind each review queue hold

Every item in a review queue was held for a reason, and the reason decides the fix. Before you change a category, read what the tool suggested and ask what made it unsure. A suggestion with no history behind it calls for a judgement. A suggestion that conflicts with an existing rule calls for fixing the rule.

Some tools show a numeric score next to each suggestion. A score is a summary of how sure the categorization step was, not a measure of whether the account is right. The post on [what a categorization confidence score means and when to trust it](/blog/categorization-confidence-score) covers how to read those numbers and where a threshold belongs.

Description text is often the hidden reason. If the bank prints the same vendor three different ways, each variant looks like a stranger to the rules, and each one lands in the queue. When you see near-identical payees held separately, the cause is the text, not the vendor. Cleaning that up is the job of [vendor name normalization on bank statement lines](/blog/vendor-name-normalization-bank-statements), which maps the variants to one name so a single rule covers them.

### A worked queue for one client

The table below is an example of one client's March queue after conversion. The client, vendors and amounts are made up.

| Line | Description | Amount | Suggested | Why held | Action |
| --- | --- | --- | --- | --- | --- |
| 1 | Statement: checking ending 2210 | | | Balance gap of 85.00 | Find the missing line first |
| 2 | HARBOR LINEN SVC | -312.40 | Cleaning | First payment to this vendor | Confirm with client, approve |
| 3 | AMZN MKTP US*2K4 | -64.99 | Office supplies | Shared vendor | Check receipt, approve or recode |
| 4 | AMZN MKTP US*7Q1 | -219.00 | Office supplies | Shared vendor | Receipt shows a chair: equipment |
| 5 | ONLINE TRANSFER TO SAV 4471 | -2,000.00 | Transfer | Account not mapped | Map savings account, approve |
| 6 | CITY WATER UTIL | -1,480.22 | Utilities | Amount is 4x usual | Ask client, likely a leak or catch-up bill |
| 7 | STRIPE TRANSFER | 3,904.18 | Sales | Rule and history disagree | Fix the rule, approve |
| 8 | ATM WITHDRAWAL 0331 | -300.00 | Owner draw | No receipt pattern | Ask client |

Line 1 is the only item that blocks the others. Lines 3 and 4 share a payee but end in different accounts, which is normal for a marketplace. Line 7 points at a rule that needs editing, not a line that needs a one-off fix.

## Clearing one client's review queue in a single pass

The fastest way to clear a review queue is to sort it by cause and work the causes in a fixed order. Statement-level problems go first, rule conflicts second, new vendors third, and anything that needs a client answer last, batched into one message. Working top to bottom by date makes you touch the same vendor several times.

A clearing order that works for most clients:

1. **Resolve every balance gap.** Open the flagged statement, find the line the gap points to, and correct the converted data. Only then look at that statement's lines.
2. **Fix rule conflicts.** When a rule and the history disagree, decide which is right and edit the rule. One edit can clear several held lines at once.
3. **Group lines by payee.** Approve or recode all lines from the same vendor together, so you make each decision once.
4. **Handle transfers and payments.** Map the client's other accounts so these lines never return as expense.
5. **Approve new vendors you can identify.** A clear payee name plus a plausible amount is usually enough.
6. **Collect the unknowns.** Put every line you cannot place into one short list for the client, with date, amount and description.
7. **Export only when the queue is empty or deliberately parked.** A line left as an open question should not slip into the client's books under a guess.

The last step matters more than it looks. Some practices park a few small unknowns in a suspense account so the month can close. That is a valid choice, but it should be a decision with a note attached, not a side effect of exporting too early.

## How many review queue items are normal for a client?

A normal review queue size depends on the client's age with you, not on a fixed number. In month one, many lines land there because no rules or history exist. By the third or fourth month, most of a steady client's lines should post on their own, and the queue should hold only genuinely new or unusual items.

Three patterns are worth watching:

- **A queue that does not shrink.** If month four looks like month one, approvals are not turning into rules. Check that you are approving the suggestion rather than overwriting it with a one-off edit each time.
- **A sudden jump.** A steady client whose queue triples in one month often changed something: a new bank, a new card, a new payment processor, or a bank that redesigned its statement.
- **The same vendor every month.** One payee that lands in the queue repeatedly usually has inconsistent description text or a rule that is too narrow.

New clients deserve extra patience. A business in its first weeks has no coding history at all, and its spending patterns are still forming. The guide to the [first month of bookkeeping for a new business](/blog/first-month-of-bookkeeping-for-a-new-business) explains what to set up before the first statement arrives, which keeps that early queue manageable.

## Review queue items you should not approve in bulk

Bulk approval is safe only when every selected line shares the same vendor, the same purpose and the same account. A review queue invites speed, and most tools let you select many lines and accept their suggestions at once. That is efficient for a recurring vendor, but some items hide a mistake that bulk approval will spread across the books.

Leave these out of any bulk action:

- **Lines from a shared vendor.** A marketplace purchase can be inventory, equipment, an office supply or a personal item. Each one needs its own look.
- **Transfers between accounts.** Approving a transfer as an expense inflates costs and leaves the other account unbalanced.
- **Refunds and reversals.** A credit from a vendor should usually reduce the original expense, not count as income.
- **Large or round amounts.** A 5,000.00 payment to a familiar vendor might be a deposit, a loan repayment or a purchase that should be capitalized.
- **Anything near the period edges.** Lines dated at the very start or end of a statement are where wrong years and duplicated pages show up.

A suggestion from an AI model is a prompt to check, not evidence that the account is right. The post on [what an AI bank statement converter actually does](/blog/ai-bank-statement-converter) explains where those suggestions come from and why a plausible guess can still be wrong for a particular client.

## Shrinking next month's review queue with each approval

Each approval in a review queue should make next month's queue smaller. When you accept or correct a suggestion, the tool can record the decision as a rule or as coding history for that client. The next statement then posts that vendor without asking. A queue that teaches is the difference between monthly review and monthly data entry.

In AutoBankConvert, a line the rules are unsure about arrives in the queue with a suggested category, and approving it teaches that client's rules, so the same vendor is categorized automatically the following month. Rules stay inside each client's workspace, so a decision for one set of books never changes another.

A few habits make the learning stick:

- **Approve the pattern, not the instance.** If a vendor always belongs in one account, record that as a rule rather than recoding the single line.
- **Write exceptions as conditions.** If the same vendor needs two accounts depending on amount or direction, express that in the rule instead of fixing it by hand every month.
- **Leave shared vendors in review on purpose.** Some payees should keep landing in the queue. Teaching a rule to post every marketplace purchase as supplies trades a few minutes of review for a misstated profit and loss.
- **Review the rule list each quarter.** Delete rules for vendors the client no longer uses, and merge rules that differ only by a stray reference code.

The goal is a queue that holds only what deserves a person's eye. To see how a monthly batch moves from statements to a short review list and then to export files, [start with AutoBankConvert](/get-started).