The bank statement shows a $500 debit. The ledger has two supplier payments for $500, one to a cleaning contractor and one to a parts supplier. A rule that matches on amount clears the first one it finds. If that was the wrong one, the real payment sits on the outstanding list for months, and someone eventually voids a check that was already cashed.
Bank reconciliation is a good candidate for automation because most lines are boring. The work is in the lines that aren’t: set rules by the evidence you actually have, leave the ambiguous lines for a person, and finish the reconciliation once matching is done.
What a finished reconciliation proves
Matching is a step, not the result. The result is a statement that explains why the bank balance and the book balance differ at the same cutoff, with every difference supported.
Save the account, currency, statement end date, ending bank balance, and book balance. Match transactions within that scope. Then adjust each side:
- Bank side: add deposits in transit, subtract outstanding payments.
- Book side: record items the bank knows about and the books don’t yet (fees, interest, returned payments), with approved entries.
Illustrative example: one outstanding payment
The statement ends at $20,000. The books show $18,800. AP recorded a $1,200 supplier payment on the last day of the month that clears two days later.
Adjusted bank balance: $20,000 − $1,200 = $18,800, which equals the book balance. The difference is explained without another entry. The following statement confirms the payment cleared, but the month-end reconciliation still shows it as outstanding at cutoff. Keep its clearance date separate from the close date.
In NetSuite, matching or clearing transactions comes before reconciling the account statement, where the reviewer checks the statement end date and balance (Oracle’s bank statement reconciliation documentation).
Prepare the exports before matching
A flipped sign or a double-imported file will produce bad matches no rule can fix. Before any rule runs:
- Export the statement and ledger for the same bank account, currency, and cutoff. Keep the original files so a reviewer can trace any match back to both.
- Check signs against one known deposit and one known withdrawal. If one export uses separate debit and credit columns, confirm the importer reads them correctly.
- Compare row counts and totals with the source exports. Check that no bank line was imported twice.
- Load the prior period’s unresolved items. They are part of this period’s reconciliation.
Set matching rules by the evidence available
Not every match deserves the same confidence. Decide in advance what the tool may accept on its own.
| Situation | Approach |
|---|---|
| Same account, reference, currency, and amount identify exactly one transaction | Automatic match under a documented rule |
| Abbreviated statement description, or dates differ by a day or two | Suggested match, with both records visible to a reviewer |
| Several candidates look alike, or one deposit covers several receipts | Manual review using the remittance or deposit record |
| No ledger transaction explains the bank line | Exception with an owner and a next step |
A practical way to configure this is in tiers, run in order:
- Exact: reference number (check number, payment ID, wire reference) plus amount plus account. Auto-match.
- Close: amount plus counterparty plus a date window you choose deliberately (for example, the number of days your checks and ACH payments typically take to clear). Suggest; don’t auto-accept.
- Grouped: one bank line to many ledger lines (a deposit of several receipts, a processor payout), or many to one. Suggest only when the components sum exactly.
- Everything else: exception queue.
The equal-amount case needs explicit handling. Microsoft documents that Dynamics 365 Finance can use the first transaction meeting a rule’s criteria by default, and provides a setting that requires manual matching when more than one transaction matches on amount (Microsoft’s bank matching rules documentation). Turn that kind of setting on, and test it with two same-amount transactions before trusting any rule that looked reliable on clean data. NetSuite similarly describes reviewing suggested matches and resolving items that require manual action before reconciling the statement (Oracle’s Matching Bank Data documentation).
Whatever the tool, a reviewer must be able to find both source rows for any match and undo a mistaken one.
Explain what is left
| Unmatched item | Evidence to look for |
|---|---|
| Two ledger entries for the same amount | Reference, counterparty, and which payment actually cleared |
| One net processor deposit | Gross receipts, fees, and refunds on the settlement report |
| Transfer between company accounts | Both accounts and the direction of each entry |
| Payment posted but not cleared | Whether it cleared after cutoff or needs investigation |
| Bank fee with no book entry | Fee detail and who approves the entry |
| Returned customer payment | Bank reversal, original receipt, invoice balance after correction |
Keep a reason, owner, and review date with every unresolved item. Book-side adjustments need approved entries with support. Illustrative entries:
| Item | Debit | Credit |
|---|---|---|
| $45 monthly bank fee | Bank fees $45 | Cash $45 |
| $3,200 customer payment returned | Accounts receivable $3,200 | Cash $3,200 |
The returned payment reopens the customer’s invoice, so tell AR before the next reminder cycle. Processor deposits are covered in the SaaS finance guide, and deposits that combine several customers’ receipts in the cash application guide.
Reconcile three ways: bank, cash subledger, and GL
A two-way bank-to-book reconciliation can hide a posting problem. For a full cash reconciliation, compare three records for one account and one cutoff: the bank statement (what cleared), the cash subledger (receipts and payments recorded by AP, AR, and treasury), and the GL cash account (what posted). Compare each pair so you see where a difference first appears.
- Bank to cash transactions. Match cleared lines by reference, currency, and amount. List outstanding payments and deposits in transit. Identify bank-only items.
- Cash transactions to GL. Trace the entries for the same account and period. Look for entries unposted, posted to another account, or reversed.
- Ending balances. Compare the bank balance after timing adjustments with the book balance after authorized corrections.
Illustrative example: a difference that stays open
The bank shows $50,000. The GL shows $48,000. A $1,800 payment posted in the GL hasn’t cleared. The bank also deducted a $200 fee that isn’t recorded.
- Adjusted bank: $50,000 − $1,800 = $48,200
- Adjusted GL: $48,000 − $200 = $47,800
- Unexplained: $48,200 − $47,800 = $400
Don’t plug the $400. Keep it open with an owner and look for another item: a deposit posted to the wrong cash account, a transposed amount, a payment voided in the subledger but not reversed in the GL.
Oracle Fusion Cash Management documents a Cash to General Ledger Reconciliation Report that lists unreconciled statement transactions and GL entries for a bank account and period (Oracle’s cash management reports). Use reports like that to find candidates, then check the underlying records before changing the books.
Carry items forward until evidence clears them
Start each reconciliation with the prior period’s open list. Mark an item cleared only when the new statement supports it. If a payment was canceled or a receipt reversed, trace the correction instead of dropping the line. An outstanding check that stays open well past your normal clearing time needs investigation: it may be lost, stale, or never sent. Your unclaimed-property obligations for old checks vary by jurisdiction, so confirm handling with counsel.
Test a tool on a period you already closed
Take a statement your team already reconciled and signed. Run the proposed rules or AI-assisted matching on the same bank and ledger exports. Include, at minimum, an equal-amount pair, a grouped deposit, an item that clears after cutoff, and a fee missing from the books. For each disagreement with the signed result, record whether the tool made a wrong match, missed a good one, or correctly left the item open.
Measure the minutes spent confirming matches, finding evidence, and correcting errors. A high match rate can coexist with a material difference. Then run two consecutive statements to check that matches in the second don’t disturb the first, and that carried items clear properly.
To try this on sample data, the bank reconciliation tool compares bank and book CSVs in your browser and lists suggested pairs and unmatched rows. Check date ranges and signs first, and finish the reconciliation from the statement balances and carryforward list.
What goes wrong
| Symptom | Likely cause |
|---|---|
| Old outstanding payment that the vendor says was paid | Amount-only rule cleared the wrong same-amount payment |
| Difference appears after matching looked complete | Duplicate bank import, or a sign flipped in one export |
| Bank and subledger agree, GL doesn’t | Entry posted to another account, or unposted batch |
| Prior-period item disappears | Dropped from the list instead of cleared with evidence |
| Reconciliation balances with a round “adjustment” | A plug where an investigation should be |
Before you let a rule auto-match
- Test it against two same-amount payments and confirm both go to review
- Load the prior period’s open items before the first rule runs
- Have the reviewer sign the adjusted balances, not the match rate
Bank reconciliation is step 3 in the month-end close sequence. For the GL control accounts that sit behind it, see intercompany and GL reconciliation.