How to Think About Ledger Balances

Introduction

Every product that moves money has a ledger. Even if you’re not thinking of it as a ledger, by its nature, your application has to track balances and keep a log of transactions. For example, a marketplace needs to keep track of payouts owed to sellers. A debit card product needs to monitor cash balances before approving transactions. A lending product needs to track loan balances. Most companies start out with a simple implementation using the standard SQL based relational database technologies we all know and love.

Simple implementations work fine, until all of a sudden they don’t. It could be an audit, a few lost transactions, a partially recorded transaction, or a number of other issues. Your balances don’t match, and it’s going to take hours to track down where this happened (if it’s possible at all). Meanwhile, Accounting is breathing down your neck because they needed to close the books on the quarter yesterday.

You find yourself needing to correct issues manually every few weeks by writing scripts against production, which interrupts engineering cycles and introduces unnecessary risk. You realize you need a new type of aggregation or status and have to hack it by creating new derived tables, introducing additional latency and complexity. What started as the option with the least amount of dev time ends up being the one taking the most.

Our Ledgers Product

Modern Treasury’s Ledgers ensures safe handling of balances and transactions through immutability and double entry accounting. It enforces proper standards to keep you safe, while providing flexibility in data structures via free form metadata.

We recently shipped three new features that let you build a better Ledger faster: Available Balances, Balance Aggregation, and Ledger Accounting Categories.

Available Balances

One of the tricker parts of ledgering is that you often need multiple views of the same underlying balance. As you have multiple transactions against the same balance—some still pending, others complete and posted—you’ll need to look at different calculations of the total balance for different use cases. Modern Treasury provides native support for three types of balances: Posted, Pending, and the recently added Available.

Processing any financial transaction—a purchase, transfer, or withdrawal—will require writing it to the Ledger. But before you can do this, you always have to ask, “Is there enough money?” Not only that, but also, “Will there be enough money when this transaction goes through?”

Because moving money takes time, you need to figure out how to take a cautious approach to approving transactions while various payments are in flight. Available balance does this by looking at all pending transactions, and assuming everything outgoing is gone, and everything incoming won’t arrive. This will always be the safest approach to take when approving a transaction.

Pending and Posted are straightforward. Posted is the sum of all posted transactions. This gives you the settled state of the world. Pending is the sum of all pending and posted transactions. This is the balance you should expect to see once everything is finished settling or processing.

Aggregating Ledger Balances with Account Categories

Account balances are the lowest level aggregates your ledger should track for you. This is a recommended practice as it’s always easier to further aggregate things than to disambiguate them. Companies will often need to aggregate these balances to perform financial analysis, to export to a general ledger, or to show a customer an aggregated balance on all their accounts in a web portal.

Ledger Account Categories can simplify this. They are predefined aggregations that will be kept up to date as you write new transactions. After you create a Ledger Account Category, you can add any number of Ledger Accounts and/or other Ledger Account Categories to it. These can be updated via the API to add or remove additional accounts. Workflows that previously required filtering on metadata or using another data store can now be defined within our system and the associated values retrieved in a single API call.

One common use case is subledgering for an FBO account. You need to keep track of balances on a per customer basis, but you also need to ensure that the total of your tracked balances is equal to what’s showing as the balance on the FBO.

With Ledger Account Categories, you add the Ledger Account for each customer to a Ledger Account Category that maps to the total balance of the FBO account. This lets you easily build in safety checks like reading the balance webhooks from our Payments product and immediately checking them against Ledgers, creating an easy alerting system.

Ledger Account Categories are not strictly hierarchical, meaning that a given Ledger Account can be in multiple different Ledger Account Categories. This flexibility allows for a combination of powerful reporting options alongside operational or product required balances that a hierarchical system couldn’t support.

For example, if you track Customer loan balances broken out by principal and interest, you may need to have a Ledger Account Category to track the total balance of each loan. However, you likely also want to know the total amount of Principal and Interest across your whole system. With Ledger Account Categories you can add the granular loan interest and principal balances to multiple categories.

This flexibility still has guard rails. Ledger Account Categories are smart enough to prevent double counting. If you’re adding Categories to other Categories, we’ll reject any actions that would add the same Ledger Account twice. In this way, we give you the protections of a hierarchical system with the flexibility of a freeform one.

Next Steps

If you're looking to keep balances in your platform or move money in your product, Modern Treasury’s Ledgers simplifies building a double-entry system from scratch. Get in touch with us or find out more here.