Skip to content
← All work
2026SoftwareSystems

Recon3: house-account reconciliation

When a system only knows the present, nobody can prove the past. Recon3 gives a marina's house accounts a memory, then reconciles that memory against the books every night.

Role
Principal architect, product & systems
Built for
Toler's Cove Marina · Marina operations · point-of-sale house accounts to accounting
Disciplines
Software · Systems
Status
Live on real data · active build
Stack
Next.js · Postgres with row-level security · nightly scheduled runs · spreadsheet exports
Reconciliation view comparing nightly house-account balances to the accounting receivable, with flagged exception days.
Recon3: nightly snapshot, receivable, difference. Shown on the built-in demo book.
The problem

A live balance with no history.

Members run house accounts at the marina's point of sale. The house-account app shows what is owed right now and nothing else. There is no record of what was owed last Tuesday, so tying the month to the accounting system meant reconstruction and judgment calls. Worse, charges could be landing in accounting as cash rather than receivables. The question was how to give a system with no memory a provable history, and reconcile it honestly.

The method — Sequence

Decompose. Digitize. Solve at the integrations.

The Sequence method, applied end to end — the same move that runs through every Digi-DNA project.

/01 — DECOMPOSE

The nightly balance

Reduce reconciliation to its irreducible unit: every account's balance on a given date, compared to the books on that same date.

/02 — DIGITIZE

Immutable snapshots

Capture every balance nightly into an append-only store. Re-running a date never overwrites a good run. Credentials for connected systems are encrypted at rest.

/03 — INTEGRATE

Reconcile, then cross-check

Pull the matching receivable from accounting and record the difference. Flag a day only when it breaches both a dollar and a percentage threshold. Cross-check charges against card-processor payments and record the basis for every match.

If reconstructed ageing does not tie to the source's own total, Recon3 reports the balance unaged rather than show buckets that disagree.

Verification is the fifth primitive of Kernal, and here it is the whole product: the system claims a balance, the books claim a receivable, and Recon3 proves whether they agree.

Inside the system

Screens and features.

Recon3 reconciliation page with totals and a card-processor tie-out panel.
Reconciliation with the source cross-check and its open exceptions.
House-account ageing report with per-row ageing basis labels.
Ageing report labels each row as source-native, reconstructed, or unaged balance only.
Snapshot run history with successful, partial, and failed runs.
Immutable nightly snapshot runs, with failed and partial re-runs logged beside them.
Charge drill-down showing a matched card sale and the match basis.
Drill from account to charge, showing the card sale and its match basis.
User administration with four roles and an invitation form.
Four roles: viewer, manager, auditor, admin, with invitations and access control.
The outcome

The books, with a memory.

  • Provable history — a nightly, immutable record of every house-account balance from go-live forward.
  • Honest exceptions — dual-threshold flagging, so finance reviews real breaks rather than noise.
  • Cross-checked — point-of-sale charges matched to processor payments with the match basis recorded; seven of seven matched on the first day of real data.
  • Governed access — four roles (viewer, manager, auditor, admin), row-level security, and audit-ready exports.
Start a Strategic Build

Have a system that should behave as one?

Start a Strategic Build →Or explore more selected work →