Batch check processing groups many paper checks into a single scanned run so a government office can capture, match, reconcile, and post them together instead of one at a time. A check scanner reads each item, software matches it to the right receipt or invoice, the batch is balanced against a control total, and only then is it posted to the general ledger and prepared for deposit.

‍

Front counters take walk-in and mailed payments all day. Back-office teams also handle stacks of checks that arrive by mail, in a lockbox, or from other departments. Processing those checks individually is slow and error-prone. Batch processing exists to move volume efficiently while keeping an audit trail. Teller Government Cashiering handles this workflow as a core back-office function, and the mechanics below apply broadly across purpose-built government cashiering systems.

‍

‍

What is a check batch, and why process checks in groups?

‍

A batch is a defined set of checks handled as one unit with a single control total. The control total is the expected sum of every check in the group, established before scanning from a calculator tape, a deposit slip, or a departmental transmittal. Everything downstream reconciles back to that number.

‍

Grouping checks serves three purposes at once:

‍

• Throughput. A feed-through scanner captures dozens or hundreds of items in a single pass rather than keying each one.
• Control. One control total per batch makes it obvious when captured items do not sum to what was expected.
• Traceability. A batch identifier ties every check, image, and receipt together, so an auditor can follow a deposit back to its source items.

‍

The control total is the anchor. If the scanned batch does not equal it, something is missing, doubled, or misread, and the batch cannot post until that is resolved.

‍

‍

Where does the check scanner fit in the workflow?

‍

The scanner sits at the capture step, after checks are gathered and endorsed but before matching and posting. Two common scanner types show up in government offices:

‍

• Single-feed scanners at a front counter, used when a cashier takes one check as part of a live transaction.
• Feed-through (multi-check) scanners in the back office, built to run a stack of mailed or lockbox checks quickly.

‍

As each check passes through, the scanner reads the MICR line at the bottom, which encodes the routing number, account number, and check number. It captures a front and back image and, on many devices, an amount that staff confirm or key. The cashiering software receives all of that and creates a line item for the check inside the open batch. Purpose-built systems certify against common scanner models so that images, MICR data, and amounts flow into the batch without manual re-entry.

‍

‍

How are checks matched to receipts and invoices?

‍

Capturing a check is only half the job. The payment still has to be applied to the correct obligation, and this is where remittance matching happens. A check might pay a property tax bill, a utility account, a permit fee, or several items at once.

‍

Matching generally works in one of a few ways:

‍

1. By reference number. The remittance stub or the check memo carries an account or invoice number that the operator enters or scans, and the software pulls the matching record.
2. By lookup. Staff search a name, parcel, or account and select the open invoice to apply the payment against.
3. By integration. The system queries the source of record in real time, retrieves the open balance from an ERP or a tax, utility, or permitting system, and applies the receipt back to accounts receivable.

‍

This is where integration breadth matters. Teller runs in production with 96+ third-party integrations, including major government ERPs and billing platforms, so a single check can pull invoice data from the source system and post the receipt back to A/R without leaving the cashiering screen. When a check pays more than one item, the amount is split across the matched invoices, and the split has to sum back to the check amount before the item is considered complete.

‍

‍

How does a batch reconcile against captured receipts?

‍

Reconciliation is the checkpoint between capture and posting. The system compares the sum of all captured items in the batch against the control total set at the start. Three outcomes are possible:

‍

‍

Beyond the pure math, a review step surfaces items that need human attention: checks the scanner could not read cleanly, amounts flagged as suspect, or payments that did not match an open invoice. Nothing posts to the ledger while the batch is out of balance or while unresolved exceptions remain.

‍

‍

How are errors corrected before posting?

‍

Correction happens inside the open batch, before anything reaches the general ledger, which keeps the audit trail clean. Common corrections include:

‍

• Rescanning a jam or misfeed. If a check is torn or fed at an angle, the MICR read may fail. The item is voided within the batch and the physical check is rescanned.
• Fixing a misread amount. If the captured amount does not match the check image, staff correct the amount against the image on screen.
• Reapplying a mismatched payment. If a check was matched to the wrong account, the application is reversed and reapplied to the correct invoice.
• Removing a duplicate. If the same check scanned twice, one line is voided so the batch total is right.

‍

Because these edits occur pre-posting, they do not require a formal void or refund against the ledger. Once a batch has posted, corrections become general-ledger events with their own audit records, which is why catching problems during reconciliation is far cleaner than catching them afterward. Role-based permissions and an activity log record who changed what, which supports later review by auditors.

‍

‍

How does a balanced batch turn into a deposit?

‍

After the batch balances and posts, two things happen in parallel. The receipts post to accounts receivable and the general ledger, closing out the obligations the checks paid. And the deposit is prepared for the bank.

‍

Deposit preparation typically produces:

‍

• A deposit total that ties back to the batch control total and the posted receipts.
• An electronic deposit file for banks that accept image-based remote deposit, so the physical checks may not need to travel to a branch.
• Deposit and distribution entries that feed the general ledger, including allocation across funds or departments when a payment covers more than one revenue source.

‍

‍

The through-line from control total to reconciled batch to posted receipts to bank deposit is what makes the process auditable. Every deposit can be traced back to specific checks, images, and applied receipts, which is exactly what a finance director or external auditor expects to see.

‍

‍

Where batch check processing fits alongside daily counter work

‍

Batch check processing runs on the same platform as live counter transactions and end-of-day cash drawer balancing, so mailed and lockbox checks are handled with the same controls and the same ledger posting as walk-in payments. For finance and treasury teams, the value is consistency: one reconciliation model, one audit trail, and one integration path back to the systems of record, whether a payment came across the counter or in an envelope.