Why your financial product needs a proper ledger

A customer sees $100 available in their wallet. Your payment provider shows a successful deposit. Your database has a balance of $100. Everything looks correct until a withdrawal times out, a webhook arrives twice, or a refund lands after a payout.

Now you need to answer more than how much money is in the account. You need to know where it came from, what has been committed, and which movements actually completed.

A proper ledger gives your product and your accounting team a shared record of those movements. Pandabase Ledger provides that foundation, built on Astrum, our open source core ledger.

A balance needs an explanation

A balance column stores a result. On its own, it cannot explain the deposits, transfers, fees, refunds, and adjustments that produced it.

That becomes a problem when customers question a charge or your finance team investigates a difference between internal records and a bank statement. Reconstructing the answer from application logs and webhook payloads is slow, especially when those records disagree.

A ledger records each financial event against accounts. The balance follows from that history, giving you a path from the number on the screen back to the transactions behind it.

Double-entry accounting connects both sides

Every ledger transaction contains debits and credits that balance. This makes the relationship between accounts explicit.

For a simplified wallet deposit, assume $100 has settled into the platform's bank account, with no fees. The platform records:

The cash asset increased, and so did the amount the platform owes the customer. That deposit is a customer obligation; treating it as sales revenue would misrepresent what happened.

Balanced entries catch missing or mismatched sides of a transaction. They still need the right accounts and business meaning: an incorrectly classified transaction can balance perfectly.

Financial products need more than a current total

A wallet, marketplace, or billing product needs to distinguish money that is recorded from money that can be spent.

Suppose a customer has $100 posted and a $30 withdrawal reserved. Their available balance should reflect that reservation while the withdrawal is in progress. Otherwise, another request could try to spend funds already committed elsewhere.

Retries create another challenge. If a transfer succeeds but its response gets lost, repeating the same operation should return the existing result. It should not create another transfer.

Corrections matter too. Editing an old payment destroys the explanation for previous balances. Recording a reversal preserves the original event and shows how it was corrected.

These behaviors belong in the foundation of a financial product, where every feature can use them consistently.

Accounting needs a history you can reconcile

A useful ledger gives finance teams records they can compare with payment provider reports and bank statements. Differences can then be investigated as specific missing, delayed, or incorrectly recorded transactions.

Reconciliation remains necessary. An internally balanced ledger does not prove that a bank transfer settled or that every external event was recorded. Linking entries to the corresponding payment, order, or payout makes those checks easier.

Closing accounting periods also helps keep reported history stable. Later corrections should remain visible, with a controlled process for reopening a period when necessary.

How Pandabase Ledger helps

Pandabase Ledger brings these controls into your product through a hosted ledger:

• Balanced entries per currency: transactions must balance within each currency, so a USD difference cannot be offset by a EUR entry.
• Precise amounts: integer amounts in each currency's smallest unit avoid floating-point representation errors when storing money.
• Posted, pending, and available balances: holds and pending outflows help distinguish recorded funds from funds available to spend.
• Safe retries: idempotency keys let you retry the same operation without posting it twice.
• Traceable corrections: reversals create linked entries while preserving the original posted transaction.
• Period controls and integrity checks: close reported periods and verify balances and the journal's seal chain.

Your application defines what a purchase, transfer, or refund means. Pandabase supplies the ledger controls for recording those events consistently, reducing the accounting infrastructure your team needs to build and maintain.

Built on Astrum, open to inspection

Our core ledger, Astrum, is open source under the MIT license. It includes double-entry accounting, multiple currencies, holds, reversals, idempotent requests, signed webhooks, and tamper-evident journal history.

You can inspect the implementation and run Astrum yourself on PostgreSQL, or use the hosted version through Pandabase. The repository includes examples for wallets, marketplaces, card authorization, lending, and usage billing to help connect ledger concepts to real product flows.

If your product tracks what customers own, owe, or can spend, those balances deserve an explainable history from the start. Explore Pandabase Ledger to build on that foundation, or visit Astrum on GitHub to examine the core.