Acumatica Cash Management — Bank Reconciliation

Bank reconciliation is where an Acumatica implementation proves whether its cash management setup was done properly. When the Cash Accounts, entry types, and clearing accounts are configured right, month-end rec is a twenty-minute matching exercise. When they are not, it is a spreadsheet-assisted archaeology dig. Having set this up for companies banking across Kenyan and regional banks — where statement formats are, let us say, diverse — here is how the pieces fit and where implementations go wrong.

The moving parts

Reconciliation in Acumatica revolves around a few objects:

• Cash Account (CA202000) — the link between a GL account and a real bank account. The critical checkbox for this topic is Requires Reconciliation; without it the account never appears on the reconciliation screen. Clearing Account designation matters too, for deposits in transit.
• Reconciliation Statements (CA302000) — where you create a statement per period, enter the bank's ending balance, and tick transactions as cleared.
• Bank statement import — the Process Bank Transactions screen (CA306000) plus an import scenario or bank feed, which brings statement lines in for auto-matching.
• Entry types — reusable definitions for bank charges, interest, and similar statement-side items, so the person reconciling can create the missing cash transaction in two clicks instead of a GL journal detour.

The manual flow, briefly

On CA302000 you create a statement for the cash account, set the statement date and the bank's ending balance, and Acumatica lists all unreconciled cash transactions up to that date — AP payments, AR receipts, cash entries, transfers. You tick what appears on the bank statement. The screen maintains the running arithmetic: reconciled balance versus statement balance, with the difference on display. When the difference is zero, you release the reconciliation, which stamps the transactions as reconciled and locks them.

The discipline that makes this work: nothing touches the bank GL account except through Cash Management documents. The moment someone posts a manual GL journal directly to the bank account, that entry exists in the ledger but not in the CA subledger, and your reconciliation screen can never see it. The fix is configuration, not vigilance — on the GL account, restrict direct posting (control account settings on recent builds make the bank account a CA-controlled account), forcing everything through cash transactions.

Bank feeds and auto-matching

For any account with real volume, manual ticking is a waste of a human. The Process Bank Transactions flow imports statement lines — via bank feeds (Plaid and similar in supported regions), OFX/QFX, or a CSV import scenario, which is what I build for most East African banks — and auto-matches them against open cash transactions.

Matching quality is configurable on the Cash Account's reconciliation settings: date tolerance in days, amount matching, reference number weighting, and payee fuzziness. My starting values, tuned per bank afterwards: ±3 days date tolerance, exact amount required, reference weight high if the bank preserves your payment references (many do not — test with a real month of data before promising anything).

Source column        -> Target field (CABankTran)
TXN_DATE             -> Tran. Date
VALUE_DATE           -> (ignored; matching uses Tran. Date)
NARRATION            -> Tran. Desc
REF_NO               -> Ext. Ref. Nbr
DEBIT / CREDIT       -> Disb. / Receipt (two columns, one signed
                        amount — normalise in the scenario formula:
                        =IIf([DEBIT]<>'', -Cdec([DEBIT]), Cdec([CREDIT])) )

Unmatched statement lines fall into two buckets: transactions Acumatica has that the bank shows differently (usually timing — cheques in transit), and bank-side items Acumatica has never heard of (charges, interest, reversed items). For the second bucket, entry types shine — the reconciler picks "Bank Charges" from a dropdown and the screen creates and releases the cash transaction with the right offset account, no accountant intervention.

The recurring failure modes

• Opening balance never agreed. If go-live cutover loaded the GL balance but not the individual uncleared cheques as CA transactions, the first reconciliation can never balance. Load uncleared items as part of cutover, always.
• Direct GL postings — covered above; lock the account down.
• Voided payments after reconciliation. A void generates a reversing cash transaction in the current period; users expect the original to "un-clear". Train for it: the reversal is a new line to reconcile, the original stays cleared.
• Duplicate statement imports. Import scenarios without a dedupe key happily load the same CSV twice. Match on Ext. Ref. Nbr plus date plus amount in the scenario, and set the bank transactions screen to flag duplicates.
• FX accounts. A USD account in a KES base-currency book reconciles in USD — the statement balance you enter is the bank's USD figure. Revaluation differences belong to the FX revaluation process, not to reconciliation; do not let anyone "plug" them on this screen.

Tying it to period close

I put bank reconciliation first on every period-close checklist, because it is the earliest reliable detector of subledger drift: un-reconcilable differences are usually mispostings that also pollute AP/AR. Release the reconciliation, file the bank statement PDF against the reconciliation record (attach it — auditors love this), and only then move down the close list.

Wrapping up

Good reconciliation is 90% setup: cash accounts flagged and locked against direct posting, uncleared items loaded at cutover, entry types for bank-side noise, deposits for batched receipts, and an import scenario tuned to your bank's actual file quality. Get those right and the monthly ritual becomes what it should be — a fast, boring confirmation that cash is where the ledger says it is.