How to test community bank teller-to-ledger workflows

Community bank teller-to-ledger testing verifies that a branch transaction entered by a teller produces the correct customer account movement, teller cash position and accounting entries across the bank’s systems. It checks the complete path from transaction capture through posting and reconciliation, including rejected, retried or reversed transactions and any delay between operational posting and general ledger updates.

Map the teller-to-ledger workflow

Start by identifying the systems and events in scope. A typical workflow passes from the teller application to a core banking system, which updates the customer account record and creates accounting entries. Those entries may reach the general ledger (GL) immediately or through an interface, queue or scheduled process. A branch cash management component may also track the teller’s drawer separately.

Confirm the bank’s posting rules before writing expected results. These can depend on transaction type, account product, cash denomination, branch, currency, business date and configured accounting mappings. Establish whether the GL is expected to show each transaction or a summarised posting, and when that posting should be available.

For each scenario, record the starting customer balance, teller drawer balance, relevant branch cash account and GL balances. Use controlled test accounts and a known business date. Ensure the environment has the intended product configuration and interface version; configuration differences can change posting behaviour and produce misleading failures.

Test the transaction and its accounting effects

Exercise the teller journey through the application, including authentication, customer and account selection, transaction entry, validation and confirmation. Check that the displayed result agrees with the transaction record and that the transaction has a traceable reference. Where supported, use service responses, posting events and audit records as additional evidence. A screen message alone does not prove that downstream posting completed.

Assert each relevant outcome against the bank’s approved rules:

• The customer account has the correct debit or credit, amount, currency, value date and resulting balance.
• The teller drawer changes by the expected cash amount, and the teller’s transaction history contains the transaction once.
• Accounting entries use the correct accounts, branch or cost centre, currency and posting date. Debits and credits must balance for the applicable accounting unit.
• Any expected interface or batch processing completes, and the resulting GL entries can be traced back to the source transaction or agreed summary.

A cash deposit illustrates the checks. If a customer deposits 200 in the account’s currency, and the bank’s rules treat the deposit as an increase to a deposit liability, the accounting entry commonly debits the branch cash asset and credits the customer deposit liability. Verify the customer balance increase, teller drawer increase, and the mapped accounting entries. Confirm the bank’s configured treatment and any aggregation rules rather than assuming every implementation posts individual entries in the same way.

Cover failures, retries and reversals

Test invalid accounts, unauthorised transaction types, exceeded limits and unavailable downstream services. A rejected transaction should follow the bank’s defined response: for example, it may leave balances and accounting entries unchanged while recording an appropriate audit event. For timeouts, determine whether the transaction committed before the response was lost. Retry behaviour should not create a second customer movement or duplicate GL posting.

Exercise reversal and correction workflows separately. Verify that a reversal references the original transaction and creates the accounting effects required by policy. Check both transactions in the audit history, the final account and drawer positions, and the GL outcome. A reversal is usually a new compensating event, so testing only the final balance can miss incorrect or missing history.

Reconcile and diagnose results

Reconcile by transaction reference where entries are individual, or by the bank’s defined control totals where postings are summarised. Compare source transaction counts and amounts with downstream records, and investigate unmatched, duplicated or differently dated entries. For asynchronous flows, poll or wait for the documented processing condition, then check that the event was consumed and posted. A fixed delay can hide timing defects or create flaky tests.

Keep evidence that links the teller action to its account posting and accounting result. If a test fails, identify the first boundary where expected data changes: teller capture, core posting, interface delivery, GL mapping or reconciliation. This distinction helps separate an application defect from stale test data, configuration drift or a delayed dependency.

A practical test case

Given an open branch, an authorised teller, a funded cash drawer and a test customer account with a known opening balance, enter a cash deposit for 200 and confirm it. Verify one transaction reference, a 200 increase to the customer balance and drawer, and balanced accounting entries using the configured cash and deposit accounts. Then reconcile the transaction to the GL within the applicable posting window. Repeat with a simulated response timeout and confirm that retrying the same request does not post the deposit twice.