End-of-Day Treasury Reconciliation: A Practical Guide

A treasury dashboard can show a healthy cash balance while an operating account is short of funds. A transfer can appear as a debit at one bank before its credit appears at another. An overnight import can finish successfully while an entire account is missing from the morning cash position.

These are different problems. Treating all of them as an “end-of-day batch issue” makes them harder to diagnose.

End-of-day (EOD) reconciliation brings bank-reported activity and internal records into agreement for a defined reporting period. Its value comes from establishing what is complete, what matches, and what still needs investigation. Faster data can improve that process, but only if the controls keep pace.

This article examines the architecture from a corporate treasury perspective. The workflows and numerical examples are illustrative; bank-specific implementations and service agreements determine the actual operating rules.

Four processes that run on different clocks

An overnight workflow may involve all four of the following processes, but they serve distinct purposes.

Process	The question it answers
Bank reporting	What balances and entries does the bank report for this account and period?
Reconciliation	How do those entries compare with internal records, and which differences remain?
Cash concentration	What funds should move between accounts to meet a liquidity policy?
Payment settlement	When does a transfer settle under the relevant payment system’s rules?

A statement file reports activity; it does not execute a sweep. A sweep instruction initiates a movement; it does not prove that both accounts have recorded it. A reconciled bank balance also does not, by itself, establish how much cash is available for immediate use.

The reporting period matters as much as the delivery time. A file received on Tuesday morning may describe Monday’s activity. A transaction received during the day may still be pending. Any consolidated cash view needs to retain those distinctions rather than presenting every observation as equally current and final.

Build the EOD pipeline around completeness

A useful reference architecture is:

The important design decision is where to stop the workflow when evidence is incomplete. A successful file transfer should establish receipt. It should not automatically certify the cash position.

1. Know what should have arrived

Maintain an inventory of expected accounts, currencies, reporting calendars, and delivery times. Compare received statements with that inventory before declaring the day’s reporting complete.

Track the bank’s reporting date separately from the arrival timestamp. Account for holidays and agreed treatment of inactive accounts. A missing statement and a valid statement with no activity require different responses.

If an expected account is absent, flag the position as incomplete. Carrying forward its last known balance may be useful operationally, but that balance needs a visible age and status.

2. Preserve evidence before transforming it

Archive the original file with its sender, receipt time, file identifier, and content hash. Validate the delivery channel and any signatures or integrity checks required by the bank’s specification.

A locally calculated hash helps detect an identical file and supports later replay. It does not independently authenticate the sender.

Prevent both duplicate ingestion and duplicate posting. The same file can be delivered twice; the same transaction can also appear through different channels. Conversely, two legitimate transactions can share an amount and date, so those fields alone make a poor duplicate key.

3. Normalize without losing meaning

Translate bank-specific records into a common model while retaining their original identifiers and source references. At minimum, preserve:

• Account, legal entity, currency, and reporting period.
• Statement identifier and sequence or page information, where supplied.
• Amount, debit or credit direction, and transaction status.
• Booking date, value date, and available timestamps.
• Bank references, payment identifiers, and remittance information.
• Balance type, as-of time, and a link to the source record.

Booking date and value date answer different questions. One concerns when an entry is recorded; the other concerns its value treatment. Flattening them into a single “transaction date” removes information needed to investigate timing and interest differences.

4. Validate balances before matching transactions

For a complete booked-activity statement, using a consistent sign convention and accounting for all booked entries, the basic check is:

Opening booked balance
+ booked credits
- booked debits
= closing booked balance

Apply this check per account, currency, and reporting period. Do not substitute an available balance into a booked-balance equation. Validate statement pagination, control totals, and continuity with the previous period where the format and bank implementation support them.

An unexplained difference should hold that account for investigation. Matching transactions against incomplete or misinterpreted statement data can produce a convincing reconciliation with the wrong foundation.

5. Make matching decisions explainable

Start with strong identifiers, then apply documented combinations of reference, amount, currency, account, and date. Support one-to-many or many-to-one matching where the bank reports aggregated payments or net settlements.

