Open Source · Self-Hosted · Java + Haskell

The Ledger SDK
Correct by Construction

Build loan ledgers that stay consistent through payment reversals, backdated entries, and out-of-order events — guaranteed by the engine, not by careful coding.

Java 21 (53 invariants) · Haskell GHC 9.6 (64 invariants) · Quarkus / Spring compatible · JavaMoney precision

Haskell Reference Implementation

NEW

The same rollback‑replay‑sync algorithm is independently implemented in pure Haskell (GHC 9.6.4) and verified with 64 passing invariants. Identical test outcomes in two type‑systems prove the logic is correct by construction — not by accident of runtime.

64
invariants
2
languages
1
algorithm

// the_problem

Your ledger isn't wrong today.
It's wrong after the reversal.

Typical In-House Ledger

  • Silent balance corruption on late-arriving payments
  • Hand-coded reversal logic with edge-case gaps
  • Backdated entries break running balances downstream
  • No idempotency — duplicate events corrupt state
  • Interest recalculations fall out of sync after corrections
  • Months of engineering to patch each new scenario

Precise Ledger Pro

  • Automatic rollback & replay on out-of-order events
  • Reversal engine emits signed compensation entries
  • Retroactive reconciliation synchs every downstream balance
  • Composite idempotency keys prevent double-application
  • Interest re-accrual built into the replay cycle
  • One SDK — correct from day one, auditable forever

// capabilities

Six pillars of ledger integrity

Retroactive Rollback + Replay

Backdated activities automatically trigger ledger rollback to the effective date, deterministic re-application of all subsequent activities, and delta-based synchronisation back into the primary ledger.

Reversal Compensation

Every reversal emits a signed compensation entry that mathematically negates the original impact, then rolls back and replays all downstream activities so running balances stay consistent.

Double-Entry Integrity

Every LedgerEntry carries both the component deltas (Δprincipal, Δinterest, Δfee, Δexcess) and the running balance — always consistent, always auditable.

💰

JavaMoney Precision

Built on Moneta with a 256-bit HALF_EVEN MathContext. No IEEE-754 floating point drift — every cent is accounted for across millions of entries.

🔒

Idempotent Application

Composite idempotency keys on every entry prevent double-application on retry storms or duplicate event delivery — critical for event-sourced architectures.

🔨

Pluggable Spread Strategies

Ship with ComputationalSpread (interest-first waterfall) and StaticAllocation. Implement TransactionSpreadStrategy for any custom allocation rule.

// how_it_works

Three-phase deterministic engine

1

Submit Activity

Transaction, SOD accrual, or reversal submitted via API

2

Detect Position

Engine checks if back-dated, reversal, or chronological

3

Rollback · Replay · Sync

Fork, recompute, and reconcile deltas back into primary ledger

LedgerService.applyLedgerActivity()
// Pseudocode — the actual engine branching logic
for each activity in pendingActivities:

  if activity.isBackdated(ledger):
    retroLedger = ledger.rollbackTo(activity.effectiveAt)
    retroLedger.apply(activity)
    replaySubsequent(retroLedger, activitiesAfter)
    ledger.syncWith(retroLedger)  // delta reconciliation

  else if activity.isReversal():
    ledger.addCompensation(negate(originalImpact))
    retroLedger = ledger.rollbackBefore(originalActivity)
    replaySubsequent(retroLedger, activitiesAfter)
    ledger.syncWith(retroLedger)  // delta reconciliation

  else:
    activity.applyTo(ledger)       // chronological — fast path

// integration

Drop into your stack in minutes

<!-- Not yet published to Maven Central. -->
<!-- Clone the repo and build locally: ./mvnw install -->
<!-- Then reference the locally installed snapshot: -->
<dependency>
  <groupId>io.github.v1bh0r</groupId>
  <artifactId>precise-ledger-pro</artifactId>
  <version>1.0-SNAPSHOT</version>
</dependency>
// Apply activities — engine handles backdated & reversals
var ledger = ledgerService.getLedger(loanId);
var clock  = ledgerService.getCurrentLedgerClock(ledger);

ledgerService.applyLedgerActivity(
    ledger, activity, clock, temporalContext
);

// That's it. Balances are correct.
var balance = ledger.getCurrentBalance();
// → Balance[principal=USD 991,000.00, interest=...]
-- precise-ledger.cabal
build-depends:  precise-ledger ^>= 1.0

-- Apply activities — same engine, pure functional
let activities = [disbursal, payment, reversal]
    (ledger, _) = applyLedgerActivities
                    lookup ctx activities
                    emptyLedger defaultClock

-- Balances are correct. No IO, no side effects.
let bal = currentBalance ledger
-- → Balance { principal = 991000.00, interest = 0 }

Your code, your servers, your audit trail

  • Full source code — open source and auditable
  • Self-hosted — deploy on-prem, private cloud, or air-gapped environments
  • Works with any JPA/Hibernate datastore (PostgreSQL, MySQL, Oracle, H2)
  • No phone-home, no telemetry, no vendor lock-in
  • Quarkus, Spring Boot, or standalone — your choice

// faq

Frequently asked questions

Yes — the full source code is open source and available on GitHub. You can audit it, fork it, and deploy it freely.
Yes. The same rollback-replay-sync algorithm is independently implemented in pure Haskell (GHC 9.6.4) with 64 verified invariants. The Haskell port ships as a Cabal library (precise-ledger) and is available in the open-source repository. It serves as both a formal cross-language verification of the algorithm and a production-ready option for Haskell-native teams.
Yes. While the reference implementation is built on Quarkus, the core ledger engine (Ledger, LedgerService, activity types) is framework-agnostic. It works with any JPA/Hibernate environment including Spring Boot, Micronaut, or plain Java SE.
Any database supported by Hibernate: PostgreSQL (recommended for production), MySQL, Oracle, SQL Server, H2 (testing). The SDK uses standard JPA entities with no database-specific SQL.
White Paper Position Paper · April 2026

Getting Retroactive Corrections Right

A structured position paper for engineering leads, compliance officers, and decision-makers. Covers why conventional ledger approaches fail on reversals and backdated entries, the four correctness requirements every regulated ledger must meet, who should use PLP, and a side-by-side competitive landscape analysis.

Ready to ship a correct ledger?

See the rollback-replay-sync engine handle reversals and backdated payments in real time, then get in touch.

View Live Demo Contact Us