Daily

automated reconciliation that used to take a week by hand

FinTech case study

A ledger you can reconcile to the cent, every day

A payments product that couldn't close its books cleanly got a double-entry ledger and automated daily reconciliation.

Client
Halora Pay
Vertical
FinTech
Role
Ledger redesign and reconciliation tooling
Year
2024

How it ran

From brief to outcome.

  1. 01

    Brief

    The books had to tie out to the cent and the close had to stop eating a week. Correctness first, speed second.

  2. 02

    Approach

    Rebuild on double-entry, make entries append-only, and reconcile against the processor automatically every day.

  3. 03

    Build

    A double-entry ledger, an append-only entry log, a daily reconciliation job, and a drill-down close view.

  4. 04

    Launch

    Ran the new ledger in parallel with the old derivation for two months until the numbers matched every day, then switched.

  5. 05

    Outcome

    Reconciliation runs daily on its own, breaks surface immediately, and the month-end close stopped being a fire drill.

What changed

Before, and after.

Reconciliation cadence
BeforeMonthly, by hand
AfterDaily, automated
Month-end close effort
Before~1 week
After~1 day
Tracing a discrepancy
BeforeRead raw logs
AfterDrill-down in clicks

The work

The problem, and how we took it on.

The challenge

Halora Pay moved money fine, but the books never quite tied out. Balances were derived from scattered tables, the month-end close took a week of spreadsheet work, and when a figure was off, tracing it meant reading raw logs. That is not a footing you want to be on when a regulator or an investor asks a sharp question.

Our approach

  • Modelled money movement as proper double-entry, so every balance is the sum of immutable entries rather than a mutable field.
  • Made entries append-only, so a correction is a new entry with a reason, never a quiet edit.
  • Automated reconciliation against the payment processor's records, run daily instead of at month-end.
  • Built the close so finance can drill from any balance down to the entries behind it in a few clicks.

What we built

  • A double-entry ledger where balances are computed from immutable entries.
  • An append-only entry log with reasons, so corrections are visible and traceable.
  • A daily reconciliation job that matches internal entries to the processor and flags any break.
  • A close view that lets finance trace any number back to its source entries.

The outcome

Halora's books now tie out daily, and a break shows up the morning it happens instead of at month-end. The close that used to swallow a week of spreadsheet work is down to about a day, and any figure can be traced to the entries behind it without spelunking through logs. When a regulator or an investor asks how a number was derived, there's a clean answer.

Built with

The stack on this project.

TypeScriptNode.jsPostgreSQLRedisDockerAWS

Where this fits

The services and industry behind it.

Straight answers

Questions about this build.

How did you switch ledgers without risking the books?

We ran the new double-entry ledger in parallel with the old balance derivation for two months. Only once the two agreed every day did we make the new ledger the source of record.

Can past entries be edited?

No. Entries are append-only. A correction is recorded as a new entry with a reason attached, so the history stays intact and every change is traceable.

Have a problem like Halora Pay’s?

Tell us what's slowing your product down. We reply to every serious enquiry within one business day.