We are restoring the requested view from its saved state. Your account and work remain unchanged while you wait.
Back to the track — Financial Accountant
How you will work through this lecture
A customer calls saying they paid; the system says they did not. Your manager asks you three things before calling them back: what is their balance now, where did it come from, and when did it last move. The journal answers none of the three however long you read it, because it is ordered by date and this customer's movements are scattered among a hundred entries that are not theirs. One ledger page answers all three. This lecture is about that page: how it is built, how it is read, and why its balance can be right in total and wrong in the name.
The general ledger is not a second book holding new information; it is the journal in a different order. The journal is ordered by time: you read what happened on the twenty-fourth, entry after entry, as events fell. The ledger is ordered by account: open the cash page and you see everything that came in and went out that month, however scattered the days. Neither holds one fact the other does not; they differ only in their order. The question worth stopping on: why keep the same thing twice?
Because each order answers a question the other cannot. The journal answers: what happened that day, on what document, authorised by whom — which is what an auditor asks when tracing an event. The ledger answers: what does this customer owe now, what did we spend on maintenance this month, what is left in the bank — which is what anybody making a decision asks. Try to find a customer's balance in a list ordered by date and you will read a thousand entries to gather the ten that concern them. Try to find what happened on Tuesday from the account pages and you will open forty of them. The two orders are not a luxury: each is the shape that makes one kind of question cheap.
Posting is taking each line of an entry and placing it on its account's page. A three-line entry posts to three pages and appears on each as a single line — its own. Which is why an account page looks simpler than the entry it came from: it shows not the whole event but the part that touched it. What binds the two is the reference: the voucher number written on the ledger page, so whoever reads a balance can return to the entry that made it, and whoever reads an entry can see where it landed. The road runs both ways, and that is not a refinement but the condition for a figure being provable.
The treatment starts from these documents. Follow the numbers to identify recognition date, amount, counterparty, reference and approval evidence before preparing the entry.
Facts and supporting evidence
Case one — a credit sale touching two layers. A sale to Al Nakheel (C-104) of 23,000.00 gross under invoice 1048. The entry touches three accounts in the general ledger, and one line posts alongside it to that customer's page in the subsidiary.
Correct treatment and entry
| Account | Debit | Credit |
|---|---|---|
| Trade receivables — 110300 (control) | 23,000.00 | |
| Sales revenue — 410100 | 20,000.00 | |
| VAT — output — 210600 | 3,000.00 | |
| Total (SAR) | 23,000.00 | 23,000.00 |
Treatment and financial effect
The entry exactly as you wrote it last module; nothing in it changed. What is new is that it lands in two places: the receivables control in the general ledger grows by 23,000, and Al Nakheel's page in the subsidiary grows by 23,000 too. This is not recording it twice: the control carries the total and the subsidiary carries the allocation, and the system updates the first from the second. Which is why the control is never posted to by hand — whoever posts straight to it breaks the relationship between the two layers at that moment.
Reperformance starts from this case's own facts: Case one — a credit sale touching two layers. A sale to Al Nakheel (C-104) of 23,000.00 gross under invoice 1048. The entry touches three accounts in the general ledger, and one line posts alongside it to that customer's page in the subsidiary. Obtain the original source that proves this event. The training drawings The general journal, The control account against its subsidiary explain field shape and reading order; they do not replace the case document or transfer their figures into it. Match entity, period, currency, reference and version to the event source, cut-off memo and journal approval, then confirm that the source supports the debit side (Trade receivables — 110300 (control)) and the credit side (Sales revenue — 410100, VAT — output — 210600). Missing ownership, date, reference or approval remains an open exception; a balancing journal or undocumented assumption does not cure it.
In an ERP there is no separate posting step: an entry posts the moment it is released, so the general ledger and the subsidiaries update in the same transaction and neither can lag the other. The control is configured as a "reconciliation account" bound to a subsidiary type — customers, suppliers, fixed assets — and the system refuses manual postings to it, which is the control that keeps the two layers equal by construction rather than by discipline. The subsidiary carries fields the general ledger does not: payment terms, due date, credit limit, and ageing reports are built from them. Every line also carries a movement type — invoice, collection, credit note, write-off — which is what makes an activity report readable rather than a list of amounts. The monthly reconciliation then becomes an automated report expected to come out at zero: coming out otherwise usually means a backdated posting or a direct intervention on the reconciliation account, and both are asked about.
The workpaper holds five entries from one week and empty account pages. Post each entry to its pages, compute the running balance after every movement, then move to the third sheet and reconcile the control against the customers' total. The difference cell checks itself. And when it comes out at zero do not stop: read the "last moved" column and say in one sentence which customer deserves a question and why — the reconciliation proves nothing was lost, and reading the names is what proves each amount sits with the right party. The file is yours; keep it with the three before it.
Work output: A reconciliation workpaper
These are yours once downloaded, and need no account. Fill them with your own figures and keep them in your portfolio.
Open an account with its opening balance and run three movements over it. The tool posts each as a real entry and returns the running balance after each — and tells you which side it settled on. What is open in front of you is July's receivables page, on the figures drawn in the previous lecture.
A month on the receivables ledger, eight decisions arriving in the order they arrive at work. Decide at each step before you see the next, and do not go back.
What you haveA credit sale entry to Al Nakheel for 23,000.00, and you are about to post it.
The arithmetic in this case runs in the tool itself, which is open to you any time with your own figures.
Log every balance you could not explain in three lines: the account, what you assumed against what it turned out to be, and how long it took to reach the document. The third line is the useful one: a balance that took half an hour to trace says a reference is missing somewhere, and that recurs while the balance itself does not.
This is not sent anywhere and not stored here. Write it down for yourself — in the workpaper you downloaded, or on paper.
The ledger is the journal ordered by account instead of by time, and nothing appears in it that was not in the journal. The journal answers "what happened that day" and the ledger "what does this customer owe", and the reference is the road between them in both directions. A balance is recomputed after every movement, so any line that does not equal the one above plus its movement reveals a movement dropped or posted twice. The side a balance settles on is a question with a specific answer for each class. The control carries the total and the subsidiary the allocation, and the control is never posted to by hand. Their monthly reconciliation proves nothing was lost between the layers — and never proves each amount sits with the right party, which needs somebody reading names and dates rather than totals.
Answer every question. Getting them all right records this lesson; you may retry as often as you need.
Reading alone records nothing.
The complete applied walkthrough is available below while the recording is prepared.
Two sheets on the table, and the same week is on both. This is the journal: ordered by date, the twenty-fourth then the twenty-fifth then the twenty-eighth. Ask it what Al Nakheel owes and it will not answer — their movements are scattered among entries that are not theirs. And this is a ledger page for one account: everything that touched receivables that month, gathered, with a balance recomputed after every line. Ask it what happened on Tuesday and it will not answer. The facts are the same on both sheets; none was added and none removed. Only the order changed. And that is why the same thing is kept twice: each order makes one kind of question cheap. And this small number here, the voucher number, is what binds the two — whoever reads a balance can get from it back to the invoice in three steps.
An account page recomputes its balance after every movement, not only at month end. The use of that is practical: any line that does not equal the one above it plus its movement reveals a movement dropped or posted twice, and reveals exactly where — instead of leaving you a whole month to search. And the side a balance settles on says something by itself: every account has a natural side — assets and expenses debit, liabilities, equity and revenue credit — and settling against it is not necessarily an error, but it is always a question with a specific answer you should have before the figure is reported.
| The account | Its normal side | If it settles the other way |
|---|---|---|
| Cash | Debit | An overdraft — presented as a liability, not as negative cash |
| Receivables | Debit | An overcollection, or a payment never applied to its invoice |
| Payables | Credit | An overpayment, or a payment recorded twice |
| Revenue | Credit | Returns exceeding the period's sales |
| Expenses | Debit | An entry with its sides reversed, or a refund booked to the expense |
And no page starts from zero on the first of the month. Balance-sheet accounts — assets, liabilities and equity — inherit their balance from the previous period, because what a business owns on the thirty-first it still owns on the morning of the first. Revenue and expenses are closed at year end and start from zero, because they measure a period that ended and adding last year's July expense to this year's means nothing. The practical effect in the ledger: an error in an expense account dies with its year, and an error in an asset account travels through the years unchanged until somebody finds it — because the balance is never recomputed from zero but inherited, line by line.
And when every ledger page has come down to one balance per account, those balances are gathered into a single list. That list is the trial balance: an account per line, its balance in the debit or the credit column according to its side, and the two column totals at the foot. Because every entry entered the books balanced, total debits must equal total credits necessarily — which makes their failing to agree an announcement of a fault in the posting itself rather than in the meaning. This is the third and last stage of the road: a journal ordered by time, then a ledger ordered by account, then a balance reducing each account to the single figure that enters the statements.
The general ledger cannot hold an account for every customer. A business with eight hundred customers does not put eight hundred accounts in its chart, or the trial balance becomes a book. The answer is two layers: one account in the general ledger called "trade receivables", carrying the total owed by all customers, and a subsidiary beneath it with a page per customer. The first enters the statements; the second answers "how much does Al Nakheel owe". And the control is not posted to by hand: every entry touching a customer posts to their page in the subsidiary, and the system updates the control itself — which is what keeps the two equal.
From this comes the check run every month: the sum of the subsidiary's balances must equal the control account's balance exactly. A difference means one moved without the other — an entry posted straight to the control with no customer, or a customer balance adjusted by hand. But note what the check does not catch: collect from Al Nakheel and credit the collection to Al Waha, and the total has not changed, the control equals the subsidiary perfectly — and both balances are wrong. The check proves the total is sound; it never proves the allocation is. Two things catch that kind: a statement sent to the customer, who objects; or an ageing report showing an old invoice against a customer who pays on time.
Three things, and each leaves a recognisable trace. The first is double posting: an entry posted twice, showing as two lines identical in date, amount and reference — and the repeated reference is what gives it away, because a voucher number does not recur. The second is posting to a parent that has children, so the balance scatters between the heading and what sits beneath it and no single report gathers it; the system is supposed to refuse this, and if it does not, the fault is in how the chart was set up rather than in whoever posted. The third is posting into another period, which makes both months wrong together: one over and the other under by the same amount.
In the end the ledger is where a figure becomes answerable. An entry says something happened; "what do we owe suppliers today" is answered only by a page gathering everything that touched them. Which is why an accountant is measured here by one thing: can they explain any balance in their book? Not read it — say where it came from, which entries made it, and what document proves it. A balance its keeper cannot explain is still in the ledger, but it has become a liability rather than information.
Remeasure from the facts before reading the proposed journal, then add it independently: total debits 23,000.00 and total credits 23,000.00. Debit detail: Trade receivables — 110300 (control) for 23,000.00. Credit detail: Sales revenue — 410100 for 20,000.00; VAT — output — 210600 for 3,000.00. Link every line to the recognition or measurement rule explained in the lecture, then trace its reference and posting date. After posting, test the general ledger, subledger and related reconciliation. Equal sides prove arithmetic only, not the correct account, period or classification.
Before close, compare the correct treatment with the common alternative and record its specific effect: The subsidiary never moved, so the control now exceeds the sum of the customers by 23,000 and the month-end reconciliation will find it. Worse, before that: Al Nakheel's statement does not show the invoice, so nobody chases it — and when they are chased three months later they ask about an invoice they were never sent. Do not close until the journal agrees with the trial balance and financial-statement lines and an independent reviewer can move from balance to account, reference and this event's own source. Keep the calculation, source version, journal identifier, reconciliation result and unresolved exceptions in the same workpaper. An attached file without a stated conclusion is not review evidence.
Facts and supporting evidence
Case two — a collection. A transfer of 18,000.00 arrived under bank advice BR-0412. It belongs to Al Nakheel (C-104), against an earlier invoice.
Correct treatment and entry
| Account | Debit | Credit |
|---|---|---|
| Cash at banks — 110100 | 18,000.00 | |
| Trade receivables — 110300 (control · subsidiary: C-104) | 18,000.00 | |
| Total (SAR) | 18,000.00 | 18,000.00 |
Treatment and financial effect
Cash grows by debit because an asset received money, and the receivable shrinks by credit because a claim was settled. There is no revenue here: the sale was recognised on delivery and recorded as revenue then, and what happens today is an asset changing form. What decides this case is not the entry but the line in brackets: which customer. The control will move by the same amount whatever name is written, and the name is the one thing nothing automated will check.
Reperformance starts from this case's own facts: Case two — a collection. A transfer of 18,000.00 arrived under bank advice BR-0412. It belongs to Al Nakheel (C-104), against an earlier invoice. Obtain the original source that proves this event. The training drawings The general journal, The control account against its subsidiary explain field shape and reading order; they do not replace the case document or transfer their figures into it. Match entity, period, currency, reference and version to the event source, cut-off memo and journal approval, then confirm that the source supports the debit side (Cash at banks — 110100) and the credit side (Trade receivables — 110300 (control · subsidiary: C-104)). Missing ownership, date, reference or approval remains an open exception; a balancing journal or undocumented assumption does not cure it.
Remeasure from the facts before reading the proposed journal, then add it independently: total debits 18,000.00 and total credits 18,000.00. Debit detail: Cash at banks — 110100 for 18,000.00. Credit detail: Trade receivables — 110300 (control · subsidiary: C-104) for 18,000.00. Link every line to the recognition or measurement rule explained in the lecture, then trace its reference and posting date. After posting, test the general ledger, subledger and related reconciliation. Equal sides prove arithmetic only, not the correct account, period or classification.
Before close, compare the correct treatment with the common alternative and record its specific effect: Two balances wrong in opposite directions: Al Nakheel is chased for money they paid, and Al Waha appears to have paid what they did not, so collection stops on them. Nothing catches it but a statement sent to one of them, who objects, or an ageing report showing an old invoice against a customer who pays on time. The monthly reconciliation will say nothing, because the total did not change. Do not close until the journal agrees with the trial balance and financial-statement lines and an independent reviewer can move from balance to account, reference and this event's own source. Keep the calculation, source version, journal identifier, reconciliation result and unresolved exceptions in the same workpaper. An attached file without a stated conclusion is not review evidence.
Facts and supporting evidence
Case three — a double posting. The receivables page shows two lines identical in day, amount and reference: both carry JV-2026-0731 at 23,000.00. The entry was posted twice, and the period is still open.
Correct treatment and entry
| Account | Debit | Credit |
|---|---|---|
| Sales revenue — 410100 | 20,000.00 | |
| VAT — output — 210600 | 3,000.00 | |
| Trade receivables — 110300 (subsidiary: C-104) | 23,000.00 | |
| Total (SAR) | 23,000.00 | 23,000.00 |
Treatment and financial effect
The correction is a full reversal of the duplicate: the same amounts with the sides flipped, in both layers because it posted in both layers. The narration names the cause and the reference explicitly: "reversing a double posting of voucher JV-2026-0731". The extra line is neither deleted nor the page's balance adjusted by hand — the first is barred because a posted entry is not erased, and the second is worse, because it leaves the ledger right and the journal behind it no longer agreeing, so the balance becomes a figure with no entry behind it.
Reperformance starts from this case's own facts: Case three — a double posting. The receivables page shows two lines identical in day, amount and reference: both carry JV-2026-0731 at 23,000.00. The entry was posted twice, and the period is still open. Obtain the original source that proves this event. The training drawings The general journal, The control account against its subsidiary explain field shape and reading order; they do not replace the case document or transfer their figures into it. Match entity, period, currency, reference and version to the event source, cut-off memo and journal approval, then confirm that the source supports the debit side (Sales revenue — 410100, VAT — output — 210600) and the credit side (Trade receivables — 110300 (subsidiary: C-104)). Missing ownership, date, reference or approval remains an open exception; a balancing journal or undocumented assumption does not cure it.
Remeasure from the facts before reading the proposed journal, then add it independently: total debits 23,000.00 and total credits 23,000.00. Debit detail: Sales revenue — 410100 for 20,000.00; VAT — output — 210600 for 3,000.00. Credit detail: Trade receivables — 110300 (subsidiary: C-104) for 23,000.00. Link every line to the recognition or measurement rule explained in the lecture, then trace its reference and posting date. After posting, test the general ledger, subledger and related reconciliation. Equal sides prove arithmetic only, not the correct account, period or classification.
Before close, compare the correct treatment with the common alternative and record its specific effect: Revenue and output tax are still overstated by 20,000 and 3,000, so the tax return will be built on sales that never happened. The "adjustments and differences" account carries 23,000 nobody can explain, and it is the first thing an auditor opens. And the duplicate entry is still in the books, able to reach the customer on a statement. Do not close until the journal agrees with the trial balance and financial-statement lines and an independent reviewer can move from balance to account, reference and this event's own source. Keep the calculation, source version, journal identifier, reconciliation result and unresolved exceptions in the same workpaper. An attached file without a stated conclusion is not review evidence.
Facts and supporting evidence
Case four — a receivable write-off covered by the allowance. There is no longer a reasonable expectation of collecting 6,900.00 from Al Rimal (C-131), and the loss allowance covered the full balance before write-off approval WO-2026-03.
Correct treatment and entry
| Account | Debit | Credit |
|---|---|---|
| Expected credit loss allowance — 110390 | 6,900.00 | |
| Trade receivables — 110300 (control · subsidiary: C-131) | 6,900.00 | |
| Total (SAR) | 6,900.00 | 6,900.00 |
Treatment and financial effect
IFRS 9 requires the gross carrying amount to be reduced when there is no reasonable expectation of recovery. Because the loss was already recognised in the allowance, the write-off uses that allowance rather than creating a second expense. It is a full accounting event, not a deletion: it passes through the customer's subsidiary page, closing Al Rimal to zero while invoice, collection attempts, allowance, approval and write-off remain on one trail. If the allowance is insufficient, expected losses are remeasured and the shortfall recognised first rather than hidden inside the write-off journal.
Reperformance starts from this case's own facts: Case four — a receivable write-off covered by the allowance. There is no longer a reasonable expectation of collecting 6,900.00 from Al Rimal (C-131), and the loss allowance covered the full balance before write-off approval WO-2026-03. Obtain the original source that proves this event. The training drawings The general journal, The control account against its subsidiary explain field shape and reading order; they do not replace the case document or transfer their figures into it. Match entity, period, currency, reference and version to the event source, cut-off memo and journal approval, then confirm that the source supports the debit side (Expected credit loss allowance — 110390) and the credit side (Trade receivables — 110300 (control · subsidiary: C-131)). Missing ownership, date, reference or approval remains an open exception; a balancing journal or undocumented assumption does not cure it.
Remeasure from the facts before reading the proposed journal, then add it independently: total debits 6,900.00 and total credits 6,900.00. Debit detail: Expected credit loss allowance — 110390 for 6,900.00. Credit detail: Trade receivables — 110300 (control · subsidiary: C-131) for 6,900.00. Link every line to the recognition or measurement rule explained in the lecture, then trace its reference and posting date. After posting, test the general ledger, subledger and related reconciliation. Equal sides prove arithmetic only, not the correct account, period or classification.
Before close, compare the correct treatment with the common alternative and record its specific effect: Profit falls a second time by 6,900.00 and the allowance remains above the receivable it was meant to cover. The monthly reconciliation also shows a control-to-customer difference, while Al Rimal's page still demands an amount written off in the financial statements. Do not close until the journal agrees with the trial balance and financial-statement lines and an independent reviewer can move from balance to account, reference and this event's own source. Keep the calculation, source version, journal identifier, reconciliation result and unresolved exceptions in the same workpaper. An attached file without a stated conclusion is not review evidence.
The balance is on its normal side
"The receivables reconciliation came out at zero this month. What error is still possible despite that, and how would you find it?"