Debits and credits are directions, not judgements

Most people meet debits and credits through a mnemonic, memorise it, and quietly never feel confident about them again. The mnemonic is not the problem. The problem is that it is usually taught as a rule to obey rather than a consequence of something simpler.

Here is the something simpler.

Debit means left. Credit means right.

That is the entire definition. Not "debit means increase", not "credit means money coming in", and definitely not "debit is good". Debit and credit are the names of the two columns in a ledger account, and they mean nothing beyond which side.

The words are historical baggage. Debit comes from the Latin for "he owes", credit from "he trusts" — useful to a Florentine merchant tracking who was in and out of pocket, actively misleading today. Banks made it worse: when your bank says it has "credited your account", it is describing its own books, where your deposit is a liability it owes you. Your money going up is, from the bank's side, a credit. From your side it is a debit. Both are correct, and the confusion is entirely the fault of the vocabulary.

So drop the intuition. Debit is left, credit is right.

Why the same side means different things

If debit just means "left", why does debiting cash increase cash while debiting a loan decreases the loan? Because of where each account sits in the accounting equation:

Assets = Liabilities + Equity

Assets are on the left of the equation. Liabilities and equity are on the right. And an account increases on the side of the ledger that matches the side of the equation it lives on:

That is the whole system. One table, derived from one equation. Nothing else to memorise — and if you ever forget a row, you can rederive it by asking which side of the equation the account belongs to.

Income and expenses need one extra step of reasoning, because they are not in the equation directly. They describe movements in equity. Earning revenue makes the business more valuable to its owners, so income behaves like equity: it increases on the credit side. Incurring an expense makes it less valuable, so expenses work the opposite way and increase on the debit side. Module 2 comes back to this — it is why income and expense accounts reset every year while assets and liabilities carry forward.

Why the equation stays true

Now the mechanism becomes visible. Every entry puts equal amounts on the left and the right. So either:

• both sides of the equation move by the same amount (you borrow RM20,000: assets up, liabilities up), or
• two things on the same side move in opposite directions and cancel out (a customer pays you RM10,000: cash up, receivables down — assets unchanged in total).

There is no third case. Any balanced entry does one of these two things, which is why no correctly recorded transaction can ever break the equation. This is not a coincidence to be grateful for; it is the direct consequence of requiring debits to equal credits.

The trap worth naming

The single most common error is reading debit and credit as good and bad. It leads people badly astray, because:

• Debiting an expense — recording that money was spent — is a debit, and spending money is not "good".
• Crediting revenue — recording a sale — is a credit, and making a sale is not "bad".
• Debiting a liability means paying down a debt, which is usually excellent.

There is no moral content in either word. They are directions. Once you genuinely believe that, entries stop being a puzzle and become a description: what went up, what went down, and on which side of the equation each of them lives.

Knowing the rule and applying it under time pressure are different skills. Here is the procedure that works, and the checks that catch you when it doesn't.

The four questions

For any transaction, in order:

1. What did the business gain or lose? Name the two accounts involved. This is the hard part, and it is a judgement about the business, not about bookkeeping.
2. What type is each account? Asset, liability, equity, income or expense.
3. Is each one going up or down?
4. Which side does that put it on? Up on its natural side, down on the other.

Worked through a rent payment of RM3,500:

1. Cash left the business; the reason was rent. Accounts: Cash, Rent expense.
2. Cash is an asset. Rent is an expense.
3. Cash goes down. Rent expense goes up.
4. Assets increase on the debit side, so a decrease is a credit to cash. Expenses increase on the debit side, so an increase is a debit to rent expense.

Entry: debit Rent expense RM3,500, credit Cash RM3,500.

Notice that step 1 did the real work. Steps 2 to 4 are mechanical once you have named the accounts — which is why the chart of accounts, the subject of module 2, matters as much as it does.

In Cynco

Most entries arrive already formed. Issue an invoice and the entry is written for you; categorise a bank transaction and the same. Where you will apply this directly is in Accounting → Journal, creating a manual entry — accruals, adjustments, depreciation, corrections, opening balances.

When you do, two things are worth knowing:

• The debit and credit totals are shown as you type, and the entry cannot be posted until they agree. Treat a stubborn imbalance as information: it almost always means a mistyped amount or a line you have not finished, not a rounding quirk.
• The account picker is filtered to postable accounts. If an account you expect is missing, it is likely a header account — a grouping label rather than something you can post to. Module 2 covers that distinction.

An exercise that builds the reflex

Work these four out on paper before checking them in the app. Name both accounts, both types, and both sides:

