How Software Systems Track Customer Balances

When you see an account balance—70.00 owed, 50.00 credit or whatever it is—it’s easy to assume that number is the “truth”, but in most systems, it’s usually a snapshot from another source. The real truth lives in the transaction history: a log of events that explain exactly how the balance got there. This article describes, conceptually, how account balances and transactions work.

This article doesn’t dig into general ledger accounting or bank nominals (I’ll cover those in a future article). Instead, we’ll look at how software systems such as e-commerce platforms, billing engines, and policy admin systems track what a customer owes or is owed using a transaction history.

Disclaimer: As I mentioned in my last article, I’m not a finance expert, accountant, or bookkeeper - I’m a techy. This is simply what I’ve learnt from spending the last 10–15 years around finance systems, in various companies, and trying to make sense of how they actually work. If a seasoned finance professional reads this and winces, please take it as proof that I’m still learning 😄

Understanding the data

In applications that handle financial data, you'll typically find there are two key data items: accounts and transactions.

Accounts

Are tied to a customer using a unique identifier. They usually store the current balance, which is derived from the transaction history (more on this below).

Example 'Account' Schema:

• Id: Unique identifier for the Account
• Balance: Derived from the transaction history

Simplified account model shown for illustration (and because I'm lazy).

Transactions

Represents an financial event, such as a payment, charge or refund.
All transactions together form the transaction history: an immutable, append-only ledger that shows all the events that has occured in an account from its opening state to now. Nothing is overwritten, nothing is deleted—each new financial event adds a new transaction to the history.

Example 'Transaction' Schema:

• Id: Unique identifier for the transaction.
• Type: Type of transaction - charge, payment, adjustment, etc. This is also determines whether the transaction is treated as a debit or credit during account balance calculations.
• Amount: The transaction amount.
• Balance After: The running balance immediately after applying this transaction, which avoids expensive re-sum operations on large histories and supports the following use-cases
  • 'Balance at time X' queries
  • Auditing
  • Reconciling the account balance
• Timestamp: When the transaction occurred or was recorded.
• Description: A human-readable explanation of the event, e.g., Payment of 50.00 received for Invoice: INV-4582.

Note: In a real transaction table, there would likely be a foreign key to the account.

Key Architectural Features

Immutable Transaction History

Instead of overwriting account balances, every financial transaction becomes a new event in an append-only log (usually a table). This provides a complete, tamper-proof history of how the account reached its current state. If something needs correcting, the system simply records a new entry rather than altering history.

If you're a software engineer, think of this like a source control repository: you never rewrite the history - you always commit a new change.

Common Uses of the Transaction History

• Producing customer statements that show charges (money owed), payments and refunds
• Supporting customer enquiries by showing what happened and when
• Helping finance teams reconcile payments and invoices
• Creating audit trails for internal or external review
• Generating reports such as ageing summaries and outstanding balances
• Exporting data to other systems for billing, finance or reporting, e.g. a general ledger for management accounts

Account Balance as a Fast-Read View

The account’s balance is a convenient snapshot - recording the latest balance from the transaction history. By storing the balance within the account record, the system avoids recalculating balances from scratch each time, which keeps performance as transaction histories grow.

Temporal Reporting Through Running Balances

Because each transaction stores the balance immediately after it is applied, using 'Balance After', the system can answer questions like “What was the balance before this payment?” or “How much did the customer owe last month?” without reprocessing the entire transaction history.

Debit vs Credit

Every financial event ultimately boils down to a simple question: does this action increase what the customer owes, or decrease it? That’s where the debit and credit distinction comes in.

A debit represents something that adds to the customer’s outstanding balance, such as issuing an invoice, applying a fee, or adding a new charge.

A credit moves the balance in the opposite direction, reducing what the customer owes through payments, refunds, or adjustments.

How a Transaction Flows Through the System

When a payment comes in, it first recognises the business event (e.g. 50.00 payment received for account 001), then it applies the movement logic, i.e., a debit or a credit. In our example, it’s a credit, because the customer has made a payment and now owes less.

The system records a new, immutable transaction row - capturing the amount, timestamp, description, and the new running balance of 70.00.

Finally, the account’s balance is updated to reflect that same value. Before the event, the customer owed 120.00; after the event, they owe 70.00.

Key Takeaways

Hopefully this gives you a clearer picture of what’s going on under the hood. The account balance you see usually comes from the account record, but it’s derived from the transaction history—the real source of truth. The transaction history is an immutable log that captures each transaction at a specific point in time.

I hope you found this useful. If you have suggestions on how I could improve the content, please feel free to message me. If you’re interested in custom visuals or system-focused content, please get in touch.