A transaction is a set of postings whose debits always equal its credits. Send a simple transfer or split one payment across many accounts, pending or posted, and Ledgr writes it to an immutable journal and updates every balance atomically.
List the legs, and Ledgr checks that debits equal credits before it accepts anything. The transfer, the platform fee, and the merchant credit settle as one atomic entry, or none of them do.
const tx = await ledgr.transactions.create({idempotencyKey: "settle_5f2a",description: "Card settlement",status: "posted",entries: [{ account: "customer", direction: "debit", amount: 10_000 },{ account: "merchant", direction: "credit", amount: 9_700 },{ account: "fees", direction: "credit", amount: 300 },],}); tx.status; // "posted" · debits === creditsThree legs, one entry. Debits and credits net to zero, so the books can never drift.
Double-entry is centuries old for a reason. Ledgr enforces it at write time, so the property you rely on for audits holds on every single transaction.
Every transaction is rejected unless its sides balance. Money always leaves one account for another, so value is never lost or invented.
Either the whole entry is written or none of it is. A partial settlement is impossible, even across many accounts.
Each posting links to the transaction that made it. Any balance can be explained by the exact entries behind it.
Post a transaction outright, or record it as pending and reserve the payer's funds until you confirm it. Corrections are first-class too: a reversal is a new, opposite entry, never an edit. Ledgr enforces which transitions are allowed.
Split one payment across payer, payees, fees, and taxes in a single balanced transaction.
Every create takes an idempotency key. A retry after a timeout returns the original result and never double-posts.
Posted, pending, held, and available update the moment a transaction lands, derived straight from the journal.
List by account, status, direction, or date range, and page through results with a stable cursor.
Retrieve any transaction with its legs, its immutable postings, and its complete event history.
transaction.created, posted, and reversed events reach your webhooks the instant they happen.
The same entry you post through the API, with its legs, postings, and status, laid out for your team to inspect and reconcile.
