Model normal debit and credit accounts

Most explanations of double-entry begin with debits and credits. That is like explaining a database by starting with INSERT and DELETE before describing the schema. The operations are simple once you know what they operate on. Without the schema, they are arbitrary words, and the mnemonics people invent to memorize them are the proof.

This guide assumes the schema exists: the five account categories and what each one measures. On top of that structure it adds one property per account - its normal balance, the side that makes it go up - and derives it rather than asking you to memorize it. By the end you can look at any account in your tree and predict whether a debit or a credit entry increases it, which is the last prerequisite for posting a first ledger transaction.

No accounting background is assumed, but one warning is worth having up front. Debit and credit are not synonyms for money in and money out. Your bank uses those two words from inside its books, not yours, so the intuition you already have is inverted, and that single crossed wire is most of the difficulty.

Debit and credit are directions, not verbs

Here is the single sentence that unblocks most engineers: debit means left, credit means right. That is the whole definition. They are not “in” and “out”, not “plus” and “minus”, not “money received” and “money sent”, and neither one is good or bad. A debit entry is an entry on the left side of an account, a credit entry is an entry on the right side, and what either one does to the balance depends entirely on the account it lands in.

Here is where that inverted intuition comes from. Your bank says it credited your account when money arrives, which reads as “credit means more money”. But that message is written from the bank’s books, not yours. Your deposit is money the bank owes you, so on their side it is a liability, and a credit increases it. On your own books the same event is a debit, because your asset went up. Same event, opposite direction, because there are two sets of books and you are only ever shown one of them.

The equation is a consequence, not a rule

Every amount of money has a source and a use, and a ledger records both ends of every movement. Write down every use on one side and every source on the other, and the two sides are equal by construction. Group them by category and you get the accounting equation:

Assets = Liabilities + Equity

Everything you hold came from somebody. Look at the balance in your Stripe account and every dollar of it arrived from one of four places: a funding round (equity), a venture debt facility (liability), the sellers whose money you are holding (liability), or commission you earned and kept (equity, via income). Rearranged, the equation says something more useful:

Equity = Assets - Liabilities

Which is the distinction that matters most to a platform holding money for other people. One holding $2M of which $1.8M is owed to its users does not have $2M. Assets are $2M, liabilities are $1.8M, and the equity, the part that is actually the company’s, is $200k. One balance column cannot say that. Two sides can, and they always have to agree.

This equation is usually presented first, as the thing to accept. It is better understood last, as the thing that falls out. You do not maintain it. It is a restatement of the fact that you recorded both ends of every movement.

Normal balance: the side that makes an account go up

Every account inherits its category from its position in the tree, and the category fixes which direction increases it. That direction is the account’s normal balance. You do not choose it per account, and you cannot: it follows from where the category sits in the equation.

Assets are on the left of Assets = Liabilities + Equity, so they increase on the left, which is debit. Liabilities and equity are on the right, so they increase on the right, which is credit. Income and expenses are equity in motion: income is a source that adds to equity, so it increases on the right like equity does, and an expense reduces equity, so it goes the other way.

There are mnemonics for this table. Skip them. The derivation above is two sentences long and, unlike a mnemonic, it still works when you meet an account type you have not seen before.

The four rules, and why there are only four

Two directions times two kinds of account is four combinations, and that is the complete rule set. Nothing else is hiding behind it.

Read it as a sign rule rather than four facts: an entry on the account’s normal side adds, an entry on the other side subtracts. The table is just that sentence, expanded.

A normal debit account is not a debit-only account

The word “normal” does less work than it appears to. Every account can receive both operations. Its normal side is simply the side that increases its ordinary positive balance.

• assets:stripe-balance is a normal debit account. A debit entry increases it and a credit entry decreases it - and it receives credits constantly, every time you pay a fee or a seller.
• liabilities:payables-sellers/9001 is a normal credit account. A credit entry increases it and a debit entry decreases it - and the debit is not an anomaly, it is what paying the seller looks like.

So never say “a debit account” when you mean “a normal debit account”. The first phrase collapses the account and the operation into one concept, and that collapse is the root of most debit-and-credit confusion. The account has a type. The entry has a direction. The four rules above connect them.

The first entry on an account does not have to be on its normal side either. Imported history, corrections, and refunds can all open with the opposite operation. The useful rule is narrower:

To increase an ordinary positive balance, post on the account’s normal side.

Read the categories as source and use

There is an intuition behind the two groups, and it is the same source-and-use idea the equation came from. For common business events, the credit-normal categories explain the source of value, or the economic reason you have it. The debit-normal categories show the resource that resulted, or how the value was used.

SOURCE / EXPLANATION                 RESOURCE / USE
Credit-normal                        Debit-normal

Income       ──────────────────────▶ Assets
Liabilities  ──────────────────────▶ Assets
Equity       ──────────────────────▶ Assets
Income       ──────────────────────▶ Expenses