1. A customer pays a RM10,000 invoice they owed you.
2. You buy a RM1,200 laptop with the company debit card.
3. You take a RM20,000 bank loan.
4. You repay RM2,000 of that loan.

Then check yourself:

1. Debit Cash, credit Accounts receivable. Both assets — one up, one down. Total assets unchanged; you converted a promise into money. Revenue is not touched, because it was already recognised when the invoice was issued.
2. Debit Equipment (or an expense, if your policy is to expense small items), credit Cash. The debit card matters: it takes the money from the bank, so cash goes down. A credit card would credit Credit Card Payable instead, and cash would not move until you settle the card.
3. Debit Cash, credit Bank loan. Assets up, liabilities up — the equation grows on both sides.
4. Debit Bank loan, credit Cash. Both go down. A debit reducing a liability is the case that most often trips people up.

Number 1 is the one to remember. Crediting revenue again on payment is the most common beginner error in double-entry, and it silently doubles your reported sales. Module 5 shows exactly why the receivable exists to prevent it.

When you are stuck

Ask what happened to cash. Cash is the most concrete account and the one you can usually reason about with certainty. Pin down its side first, then the other side is whatever explains it.

How should a database represent "this line is a debit of RM3,500"? The question sounds trivial and the answers differ in ways that matter.

Three candidate designs

One: a signed amount. A single amount column, negative for credits.

amount numeric(18,2)  -- 3500.00 debit, -3500.00 credit

Compact, and the balance check becomes SUM(amount) = 0, which is elegant. But it invites sign errors everywhere: every report has to remember which types read naturally negative, ABS() starts appearing throughout the codebase, and a display bug turns a credit into a debit silently because the two are one character apart. Worse, "negative amount" now has two possible meanings — a credit, or a genuinely negative value someone entered by mistake — and no constraint can distinguish them.

Two: an amount plus a side.

amount numeric(18,2) NOT NULL CHECK (amount > 0),
side   text NOT NULL CHECK (side IN ('debit','credit'))

Amounts are always positive, which the CHECK can enforce absolutely. The side is explicit and self-documenting. The cost is that every aggregation needs a CASE, and the balance check is a little wordier.

Three: two columns.

debit  numeric(18,2) NOT NULL DEFAULT 0 CHECK (debit  >= 0),
credit numeric(18,2) NOT NULL DEFAULT 0 CHECK (credit >= 0),
-- exactly one side carries the amount
CHECK ((debit > 0) <> (credit > 0))

This is what most accounting systems use, including the teaching engine in this course. It maps directly onto how a ledger is read, aggregates trivially (SUM(debit), SUM(credit)), and the balance rule is a clean comparison of two sums.

That last CHECK is doing real work, and it has to say exactly one. NOT (debit > 0 AND credit > 0) rules out the line that is somehow both a debit and a credit, but it still admits a line where both columns are zero — a posting to an account that moves nothing, which balances perfectly and is invisible in every total. The exclusive form rejects both nonsense cases with one constraint.

The tradeoff is a slightly wider row and one always-zero column per line. That is a rounding error in storage terms, and you buy readability and constraint-friendliness with it.

Notice the common thread: two of the three designs let the database enforce correctness with CHECK constraints. That is the deciding factor, not elegance.

Natural side belongs on the account type, not the line

A line records which side an amount is on. Whether that side increases the account is a property of the account's type:

const NATURAL_SIDE = {
    asset: "debit",
    expense: "debit",
    liability: "credit",
    equity: "credit",
    income: "credit",
} as const;

One lookup table, defined once. Every report that needs to show a balance "in the natural direction" consults it rather than reimplementing the rule — and there are many such reports, which is exactly why the rule must live in one place.

Get this wrong and the failure is quiet. Type an expense account as an asset and its balance flows to the balance sheet instead of the P&L. The trial balance still balances perfectly. Profit is overstated and assets are overstated by the same amount, and nothing in the system complains. Module 2's technology section returns to this, because it is the strongest argument for account type being a constrained enum rather than a free-text field.

Why not store per-account balances?

The tempting optimisation is a balance column on each account, updated on every posting. It makes reading a balance instant.

It also creates a second source of truth. Now the entries say one thing and the cached balance says another, and they can drift — through a failed transaction, a concurrent update, a bug in one of the many code paths that post, or a data migration that inserts entries without going through the update. Every system that has tried this eventually ships a "recalculate balances" button, which is an admission that the cache was wrong.

The safer default is to derive balances from the lines and let the database aggregate. When that genuinely becomes too slow, the fix is a cache you can rebuild and verify against the source — period-scoped aggregates, materialised views, snapshot rows — never a figure that only exists in one place. Module 6 covers this properly, along with why reports are pure functions over posted entries.