Siesta Global

A ledger that reconciles, not just one that records.

Most platforms don't set out to build a ledger. They add a balance column, then a pending column, then a spreadsheet that explains the difference — and by the time anyone calls it a ledger, finance no longer trusts it. We design the thing properly, in one pass.

Engagement model
Design review, build sprint, or retainer
Service area
United States
Response time
Two business days

When this is the right call

Someone is reconciling by hand, every month.

The balance is computed, not recorded

Balances are derived by summing rows at read time. It works until a retry, a partial refund, or a race writes the same movement twice, and then nothing can prove which number was ever right.

FX is applied wherever it is noticed

Conversion happens in application code at varying moments, so the same transaction reports different values depending on who asks and when.

Finance keeps a second set of books

The spreadsheet that corrects the system is the clearest signal the system is not the source of truth — and it is load-bearing long before anyone admits it.

What the engagement covers

Immutable movements, derived balances, provable totals.

Ledger design

Double-entry movements as the only way money changes hands, with accounts modelled per party and per currency. Entries are appended and never edited, so history is reconstructible and a correction is a new entry rather than a mutation nobody can see.

Cross-border settlement

Currency held as a property of the account rather than converted in transit, with the rate and its timestamp recorded on the movement that used it. Conversion becomes an explicit, auditable event instead of a number that cannot be reproduced later.

Reconciliation tooling

Automated reconciliation against provider settlement reports, with breaks surfaced as a worklist rather than found at month end. The goal is that nobody opens a spreadsheet to answer "why don't these agree".

Idempotency and ordering

Every movement keyed so a retried webhook or a replayed job cannot double-post, and ordering that holds under concurrency. This is the difference between a ledger that survives an incident and one that quietly diverges during it.

How it runs

Design review

A read of how money is represented today and where it can drift, ending in a written ledger model — accounts, movements, invariants, and the reconciliation strategy.

Build sprint

Implementation with your team, including the migration path from whatever exists now. Backfilling history into a new ledger is usually the hardest part and the part most plans omit.

Retainer

Ongoing review as currencies, payout methods, and party types are added — each one a change to the money model, not merely a configuration change.

Why us

Decades on core financial systems, and a payout platform of our own.

Track record

Principal architect, financial systems

High-throughput payment systems and real-time transaction pipelines, plus lead and architect work on tax engines at Amazon spanning global, state, and federal jurisdictions — where getting the number provably right is the whole job.

Full track record →

In-house venture

Imerzn™

A two-sided marketplace we built and operate, with payments and payouts on both sides of the market — so the reconciliation problem described here is one we own rather than one we have only reviewed.

imerzn.com →

Questions we get

Should we buy a ledger instead of building one?

Sometimes, and we will say so. The design work is the same either way: a product you cannot model your money in is not cheaper than one you can, and the decision is easier once the model is written down.

Do we need this before we have scale?

The cost of retrofitting a ledger rises with the amount of history you have to backfill. Early is cheap. It becomes urgent when the manual reconciliation starts.

Can this run alongside what we have?

Usually yes — writing to both and comparing is the normal migration path, and the comparison is how you earn the confidence to cut over.

Is this an accounting engagement?

No. We build the system your accountants can rely on, and we work with them on the chart of accounts. We are not your auditors and will not pretend otherwise.

Tell us where the numbers stop agreeing.

Describe how money is represented today, which currencies are involved, and what someone currently fixes by hand. We reply within two business days.