Account reconciliation ledger vs bank balance means comparing internal and external cash records at the same cut-off, then explaining every difference with matched transactions, timing items or documented corrections.

The useful comparison is not “whatever the API returns now” against yesterday’s bank statement. It is a ledger balance and a bank-reported balance for the same account, currency, timestamp and transaction state. That alignment turns a vague cash difference into a list of payments, fees, returns or timing items your operations team can resolve.

The two balances being compared

An application ledger is the platform’s internal record of who owns money and why it moved. A bank or payment provider reports the cash it holds for the platform. Account reconciliation checks that these two records describe the same funds.

Modern Treasury’s documentation frames the comparison as two balances at the same point in time: a Ledger Account balance and an Internal Account balance representing a bank- or vendor-reported account. The goal is to confirm that every movement through the external account has been tracked and attributed internally.

That sounds simple, but each side can expose several balances. A ledger may have pending, posted and available balances. A processor may expose pending and available funds. A bank file may carry opening, closing, intraday and prior-day figures.

Use a single rule for every reconciliation run:

Field Ledger side Bank or provider side
Account One control or settlement account The matching bank or provider account
Currency One currency The same currency
Cut-off Exact timestamp and timezone The bank’s reporting timestamp and timezone
State Usually posted entries Settled or reported cash at that cut-off
Evidence Ledger transaction IDs Bank transaction, payout or balance-report IDs

The choice of posted entries matters. Pending entries represent expected movements that may still fail or change. For more detail, see pending, posted and available ledger balances.

Why a correct system can still show a variance

A variance is not automatically a loss. It often starts as a timing difference.

One side may record a payment when it is initiated while the other records it when the bank settles it. Card fees may be netted from a payout. An ACH return can arrive after the original credit. A bank may post an adjustment without the identifier your application expected. Timezone boundaries can place the same movement on different reporting days.

Common causes include:

  • a payment that has posted in the ledger but has not settled at the bank;
  • a bank transaction that has no matching ledger entry;
  • fees or reserves deducted from a processor payout;
  • a return, reversal or chargeback posted after the original payment;
  • duplicate ingestion of a bank transaction or webhook;
  • different day boundaries or currencies on the two sides;
  • a manual bank movement that bypassed the platform’s normal payment flow.

The response should depend on the cause. A genuine timing item may be carried until the next run. A missing ledger entry needs a supported transaction. A duplicate needs to be reversed without deleting the audit trail.

Build the reconciliation around a fixed cut-off

Choose the reporting cut-off before matching transactions. Modern Treasury says its reconciliation view aligns balances to the bank’s timetable and timezone. Its bank side can use real-time, intraday or previous-day balance reports, while its ledger side uses the posted balance for the corresponding period.

For a daily process, define:

  1. the bank or provider account;
  2. the ledger account mapped to it;
  3. the timezone and cut-off;
  4. the balance type on each side;
  5. the set of transactions included in the period.

Store those choices with the run. Otherwise two people can repeat the same date using different cut-offs and produce different answers.

Stripe illustrates why the balance type must be explicit. Its Balance object separates available funds from pending funds, and its balance transactions represent the movements that enter or leave the Stripe account balance. Comparing a platform ledger’s posted cash to Stripe’s pending total would mix two states.

Match transactions before writing adjustments

Start with identifiers that survive across systems: payout ID, bank reference, provider transaction ID, amount, currency and effective date. Exact identifier matching is safer than pairing only by amount.

Then classify the unmatched items:

  • In transit: recorded internally but not yet reported externally.
  • Unrecorded external item: reported by the bank or provider but missing from the ledger.
  • Amount difference: both sides refer to the same movement but fees, FX or netting changed the amount.
  • Duplicate: the same external movement was recorded more than once.
  • Unknown: insufficient evidence to post a correction.

Do not create a balancing entry merely to force the variance to zero. A correction should link to the source transaction and state why it exists. If the cause is not known, keep it in an exception queue with ownership and an ageing clock.

Modern Treasury’s workflow follows that principle: reported transactions that have not been added to the ledger can be reviewed and then represented by a Ledger Transaction and an Expected Payment. The variance moves closer to zero because the missing economic event is recorded, not because the balance was overwritten.

Preserve an auditable correction path

A ledger correction should be additive. Posted entries should not be silently edited or deleted. Write a reversing entry when an earlier posted entry is wrong, then post the corrected transaction with references to the original.

This keeps three questions answerable:

  • What did the system believe at the time?
  • What new evidence changed that view?
  • Which entry corrected the balance?

That model also supports ledger as a service, where a product team relies on infrastructure to preserve transaction history while the application owns the business reason for each movement.

Operational controls for a reliable process

Run reconciliation often enough that the exception set stays small. Daily is common for settlement accounts; higher-risk or high-volume flows may need intraday checks. Frequency does not replace clear cut-offs.

Useful controls include:

  • immutable source files or API snapshots for each run;
  • idempotent ingestion so the same bank item cannot be booked twice;
  • account and currency mapping reviewed before launch;
  • an exception queue with owner, reason and age;
  • approval for manual adjustments above a threshold;
  • monitoring for missing files, stale balances and unresolved variances;
  • a signed-off result that records both balances and the remaining difference.

The final status should separate timing items from unexplained items. A zero arithmetic difference can still hide bad matching if unrelated movements offset each other.