How Bank Reconciliation Automation Handles Unmatched Transactions

Bank reconciliation automation should keep unmatched transactions visible and explain why they did not clear. A missing feed, timing difference, ambiguous match, bank charge or posting error needs a different next step. The system proposes the match or investigation; the finance team decides the accounting treatment and approves the reconciliation.

A high match rate is only part of the answer. If the remaining items have no owner or the software clears two unrelated transactions because their amounts agree, the dashboard can improve while the reconciliation becomes less reliable.

Timeliness matters for a legal reason as well. Under UCC section 4-406, a customer must examine bank statements with reasonable promptness to find unauthorized payments, and a customer who does not discover and report an unauthorized signature or alteration within one year after the statement is made available is precluded from asserting it against the bank. Your deposit agreement may set its own reporting terms, so check it. Checks remain the most exposed item: they were the payment method most often targeted by fraud in 2025, cited by 58% of organizations in the AFP's 2026 survey.

Explore an illustrative finance exception and review workflow.

Check the input before investigating the transaction

Confirm the bank account, entity, currency and statement period. Check whether the imported opening and closing balances and transaction totals agree with the source statement. Record the last successful import and any missing dates. A line absent from an incomplete feed is not yet evidence of a missing transaction.

Microsoft’s Dynamics 365 Finance documentation describes statement imports, configurable matching rules and side-by-side review. Inspect the equivalent functions in your existing ledger before adding a separate reconciliation product. A supported statement import can be appropriate; a live connection is not automatically a better control.

Give unmatched items a reason and a destination

This exception method is a proposed reconciliation design, not a measured implementation or an accounting standard.

Every item should retain its original age, source references, current owner, last action and supporting evidence. Passing it to another department must not restart its age. “Reviewed” and “resolved” should be distinct states.

Reconcile a net settlement without plugging the difference

Illustrative example: the bank shows a $9,700 processor deposit and the ledger shows $10,000 of related sales. A settlement report identifies $250 in fees and a $50 refund. These are fictional amounts.

The arithmetic is $10,000 − $250 − $50 = $9,700. That is a candidate explanation, not enough evidence on its own. The reconciler still verifies that the settlement report covers the same merchant account, sales batch and period, and that the fees and refund have not already been recorded elsewhere.

If the components are substantiated, the accounting owner follows the approved posting policy and links the resulting entries to the settlement. If the report is missing or the dates do not agree, the item remains open. Do not create a miscellaneous expense simply to make the bank total match.

The same care applies to grouping several ledger lines into one bank line. Preserve the full group membership. A later reversal or adjustment should make the affected match available for review rather than disappearing inside a net amount.

Make matching rules inspectable

Start with narrow rules based on stable identifiers and the company’s documented practices. Record which rule cleared each item, its version and the source records used. Equal amounts alone should not settle an ambiguous match. Date windows, tolerances and grouping rules need explicit approval appropriate to the account.

Where a tool suggests a match using history or document interpretation, show the evidence and competing candidates. Test suggestions on known ambiguous cases before allowing automatic clearance. Keep match permissions distinct from permissions to create journal entries.

Import retries also need control. Retain file and transaction identifiers, detect records already loaded and make failed imports visible. Re-running the same statement must not double the transaction population.

What the reviewer should see at sign-off

Provide the source balances, matched population, remaining differences, supporting schedules, approved adjustments and aged items carried forward under policy. Show when the source last changed. A new transaction or revised entry after review should trigger the defined reopening process.

For a pilot, compare manual preparation effort, false matches, unexplained amounts, oldest open items and reviewer time using the same accounts and periods. Include a stale feed, duplicate import, reversal and ambiguous equal-amount pair in testing. A narrower correct rule is preferable to a wider rule that hides its mistakes.

This work may support the month-end close, but a faster reconciliation does not remove delays elsewhere. Use the finance operations overview to keep the improvement connected to the complete reporting process.