_ENGINEERING/
Debits and Credits Explained
By Formance Staff
Ledger
Accounting
Payments
Loading article content
Loading table of contents
Loading author
Ask two ledger engineers whether a refund is a debit or a credit and you will get two confident, opposite answers. Both can be right.
Debits and credits are the foundation of classical double-entry accounting, and every engineer building a ledger or payment system eventually runs into them when someone asks whether to record a refund as a debit or a credit.
Unless you're an accountant (or just really interested in accounting concepts), the terms can be confusing because they are ambiguous in everyday use. Any given transaction is both a debit and a credit at the same time, and it depends on which side of the transaction you're on.
The engineering shortcut is to stop thinking in debits and credits altogether and think in sources and destinations (where value flows out of, and where it flows into) and let the core ledger enforce the debit/credit mapping underneath. This article defines debits and credits, shows examples, maps the rules to each account type, answers the refund question, and shows how the same balanced postings appear in a core ledger.
A debit (DR) is an entry recorded on the left side of an account, and a credit (CR) is an entry recorded on the right side. That is the whole mechanical definition, with the abbreviations "Dr." and "Cr.", coming from the Latin debere (to owe) and credere (to entrust).
Debits and credits do not have a fixed meaning like "increase" or "decrease." The effect of a debit or credit depends entirely on the account type being posted to. A debit increases some account types and decreases others, and a credit does the opposite.
Bank statements often cause confusion. Money in a personal bank account is a liability to the bank. When the account holder withdraws cash, the bank debits its own liability account, and the customer sees a "debit" on the statement.
A company borrowing $10,000 from a bank requires two journal entries: a debit to Cash and a credit to Notes Payable, each for $10,000. Cash goes up by $10,000 (an asset increases) and the bank is owed $10,000 (a liability increases), so both sides must be recorded:
| Date | Account | Debit | Credit | Memo |
| Mar 1 | Cash | $10,000 | Borrow $10,000 from the bank | |
| Mar 1 | Notes Payable | $10,000 |
Cash is debited because assets increase with debits. Notes Payable is credited because liabilities increase with credits. Both accounts went up, and the entry balances because total debits equal total credits.
Repaying $2,000 of the loan principal a week later posts the mirror-image entry:
| Date | Account | Debit | Credit | Memo |
| Mar 8 | Notes Payable | $2,000 | Repay loan principal | |
| Mar 8 | Cash | $2,000 |
Notes Payable is debited to reduce the liability, and Cash is credited to reduce the asset.
However, in bookkeeping and ledgering, debit and credit describe positions on an account, and not directions of money movement as they are in banking. The loan example records both positions for a single transaction because it follows the double-entry model, one of the two bookkeeping systems used to track debits and credits.
Debits and credits are tracked inside one of two bookkeeping systems: single-entry, which records only one side of each transaction, or double-entry, which records both sides in equal amounts. The two systems differ in how much information each captures and whether they can detect errors automatically. Core ledgers like Formance Ledger use the double-entry model because it makes posting errors detectable at write time.
Single-entry bookkeeping records each transaction as a single line (date, description, amount in, amount out, and running balance), the same format as a checkbook register. A personal bank statement is a single-entry ledger.
Single-entry captures only one side of every transaction. A single-entry record shows the cash balance went down by $2,000, but does not show why or which other account was affected.
There is no built-in consistency check, so errors can go undetected indefinitely. Single-entry is often sufficient for a company tracking income and expenses, but insufficient for any business that needs to produce financial statements, pass an audit, or reason about assets and liabilities.
Double-entry bookkeeping records every transaction as at least one debit and one credit, in equal amounts, across two or more accounts.
Luca Pacioli first formally described double-entry bookkeeping in Summa de Arithmetica, printed in Venice in 1494. Pacioli placed creditors on the right side of the ledger and debtors on the left, the same convention still used today. When the two sides of the books (or core ledger) diverge, an entry is wrong somewhere.
Double-entry keeps two structures in sync:
The journal provides a timeline of what happened, and the ledger provides a per-account view of where each balance stands. That per-account view is usually drawn as a T-account.
A T-account is the per-account view of the same debits and credits recorded in the journal. It shows a single ledger account with debits on the left (the debit position) and credits on the right (the credit position):
Cash (asset)
Debit (left) | Credit (right)
Opening 500 |
Cash sale 1,000 | Advertising 300
Balance 1,200 |
The ending balance is computed by totaling each side and subtracting the smaller from the larger. The balance sits on the larger side.
In the Cash T-account, debits total 1,500 and credits total 300, leaving a 1,200 debit balance. Because Cash is an asset, its balance sits on the debit side, matching the rule that assets increase with debits.
T-accounts make the double-entry model visible one account at a time. Every debit posted to one T-account has a matching credit in another, and totaling debits across every T-account against total credits is the check that catches posting errors.
Debits and credits are applied to each account type according to fixed rules: assets and expenses increase with debits, while liabilities, equity, and revenue increase with credits. Every account in a double-entry system falls into one of a handful of core types, and each type has a fixed rule for which side increases it.
| Account type | What it represents | Increases with | Decreases with | Normal balance |
| Asset | What the business owns (cash, inventory, equipment and receivables) | Debit | Credit | Debit |
| Liability | What the business owes (loans, payables and accrued expenses) | Credit | Debit | Credit |
| Equity | Owners' residual claim on the business | Credit | Debit | Credit |
| Dividend (equity sub-account) | Distributions of earnings to owners | Debit | Credit | Debit |
| Revenue | Income earned from primary operations (sales and service fees) | Credit | Debit | Credit |
| Expense | Costs incurred to generate revenue (rent, salaries and advertising) | Debit | Credit | Debit |
| Gain | Income from non-primary activities (asset sales and favorable settlements) | Credit | Debit | Credit |
| Loss | Costs from non-primary activities (asset write-downs and lawsuit losses) | Debit | Credit | Debit |
| Contra account | An account paired with another to offset its balance | Opposite of the paired account | Opposite of the paired account | Opposite of the paired account |
A refund is recorded as both a debit and a credit. On a marketplace's ledger, debit the revenue (or seller-payable) account to reduce it, and credit the cash (or buyer wallet) account to reduce the asset holding the buyer's money.
Every transaction, refunds included, has both a debit leg and a credit leg, and the correct posting depends on which account each leg lands in.
From the buyer's perspective on the buyer's bank statement, the refund appears as a credit, because the bank's liability to the buyer is going up. The refund posts to opposite sides on the marketplace's ledger versus the buyer's bank statement.
It's the same transaction, but it appears in two different ledgers with mirror-image entries.
Debits and credits roll up into three core financial statements: the balance sheet, the income statement, and the cash flow statement. Every posted account lands in one of the three:
At period end, revenue and expense accounts are closed into retained earnings so the next period starts fresh. Adjusting entries (accruals, deferrals, and depreciation) align the ledger with what actually happened economically.
The four most common debit and credit mistakes are assuming direction is universal, misclassifying transactions, posting unbalanced entries, and reading a bank statement as one's own ledger.
A debit increases debit-normal accounts and decreases credit-normal ones. Applying the asset rule to a liability account reverses every entry posted to the liability account.
Recording a transaction against the wrong account type reverses its effect on the financials. Booking borrowed cash as revenue, for instance, overstates income and hides a liability that still has to be repaid.
Omitting a leg or entering unequal amounts leaves total debits and total credits out of agreement, and every downstream report inherits the error.
The bank's debits and credits reflect the bank's perspective, and the customer's ledger records the same transaction from the customer's perspective. The two are mirror images.
Each of these mistakes traces back to treating debit and credit as fixed directions rather than positions on an account. Engineers building on a core ledger can sidestep them entirely by describing transactions as flows between accounts, and letting the ledger enforce the debit/credit mapping underneath.
Sources and destinations are an engineering reframing of debits and credits. A source is the account value that flows out of (debited), and a destination is the account value that flows into (credited). The source/destination model sits on top of the same balanced postings accountants and auditors use, but expresses each transaction as a flow of value rather than a pair of positions.
In a two-sided marketplace, each user has an account. The buyer's account makes purchases and receives refunds, and the seller's account accrues revenue and pays platform fees. A finance team will eventually classify each account as an asset or a liability for statutory reporting, but engineering-level questions are different. Did the seller get paid, was the refund processed, were the correct platform fees collected?
For engineering-level questions, transactions are easier to reason about as flows of value between sources and destinations. A buyer purchasing an item from a seller for €10,000 makes the buyer's account the source and the seller's account the destination:
+---------+ €10000 +---------+
| Buyer | ----------------------------------> | Seller |
+---------+ +---------+
Using Numscript, a domain-specific language developed by Formance for modeling financial transactions in a core ledger, the purchase flow is expressed this way:
send [EUR 10000] (
source = @buyers:carol:wallet
destination = @sellers:dave:payable
)
set_tx_meta("type", "purchase")
set_tx_meta("order_id", "ord_8421")
//Refunding that order is the same statement with source and destination swapped, plus metadata linking the refund back to the original transaction:
send [EUR 10000] (
source = @sellers:dave:payable
destination = @buyers:carol:wallet
)
set_tx_meta("type", "refund")
set_tx_meta("refunds_tx", "ord_8421")The engineer never has to decide which leg is the debit and which is the credit. Each Numscript send statement compiles to a balanced double-entry posting: it debits the source and credits the destination. Source/destination is a rename of debit/credit into terms engineers already use.
In production, describe each transaction as a flow from one account to another and let the ledger map the flow to balanced debit and credit postings.
Formance Ledger exposes the source-and-destination model as its transaction interface. The source/destination model makes transaction intent unambiguous at the API layer and is already familiar to engineers: engineers describe where ledger value comes from and where it goes.
Beneath the API, Formance applies the debit/credit mapping, so the resulting balanced postings and customer-defined account structures can feed downstream accounting systems and reporting systems for period-end close, audits, and regulatory filings.
When designing a flow of funds, write it as a source and a destination first, then check the flow against the account-type table above. If the source/destination flow and the account-type mapping agree, the underlying debits and credits were balanced before either side had to be named.