Tolerances need a reason. A small amount difference might represent a fee, an FX conversion, or an error. Automatically clearing it without classification hides the distinction.

Record the rule and evidence behind each match. Send ambiguous candidates to review, and retain the history of manual adjustments. The desired outcome is a defensible reconciliation with a manageable exception queue.

File format affects the work, but does not guarantee the result

BAI2, MT940, and ISO 20022 camt messages can all support treasury reporting. The practical question is what information each bank actually supplies, how consistently it supplies it, and what the receiving system preserves.

BAI2: structured records with bank-specific interpretation

BAI2 organizes reporting into file, group, account, and transaction records. Continuation records carry additional content, and trailers provide control totals. It is not exclusively an overnight format: Huntington documents both prior-day and current-day delivery. Huntington’s BAI2 implementation guide

Transaction codes need careful mapping. Goldman Sachs, for example, documents 175 for checks deposited, 475 for checks paid, 195 for incoming wires, and 495 for outgoing wires. Its guide also assigns some codes to several transaction types, illustrating why a code alone may not describe the full business event. Goldman Sachs BAI code reference

MT940: statements with structured tags and variable narrative

MT940 is a SWIFT customer statement message containing booked account entries. Its tagged structure carries balances and transaction information, but the useful detail available for matching depends on the sending bank’s implementation. Goldman Sachs SWIFT reporting guide

Before writing matching rules, inspect real samples from each bank. Check how references, fees, reversals, and remittance details appear, including continuation and narrative fields.

camt: richer structure that still needs implementation checks

ISO 20022 distinguishes camt.052 account reports, camt.053 statements, and camt.054 debit/credit notifications. These messages support different reporting needs; the message name alone does not establish delivery frequency. SIX cash-management message glossary

Structured identifiers and transaction details give reconciliation systems more information to work with. They do not guarantee that every field is populated, that an upstream payment retained its references, or that the ERP uses the available data correctly.

Confirm the supported schema version and the bank’s implementation guide. Test the actual data before promising a higher automatic match rate.

Cash concentration needs its own controls

A zero-balance arrangement can move surplus funds from subsidiary accounts to a concentration account and, where configured, fund deficits in the opposite direction. A target-balance arrangement retains an agreed operating amount. Oracle’s liquidity-management documentation shows how execution also depends on funding availability, priorities, limits, and partial-sweep settings.

Consider an illustrative target-balance policy with a minimum transfer size:

B = balance eligible for sweeping
T = target balance
D = positive minimum transfer amount
V = B - T

If V >= D:   transfer V to concentration
If V <= -D:  request -V from concentration
Otherwise:   make no transfer

This is a simplified policy, not a universal banking algorithm. “Eligible” must be defined by the arrangement: a ledger balance, available balance, and transferable balance may differ. Funding requests also remain subject to available cash, limits, and execution rules.

Reconcile the resulting movements separately from the instructions. Capture the expected source and destination entries, currency, amount, references, and expected completion time. One observed leg should remain an open transfer until the other leg is confirmed or the exception is resolved.

Physical concentration and notional pooling also require different treatment. Physical concentration moves funds; notional pooling can combine balances for interest purposes without moving them between the underlying accounts. Cross-entity and cross-border structures require review of the relevant legal, tax, and accounting arrangements. Bank of America on notional pooling

Settlement windows belong in the operating model

A corporate bank cutoff, a payment system deadline, and a statement-generation time are separate constraints. Combining them into one “bank closes at” timestamp creates avoidable errors.

For U.S. dollar payments, the Federal Reserve’s published Fedwire schedule specifies a 6:45 p.m. Eastern Time customer-transfer cutoff and a 7:00 p.m. cutoff for bank transfers and certain other messages, subject to stated exceptions and extensions. The funds-transfer business day starts at 9:00 p.m. ET on the preceding calendar day. Fedwire operating hours

FedACH’s published schedule distinguishes transmission deadlines from settlement times for same-day eligible forward items:

Submission deadline, ET	Scheduled settlement, ET
10:30 a.m.	1:00 p.m.
2:45 p.m.	5:00 p.m.
4:45 p.m.	6:00 p.m.

