How to read check images for a bookkeeping cleanup

To read check images for a bookkeeping cleanup at scale, pull the images from the bank, read the payee line, match it against a roster of employees, owners, vendors, and sister entities, and let the match decide the category by rule. A person then reviews only the checks that didn't match. Done that way, several hundred handwritten checks take an afternoon of review instead of a week of squinting at the bank's image viewer.

We run an accounting firm, and the week before the September 15 extension deadline we closed a full year of books for a restaurant client that had written nearly 700 checks by hand. Here is how those checks got coded, and why the method matters beyond restaurants.

Why handwritten checks break bank-feed bookkeeping

A bank feed gives you "CHECK 4471, $612.00." That's it. No payee, no memo. For a business that pays by card and ACH, the feed carries enough to categorize. For a business that pays its produce vendor, its plumber, and its Friday tip-outs by paper check, the feed is a list of amounts, and every one of them lands in Uncategorized.

The bookkeeper's options have historically been bad. Open the bank's website, click each check image, read the handwriting, type the payee, pick the account, repeat 700 times. Or ask the owner, who will say "that's probably the fish guy" about a check from eleven months ago. Or code them all to Miscellaneous and let the tax preparer sort it out, which is how a restaurant ends up with $180,000 of "Other Expense" on a return.

The images exist. The bank has one for every cleared check. The work is reading them at volume and deciding what each means, and both halves can be done mostly by software.

Building the payee roster

The roster is the whole method. Before reading a single check, assemble a list of every name a check could plausibly be written to, tagged by what a check to that name means:

• Employees, from the payroll provider's roster, with hire and termination dates. A check to a current employee that isn't a payroll run is almost always a tip payout, a reimbursement, or an advance.
• Owners and family, from the ownership records. A check to the owner is a draw. A check to the owner's spouse is usually a draw too, unless the spouse is on payroll.
• Vendors, from the existing vendor list, the prior year's 1099 file, and the bills already in the system. The produce supplier, the linen service, the landlord, the utility.
• Sister entities, from the ownership chart. A check from the restaurant to the owner's LLC that holds the building is rent or an intercompany transfer, and the roster needs to say which.
• Lenders and agencies, from the loan sub-ledger and the tax filings. The check to the state for sales tax and the check to the equipment lender each go to a liability, not an expense.

For the restaurant, the roster came to about 140 names. Handwriting is variable, so the match is fuzzy: "J. Ramirez," "Jose R," and "Ramirez" all resolve to the same employee. The match returns a confidence, and anything below the threshold goes to the exception queue rather than being guessed.

Rules for counter checks, round amounts, and transfers

Several patterns show up in every check-heavy business and can be coded by rule once the roster exists.

Counter checks. Low-numbered or unnumbered checks, usually round amounts, no payee or "Cash" on the payee line. These are the owner walking into the branch. Coded as owner draws by rule, with the list sent to the owner once for confirmation.

Round amounts to employees. A $200 check to someone on the payroll roster on a Friday, in a restaurant, is a tip payout from the drawer. It goes to Tips Paid Out, a pass-through, not to wages and not to a vendor. The distinction matters for prime cost and for the W-2s, because tips paid out from cash sales were already reported through the POS.

Repeating amounts to a vendor. The same $1,850 to the same name on the first of every month is rent. The same $412.16 every month is a loan payment or a lease, and it belongs to the sub-ledger with the interest split out.

Checks to sister entities. Coded to the intercompany account, with the same check booked as a receipt on the other entity's books so the due-to and due-from balances tie. If the entity holding the building charges rent, it's rent expense here and rent income there.

Checks to the owner in odd amounts. Usually reimbursements for something bought personally. These need the receipt, and the question goes on the batched list.

Each rule is written once and applied to every check that fits it. For the restaurant, rules and roster matching coded about ninety percent of the 700 checks without a person touching them.

The exception queue and what a human still decides

The remaining ten percent is where the bookkeeper's time goes, and it's the right ten percent. Checks where the handwriting was illegible even after a second read. Checks to a name that matched nobody on the roster: a one-time contractor, a new vendor, a refund to a customer. Checks to an employee for an amount that doesn't look like a tip payout.

The queue shows each check image next to its best guesses, and the bookkeeper decides. Each decision can become a new rule or a new roster entry, so the second year of the same client has a smaller queue than the first. The batched question list to the owner contains only what the bookkeeper couldn't resolve, with the images attached, so the owner answers "that's the new hood cleaner" once instead of being asked about 700 checks.

Nothing is posted without a person having seen either the rule that coded it or the check itself. Software reading handwriting is a reviewer, not an authority.

The restaurant example: nearly 700 checks in one year

The client: a single restaurant, all of 2025 untouched, roughly 2,500 ledger lines, nearly 700 of them paper checks. The owner paid tip-outs, several vendors, the landlord, and himself by check.

The sequence: statement import tied every month of the operating account to the bank's PDF first, so every check existed in the ledger before any was categorized. Then the roster was built from the payroll provider's employee list, the prior-year 1099 file, and the ownership chart. Check images were pulled and read, payees were matched, and rules coded the tip payouts, the rent, the draws, and the recurring vendors. The exception queue came to under seventy checks, which one bookkeeper cleared in an afternoon. The owner got one question list with the unmatched images attached.

Result: every coded check had a payee and an account, tip payouts were separated from wages so the prime cost calculation was right, and the year closed in a fraction of the staff time a manual read would have taken. Alongside three sister restaurants, all four years of books closed in under ten hours of staff time combined. The full sequence is in our guide to running a cleanup in the right order.

Where the platform comes in

Woven is our product, and check-image matching is one of the pieces we built for exactly this client. It reads the bank's check images, fuzzy-matches the payee against the client's payroll roster, owners, vendors, and linked entities, codes by rule, and puts only the unmatched checks in front of a bookkeeper with the image beside the guess. Every decision can become a rule, and the questions go to the owner as one list through the client portal. Identifying information is redacted before any image leaves the firm's environment, and every AI step is verified by a person before it posts. To see the exception queue on a real check-heavy file, book a demo.