Chapter 009: Booking Date, Value Date and Reporting Date

Section 2: Accounting Foundations for Banking · Chapter 009 of 100

A corporate treasurer phones, angry: "You received our million on Monday but only value-dated it Wednesday — that's two days of interest stolen." Operations replies: "But we booked it Monday, see?" Both are right about their own date — and wrong about the other's. Banks run on at least three dates per event, and confusing them misstates interest, breaks cut-off, and loses customer trust. This chapter defines booking, value and reporting dates, shows how they drive journals, and gives the testing logic that keeps them honest.

1. Chapter opening

Booking date is when the bank captures the entry; value date is the contractual date used for interest or agreed settlement economics; it does not prove that funds settled. The reporting date is the statement measurement date, and recognition facts determine the period. Add trade date, settlement date, authorisation and capture timestamps, and one payment carries half a dozen dates — each consumed by a different engine. This chapter maps every date, its owner, its journal effect, and the controls around backdating and float.

2. Learning objectives

By the end of this chapter you will be able to:

1. Define booking, value, trade, settlement and reporting dates and state which engine consumes each.
2. Show with journals how value date changes interest while recognition facts and cut-off controls determine period ownership.
3. Explain float: how value-date gaps create income, and where conduct boundaries sit.
4. Apply the backdating policy: window, evidence, authorisation, logging.
5. Write journal entries for FX, securities and repo transactions with correct date handling.
6. Specify date-field requirements developers must implement and testers must verify.

3. Business context

Dates are money and trust. Two days of value delay on a million at 4% is ~222 of interest moved between bank and customer (Figure 2) — immaterial once, systemic across millions of payments (float income was historically a real profit line, now heavily regulated and disclosed). For corporates, value dating decides whether payroll funding counts today; for trading, trade-vs-settlement-date accounting changes which balance sheet date shows the position; for finance, the booking/value gap population is a standing audit and supervisory sample.

4. Finance and accounting view

4.1 Journals under each date logic

Illustrative outgoing payment of 50,000: when the customer-account debit becomes a recognised liability reduction, Dr Customer deposit 50,000 / Cr Settlement payable 50,000. At external settlement, Dr Settlement payable 50,000 / Cr Settlement cash 50,000. A pre-posting instruction may instead create only a memo hold. Neither a booked instruction nor a value date proves external settlement.

Regular-way security purchase: IFRS 9 allows trade-date or settlement-date accounting for qualifying regular-way purchases/sales of financial assets, applied consistently to the relevant category. For a trade-date purchase, Dr Security / Cr Settlement payable at trade date, then clear the payable against cash at settlement. Settlement-date accounting has specific fair-value treatment between trade and settlement; it does not always mean no accounting impact.

FX spot or forward contract: a derivative within IFRS 9 is recognised when the bank becomes party to its contractual provisions and remeasured as required. The regular-way security policy is not an election to ignore an FX derivative until settlement. T+2 from Monday normally means Wednesday when both intervening days are valid settlement business days; currency calendars can change that result.

4.2 Float, and its limits

Float income arises whenever the bank holds value between debit and credit legs (payment float, cheque clearing float, FX settlement gaps). Historically material, now constrained: payment regulation increasingly mandates same-day/next-day value parity (for example SEPA value-date rules, Faster Payments immediacy, jurisdiction-specific corporate value-dating standards), and conduct supervisors treat systematic adverse value-dating as unfair practice. Finance should measure float internally and classify/disclose it under the applicable financial-reporting and conduct rules. There is no universal requirement for a separate public float-income line. Product policy should explain lawful value-dating terms.

4.3 Backdating and pre-dating controls

Legitimate backdating: late-captured events with genuine earlier value dates (weekend deals, intermediary delays) posted within a short policy window (for example, 2–5 business days), with evidence, authorisation, original linkage and reason codes. Abuse: holding periods open, cherry-picking dates to flatter results or exposures, silent edits. Controls: hard period locks, value-vs-booking gap monitoring with thresholds, dual approval beyond the window, and internal-audit sampling of the gap population every close (Figure 3). Pre-dating (future value dates) needs symmetric control — future value dates must not override recognition facts. A trade or derivative can be recognised today despite future settlement; other instructions may remain pending until their recognition conditions are met.

4.4 Product journal patterns with dates

5. Product and customer impact

Value dating is a customer promise: published cut-off times and value rules decide when salaries are spendable, when deposits earn, when FX converts. Complaints and ombudsman cases cluster here — "my statement says Monday but interest started Wednesday." Product owners should publish plain-language value rules per channel and currency, and apps should display value date alongside booking date for material transactions. Positive-value float strategies (delaying customer value while taking sender value early) are conduct-risk dynamite; design symmetric, explainable rules instead.

6. Regulatory and supervisory view

Payment instruments carry value-date regulation (timing of credit, availability of funds — scheme rules and national payment regulations vary by jurisdiction); securities settlement discipline regimes penalise fails; trade-vs-settlement accounting choices must be disclosed and consistent (IAS 39/IFRS 9 carryover requirements); and prudential reporting snapshots (FINREP quarter-ends, LCR daily points) are gamed through date manipulation often enough that supervisors specifically test period-end window-dressing (repo netting around reporting dates is a standing examination topic — Repos, Reverse Repos and Securities Lending).

