Booking Date

Overview

Booking Date indicates when a transaction becomes recorded in an accounting system or account statement. A payment initiated late in the day can be processed on one date and booked on the next, especially across weekends, cut-off times, or time zones.

The concept differs from Processing Date , which identifies when an operational system handled the instruction. It can also differ from final settlement or the date the beneficiary can use the funds.

Accounting systems may derive the booking or general-ledger date from the payment date, invoice date, receipt date, clearing date, or the first open accounting period. The configured rule should be documented and applied consistently.

Reconciliation should preserve all relevant dates in the Transaction Record rather than overwriting one with another. Different dates answer different questions about customer action, operational handling, accounting recognition, and cash availability.

Period-end controls should review transactions booked after a cut-off but economically related to the prior period. Adjustments or accruals should follow accounting policy rather than informal date changes. Audit reports need the original event time and every system-assigned date.

Date controls should be consistent across subledger and general ledger. If a payment is booked in one period while its fee or settlement is booked in another, temporary reconciliation differences can appear. Finance teams should understand whether the difference is expected timing or an error. Backdated and future-dated entries need restricted permissions, open-period validation, and a clear reason in the audit trail.

Statement and ledger exports should expose the booking date as a distinct field instead of using one generic transaction date. This supports reliable period and timing reconciliation.