Reconcile every ledger. Across entities, across regions.
LedgrSync ingests transactions from each entity and automatically surfaces what doesn't match — missing records, mismatched amounts, divergent status — on a distributed SQL database that never sleeps.
Live demo · no setup required.
| Type | Reference | Detail |
|---|---|---|
| Amount mismatch | ref-002 | USD 250 vs 250.50 |
| Status mismatch | ref-003 | posted vs pending |
| Missing in B | ref-004 | — |
| Missing in A | ref-005 | — |
Built on a modern, distributed stack
ACID, serializable isolation
us-east-1 + us-east-2 + witness
no static DB passwords
56 unit tests on every push
The problem
Reconciling ledgers by hand breaks at scale
When every entity keeps its own books, the smallest divergence is expensive to find — and impossible to find fast.
Without LedgrSync
- Spreadsheets and manual cross-checks across regions
- Mismatched amounts and statuses slip through unnoticed
- No safe story for concurrent writes — lost updates, races
- Reconciliation that cannot keep up as volume grows
With LedgrSync
- Automatic pairing by reference across two entities
- Every discrepancy classified: missing, amount, status
- Optimistic-concurrency retries built for Aurora DSQL
- Two engines: streaming or in-database FULL OUTER JOIN
How it works
From raw transactions to a clean reconciliation
- 01
Register entities
Add each ledger with its region and currency — your books, your structure.
- 02
Ingest transactions
Push transactions per entity. A shared referenceId links the two sides; writes are OCC-safe.
- 03
Run reconciliation
Compare any two entities — stream the larger ledger, or join entirely in the database.
- 04
Resolve discrepancies
Review missing, mismatched, and divergent records, plus the live concurrency-conflict log.
For developers
A real API, not a black box
Auth-gated REST endpoints, validated with zod, with two reconciliation engines behind a single call.
- Streaming engine indexes the smaller ledger, paginates the larger
- SQL engine runs FULL OUTER JOIN inside Aurora DSQL — memory bound by discrepancies
- withOCCRetry handles 40001 serialization conflicts with backoff
- IAM token auth via @aws-sdk/dsql-signer — refreshed per connection
- 56 unit tests, GitHub Actions CI on every push
{
"entityAId": "acme-us",
"entityBId": "acme-eu",
"engine": "sql"
}
→ 201 Created
{
"totalChecked": 5,
"discrepancies": [
{ "type": "amount_mismatch", "referenceId": "ref-002" },
{ "type": "status_mismatch", "referenceId": "ref-003" },
{ "type": "missing_in_b", "referenceId": "ref-004" },
{ "type": "missing_in_a", "referenceId": "ref-005" }
]
}FAQ
Frequently asked questions
What is Aurora DSQL?+
AWS's serverless, distributed SQL database — PostgreSQL-compatible, strongly consistent, and active-active across regions with no servers to manage.
How does multi-Region work here?+
Two peer clusters (us-east-1 + us-east-2) share the same data with a witness region (us-west-2) for quorum. The app connects to the reachable region and fails over automatically.
How are concurrent writes handled?+
Aurora DSQL uses optimistic concurrency. LedgrSync retries serialization conflicts with exponential backoff and logs each conflict so you can observe contention.
Which reconciliation engine should I use?+
The streaming engine is the default and bounds memory to the smaller ledger. The SQL engine performs a FULL OUTER JOIN in the database — ideal when both ledgers are very large.
What is the stack?+
Next.js 16 (App Router), React 19, Prisma 7 over Aurora DSQL, zod validation, a self-contained HMAC auth gate, Vitest tests, and GitHub Actions CI — deployed on Vercel.
Can I see the code?+
Yes — the full source is on GitHub, including the reconciliation engines, the API, and the infrastructure notes.
See reconciliation in action
Open the live dashboard, run a reconciliation between two entities, and watch the discrepancies surface in real time.