Why overwriting a balance creates disputes
If a customer owes £300 and pays £100, changing a single field to £200 gives today’s total but removes the payment date and reason. Later, neither the shop nor the customer can reconstruct the sequence with confidence.
An event-based record keeps the £300 sale and adds a £100 receipt. The remaining £200 is a result, not an unsupported number.
A part-payment example
A customer buys £450 of goods, pays £150 now and £100 later:
- the sale records the products and £450 value;
- the first receipt leaves £300 outstanding;
- the next receipt leaves £200;
- stock changed with the original sale only.
This avoids counting a receipt as a second commercial sale or reducing merchandise twice.
Check the sequence before contacting the customer
Review completed and cancelled sales, receipts, dates and the customer assigned to every record. Where names are similar, stable contact details help prevent posting money to the wrong account. Correct the erroneous event instead of forcing the total to the expected figure.
Software does not set the credit policy
An app can display an operational balance but cannot decide who should receive credit, choose lawful terms or guarantee recovery. Set limits and communication rules outside the feature claim, and reconcile significant accounts with formal bookkeeping.