kordio.

Ledger · Build vs buy

The schema takes a week. The next eighteen months are the cost.

Everyone can write a debits and credits table. Almost nobody budgets for concurrency, idempotency, reconciliation, corrections, multi-currency and period close. This page is the honest version of that decision, including when you should build it yourself.
Post a balanced transaction in test modeSee what actually costs
  • Free sandbox, no card
  • We never hold your funds
POST /v1/transactionsunbalanced
{
  "postings": [
    { "account_id": "acc_merchant", "amount": -5000, "currency": "USD" },
    { "account_id": "acc_fees",     "amount":  4700, "currency": "USD" }
  ]
}
Kordio answers
{
  "error": {
    "code": "unbalanced",
    "hint": "USD: add 300 of credits or remove 300 of debits"
  }
}

The state that would have quietly drifted is the state the API refuses to accept.

Build it yourself

Three situations where in-house is the right answer.

A vendor telling you to always buy is a vendor, not an advisor. If you are in one of these, keep your table and come back when something below changes.
One currency, one product, one team
Balances that only ever move one way, nobody else holding funds, and no auditor in the picture yet. A table is genuinely the right answer here and anyone selling you otherwise is selling.
The ledger is the product
If double-entry semantics are the thing customers pay you for, own it. That is a different situation from needing books underneath something else.
Volumes stay small enough to fix by hand
When a discrepancy is a ten-minute query rather than a week of forensic work, the cost of being wrong has not arrived yet.

Stop building

Five signals the table has run out.

None of these are theoretical. Each one is a specific week where a team discovers the thing they built is not the thing they now need.
You hold balances for more than one party
The moment a balance belongs to a merchant, a seller, a customer or a counterparty rather than to you, every mistake is somebody else money and the reconciliation stops being optional.
A second currency or a second rail arrived
One currency hides an enormous amount of design debt. The second one surfaces all of it at once, usually in the same sprint you promised the feature.
Somebody asked for a balance as of a date
An auditor, a regulator, a licence application or a serious customer. If answering means writing a query and hoping, the books are not a system of record yet.
A retry paid somebody twice
Idempotency is easy to describe and easy to get subtly wrong. It usually gets discovered by a payout run rather than by a test.
The person who wrote it is leaving
Financial correctness that lives in one engineer head is a single point of failure with a notice period.

The real bill

Eight things that cost more than the schema.

The schema is the part that looks like the work. These are the parts that turn into incidents, and every one of them is already solved in a ledger you can call today.
What you end up buildingWhy it is harder than it looks
Balanced writes under concurrencyTwo requests reading the same balance and both deciding they can proceed. The fix is not a transaction wrapper, it is a design.
Idempotency that survives retriesEvery write needs a key, every key needs a lifetime, and the semantics of a replayed write have to be defined rather than assumed.
Reconciliation against what actually clearedNot what you told the processor to do. The breaks are the product, and a number that quietly absorbs them is worse than no number.
Point-in-time historyA stored balance column cannot answer what it was last March. A derived balance over an append-only journal can.
Corrections without editsReversals rather than updates, or the audit trail is fiction the first time somebody fixes a typo in production.
Multi-currency that balances per currencyOne transaction, several currencies, each summing to zero on its own. Retrofitting this into a single-currency schema is a migration, not a change.
Period closeThe books have to stop moving underneath a closed month, and reopening has to be deliberate.
The reports finance will ask forTrial balance, balance sheet, income statement. Generated from the postings, not from a parallel pipeline that drifts.

Kordio ships all eight. See what the ledger does, or read the API reference.

Deciding

The question that settles it.

Not "can we build this", because you can. The question is whether financial correctness is where you want your best engineers spending the next four quarters, and whether the answer is still yes after the second currency.
1
Ask when your last balance discrepancy was
And how long it took to find. That number is the real input, and most teams have never written it down.
2
Ask who answers an auditor
If the answer is one engineer and a query, you have a reporting process rather than a system of record.
3
Land the next thing on a real ledger
New product, new rail, new market. No migration, no downtime, and a like-for-like comparison you can actually judge.

Questions

The objections worth taking seriously.

Is this not just a table with debits and credits?

That is the first version, and it works. What follows is concurrency, idempotency, reconciliation, corrections, multi-currency, point-in-time history and close. Each is small on its own. Together they are the eighteen months teams do not plan for.

What about using our accounting software instead?

Different job. Accounting software keeps your company statutory books for tax and statements. A ledger keeps per-party balances at transaction granularity, in real time, for your product to read. Most companies that need one need both.

Can we migrate without downtime?

The usual path is not a migration at all. Land a new product, a new rail or a new market on Kordio, leave the running system alone, and let the old balances age out. Ledgers get adopted at greenfield moments, not swapped underneath live money.

What if we want to leave later?

Postings and events are exportable continuously, so your own warehouse can hold a mirror from day one. Nobody should put their financial history somewhere they cannot get it out of.

Is Kordio holding our money?

No. Kordio holds no funds, no accounts and none of your credentials. The rails move money and Kordio keeps the record of what moved.

Try to make it drift.

The sandbox is free, needs no card, and touches no live books. Post an unbalanced transaction and watch it get refused, then decide whether that is a week of your team or an API call.
Get API keysSee ledger pricing