%402x.svg)
No results.
Teller Government Cashiering processes checks either one at a time at the counter or in batches through a connected check scanner. A cashier or back-office clerk feeds physical checks into the scanner, Teller captures the MICR line and dollar amount, applies each check to the right receipt or account, and rolls the batch into the same end-of-day balancing and deposit workflow as every other tender.
The result is that a stack of paper checks becomes structured, reconcilable data without manual re-keying. Below is how that flow works, from capture to deposit.
In government finance, checks arrive in volume and from many directions: mailed-in tax payments, dropped-off utility bills, permit fees, court remittances, and internal transfers from departments that collect their own revenue. Processing these one at a time at a live counter is slow and error-prone.
Batch check processing groups many checks into a single scanning session. Instead of typing each check number, routing number, and amount by hand, a clerk runs the stack through a scanner. Teller reads each check, matches it to the correct receivable, and assembles the whole set into one deposit-ready batch. This is a common back-office pattern in treasury operations, and Teller is built around it rather than treating it as an afterthought.
A check scanner reads the MICR (Magnetic Ink Character Recognition) line printed along the bottom of every check. That line encodes the routing number, account number, and check number. When a check passes through the scanner, Teller captures:
Because the routing and account data are captured electronically, the clerk avoids the transcription errors that come with manual entry. The check image is retained alongside the transaction, which matters later for audit lookups and for resolving disputes about what was actually deposited.
A scanned check is not just a payment. It is a payment plus an image plus structured MICR data, all attached to the receipt it settled.
Capturing a check is only half the job. The check then has to be applied to whatever it is paying for. This is where Teller's integration breadth matters. When a check settles an invoice in an ERP or a bill in a utility or tax system, Teller can look up that receivable and post the payment against it in real time.
Teller is in production with 96+ third-party integrations, including major government ERPs such as Workday, Oracle, PeopleSoft, JD Edwards, NetSuite, and SAP, along with tax, utility billing, and permitting systems. A single scanned check can therefore pull the open invoice, apply the payment, and post the receipt back to accounts receivable without a clerk switching screens or re-entering data.
For payments that do not tie to a specific invoice, such as miscellaneous receipts, the clerk assigns the check to the appropriate revenue account or department. Either way, the check enters the system as a coded, categorized transaction rather than a loose piece of paper.
Once a batch is scanned and applied, it moves through the same daily workflow as the rest of a cashier's activity. The typical steps look like this:
Because Teller can feed receipt data to accounts receivable and deposit entries to a separate general ledger in the same transaction, finance teams get a clean tie-out. The checks that came in the door match the batch totals, the batch totals match the deposit, and the deposit matches what posts to the ledger.
Every scanned check carries its image and MICR data with it, and every action against it is logged. That means an auditor or clerk investigating a specific deposit can pull up the individual checks that composed it, view the images, and trace each one back to the account it settled and forward to the ledger entry it produced.
This end-to-end traceability is one of the practical reasons agencies move off manual check logs and spreadsheets. Instead of reconstructing a deposit from a handwritten tape and a bank statement, the record already exists as structured, searchable data.
Teller supports check scanners as part of its device layer, alongside receipt printers and other point-of-sale hardware. Subscriptions are typically scoped in part by the number and type of check scanners in use, since scanning volume varies widely between a small city clerk's office and a large county treasury.
For a sense of that range, Teller runs from deployments in cities with populations under 50,000 up to Santa Clara County, California, which serves a population of roughly two million and handles around 500,000 customers in tax season. A high-volume operation may run multiple scanners in parallel during peak periods, while a smaller office may share a single scanner across occasional batch runs. In both cases the workflow is the same: capture, apply, close, deposit, reconcile.
Retail point-of-sale systems are built for card-first, low-check environments. Government counters are not. Checks remain a significant share of public-sector receipts, and they arrive in bulk, tied to specific bills and funds that must reconcile precisely.
Because Teller is built for government cashiering rather than adapted from retail, batch check processing is a first-class workflow: MICR capture, image retention, real-time application to receivables, and a straight path into deposit and ledger posting. For finance and treasury teams, that means fewer keystrokes, fewer transcription errors, and a paper trail that holds up under audit.
