Think of a business's books as a giant inbox. Every time money moves, someone drops a slip into that inbox describing what happened: "Paid ₹5,000 cash for rent," "Sold goods to Ramesh on credit for ₹20,000." That inbox is the journal — a chronological pile of events, in the order they occurred. It tells you what happened, but it is terrible at answering the question you actually care about: how much does Ramesh owe me right now? To answer that, you would have to sift through the entire pile and pick out every slip mentioning Ramesh. Do that for fifty parties and a hundred expense heads, and the journal becomes useless for decision-making.
The ledger solves this. Instead of one pile sorted by time, you keep one separate page (or account) per thing you care about — one for Ramesh, one for Cash, one for Rent, one for each bank, each supplier, each expense. Every slip from the journal gets copied onto the relevant page. Now "how much does Ramesh owe me?" is answered by glancing at Ramesh's page. The journal is the diary; the ledger is the filing cabinet. Same information, reorganised so each account tells its own story.
The shape of a ledger account
A ledger account is a T-shaped page. The left side is Debit (Dr), the right side is Credit (Cr). Every transaction touches at least two accounts, and for each account you record the amount on the side the rules of double entry demand.
For the three families you mentioned, the rules are:
| Account type | Debit (Dr) when… | Credit (Cr) when… |
|---|
| Asset (Cash, Machinery, Furniture) | it increases | it decreases |
| Expense (Rent, Salaries, Wages) | it increases | it decreases (rare) |
| Party / Personal (Ramesh, a supplier, a bank) | the party becomes a debtor — owes us | the party becomes a creditor — we owe them |
So when you sell goods to Ramesh on credit for ₹20,000, Ramesh's account is debited (he now owes you) and the Sales account is credited. When Ramesh later pays ₹20,000 cash, you credit Ramesh (his debt shrinks to zero) and debit Cash (your cash rises).
The running balance
Here is the part that makes the ledger genuinely useful. After each entry, you do not just leave a list of numbers — you compute a balance: the debit side total minus the credit side total, carried forward line by line. This is the running balance, and it is the single most valuable feature of the account.
Balance=Total Debits−Total Credits
If debits exceed credits, the account has a debit balance (normal for assets and expenses). If credits exceed debits, it has a credit balance (normal for liabilities, capital, and income). A party's account can swing either way depending on whether they owe you or you owe them.
The running balance means you never have to re-add the whole column to know where you stand. Ramesh's page might read: debit ₹20,000, credit ₹20,000, balance ₹0 — and you can see at a glance he is settled.
Creating accounts under the right group
In any accounting software — and in manual bookkeeping too — you do not create a ledger account in isolation. You create it under a group, and the group determines the account's nature and therefore its debit/credit behaviour.
The standard groups you will meet first:
- Assets — Cash, Bank, Machinery, Furniture, Debtors
- Liabilities — Creditors, Loans, Outstanding Expenses
- Expenses / Nominal accounts — Rent, Salaries, Wages, Electricity
- Income — Sales, Commission Received, Interest Received
- Capital — the owner's account
When you create Ramesh's ledger, you place it under Sundry Debtors (a sub-group of Assets). The software now knows Ramesh is an asset-type account, so it expects a debit balance and will treat a credit balance as unusual. Create Rent under Indirect Expenses, and it knows Rent is a nominal account that gets closed out at year-end. The group is not decoration — it is what gives the account its meaning.
If you are ever unsure which side to post to, ask what the account is first. Once you know it is an asset, the rule "debit to increase" does the rest. Group first, side second.
Editing and deleting …