Accounting For Developers, Part I: The Fundamentals

Update published August 13, 2025.

Introduction

As a payment operations startup, accounting principles are core to our work. While some of the largest fintechs and marketplaces implement accounting principles at scale, they seem an arcane topic for new startups. This HackerNews thread, for example, is rather representative of the state of confusion around the topic.

Over the years, many guides such as this have tried to explain accounting to developers (for example, these two great pieces from Martin Blais and Martin Kleppmans). But in our experience, a concepts-first approach to explaining accounting comes in handy when you are designing systems that move or touch money.

Whether you're reconciling accounts, tracking balances, or building a ledger from scratch, this series is for engineers working on financial systems. We think that every engineer that builds or maintains such systems benefits from knowing the core principles of accounting.

Because, if you’re building a product that moves money, you’re already in the business of accounting. While traditional accounting might seem abstract or “not for developers,” this guide reframes it in technical terms. You’ll learn how to track balances, avoid financial inconsistencies, and structure systems that scale cleanly.

This three-part series includes:

• Part I (this post): Accounting foundations for engineers
• Part II: Designing a ledger system to power a Venmo-style app
• Part III: Applying principles to build a lending marketplace akin to Lending Club

Who Should Read This Guide?

This guide is for:

• Developers at fintechs building products that move or hold money.
• Engineers integrating payment providers, ACH, RTP, or card systems.
• Product teams designing wallets, marketplaces, or accounting features.

If you write code that touches financial data, this guide will help you reduce bugs, align internal records with banking systems, and avoid common pitfalls.

Why Developers Need to Understand Accounting

Double-entry accounting is the most reliable way to track money. It ensures every financial event is recorded accurately, with a clear source and destination for funds.

As a payments infrastructure company, we often get to see the architecture of some of the most successful software companies. Top companies rely on double-entry principles. Some build their applications from the start with accounting concepts in mind, but in most cases, companies need to retrofit them after painful incidents involving missing funds, broken payout flows, or inconsistent balances.

When software fails to track money properly, it does so in a number of common patterns. The most common failure mode is software accidentally creating or destroying records of funds. This leads to all sorts of inconsistencies. Every developer we know has horror stories about explaining to their finance team why a customer is owed money or what caused a payout to have an unexpected amount:

• Internal records differing from bank statements
• Reconciliation engines mismatching
• Balances that don’t make sense given a set of transactions

For more evidence that double-entry systems are a good standard for scalable applications, see the stories of Uber, Square, and Airbnb.

The core principle of double-entry accounting is that every transaction should record both where the money came from and what the money was used for.

With double-entry, you can:

• Reconstruct balances as of any date
• Track money movement with full auditability
• Align system logic with real-world finance

Core Concepts: Accounts, Transactions, and Ledgers

Let's break down the building blocks of an accounting system.

What is an Account in Accounting?

An account is a segregated pool of value. The easiest analogy here is your own bank checking account: money that a bank is holding on your behalf, clearly demarcated as yours. Any discrete balance can be an account: from a user’s balance on Venmo to the annual defense spending of the United States. Accounts generally correlate with the balances you want to track.

In accounting, accounts have types. More on this later.

How Transactions Work in a Ledger

A transaction is an atomic event that affects account balances. Each transaction:

• Has at least two entries, each of which corresponds to one account
• Affects two or more accounts
• Keeps the ledger balanced

Let’s use a simple Venmo transfer as an example. Van is sending $50 to Tai:

The entries in this transaction tell which accounts were affected. If each user’s balance is set up as an account, a transaction can simultaneously write an entry against each account. This ensures the total money in the system doesn't change, it just moves.

Now, let’s expand this model with more accounts and a handful of additional events:

Here I have a ledger—a log of events with monetary impact. We often see developers mutating balances directly rather than computing a balance from a log of transactions. This is suboptimal.

While mutating a balance directly is more efficient and simpler to implement, it’s more accurate to store immutable transactions and always compute balances from those transactions. Mutating balances directly creates a system that is prone to errors, as it becomes non-trivial to detect and reconcile inaccuracies.

Notice how each transaction has multiple entries. Each entry belongs to a transaction and an account. By comparing entries side by side, you can see where the money came from and what it was used for.

Double-entry ensures that, as transactions are logged, sources and uses of funds are clearly shown, and balances can be reconstructed as of any date:

This core idea—one transaction, at least two entries, one representing the source and the other representing the use of funds—is one of the foundational ideas of double-entry accounting [1]. We’ll expand more on this later.

