Learn the bookkeeping behind an explainable business

Start with a business event, follow its entry into the accounts, and learn which checks make the resulting balance worth trusting.

These lessons use original fictional examples. They teach general bookkeeping, not a tax regime or a supported statutory framework. A software demonstration and an accountant’s review remain different kinds of evidence.

What should you learn first?

Learn the relationship between an event, its accounts and its source before trying to memorise reports or software screens.

A bank balance is familiar, but it does not explain why the money is there. A receipt may be earned income, borrowed money or owner funding. A payment may be an expense, a debt repayment or an asset purchase. The first skill is identifying the event. The second is recording its effects consistently. The third is checking those records against evidence that did not come from the same entry screen.

This library follows that order. You can read it without using PHP Ledger; the examples are small enough to work on paper. The product-specific sections at the end of each lesson then show where the existing software helps and where its scope stops.

Which lesson answers your question?

Use the sequence below for a first pass, or jump to the control you are trying to understand.

1. Double-entry bookkeeping
2. Debits and credits
3. Journal entries
4. Chart of accounts
5. Trial balance
6. Profit and loss versus balance sheet
7. Cash versus accrual
8. Bank reconciliation
9. Correcting mistakes
10. Opening balances and cutover

How do the first five lessons connect?

They move from the double-entry relationship to the account balances you can inspect in a trial balance.

Double entry asks what changed and why. Debits and credits translate that explanation into account directions. A journal entry brings those lines together with a source and date. The chart gives recurring events consistent categories. The trial balance checks the relationship between the resulting debit and credit balances.

None of these controls can do every job. A journal can balance with a wrong amount. A chart can be consistent but unsuitable for the business. A trial balance can agree while a complete transaction is missing. Learning those limits is as important as learning the mechanics.

What is the shared worked example?

A fictional business starts with no balances, earns and receives 1,000.00 for a completed service, then pays a 125.00 operating expense.

With one currency, no tax and no other activity, cash closes at 875.00. The stated income less expense is also 875.00. The lessons then vary one assumption at a time: a loan explains why cash is not always profit; an unpaid service explains recognition versus settlement; an uncleared payment explains a bank timing difference; a wrong expense amount explains a reversal.

Every variation says what it changes. Do the same in your own exercises. A useful example is one you can reproduce from its assumptions, not a realistic-looking table with unexplained totals.

Why learn controls before adding complexity?

More transactions do not repair a weak starting record. Small examples expose misunderstandings while the evidence is still easy to follow.

• Check the company, book, date and currency before comparing figures.
• Retain the source reference behind every entry.
• Distinguish saving a draft from posting a balance.
• Investigate duplicates and missing events even when totals agree.
• Keep corrections linked to the original history.
• Reconcile external evidence rather than forcing agreement.

Once these habits are reliable, more specialised subjects become easier to scope. Inventory costing, customer allocations, foreign exchange and tax each add rules; they do not replace the need for a traceable source and balanced accounting.

How should you use the glossary and guides?

Use definitions when a word is unclear and worked guides when you want to inspect an actual product path.

The glossary separates account types, reporting terms and software concepts. The guide library connects those concepts to synthetic screens and release-specific steps. Keep that distinction visible: a concept can be valid even when a particular application has not implemented its complete operational workflow.

For a first practical exercise, use the daily cash check, then the monthly review. Write down the expected result before opening the report. If the result differs, investigate rather than editing the expectation to match the screen.

What does PHP Ledger currently contribute?

It provides an inspectable core for drafts, balanced posting, linked history, account ledgers and basic reports, with defined preview limits.

The 0.4.0 starter adds customer invoices, supplier bills, partial payments, credits and ageing. Optional Inventory and Purchasing add stock costing and receipt matching; core tax uses manually configured codes and rates. Tax filing and a complete statutory reporting package remain outside this release. Use the current product description to distinguish a foundation from a workflow you can operate today.

When PHP Ledger is not the right choice

Use a mature system when missing business modules are essential to your immediate work, or when nobody can maintain a self-hosted installation.

Read the comparison questions before committing real records. If your question is which accounting treatment or filing rule applies, ask a qualified adviser. These lessons are a way to understand the conversation, not a substitute for that decision.

What should you do after reading?

Explain one transaction, predict its account balances, and ask another person to follow the source trail.

If they can reproduce the result, you have more useful evidence than a memorised definition. If they cannot, identify the missing assumption or record. Keep practising with fictional data until the reasoning is clear.