Three dates that people collapse into one
An entry has a moment it happened, a day it belongs to in the books, and a day from which it counts economically. These coincide often enough in a nine-to-five batch world that systems get built as if there were one date, and then a continuous rail pulls them apart permanently.
The event timestamp is machine truth: the instant, recorded to whatever precision you keep, in a single reference zone. It is never adjusted and it is what you order events by.
The accounting or booking date is the business day the entry falls into for the purposes of the books, the trial balance, the daily statement and every downstream report. It is a business attribute derived from the timestamp, the entity's calendar, and the rail's conventions — not a truncation of the timestamp.
The value date is the day from which the money counts for interest and availability. It can precede the accounting date, as with a back-valued correction, or follow it, as with a forward-dated instruction or an inbound item whose funds are not yet usable.
Say all three out loud early, because most of the wrong answers in this area are variations on treating the accounting date as date(timestamp).
The accounting date is assigned, and then it is a fact
The rule that assigns it is a business rule with several inputs. The entity's own calendar decides which days are business days, and calendars differ by country and often by region within one. The currency has its own calendar, because a currency's settlement days are those of its home market regardless of where you are booking. The rail contributes a cut-off, which is a scheme construct: instructions accepted after it belong to the next business day even though your system processed them today. And there is a local-versus-reference-zone question, because a payment at ten in the evening in one zone is a different calendar day in another.
Two consequences follow, and both are the difference between a design that survives and one that quietly restates history.
First, compute the accounting date once, at posting, and store it on the entry. Do not derive it at read time from the timestamp. A rule change, a calendar correction, a new public holiday added to a table, or a library upgrade that changes a zone offset will otherwise change what happened in a period that has already been reported. An accounting date recomputed on read means yesterday's balance sheet is a function of today's configuration, which is the most insidious form of unreproducible reporting there is.
Second, store the rule version alongside it, or at least the calendar and cut-off configuration in force. When someone asks why a payment that arrived at 23:58 booked to the following day, the answer should be retrievable rather than reconstructed by reading the code as it stands now.
Closing a period without stopping
The instinct from batch systems is that closing means a quiet window: stop accepting, run the jobs, open the next day. On a continuous rail there is no quiet window and the customer is entitled to send a payment at four in the morning on a Sunday.
So closing becomes a lock rather than a pause. The flow continues; what changes is which accounting dates are open for posting. Closing date D means: no new entry may be assigned reporting classification D, publish a completion event for D, and capture a snapshot of exactly what D contained — most usefully the highest entry sequence included, plus the resulting balances. Everything that consumes closed data, from the customer statement to the regulatory return to the reconciliation against a counterparty statement, reads the snapshot for D rather than querying live and hoping nothing has changed.
That snapshot is the part candidates skip, and it is what makes a re-run reproducible. Months later you will be asked to reproduce a figure for D. If your report recomputes from the entry table, it will now include the back-dated correction that was posted a week after D closed, and it will disagree with the number that was filed. If it reads the snapshot, it agrees, and the correction shows up where it belongs: in the period it was posted in, flagged as relating to D.
Late and back-dated items
Once a period is locked, an entry that genuinely relates to it has to go somewhere. The pattern that works is to post it into the earliest open period with two additional attributes: the posting day it actually landed in, and the value date it economically belongs to. The entry is therefore visible in the current period, correctly dated economically, and traceable to the closed period it relates to.
Where value date differs from period classification, an interest consequence usually follows, and it is a posting rather than a re-computation. Interest accrues over a series of value-dated balances, so a credit value-dated four days ago changes the accrual for those four days; you calculate the difference and post an adjustment, leaving the original accruals untouched. This is exactly the same discipline as correcting a ledger with compensating entries instead of updates, applied to the time dimension.
Whether a customer-facing artefact is reissued or corrected on the next one varies by market and product, and it is a question to ask rather than to assume: some regimes and some products require a corrected statement, others expect the adjustment to appear as a dated line in the following period. Either way, the artefact already sent must remain reproducible.
Where this goes wrong in practice
The failure is rarely a wrong design; it is a hard-coded assumption in one component. A batch job scheduled at a fixed local hour because that was when the cut-off used to be, so the day a scheme moves its cut-off, a slice of payments is misdated and nobody notices until a counterparty reconciliation shows a systematic one-day offset. A report that filters on timestamp::date in one place and on accounting_date in another, so two reports of the same day differ by exactly the transactions between the cut-off and midnight. A holiday table maintained by hand and one country short. A service deployed in a different region whose default zone shifts the day boundary for the entries it posts.
The defence is to make the date a value on the record rather than a computation anyone can repeat differently, to have one component own the calendar and cut-off configuration, and to run a daily control that counts entries by reporting day against the rail's own reporting for the same date. A one-day offset is trivially detectable if anyone is looking for it, and almost invisible if nobody is.
The assigned posting day is a business decision recorded on the entry, not a truncation of a timestamp. Store it, store what it was closed with, and a question about last March has one answer rather than as many answers as there are ways to re-derive it.
© 2026 Preptima. Originally published at preptima.com (opens in a new tab).