Mobile agent cash reconciliation testing verifies that a microfinance bank's agent app and connected banking systems record cash movements accurately and agree with the agent's physical cash position. It checks transaction capture, posting, reversals, synchronisation and the closing balance, including situations where connectivity is interrupted or a transaction remains pending.

What mobile agent cash reconciliation testing covers

Agents may collect loan instalments or savings deposits in cash, pay out cash withdrawals, and receive or return cash float. Testing checks that each completed transaction affects the agent's expected cash position correctly and appears in the relevant transaction records. The precise rules depend on the bank's products and operating procedures.

A basic expected-balance calculation is:

closing cash = opening cash + cash received - cash paid out + cash transfers in - cash transfers out

Fees, commissions, non-cash transactions and pending transactions should be handled according to the bank's rules. For example, a commission credited to an agent's account should not be treated as physical cash unless the process actually pays it in cash. Test cases should define which transactions count towards the cash position and when they become effective.

The reconciliation may compare the app's calculated balance with an agent's declared cash count, transaction records, a branch settlement record, or a ledger posting. These are related checks with different sources of truth. A matching app balance alone does not prove that a transaction has reached the core banking system or been recorded in the correct account.

How to test the reconciliation workflow

Start with defined test data: an agent account, opening cash, product and transaction limits, customer accounts, and a known set of cash-in and cash-out transactions. Confirm the expected posting and reconciliation rules with the product owner or banking operations team. Keep the transaction date, agent session and transaction status consistent across the app, integration services and core banking test environment.

Cover normal activity and exceptions. Useful cases include a loan repayment collected in cash, a savings deposit, a customer withdrawal, a voided transaction, a reversal, a duplicate submission, and a transaction that is authorised in the app but still pending downstream. Check that each item appears once, has the correct amount and status, and affects the balance at the correct point in its lifecycle.

For offline use, interrupt connectivity after the agent records a transaction and then restore it. Verify that synchronisation preserves the original transaction details, avoids duplicate posting after a retry, and updates reconciliation status when the bank's systems acknowledge the transaction. A transaction that fails to synchronise should remain visible for investigation rather than silently disappearing from the agent's records.

When the declared cash count differs from the expected balance, verify that the system records the variance, identifies the relevant session and transactions, and follows the configured review or escalation process. Check role permissions and audit records for any adjustment, approval or session closure. A test should also confirm that a user cannot make an unexplained adjustment appear as a balanced reconciliation.

Practical example

An agent starts a session with 500 units of local currency. The agent collects 300 in cash for repayments and pays out 220 for withdrawals. There are no cash transfers or other cash movements, so the expected closing cash is 580. The agent declares a count of 570.

The test should expect a variance of 10 below the calculated balance, with the reconciliation left in the configured exception state. It should then verify that the transaction list supports investigation, the variance is stored against the correct agent session, and an authorised user can follow the bank's review process. It should not assume that the bank permits session closure or adjustment without approval; that behaviour must follow the configured rules.

Distinguishing cash and ledger reconciliation

Cash reconciliation focuses on physical cash held by an agent against recorded cash movements. Ledger reconciliation checks that financial postings balance across accounts or accounting records. They intersect when agent transactions post to the bank's subledger or general ledger, so end-to-end tests should trace representative transactions through both. A cash variance and a ledger imbalance are different defects and should be reported separately.

Useful evidence includes the opening and closing cash values, transaction identifiers and statuses, the variance calculation, downstream posting references, and any approval or adjustment history. These records help distinguish an app calculation defect from delayed synchronisation, incorrect posting rules or a genuine cash shortage.

Frequently asked questions

Can an agent reconcile cash before every transaction has synchronised?

That depends on the bank's session rules. Tests should confirm whether pending transactions block reconciliation, appear as explicit outstanding items, or are handled through another defined exception process.

How should tests cover cash in more than one currency?

Treat each currency as a separate cash position unless the bank's rules specify an approved conversion process. Verify currency-specific totals, permitted conversion rates and rounding, and ensure one currency's cash does not conceal a shortage in another.

How can test teams distinguish a cash shortage from a posting delay?

Compare the physical count and agent transaction records with transaction statuses and downstream posting references. A missing posting with a pending or failed status points to a processing issue, while a count below the expected cash position requires investigation as a cash variance.