The file must be fully received by the relevant deadline. These are operator schedules; a company’s bank may require earlier submission. FedACH processing schedule

Maintain a calendar by bank, rail, currency, and jurisdiction. Store named time zones rather than fixed UTC offsets where daylight saving applies. Record the expected settlement date when an instruction is created, then investigate departures from that expectation.

Schedules checked on 14 October 2026. Operational configuration should follow current operator schedules and bank agreements.

Quantify the cost of delayed access carefully

Delayed visibility can lead a treasury team to hold larger buffers. Delayed movement can leave usable surplus in a lower-yielding account. Neither effect means that every unreconciled balance represents an investment opportunity.

A simple scenario estimates foregone interest as:

Opportunity cost
= deployable surplus
  × annual yield difference
  × delay in days / day-count basis

Suppose $150 million is genuinely surplus, earns 1%, and could otherwise earn 5% over the same period. Assume it remains in the lower-yielding account for three days, using an actual/360 convention:

$150,000,000 × (0.05 - 0.01) × 3 / 360
= $50,000

If those exact conditions recurred over 52 weekends, the annualized scenario would total $2.6 million. This is an illustrative calculation, not an observed loss or a savings forecast. The assumed rates are not current market quotes.

The estimate changes if some cash is restricted, needed for payments, unavailable for transfer, or unable to enter the alternative investment before its cutoff. Fees, taxes, credit exposure, and investment liquidity also affect the decision. Earnings credits that offset bank fees should be modeled separately from cash interest.

For a modernization proposal, measure the balance actually eligible for deployment and the delay the proposed change can remove. Earlier reporting creates financial value only when it enables an available, permitted action.

Design exceptions around the next decision

An exception queue should tell the team what evidence is missing, who owns the investigation, and when to escalate.

Missing statement. Compare delivery with the expected account inventory. Label the cash view incomplete, request the missing report, and show the age of any balance carried forward.

Duplicate or replacement file. Check identifiers and content hashes. Distinguish an exact redelivery from a corrected statement. Preserve the original version and prevent a correction from silently creating duplicate postings.

Transfer visible on only one side. Keep both expected legs linked. Check bank status and destination reporting before deciding whether the issue is settlement, reporting, or matching. A missing credit in the dashboard does not establish that cash has been lost.

Back-valued entry or reversal. Retain booking and value dates, link the correction where possible, and route affected accounting or interest calculations for review under the close policy.

Ambiguous remittance. Expose candidate matches with their evidence. Require review when several invoices fit. A high automatic match rate has little value if the system quietly clears the wrong items.

Measure reporting completeness, on-time reconciliation, exception age and value, and the proportion of matches later corrected. Break results down by bank, account, currency, and exception type. An aggregate success percentage can conceal the account that repeatedly needs intervention.

Add real-time data without double-counting the cash

Intraday reports, APIs, and webhooks can help teams detect changes before the next statement arrives. They also introduce another representation of activity that may later appear in EOD reporting.

A useful hybrid design gives those channels complementary jobs:

• Intraday data supports current cash visibility, funding decisions, and early exception detection.
• Period statements support reconciliation of reported booked activity and balances for a defined period.
• The internal ledger and close process retain approved accounting entries, adjustments, and review evidence.

Treat the incoming messages as observations of business events. Where identifiers and reporting detail permit, link a webhook, an API transaction, and a statement entry to the same underlying movement. Preserve their status history instead of booking each observation as new cash.

Design for redelivery, late messages, corrections, and gaps. Use durable identifiers where available, process repeated deliveries without repeating their financial effects, and provide a way to recover missed activity. Expose freshness by account rather than attaching a single “live” label to the entire dashboard.

Faster reporting also needs to be distinguished from faster settlement. FedNow supports around-the-clock instant payments through participating financial institutions, but access to a bank API does not itself put a payment onto that rail. Federal Reserve FedNow service overview

For an existing EOD operation, I would start with three questions: Did every expected account report? Can every material movement be traced? Can the team identify the unresolved items before the next funding decision?

Those answers reveal where modernization will help. Faster delivery is valuable when it gives treasury more time to act on a cash position it can explain and trust.