7. Systems and data view

Date architecture: store every timestamp separately — event/authorisation time, capture time, booking date, value date, settlement date, posting date, period — with source-timezone normalisation and no overwriting. Engines consume explicit fields: contractual accruals use rate and value-date rules; cut-off assesses recognition facts; liquidity uses expected and actual cash settlement; reporting uses the approved accounting period and measurement date. Validation: value date within product-allowed windows, no posting-date in locked periods, gap reports (value ≠ booking beyond tolerance) auto-flagged, and holiday/currency calendars versioned (a stale calendar mis-values a whole currency's flow).

8. End to end process

A fictional cross-border payment illustrates the separate dates: instruction Monday 10:00; capture Monday 10:04; legally permitted contractual value/settlement Wednesday on the relevant currency calendars. Assume these terms mean sender interest stops Wednesday. This is not a default for all payments: local law, scheme rules, contract and actual recognition/settlement facts govern. A memo hold can reduce available funds before a booked debit; intermediaries have their own agreed legs. Record customer charge basis, unsettled items and month-end recognition evidence separately, and do not treat T+2 FX convention as a universal customer-payment value-date rule.

9. Controls and risks

10. Practical examples

Example A: quarter-end straddle. An FX forward contracted on 30 June settles on 2 July. Recognise the derivative from contract inception and measure it at 30 June under the applicable IFRS 9 treatment; settlement in July clears the relevant cash/receivable/payable legs. Test separately a qualifying regular-way security purchase under the bank's consistently applied trade-date or settlement-date policy.

Example B: 222.22 interest adjustment. A fictional corporate deposit of 1,000,000 is wrongly value-dated two days late. Under the contract's Actual/360 convention at 4%, omitted interest is 1,000,000 × 4% × 2/360 = 222.22. Check receipt timestamp, contractual conditions and applicable payment law; do not infer the entitlement from the booking date alone.

11. Diagrams

Figure 1. Booking, value and reporting dates.

Figure 2. Two days of deposit interest.

Figure 3. Controlled date corrections.

12. Tables

Table 1 — Which date each consumer reads

Table 2 — Date-field specification for developers

13. Illustrative bank case study

A reporting-date concentration is challenged. In this fictional case, short-dated transactions cluster around quarter-end and reverse shortly afterward. A control team compares daily and reporting-date exposure measures, examines contractual substance and identifies whether the accounting and prudential treatments comply with applicable rules. A genuine trade is not automatically misconduct, but transaction form does not excuse misclassification, omitted disclosures or misleading presentation.

14. BA, developer, tester and operations guidance

• BA: Capture every date per event in requirements with owner and consumer; define cut-off times, value windows and straddle handling explicitly — ambiguity here becomes production incidents.
• Developer: Persist all timestamps immutably; derive periods from calendars, never input; enforce locks server-side; emit gap metrics for monitoring.
• Tester: Build a date-matrix suite: same-day, T+1/T+2, weekend/holiday capture, quarter straddles, backdated-within-window, backdated-beyond-window, future-dated, timezone edges.
• Operations: Publish cut-off and value rules per channel/currency where customers can find them; staff the value-date helpdesk with people who understand Figure 2's arithmetic.

15. Common mistakes

1. Using booking date for interest calculations (value date owns economics).
2. Assigning a reporting period solely from booking or value date rather than the recognition facts.
3. Failing to monitor float or apply the required classification and disclosure; a separate public line is not universally required.
4. Accepting "the system defaulted the value date" as an explanation.
5. Testing only happy-path same-day scenarios.

16. Key takeaways

1. Booking records processing; value date drives contractual interest where applicable; settlement records transfer completion; the reporting date fixes the statement measurement point.
2. Value-date gaps move real money at scale — measure float, publish rules, stay symmetric.
3. Trade-vs-settlement accounting must be consistent and disclosed, especially across period-ends.
4. Backdating needs windows, evidence, approval and logs — everything else is blocked.
5. Store every timestamp; derive periods; lock the past.

17. References and verification notes

• IFRS Foundation: IAS 10: adjusting events evidence conditions at the reporting date; non-adjusting events concern later conditions and material ones require disclosure.

• IFRS Foundation: IFRS 9: classification depends on business model and contractual cash flows; initial recognition and directly attributable costs follow IFRS 9. This is the IFRS track, not US GAAP CECL.

• IFRS trade-vs-settlement-date accounting requirements (applied consistently by category) and IAS 10 events-after-reporting-period rules; US GAAP equivalents differ in detail — verify the applicable framework.

• Payment value/availability timing (SEPA, Faster Payments, UPI and FedNow scheme rules; SWIFT gpi is a messaging/tracking service, not a universal settlement or value-date rule) and settlement discipline regimes are scheme- and jurisdiction-specific; confirm current rules before product or control design.

• Figures are fictional training simplifications; day-count and calendar conventions are contract-specific.