Debits and Credits, for the Befuddled

Debits and credits are the foundation of classical double-entry bookkeeping, but unless you’re an accountant (or just really interested in accounting concepts), they can be confusing because they are ambiguous. Any given transaction is both a debit and a credit at the same time. It just depends on which side of the transaction you’re on. It’s worth taking a little time to get clear on the concept of debits and credits, liabilities and assets. But once we have a basic understanding of those concepts, when thinking about core ledgers we can replace these concepts with analogs more familiar to engineers, sources and destinations.

Moving Money: Debits and Credits

If you’re new to the world of accounting, you might reasonably believe based on your experience with your bank account that a debit is a reduction in an account balance, and a credit is an increase in an account balance, because this is how the movement of money in your bank account is represented to you. But in accounting practices, it’s actually more subtle. Because your bank statement is presented to you from the bank’s perspective, the terms get confused.

• A credit: decreases an asset, or increases a liability.
• A debit: increases an asset, or decreases a liability.

The (simplified) fundamental equation that must be balanced when doing accounting is this:

Put differently, for every transaction, there is one credit and one debit, and these are recorded separately for double-entry bookkeeping. Each transaction impacts a set of business’s assets and liabilities at the same time, in the same amount.

Money in your account is an asset—it’s cash on hand for the bank to use to fund home mortgages for example. But it’s also a liability—the bank owes you that money on demand. So when you withdraw money at an ATM, it is a debit in the sense that it decreases the bank’s liability to you. And it is a credit in the sense that it is value flowing out of the bank's cash or cash-equivalent assets accounts. That the bank reports this to you as a debit on your account is only half the story, as you can see.

We can look at it the other way too, if you were to deposit money into your account. On one hand, this transaction is recorded by the bank as a credit, because it increases its liability to you. On the other hand, it is also recorded as a debit because it is value flowing into the banks cash assets accounts (which they will promptly and happily transmute into another type of non-cash asset).

So, the concept of debits and credits is more complex than mere decreases and increases in account balances, because any given transaction in that account will count as both a debit and a credit against the bank’s assets and liabilities.

This traditional way of viewing the flow of value has a lot of advantages for helping accountants and auditors understand the financial state of a business. But when we’re building a core ledger to manage transactions among our users, our goals are different and we can use a simpler, more engineering-friendly conceptualization of the movement of money.

Sources and Destinations

Suppose we’re operating a two-sided marketplace. We have sellers and buyers. Each of them has an account. The buyer has an account that is used to make purchases and receive refunds and gift cards. The seller has an account that accrues revenue from sales, and is used to process refunds and pay platform fees.

It doesn’t make sense to view any of these accounts as assets or liabilities. Our interest as the marketplace is tracking the flow of funds through the marketplace: Did the seller get paid? Was the refund processed correctly? Are the correct platform fees being collected? For these kinds of questions, it makes more sense to think of transactions as flows of value between sources and destinations. This is a much simpler model to conceptualize, and a much simpler model to code for.

Here is a simplified example. A buyer wants to purchase an item from a seller on your hypothetical platform, for a cost of €100. The buyer’s account is the source of the flow, and the seller’s is the destination. We can represent this flow visually:

  +---------+                €100                 +---------+
  |  Buyer  | ----------------------------------> | Seller  |
  +---------+                                     +---------+

Or, using NumScript, a domain-specific language developed by Formance for modeling financial transactions in a core ledger, we can describe the flow of funds this way:

send [USD 100] (
  source = @customer
  destination = @seller
)

This model of monetary movement is easier to understand in this context, because we don’t care which accounts are assets or liabilities for which of our customers. We don’t care whether a transaction is a credit or a debit. We only care that the buyer’s account has €100 less and the seller’s account has €100 more than they each had before the transaction.

Putting it in practice

Formance Ledger uses a source & destination model instead of a debit & credit model for tracking value flows in your core ledger. The source & destination model is completely unambiguous, carries the same information, and is already familiar to your engineers. This makes integrating Formance Ledger into your app simpler and faster for your engineers, and makes it easier to answer relevant questions you have about the flow of value through your app. At the end of the day, every transaction recorded using the source & destination model can be completely mapped back into a credit & debit model for subsequent reporting and auditing.