Understanding Debit Vs. Credit Normal Accounts

As mentioned before, each account has a type. The two types we will cover here are debit normal and credit normal.

By definition:

• Accounts that represent funds you own, or uses of money, are debit normal accounts.
  • Debit normal accounts increase with a debit entry and decrease with a credit entry.
  • Examples of uses of funds are assets (e.g., cash) and expenses.
  • Note: The term “use” here is broadly defined: letting cash sit in a bank account is a use of funds, as well as selling on credit to someone else (you are effectively ‘using’ the money you’d get on a sale by extending them credit).
• Accounts that represent funds you owe, or sources of money, are credit normal accounts.
  • Credit normal accounts increase with a credit entry and decrease with a debit entry.
  • Examples of sources of funds are liabilities, equity, or revenue; this can mean investors' capital, accumulated profits, or income.
  • Note: “Source” is broadly defined here, too: if you are buying on credit, for instance, that is a “source” of money for you in the sense that it prevents you from spending money right now.

Let’s illustrate that with a simple table with two columns, the right side listing credit normal accounts and the left side listing debit normal accounts. We will place accounts that track uses of funds on the debit normal side and accounts that track sources of funds on the credit normal side.

Buying inventory? That's a use (debit). Taking out a loan? That's a source (credit).

What are Debits and Credits in Accounting?

Some of the guides we mentioned at the beginning of this post advise developers to “save the confusion and flush out debits and credits from your mind.” We do recognize that debits and credits can be challenging to grasp, but we think fully mastering these concepts is important when creating transaction handling rules.

Part of the confusion is that “debits” and “credits” are often used as verbs: to debit or to credit an account, which trip up developers. Debits and credits can also refer to entries. Here's the simplest way to think about them:

• Debit entry: Adds to a debit normal account or subtracts from a credit normal account
• Credit entry: Adds to a credit normal account or subtracts from a debit normal account

In software terms, it's like flags for how a value should affect a given account based on its type.

Let’s continue to model out a few transactions to drive this point home. Let’s use a fictitious startup called Modern Bagelry—an eCommerce store for premium bagels.

In this example, we will use four accounts: Cash and Inventory (both debit normal accounts) as well as Equity and Loans (both credit normal accounts). Let’s say this ledger starts on a day T, and we are measuring time in days.

A common misconception is that one account needs to decrease while another needs to increase. However, they can both increase or decrease in tandem, depending on the debit and credit entries in the transaction and the account types. In the first transaction cash increases because it’s a debit entry in a debit normal account (cash); equity also increases because it’s a credit entry in a credit normal account (equity). Conversely, in the last transaction both balances decrease because we are adding a debit entry into a credit normal account (loans) and a credit entry into a debit normal account (cash).

How to Ensure Your Ledger is Balanced

The power of double-entry comes from ensuring the sum of al credit normal balances always equals the sum of all debit normal balances.

Let’s say we are aggregating the balances for each account in the example above right after each transaction takes place:

A system of accounts will balance as long as the balance on debit normal accounts equals the balance on credit normal accounts.

• The ending balances of debit normal accounts, Cash ($1.22M) and Inventory ($250k), sum to $1.47M.
• The ending balances of credit normal accounts, Equity ($1M) and Loans ($470k), also sum to $1.47M.
• Total Debits = Total Credits.

Our Ledger is balanced. Not matching would mean the system created or lost money out of nothing.

Summary: Accounting Principles Developers Should Know

Let’s recap the principles we reviewed so far:

• A ledger is a timestamped log of events that have a monetary impact.
• An account is a discrete pool of value that represents a balance you want to track.
  • Accounts are classified as debit normal or credit normal.
• A transaction is an event recorded in the ledger.
  • Transactions must have two or more entries.
• Entries belong to a ledger transaction and also belong to an account.
  • Entries change balances based on account type and entry direction.
    • Debits—or entries on the debit side—increase the balance of debit normal accounts, while credits decrease it.
    • Credits—or entries on the credit side—increase the balance of credit normal accounts, while debits decrease it.
• The system is correct if the sum of balances of all credit normal accounts matches the sum of balances of all debit normal accounts. This means all money is properly accounted for.

What's Next?

In Part II, we’ll add some complexity to transaction structures, and we’ll bring everything together by doing a walkthrough of how to build a Venmo clone.

Modern Treasury Ledgers gives developers the tools to design scalable, GAAP-friendly double-entry systems—no accounting background required. Contact us to learn how to integrate a reliable ledger into your stack.