A completed sale and money collected are related records, but they answer different questions. The sale record says what was sold, to whom, and on what terms. The payment record says what money came in, when, by which method, and under which reference. If the customer takes approved credit, the unpaid amount belongs on that customer’s account with a due date. It is not money in the till.
That distinction matters most when a customer pays later in part. If the collection is entered as another sale, sales are overstated. If it is left as an unlinked receipt, the customer’s original balance can remain open even though money was received. A short, traceable record trail avoids both errors.
The method below uses fictional transactions at a small East African shop. It is an operational recordkeeping guide, not advice on revenue recognition, tax, statutory receipts, or the accounting treatment required in a particular country. The example uses CU for fictional currency units; it does not represent a real currency or tax calculation.
Keep three records connected
Use a sale record, one or more payment records, and a customer balance record. Give each its own reference, then link the references. A receipt or till report supports the sale and tender; a later collection gets its own payment reference and is allocated to the original sale or invoice.
| Record | Question it answers | Minimum details |
|---|---|---|
| Sale | What was sold, and to whom? | Sale reference, date, item lines, customer or walk-in marker, total, cashier, approved terms if credit was granted |
| Tender or collection | What money was received? | Payment reference, date, amount, method, provider or till evidence, sale or invoice allocated |
| Customer balance | What remains due, and by when? | Customer account, original sale, approved terms, due date, payments allocated, remaining balance |
In a simple bookkeeping example, cash from an immediate sale and a later receipt against a credit sale appear as distinct events. The transaction links help explain why the amount in sales records and the amount collected today need not be identical. OpenStax’s worked merchandise-sale examples show this separation; the accounting entries and rules applicable to your business still depend on its reporting basis and local requirements.
Illustrative stock photo. The notes and ledger figures shown are unrelated to the fictional CU amounts in this article.
Example one: the customer pays in full
Fictional transaction CS-104 — Day 1. A customer buys two items for CU 120,000. The receipt is RCP-104. The customer pays CU 70,000 in notes and CU 50,000 by mobile payment.
The sales record shows the two items and the full CU 120,000 total. The tender record breaks the amount received into two methods:
| Tender method | Amount | Evidence to match |
|---|---|---|
| Cash | CU 70,000 | Receipt RCP-104 and expected-cash report; compare expected cash with the counted drawer after accounting for the opening float and documented paid-ins or paid-outs |
| Mobile payment | CU 50,000 | Receipt RCP-104 and the provider transaction reference or statement line |
| Total received for CS-104 | CU 120,000 | Agrees to the sale total |
At close, the cashier records the count and a reviewer checks the till evidence. The mobile-money or card confirmation is matched to the provider record; any later bank settlement is checked separately because a provider may settle a different amount or on a different date after fees. Do not use the sale total alone as proof that every tender arrived.
Illustrative stock photo. These banknotes do not represent the fictional transactions described here.
For payment methods that are not physical cash, record the actual method. “Paid” does not tell the next person whether to look in the drawer, a mobile-money statement, a card batch, or a bank account.
Example two: approved customer credit and a later collection
Fictional transaction CR-205 — Day 1. A returning customer, Kito Office Supplies (a fictional business), takes goods totalling CU 250,000 on approved 14-day terms. The sale reference is CR-205; its due date is Day 15. The sale record lists the items, named customer account, the person who approved the credit, and the agreed terms. The payment-at-sale record shows CU 0 received. The customer balance for this sale is CU 250,000 due.
Collection COL-118 — Day 5. The customer pays CU 80,000 by bank transfer. Record COL-118 as a collection, capture the bank or payment reference, and allocate it to CR-205. The remaining balance on that sale is CU 170,000. CR-205 remains open with its original due date.
The collection is not another sale. It changes how much the customer still owes and how much money has been received. Keep the original sale intact and attach the collection reference to it. When a customer has several open invoices, record which one the payment reduces; send an unclear allocation to an exception queue instead of guessing.
| Event | Sale reference | Payment reference | Sale total | Received at sale | Later collection | Balance on CR-205 |
|---|---|---|---|---|---|---|
| Credit sale | CR-205 | — | CU 250,000 | CU 0 | — | CU 250,000 |
| Part payment | CR-205 | COL-118 | — | — | CU 80,000 | CU 170,000 |
Before releasing goods on credit, use the business’s approved customer account and credit limit. Record who approved the sale and the due date. A cashier should not turn an unfamiliar walk-in sale into credit by leaving the tender blank; missing approval is an exception to resolve, not a credit policy.
Reconcile by payment method, then review open balances
At the end of a shift or day, compare records that should agree:
- Sale to receipt: sale reference, item lines, total, and receipt number agree. Cancelled or corrected transactions remain traceable to the original reference.
- Cash tender to till: expected cash is compared with the physical count, with the float and authorised movements shown separately. Record and review any difference.
- Electronic tender to provider evidence: match each payment reference or provider statement line to the receipt. Compare provider batches with later bank settlements separately; do not hide fees or timing differences inside the customer’s balance.
- Credit sale to customer account: every credit sale has an approved customer, approver, terms, due date, and opening amount due.
- Collection to original sale: each later payment has its own reference, method, evidence, customer, and invoice allocation. Recalculate the remaining balance.
Keep exceptions visible: a missing receipt, payment with no sale allocation, credit sale without approval, duplicate provider reference, unexplained cash difference, or a settlement that does not match the provider report. Assign an owner and follow-up date. A balanced daily total can still conceal a wrong customer allocation.
Daily sales-to-collection worksheet
Use one row for each sale and a separate row or linked collection log for every later payment. Never put a later collection in the sales column.
| Date | Sale / collection ref. | Type | Sale ref. | Customer account | Sale total | Received now by method | Credit approved / due date | Later collection ref. and amount | Balance due | Evidence checked by / exception |
|---|---|---|---|---|---|---|---|---|---|---|
| Day 1 | CS-104 / RCP-104 | Paid in full | CS-104 | Walk-in | CU 120,000 | Cash CU 70,000; mobile CU 50,000 | Not applicable | — | CU 0 | Cash count and provider reference matched; reviewer initials |
| Day 1 | CR-205 | Customer credit | CR-205 | Kito Office Supplies | CU 250,000 | CU 0 | Approved; due Day 15 | — | CU 250,000 | Approval and terms checked; reviewer initials |
| Day 5 | COL-118 | Collection | CR-205 | Kito Office Supplies | — | Bank transfer CU 80,000 | Existing terms; due Day 15 | COL-118 / CU 80,000 | CU 170,000 | Bank reference matched and allocated; reviewer initials |
At the daily summary level, keep these figures on separate lines: sales completed today, tenders received against today’s sales, credit extended today, collections received against earlier sales, cash counted, and open exceptions. In this example, sales are CU 370,000; tenders against today’s sales are CU 120,000; new credit is CU 250,000; and collections against an earlier sale are CU 80,000. Money received today totals CU 200,000, while CR-205 still has CU 170,000 due. The CU 80,000 collection is not added to today’s sales.
If the sale includes an advance, a discount, returned goods, a refund, a disputed amount, multiple currencies, or a payment-provider fee, stop using the simple example and follow the business’s approved process. Keep the source document, correction or approval, and reviewer visible. Local rules determine invoice and fiscal-receipt requirements, tax handling, and accounting recognition; ask the business’s accountant for those decisions. IFRS 15, where applicable, frames revenue recognition around satisfying a performance obligation by transferring a promised good or service, but this article does not determine the accounting for any particular sale. See the IFRS Foundation’s IFRS 15 overview.
Apply the same trail in other markets
Start with a small East African shop or service business, then adapt the evidence sources, not the distinctions. Elsewhere in English-speaking Africa, keep each market’s actual currency code, available payment providers, settlement pattern, fiscal-receipt rules, and accounting policy explicit. In the UK and other global SME markets, replace local payment evidence with the providers and bank records actually used there, and have a local accountant confirm tax, invoicing, and reporting requirements. The worksheet is a management aid, not a jurisdictional compliance template.
Do not assume that M-Pesa, a particular card service, or a bank integration exists for every country or account. Check country availability, payment methods, device and language support, integrations, and any offline or settlement limits with the provider before relying on them. Do not put personal customer data into a shared sheet unless access and retention follow the business’s policy.
What to test in a Maduuka demonstration
Maduuka’s published features page lists credit sales with limits and customer profiles. Its finance and accounting page describes POS payments routed to cash, mobile-money, card, bank, or customer-credit accounts. Those are first-party product statements, not independently tested capabilities, accounting advice, or a promise that a particular local integration is supported.
This guide stays with the daily transaction trail. For broader customer credit policy, including limits, ageing, and follow-up, see Maduuka’s customer credit accounts guide. For provider statement matching and mobile-money settlement exceptions, see its mobile-money reconciliation guide.
Sources and product scope
- Rice University, OpenStax, Principles of Accounting, Volume 1: Financial Accounting, “Analyze and Record Transactions for Merchandise Purchases and Sales Using the Periodic Inventory System.” Educational worked examples; consulted 29 September 2026.
- IFRS Foundation, IFRS 15 Revenue from Contracts with Customers. Standard overview; cited only to mark the boundary of this operational guide; consulted 29 September 2026.
- Maduuka, POS, Inventory & Accounting Features and Finance, Accounting & Expense Software. First-party published scope; no independent feature, compliance, security, or performance verification; demo confirmation required; consulted 29 September 2026.
- Chwezi Core Systems, Maduuka Bookkeeping Software for African SMEs. Chwezi’s public offer page, not evidence of customer results or independently tested capability; consulted 29 September 2026.