Transaction in Accounting Example

Accounting transactions sound technical until a practical question lands: why did the profit move, why does the bank not agree, or why is SARS asking for support? For a South African SME, the transaction is the point where the business event becomes part of the accounting record.

An accounting transaction is the starting point of the reporting process.

It is not every event in the business. It is the events that change the financial records in a measurable way. Once that is clear, a lot of accounting becomes easier to understand.

The numbers first

The key question is always whether the books need to move.

What counts as a transaction

A transaction usually has three features:

1. it has a financial effect
2. it can be measured
3. it has some form of support

That support might be an invoice, receipt, contract, payroll schedule, or bank proof.

Step 1: Identify the business event

Start with the plain-language event before thinking about debits and credits. Did the business sell something, buy something, pay a supplier, receive money, process payroll, move stock, or correct an old balance?

This step matters because many errors begin with the wrong description of what happened. A customer deposit is not the same thing as earned revenue. A supplier statement is not the same thing as a supplier invoice. A card swipe by the owner might be a business expense, a drawing, or a loan account movement depending on the facts.

For SMEs, this is where the person doing the books should ask for context early. Waiting until month-end usually turns one unclear transaction into a list of queries that slows the monthly close checklist.

Step 2: Match the event to evidence

The next step is to connect the event to support that can still be understood later. A bank line proves money moved, but it does not always prove what the money was for. The accounting file usually needs the invoice, receipt, contract, statement, or approval trail that explains the bank movement.

Good support should answer four questions:

1. who was involved
2. what was bought or sold
3. when the event happened
4. how much should be recorded

If VAT is involved, the support should also make the VAT treatment clear. That is why transaction quality sits close to bookkeeping documents and not only to accounting theory.

Step 3: Record and review the effect

Once the event and evidence are clear, the transaction can be posted to the correct accounts. The entry should then be reviewed against the balance it affects. A debtor entry should still make the customer account sensible. A supplier invoice should still agree to the supplier position. A bank payment should still clear through the bank reconciliation.

This review step is where owners often get value from journal entry examples. The point is not to memorise entries. It is to understand whether the final report now tells the right story.

Example 1: Customer invoice

Assume the business invoices a client R15,000 for services rendered.

This is an accounting transaction because the business has earned revenue and created a receivable.

Example 2: Customer payment

The client later pays the invoice.

The cash position improves and the debtor balance reduces. The transaction now affects the balance sheet differently to the first entry.

Example 3: Supplier invoice

If the business receives an expense invoice for R2,400 and has not paid it yet:

That is also a transaction because a cost and a liability have been created.

Why the source document matters

A transaction is easier to record well when the source document is clear.

Poor source documents create problems such as:

• wrong account coding
• unclear VAT treatment
• weak explanations for review
• unsupported balances later

So bookkeeping quality still matters even where accounting software automates part of the workflow.

A practical transaction flow

This is the same logic that runs through the wider accounting cycle.

In a live SME file, the flow should not be treated as one person's memory. It should be visible enough that a reviewer can trace the transaction from the bank, invoice, or journal into the ledger and then into the management pack. That trace is what protects the business when a lender, accountant, or SARS reviewer asks why a number changed.

Example 4: Owner pays a business expense personally

Assume the owner pays R1,150 for a business subscription using a personal card and the business agrees to reimburse the owner.

The business has incurred an expense, but the bank account has not moved yet. If the company later reimburses the owner, the second entry clears the owner loan account rather than recording the expense again.

This example is common in smaller businesses. If it is not recorded carefully, expenses are missed, owner balances become untidy, or the same cost is captured twice when the reimbursement appears in the bank.

Example 5: VAT-sensitive supplier invoice

Assume a VAT-registered supplier invoice totals R11,500, including VAT of R1,500, for goods bought by a VAT-registered business.

The transaction affects the income statement, the creditor balance, and the VAT control account. If the invoice is coded as R11,500 to expense with no VAT split, the monthly profit, VAT reconciliation, and creditor position can all be wrong at the same time.

What owners should watch for

The most useful management questions are simple:

1. is every major transaction supported properly
2. are unusual transactions explained clearly
3. are the related balances reviewed after posting

These questions matter because weak transaction handling compounds over time.

The common mistakes

Businesses usually go wrong in one of these areas:

• recording the transaction too late
• posting it to the wrong account
• missing the tax effect
• failing to clear the related balance later

The transaction may still appear in the system, but the reports become less useful.

Questions owners can ask without becoming accountants

Owners do not need to post every transaction themselves, but they should be able to challenge weak entries. Useful questions include:

1. Is there enough support to explain this entry six months from now?
2. Does the VAT treatment match the supplier document and the business registration status?
3. Has the related debtor, creditor, bank, or loan balance been checked after posting?
4. Would the entry still make sense to the accountant preparing year-end?

Those questions keep transaction quality practical. They also help separate ordinary data capture from the review work that belongs inside a stronger accounting cycle.

What to keep in the transaction file

A transaction file does not need to be complicated, but it should be complete enough for someone else to follow the trail. For a sale, keep the customer invoice, proof of delivery or service completion where relevant, receipt or allocation, and any credit note if the amount changed. For a purchase, keep the supplier invoice, approval, payment proof, and statement if the supplier account is material.

For bank transfers, director payments, reimbursements, and loan movements, add a short note that explains why the money moved. These are the transactions that often look harmless during the month and then become difficult at year-end because the bank line alone does not explain the accounting treatment.

If the business is VAT registered, keep the tax invoice and make sure the supplier details, VAT number, date, and amount support the VAT claim. A transaction can be commercially real and still be weak for VAT support if the document is incomplete.

The aim is simple: the next person reviewing the file should not have to ask what happened. They should be able to see the event, the evidence, the entry, and the balance affected.

That standard is useful even in a very small business. It keeps routine bookkeeping from becoming a reconstruction job when the accountant, owner, bank, or SARS asks for the detail behind a number.

It also makes training easier because new staff can see good examples in the file instead of copying old, unclear habits.