Ask a lending platform a simple question — what was this customer's balance on the 1st of March? — and you'll usually get a simple answer. Ask the harder version — what did we believe the balance was on the 1st of March, when we cut the statement on the 2nd? — and most systems go quiet.
That second question is the one your auditors, your complaints team and your regulator actually ask.
One timeline is not enough
A conventional ledger records one date per entry: when it was posted. But in consumer credit, two different facts matter for every event:
- Effective time — when the thing actually happened. The customer paid on the 28th of February, even if their bank was slow.
- Recorded time — when your system learned about it. The payment arrived in your ledger on the 5th of March.
Between those two dates, your system accrued interest on a balance that was wrong — and issued a statement based on it. That isn't a bug; it's unavoidable. The only question is whether your ledger can represent it.
What bitemporality buys you
A bitemporal ledger stores both clocks on every posting. Corrections are new events with a back-dated effective time, never edits. That gives you three things a single-timeline system can't offer:
- Honest restatements. Record the late payment as of the 28th, re-accrue two days of interest, and post the difference — without rewriting the statement you already sent.
- Answers as-of any moment. Any balance, queried by both clocks: what we know now about then, and what we knew then about then.
- A complaints defence that holds. When a customer disputes a figure from last year, you reproduce exactly what the system believed at the time — not a reconstruction.
The operational payoff
Teams usually discover they needed two clocks the first time a batch file arrives three days late, or a rate change lands with retroactive effect. By then, the single-timeline workarounds — manual adjustments, spreadsheet reconciliations, "goodwill" write-offs — are already in production.
Build on two clocks from day one and those events become ordinary ledger entries. That's the design choice at the bottom of Kontor Ledger, and everything else — allocation, statements, hardship, disputes — reads from it.