Ledgers 101: Overview

So you want to move money! Maybe you’re looking to process recurring business to business payments (B2B), or setup a new online marketplace facilitating social commerce. You need a ledger! You've come to the right place.

‍

Ledgers serve as a detailed record-keeping tool used to track and manage your business’ financial transactions. Without a reliable and trustworthy system of record for your transactions, you’ll have no business (pun intended) moving money.

‍

In our Ledgers 101 series, we’ll explore technical topics and design decisions, as well as the business and operational concerns of building, scaling, and maintaining a financial ledger. Stemming from our experience offering a digital closed-loop wallet, our posts will approach ledger design through the lens of a financial consumer product, though many of the topics covered and lessons learned will still apply to different applications of ledgers.

To start, this post covers a few high level aspects of digital ledgers and sets the stage for how Ansa has tackled some of the common problems and pitfalls you may come across when designing your own ledger.

Why is a ledger so important?

‍In essence, the ledger is the backbone of financial management in a payments product, providing the necessary structure for recording, tracking, and managing financial transactions. While required, they also serve a key tool to:

‍

1. Build and maintain trust by providing customers with real-time, transparent access to accurate balances and clear, easily understood transaction details. Readily providing this clarity into your platform’s activity will foster confidence in your service by allowing customers to independently confirm the accuracy of your statements.
2. Accurately report all financial transactions to internal and external stakeholders, such as accounting teams, regulators, and auditors.
   ‍

If designed well, a ledger should offer a rock-solid foundation on which to build flexible and innovative financial tooling. If designed poorly, a ledger will restrict and slow down your business, leading to a nightmare scenario of financial losses due to unexplained missing funds, difficulties reconciling transactions against other systems, and an inconsistent view of your product transactions.

Different Types of Ledgers:

Everyone needs a ledger, but there are actually many types of ledgers:

• Product Ledger: a ledger purpose-built to serve as the source of truth for your product, in our case a digital financial service. Product ledgers are the most customized type of ledgers because they must be tailored to address the specific business needs of the financial service you provide. Product ledgers will be our primary focus in this series.
• General Ledger: the ledger most accountants interact with, and presents a holistic view of the business’ assets, liabilities, revenue, and expenses. Contains higher level aggregate data combined from a wide range of sources, such as banking transactions, payroll data, and invoicing platforms.
• Shadow Ledger, also known as a Follower Ledger: responsible for recording transaction level data for financial movements happening outside of your product, and a core tool for reconciliation. This type of ledger ensures your product’s transactions align exactly with other systems, such as banks or payment processors. Serves as a simply recording and accounting for transactions that already occurred in other systems rather than a source of truth.

Introducing Double-Entry Ledgers

Double-entry ledgers are the universally accepted and GAAP compliant practice of recording the financial impact of a transaction in at least two accounts. The practice of recording the financial impacts, referred to as Debits and Credits, in separate accounts ensures that these impacts (debits and credits) are always equal for any given transaction.

‍

To briefly cover our terminology, an Account refers to a place that funds can come from and go to. The most common consumer examples are Checking or Savings accounts at a bank, and for businesses an Expense account or a Liabilities account. A Transaction is a general term covering all movements of funds. Using the withdrawal of cash at an ATM as an example, the Accounts impacted would be ‘ATM Cash Account’ and ‘Consumer Checking Account’, with the recorded debits, credits, and any associated description of the activity being the Transaction.

‍

Wait, didn’t I say there were three types of ledgers? Well “double-entry” refers to the structure of the ledger, regardless of the application and therefore can be used for any type of ledger.

Why are double-entry ledgers important?

Our strongly-held opinion is that all types of ledgers should be double-entry. They set you up for success by operating within a framework that helps enforce a consistent application of transactions and prevents errors.

‍

Double-entry ledgers allow you to:

1. Guarantee that funds are never created nor destroyed
2. Enable error detection by providing a consistent method for verifying the ledger
3. Allow for auditing as you can faithfully reconstruct the balance of the account at any point in time along with an explanation for each change in the balance at the transaction level.

The Technical Requirements for Ledgers

Aside from niche, domain-specific use cases, digital ledgers will require a strict focus on performance, durability, concurrency, and immutability.

• Performance: Users will expect a fast experience when it comes to seeing their balance, account histories, and minimal latency when transacting. Maintaining a performant ledger is quite challenging as you balance increasing levels of traffic, offering real time aggregations as needed, and evolving the ledger to support more nuanced or multipart transactional flows.
• Durability: While it feels like a given with ubiquitous ACID databases, it is an absolute necessity to ensure your financial history is preserved in the event of an application crash, server shutdown, or worst case a datacenter outage
• Concurrency: This means handling two transactions involving the same accounts occurring at the same time. Effective handling of concurrency is vital for maintaining a consistent and accurate ledger. The bugs that arise from concurrency can often be the hardest to identify or effectively test for, but can be especially pernicious in financial applications. One of our future posts will focus on the trials and tribulations of managing concurrency.
• Immutability: Transactions and their impacts to various accounts cannot be altered, only new transactions added. While outside the internet-age norm of editing, immutability is essential to offering a trustworthy view of financial records. Would you trust a bank if they altered your listed deposits and withdrawals from two months ago?
  ‍

The Features of a Ledger

Ledgers need a few "bread and butter" features: a user should be able to check their accounts’ balances, review their transaction history, and transact. Additionally, digital ledgers must service key internal operations: supporting easy introspection for finance or accounting teams, and offering an audit log for tracing any deviations from the expected state. A few more advanced concepts that every robust ledger should account for:
‍

• Funds in flight: Any ledger dealing with non-immediate transactions must effectively handle the state of funds, and ensure you prevent spending funds that are already ‘in flight’.  Most  financial transactions take time to process, such as ACH transfers. When a user initiates an ACH transfer to pay a bill, the funds can take anywhere from 1 to 3 business days to arrive in the receiving bank account.
  ‍
• Backdating a transaction: For a myriad of reasons, ranging from someone being out-of-office for a manual process to a scheduled job failing to complete for a period of time, your ledger may need to support ingesting a transaction that happened in the past, sometimes a few days, sometimes a few months. Naturally, backdating a transaction has interesting complications with maintaining an immutable ledger that prevents the alteration of transactions that were already written. Depending on the expectations of backdating a transaction, doing so may create situations that break the rules of your ledger when you consider transactions that have already occurred in between the backdated transaction and the present, potentially causing an account balance that should always be positive to go negative.
  ‍
• Expecting the unexpected: Do not fall into the hubris trap of thinking all bases have been covered and live activity will always go as planned. Just as humans make mistakes, software has bugs, both in the code you write and in the systems your application interacts with. Not to mention your business and use cases will evolve. Devising an approach for reverting operations when needed while still maintaining the reliability and consistency a ledger demands is no trivial task.

As we expand on the Ledger 101 Series, we’ll continue to dive in and demystify everything accounting from the nuts and bolts to the intricate and nuanced. Stick with us as we press forward in our exploration of how Ansa built our immutable, robust, double-entry ledger at the core of our closed-loop, stored value financial platform!