Introduction

These use cases describe common patterns where teams reach for Ledgers-aaS. Each one assumes the concepts in Key Concepts — accounts, transactions, entries, and the three balance views.

Marketplace sub-balances

A marketplace holds funds on behalf of many sellers. A single payout bank account is not enough, operations need to know how much belongs to each seller at any moment.

With Ledgers-aaS, the marketplace creates one ledger and one ledger account per seller. Every order books a credit to the seller's account; every payout books a debit. The posted balance per account answers the question "how much do we owe this seller right now" without running an end-of-day batch.

Payout scheduling and holds

A platform that pays out on a schedule needs to separate funds that are earned, funds that are reserved, and funds that are ready to send.

Each seller gets a ledger account, and the platform models the three states with the pending, posted, and available balances. New earnings land as pending, clear to posted after the hold period, and become available when no chargebacks are outstanding.

Internal reconciliation

Finance teams need an immutable record they can reconcile against external statements, acquirer settlements, bank deposits, partner reports.

A ledger gives every movement a transaction ID and a pair of balanced entries. Reconciliation becomes a join between external statement rows and ledger entries, with discrepancies surfaced rather than buried in summary totals.

Wallet and stored-value products

Consumer wallets, gift cards, and stored-value products all need a per-user balance with a complete history.

A ledger account per wallet, with transactions for top-ups, spends, refunds, and expirations, gives the product a single source of truth. The available balance powers in-app spending checks; the posted balance powers monthly statements.

Test ledgers

A sandbox environment for Ledgers-aaS is not yet available. Until it is, teams can create a dedicated test ledger inside their organization and run controlled transactions against it. This isolates integration testing from production balances while still exercising the real API.