Money entering an account can represent a sale, a customer advance, or funds held for a wallet user. Each increases the cash balance, but its effect on revenue and liabilities is different. A general ledger makes those differences visible by recording how each transaction affects the relevant accounts.
The clearest way to understand that process is to follow the numbers. The general ledger examples below trace everyday business transactions and digital wallet activity from journal entries to account balances. They show how to calculate a trial balance, distinguish customer funds from earned fees, and investigate a reconciliation difference.
What does a general ledger look like?
A general ledger contains the activity and balance of each account in an organisation’s chart of accounts. A typical ledger account includes the transaction date, description, journal reference, debit, credit, and running balance.
Here is a sample general ledger extract for a Cash account:
| Date | Description | Reference | Debit ($) | Credit ($) | Running balance |
|---|---|---|---|---|---|
| 1 April | Owner contributes capital | J001 | 20,000 | 0 | 20,000 Dr |
| 2 April | Equipment purchased | J002 | 0 | 4,000 | 16,000 Dr |
| 3 April | April rent paid | J003 | 0 | 1,200 | 14,800 Dr |
“Dr” identifies a debit balance. “Cr” identifies a credit balance. These labels matter because a debit does not always mean an increase, and a credit does not always mean a decrease. Their effect depends on the account type.
This table shows only the Cash account. Each transaction also affects another account: Owner’s Capital, Equipment, or Rent Expense. Together, those account records form the general ledger.
The journal reference connects a ledger posting to the original entry. J002 identifies the $4,000 equipment purchase; it is not an account code. A chart of accounts might use 1000 for Cash, while J002 identifies the entry posted to Cash and Equipment. Account numbering varies by organisation.
Journal, ledger and trial balance: how they connect
| Record | What it shows |
|---|---|
| General journal | Each transaction in date order, with its complete debit and credit entries. |
| General ledger | Entries grouped by account, with each account’s activity and balance. |
| Trial balance | Closing debit and credit balances across accounts at a particular date. |
General ledger accounts: five types with examples
Before recording a transaction, identify what changed. Did the business receive an asset, incur an expense, earn revenue, or create an obligation?
| Account type | What it records | Example accounts | Normally increased by | Normally decreased by |
|---|---|---|---|---|
| Assets | Resources controlled by the business | Cash, Accounts Receivable, Equipment | Debit | Credit |
| Liabilities | Obligations the business owes | Accounts Payable, Accrued Expenses Payable, Customer Wallet Liabilities | Credit | Debit |
| Equity | Owners’ residual interest | Owner’s Capital, Retained Earnings | Credit | Debit |
| Revenue | Income from ordinary business activities | Service Revenue, Fee Revenue | Credit | Debit |
| Expenses | Costs recognised in the period | Rent Expense, Utilities Expense | Debit | Credit |
These rules cover the ordinary accounts used below. Contra accounts, such as Accumulated Depreciation, have the opposite normal balance to the related account category.
Every complete journal entry must have equal total debits and credits. It may contain two lines or several lines, depending on the transaction.
Example 1: From business transactions to a trial balance
Consider Northbridge Services, a fictional business recording its first transactions. All accounts start at zero. All amounts in this article are in US dollars.
During April, the owner contributes $20,000. The business buys equipment for $4,000, pays $1,200 for April’s rent, and completes a consulting project worth $6,000. The customer pays the invoice in two instalments.
This example includes only those six transactions. It excludes depreciation and other period-end adjustments, so the final trial balance is unadjusted.
Record the transactions in the journal
The journal records events in date order. The table below shows the debit and credit sides of each entry.
| Date | Reference | Transaction | Account debited | Account credited | Amount on each side ($) |
|---|---|---|---|---|---|
| 1 April | J001 | Owner contributes cash | Cash | Owner’s Capital | 20,000 |
| 2 April | J002 | Equipment purchased for cash | Equipment | Cash | 4,000 |
| 3 April | J003 | April rent paid | Rent Expense | Cash | 1,200 |
| 10 April | J004 | Completed consulting project invoiced | Accounts Receivable | Service Revenue | 6,000 |
| 18 April | J005 | Customer makes a partial payment | Cash | Accounts Receivable | 2,500 |
| 25 April | J006 | Customer pays the remaining invoice balance | Cash | Accounts Receivable | 3,500 |
| Total | Debits: 37,200 | Credits: 37,200 |
Each entry answers a specific accounting question:
- J001: Cash increases, and the owner’s investment increases equity.
- J002: One asset, Cash, is exchanged for another, Equipment.
- J003: Rent for the current month becomes an expense, and cash decreases.
- J004: The completed service creates revenue and an amount receivable from the customer.
- J005 and J006: Cash increases while the receivable decreases. Collecting the invoice does not create revenue again.
For J004, assume the service obligation has been fully satisfied and the amount is due. The invoice date alone does not determine revenue recognition. IFRS 15 links recognition to the transfer of promised goods or services to the customer.
Post the entries to individual ledger accounts
The ledger groups those same journal entries by account. Posting does not create another economic transaction; it organises the recorded debits and credits so each account’s history is visible.
For example, J002 posts a $4,000 debit to Equipment and a $4,000 credit to Cash. The same reference connects both postings to one purchase. Equipment increases by $4,000, while Cash falls from $20,000 to $16,000.
Cash account
| Date | Reference | Description | Debit ($) | Credit ($) | Running balance |
|---|---|---|---|---|---|
| 1 April | J001 | Capital contribution | 20,000 | 0 | 20,000 Dr |
| 2 April | J002 | Equipment purchase | 0 | 4,000 | 16,000 Dr |
| 3 April | J003 | April rent | 0 | 1,200 | 14,800 Dr |
| 18 April | J005 | Partial invoice payment | 2,500 | 0 | 17,300 Dr |
| 25 April | J006 | Final invoice payment | 3,500 | 0 | 20,800 Dr |
| Total movement | 26,000 | 5,200 | 20,800 Dr |
For an account expressed as a debit balance:
Closing balance = opening balance + debits − credits
Here, the calculation is:
$0 + $26,000 − $5,200 = $20,800 Dr
Accounts Receivable
| Date | Reference | Description | Debit ($) | Credit ($) | Running balance |
|---|---|---|---|---|---|
| 10 April | J004 | Completed project invoiced | 6,000 | 0 | 6,000 Dr |
| 18 April | J005 | Partial payment received | 0 | 2,500 | 3,500 Dr |
| 25 April | J006 | Final payment received | 0 | 3,500 | 0 |
| Total movement | 6,000 | 6,000 | 0 |
The zero closing balance means the customer has paid the full invoice. The transaction history remains available even though nothing is outstanding.
The other accounts each contain one posting:
| Account | Date | Reference | Debit ($) | Credit ($) | Closing balance |
|---|---|---|---|---|---|
| Equipment | 2 April | J002 | 4,000 | 0 | 4,000 Dr |
| Rent Expense | 3 April | J003 | 1,200 | 0 | 1,200 Dr |
| Owner’s Capital | 1 April | J001 | 0 | 20,000 | 20,000 Cr |
| Service Revenue | 10 April | J004 | 0 | 6,000 | 6,000 Cr |
For a credit-normal account such as Service Revenue, calculate the credit balance as opening credit balance plus credits minus debits.
Calculate closing balances and prepare the trial balance
A trial balance lists the closing balances of ledger accounts at a particular date. It summarises the ledger rather than repeating every transaction.
Northbridge Services: unadjusted trial balance at 30 April
| Account | Debit balance ($) | Credit balance ($) |
|---|---|---|
| Cash | 20,800 | 0 |
| Accounts Receivable | 0 | 0 |
| Equipment | 4,000 | 0 |
| Rent Expense | 1,200 | 0 |
| Owner’s Capital | 0 | 20,000 |
| Service Revenue | 0 | 6,000 |
| Total | 26,000 | 26,000 |
The journal totals were $37,200 on each side. The trial balance totals are $26,000 on each side. They differ because the journal totals measure activity, while the trial balance uses each account’s net closing balance.
A second check uses the accounting equation:
- Assets: $20,800 cash + $4,000 equipment = $24,800.
- Liabilities: $0 in this example.
- Equity: $20,000 contributed capital + $6,000 revenue − $1,200 expense = $24,800.
The figures agree before the excluded adjustments.
However, equal trial balance totals do not prove every entry is correct. Recording both sides of a transaction twice, or posting to the wrong account, can still leave debits and credits equal.
More general ledger examples
The following general ledger examples are independent of Northbridge Services. Each shows why the timing of cash movement can differ from the timing of an asset, liability, revenue, or expense.
Example 2: Buying inventory on credit and paying the supplier
A retailer receives $3,000 of inventory in May and pays the supplier in June.
| Date | Transaction | Debit | Credit | Amount on each side ($) |
|---|---|---|---|---|
| 6 May | Inventory received on credit | Inventory | Accounts Payable | 3,000 |
| 5 June | Supplier paid | Accounts Payable | Cash | 3,000 |
The purchase increases Inventory and Accounts Payable by $3,000. June’s payment clears the payable and reduces Cash by $3,000; it creates no new purchase or expense. Inventory remains $3,000 higher until a sale or another inventory adjustment.
Accounts Payable for this purchase: opening balance $0 → purchase on credit $3,000 Cr → supplier payment $0.
Example 3: Receiving an advance and recognising revenue
A customer pays $2,400 in June for a service that will be delivered entirely in July. Assume the amount remains unearned until that service is completed.
| Date | Transaction | Debit | Credit | Amount on each side ($) |
|---|---|---|---|---|
| 20 June | Advance received | Cash | Contract Liability | 2,400 |
| 31 July | Service completed | Contract Liability | Service Revenue | 2,400 |
In June, cash increases but revenue remains unchanged. The business still owes the customer a service.
After the service is completed in July, the contract liability for this advance is zero, Service Revenue has increased by $2,400, and Cash remains $2,400 higher from June’s receipt. Contracts involving delivery over time may require a different recognition pattern.
Example 4: Accruing an expense and paying it later
A business uses $600 of electricity in September and pays for it in October. Assume the September amount is known.
| Date | Transaction | Debit | Credit | Amount on each side ($) |
|---|---|---|---|---|
| 30 September | September electricity cost accrued | Utilities Expense | Accrued Expenses Payable | 600 |
| 15 October | Electricity amount paid | Accrued Expenses Payable | Cash | 600 |
At the end of September, Utilities Expense has a $600 debit and Accrued Expenses Payable a $600 credit for this electricity use. October’s payment reduces the payable to zero and Cash by $600. The expense remains recognised in September; payment does not create another expense.
Across these examples, the same principle applies: record what the event changes, then distinguish that event from the later receipt or payment of cash.
Example 5: A digital wallet general ledger
In a wallet business, money received from users needs to be distinguished from revenue earned by the operator.
This simplified example uses the operator’s accounting perspective. It assumes funds received are recognised as a bank asset with a corresponding liability to wallet holders. Actual account classification depends on the contractual and custody arrangements.
All balances begin at zero. Transactions are completed and settled; pending payments, processor receivables, taxes, and provider charges are excluded. Any subsequent transfer of earned fees to another bank account is also outside the example.
Four events occur:
- User A tops up their wallet with $1,000.
- User A transfers $250 to User B.
- The operator deducts a $5 earned service fee from User A.
- User B withdraws $200 to an external bank account.
Record the wallet events
The entries below show the liability detail for each user. These balances sum to the Customer Wallet Liabilities control total; they are not additional liabilities to be posted a second time.
| Reference | Event | Account debited | Account credited | Amount on each side ($) |
|---|---|---|---|---|
| W001 | User A tops up | Bank Funds | Wallet Liability: User A | 1,000 |
| W002 | User A transfers to User B | Wallet Liability: User A | Wallet Liability: User B | 250 |
| W003 | Earned fee deducted from User A | Wallet Liability: User A | Fee Revenue | 5 |
| W004 | User B’s withdrawal settles | Wallet Liability: User B | Bank Funds | 200 |
- The top-up creates an obligation. The operator holds $1,000 and owes the corresponding wallet value to User A. The top-up itself produces no fee revenue.
- The internal transfer changes who is owed money. User A’s liability balance falls by $250, and User B’s rises by $250. Total customer liabilities and bank funds remain unchanged.
- The fee reduces the amount owed to User A. Assuming the fee has been earned, the $5 becomes revenue.
- The withdrawal reduces both bank funds and the liability to User B. The entry reflects a settled payout, not merely a withdrawal request.
Check the balances after each event
| Position | Bank funds ($) | Liability to User A ($) | Liability to User B ($) | Total wallet liabilities ($) | Fee revenue ($) |
|---|---|---|---|---|---|
| Opening | 0 | 0 | 0 | 0 | 0 |
| After W001 | 1,000 | 1,000 | 0 | 1,000 | 0 |
| After W002 | 1,000 | 750 | 250 | 1,000 | 0 |
| After W003 | 1,000 | 745 | 250 | 995 | 5 |
| After W004 | 800 | 745 | 50 | 795 | 5 |
The closing calculations are:
- Bank funds: $1,000 − $200 = $800.
- User A: $1,000 − $250 − $5 = $745.
- User B: $250 − $200 = $50.
- Total customer liabilities: $745 + $50 = $795.
The resulting trial balance is:
| Account | Debit balance ($) | Credit balance ($) |
|---|---|---|
| Bank Funds | 800 | 0 |
| Customer Wallet Liabilities | 0 | 795 |
| Fee Revenue | 0 | 5 |
| Total | 800 | 800 |
This explains why bank funds and customer wallet liabilities need not be identical in this simplified snapshot. The $5 difference is the earned fee still included in the bank balance.
It does not establish how a regulated business must segregate or safeguard funds. Those arrangements require their own accounting and operational treatment.
Reconciliation example: Finding a missing $5 fee
A general ledger control account and its supporting subledger answer different questions.
The control account shows the total liability to wallet holders. The subledger identifies the individual balances behind that total. Both must be compared using the same currency, cut-off time, and transaction scope.
The previous example shows the expected user balances. Now compare the GL control total with a separately maintained operational wallet subledger. Suppose W003 was posted correctly to the GL, but the corresponding $5 fee deduction is missing from that subledger.
At the same cut-off, the records show:
- GL Customer Wallet Liabilities: $795.
- Wallet subledger: $750 for User A + $50 for User B = $800.
The subledger exceeds the GL control total by $5 ($800 − $795).
The reconciliation process is:
- Confirm that both reports use the same currency, cut-off time and transaction-status criteria.
- Compare their references and amounts.
- Identify W003 in the GL and verify the fee against its source record.
- Confirm that the corresponding subledger update is missing.
- Correct the missing update through the system’s controlled process.
- Rerun the comparison.
After correction, User A’s balance is $745. Together with User B’s $50, the subledger totals $795 and matches the GL.
Do not post another fee entry to an already correct GL. That would reduce the control account to $790 and overstate fee revenue. Reconciliation should establish which record is wrong before any correction is made.
This check also differs from bank reconciliation. Matching the wallet subledger to its control account does not independently confirm that the recorded bank funds agree with the bank statement.
Common general ledger mistakes
Balanced entries can still contain business or accounting errors.
| Mistake | Example | Useful check |
|---|---|---|
| Wrong account | Equipment purchase posted to Rent Expense | Compare the posting with the invoice and asset policy |
| Duplicate entry | The same customer payment recorded twice | Check source transaction IDs and bank receipts |
| Missing transaction | A completed payout omitted from the ledger | Reconcile source-system records with GL postings |
| Wrong period | September expense recorded only when paid in October | Review service dates and period-end accruals |
| Reversed debit and credit | Cash credited when a payment was received | Trace the economic effect on each account |
| Revenue recorded twice | Revenue recognised at invoicing and again at collection | Confirm that collection clears Accounts Receivable |
| Subledger mismatch | Wallet fee posted only in the GL | Compare supporting balances and references |
A useful review combines arithmetic checks with source evidence. Confirm the amount, account, date, transaction status, and reference, then reconcile the relevant balances.
Corrections should remain traceable. In a ledger that locks posted entries, use the supported reversal or correction process and retain the connection to the original entry.
SDK.finance General Ledger: Rules, Postings and Balances
SDK.finance General Ledger is a standalone accounting product that can work alongside the SDK.finance Transaction Platform or an external transaction core. It converts incoming business events into double-entry journal entries using configurable account structures and accounting rules.
For a wallet fee such as the $5 charge in the example above, a configured rule can debit the customer liability account and credit Fee Revenue. The processing sequence is:
- Receive the event. The source system sends the business event through Kafka or the REST API.
- Determine the accounts. Configured Determinations identify the transaction category and the GL accounts that apply to the event.
- Build the journal entry. Mapping Rules define the debit and credit legs and specify which event fields supply the amounts, currencies, and dates.
- Validate and post. Before posting, SDK.finance checks that debits equal credits, the accounts are active, and the value date falls within the allowed back period. Automatic posting is available when configured. Only posted entries affect balances and reports; rejected entries must be corrected before posting.
- Update balances and preserve the record. Posted entries update account balances and turnovers. They cannot be edited or deleted; reversing entries preserve the original record when a correction is needed.
The product also provides configurable Charts of Accounts and account hierarchies, support for fiat and crypto currencies, and role-based access. Its Current Balance Report shows account balances, while the Turnover Report shows debit and credit activity for a selected period. These records support finance teams’ reporting and reconciliation work.
Explore the General Ledger demo to see accounts, journal entries, and balances in practice.
Put the general ledger examples to work
The journal records each transaction, the ledger shows its effect by account, and reconciliation checks the resulting records against independent evidence. To apply these examples, trace one transaction from its source document through the postings and closing balances, then compare the relevant balance with its supporting records.