Here are concrete versions of the same arrows:

Service income       ──────────────▶ Cash
Service income       ──────────────▶ Accounts receivable
Bank loan            ──────────────▶ Cash
Bank loan            ──────────────▶ Equipment
Founder contribution ──────────────▶ Cash
Service income       ──────────────▶ Hosting expense

The right side tells you where value is or how it was consumed:

• Cash means the value currently exists as cash.
• Accounts receivable means it exists as a right to collect.
• Equipment means it exists as a productive resource.
• Hosting expense means it was consumed as hosting.

The left side explains why the company had that value:

• Income means the business earned it.
• Liabilities mean the business received a resource together with an obligation.
• Equity means an owner contributed it, or prior results accumulated for the owners.

This is a teaching model, not the definition of debit and credit, and it has limits worth stating. Not every transaction flows from a credit-normal account into a debit-normal one. Repaying a loan reduces a liability and an asset together. A refund reverses a flow. Moving money between two asset accounts never touches a source at all. The model explains the roles of the categories. The four rules govern every entry, in every direction.

Cash and income answer different questions

In everyday language, “we made money” can mean several different things:

• we completed the work
• we sent an invoice
• the customer now owes us
• the customer paid us
• the payment reached our bank

Accounting separates those events because they can happen on different dates, and the account model is what holds them apart. Suppose you deliver $100 of consulting today and the customer will pay in 30 days. You have earned income, but you have not received cash. The value currently exists as a receivable - an asset, because a right to collect is a resource you control. Thirty days later the customer pays, and the value changes form from a right to collect into cash. The second event does not create more income. It moves an existing asset between shapes.

The reverse timing is also possible. A customer prepays $100 for work you have not done. You have cash, but you have not earned income: until you deliver, the prepayment is a liability called deferred income, because you owe the customer work or a refund. Accountants call the first situation accrued income and the second deferred income. The terms matter less than the distinction:

Earn first, collect later:  Income → Receivable → Cash
Collect first, earn later:  Cash + Liability → Income when earned

Cash answers “what monetary resources do we control now?” Income answers “what value did we earn during this period?” They are related, and they are not interchangeable. Every one of these timing shapes becomes a two-line posting in the transaction guide’s worked examples.

Why not just use positive and negative numbers?

A fair objection, and worth answering honestly rather than waving at tradition. You can build a working ledger with signed amounts and a constraint that every transaction’s entries sum to zero. Some do. The maths is the same.

What the debit and credit convention buys you is three specific things:

1. Every stored amount is positive. In a financial system a negative number is almost always a bug, so a schema where negatives cannot be represented is a schema where a class of errors cannot occur. Direction is a separate field with two values.
2. “Increase” is not a property of the amount. It is a property of the pair (direction, account). A credit of $900 increases a liability and decreases an asset. Storing the direction keeps the entry meaningful without also knowing the account’s category, which matters because the same entry is read by code that does not care.
3. The check compares two positive sums. sum(debits) = sum(credits) is the same check an auditor runs by hand, on the same numbers, which is a real advantage the first time somebody outside engineering has to confirm your figures.

There is a historical reason too, and it is more than trivia: the method predates the routine use of negative numbers in European bookkeeping by a long way. It was designed to work without them. That constraint is why the rules look the way they do, and knowing it makes them stop feeling arbitrary.

Where the model stops

The source-and-use model is deliberately simpler than all of accounting. Contra accounts have the opposite normal balance from their parent category: accumulated depreciation, for example, relates to assets but normally carries a credit balance. Unusual states can put an ordinary account on its non-normal side. And accounting standards add rules about when income, expenses, assets, and liabilities should be recognized, which no normal balance can decide for you.

None of those limits changes the account-modeling workflow:

1. Identify the economic quantity you need to measure.
2. Decide whether it is a resource, an obligation, an ownership interest, earned value, or consumed value.
3. Place the account under assets, liabilities, equity, income, or expenses.
4. Let that type determine its normal side.

The account model in one screen

Normal debit                         Normal credit
Assets                               Liabilities
Expenses                             Equity
                                     Income

                         Debit entry       Credit entry
Normal debit account      increase           decrease
Normal credit account     decrease           increase

An account type describes economic meaning. A normal side describes how its ordinary positive balance increases. Neither one describes a particular event, and that separation is the entire trick.

Where this goes next

The missing layer is the event itself: how several entries form one balanced transaction, and why the ledger can reject an incomplete one at write time. Post your first double-entry ledger transaction turns this account model into postings, using the same marketplace order throughout.

If the five categories themselves are still unfamiliar, create the ledger structure builds them from zero and covers the filing mistakes that survive every arithmetic check. On the product side, Accounts explains control accounts, template accounts, and human-readable slugs, and Transactions shows the posting API these rules feed into.