A customer pays a R48,000 invoice by EFT on Thursday afternoon. The bank statement is imported on Monday morning, and the payment is matched to the invoice on Tuesday. On Friday, however, the automatic reminder run sent a firm message with the subject line "Overdue: please pay immediately". The customer's accounts clerk forwards it to her manager with the proof of payment attached, and her manager phones the sales rep. A good customer has just been treated like a bad one.
This article looks at that operating condition: customers receiving reminders for invoices they have already paid. It becomes more common as a business grows, because the volume of payments rises faster than the capacity to allocate them.
The problem in plain language
Reminder messages are usually generated from the invoice status in the accounting or billing system. If the status says unpaid, the reminder goes out. The status, however, only changes when someone or something records the payment against the invoice. Between the customer paying and the business recording it, there is a gap that can last hours or weeks. Part payments, payments with the wrong reference, payments made on behalf of a group of companies and payments allocated to the account rather than to an invoice all lengthen the gap. During that time the reminder logic cannot tell the difference between a customer who has not paid and a customer whose payment has not been recorded.
What the buyer is actually trying to solve
A finance manager or credit controller who searches for this wants to stop embarrassing the business in front of customers, keep the reminders that do speed up payment, and cut the time spent apologising and resolving queries. They are not asking to stop reminders altogether, since reminders work. They want reminders that are accurate, which means they depend on payment data being current.
Evidence and system mechanism
Reminders are driven by invoice status
Stripe's documentation on automatic collection describes reminders for unpaid one-off invoices that are switched on in the billing settings and sent on a schedule relative to the due date. It also describes a setting that reconciles partial payments: if the payment received is within a configured amount of the total, the invoice is credited for the outstanding balance and marked paid. The design shows two things. A reminder schedule keys on status. And status depends on rules about what counts as paid, so a small shortfall that is not handled will leave an invoice open and the reminders running.
Invoice statuses are a small set of states
Stripe's invoice object reference lists the possible statuses as draft, open, paid, uncollectible and void, and tracks the amount due, amount paid and amount remaining separately. The practical lesson is that a clean reminder rule checks the remaining amount, not merely whether the status label is paid. An invoice with an amount remaining of a few cents is not the same as an invoice with the full amount outstanding, and the message should differ.
The set of messages is wider than one reminder
Stripe's page on customer emails lists the notifications a billing system can send: after an invoice is finalised, after a failed payment, when a one-off invoice has not been fully paid, and receipts after payment. The existence of a receipt notification matters. A customer who gets an immediate acknowledgement of payment is less likely to send proof of payment to the sender later, and a business that sends receipts is forced to keep payment status current.
The law asks for accurate data
Section 16 of POPIA, on quality of information, requires a responsible party to take reasonably practicable steps to ensure that personal information is complete, accurate, not misleading and updated where necessary. A customer record that says unpaid when the customer has paid is inaccurate data about an identifiable account holder, and where the customer is an individual or a sole proprietor, the principle is relevant. It is also a good test for internal practice generally.
Warning signs
- Customers reply to reminders with proof of payment.
- Collections staff spend time checking whether an invoice has actually been paid before they chase it.
- Payment allocation is done in batches once or twice a week.
- Part payments and unreferenced deposits pile up in an unallocated list, as described in the cost of manual payment matching.
- Reminders go out on Friday afternoons and weekends, when no one can fix a mistake.
Problem owner and why-now trigger
The credit controller or accounts receivable lead owns the reminder routine. The finance manager owns the accuracy of payment allocation. The system administrator or accounting software partner owns the reminder configuration. The budget owner is generally the financial director.
The trigger is customer growth. A business with forty invoices a month can match payments by eye. At four hundred, the matching queue falls behind, automated reminders are switched on to relieve pressure, and the mismatch between payment and status becomes visible to customers. Rising use of instant payment methods raises expectations further, because customers assume the business sees their payment at once.
Economic consequence
The direct cost is staff time. If a wrongly sent reminder takes fifteen minutes to resolve across the customer's query, the credit controller's reply and a correction, then 80 a month is 20 hours of work that adds nothing. The indirect costs are harder to see but matter more. Relationship damage with good customers, who may begin to doubt the business's accuracy generally. Reduced credibility for correct reminders, since customers learn to ignore them. And a weaker case for a firm tone when a customer really is late. See also collections teams that chase customers without a priority queue.
Root cause
- Allocation lags receipt. Bank data is imported in batches and matched by hand.
- Reminder timing is independent of allocation timing. The reminder job runs on its own clock.
- Poor references. Customers pay without an invoice number, or one payment covers several invoices.
- Part payments are not handled. Small shortfalls leave invoices open.
- No pause on queries. If a customer says they have paid, the reminder routine is not told.
Practical intervention
- Measure the gap. For a month, record the days between the bank date and the allocation date for each payment. This is the window in which wrong reminders can occur.
- Run allocation before reminders. Schedule the reminder job after the daily bank import and matching, not before.
- Add a hold for recent payments. Suppress reminders for any customer with an unallocated deposit received in the last five days.
- Check the remaining amount. Send a different message for small balances from part payment than for a full outstanding amount.
- Improve references. Put the invoice number and a short reference instruction at the top of the invoice, and use a payment method that carries the reference automatically where possible.
- Let customers say they have paid. Add a link in the reminder to submit proof, which pauses further messages and creates a task for allocation.
- Send receipts. Acknowledge payment promptly so that customers have evidence and the business has a reason to record it quickly.
Trade-offs
A hold on reminders for customers with recent deposits delays genuine chasing by a few days, which is a small price. Allocation every day instead of every week needs time from someone, though bank feeds and rules can cut it. Where a business has no feed, the hold is the cheapest first measure.
An illustrative example
Illustrative: a Pretoria services firm with 350 active customers sent automatic reminders every Friday. Its finance clerk allocated payments on Mondays and Wednesdays. After moving allocation to a daily bank import and adding a five-day hold for unallocated deposits, the number of reminder-related queries fell from around two dozen a month to a handful, and the credit controller stopped checking by hand before each chase.
Diagnostic questions
- How many days pass between a customer paying and the invoice showing as paid?
- Does the reminder job run before or after the payment is allocated?
- What happens to an invoice with a small balance left after a part payment?
- How many reminder-related queries did customers send last month?
What good looks like
Payments are matched within a day. Reminders go out only after allocation and skip customers with recent unallocated deposits. Customers who have paid can say so and be left alone, and reminder tone matches the real balance. Credit controllers spend their time on customers who really are late.
Where Mellorca fits
Mellorca's business automation work can connect bank data, payment matching and the reminder schedule so that status is current before any message goes out. A digital systems audit can first measure the gap between payment and allocation.
Method note
The sources are billing platform documentation and the text of POPIA section 16. They describe how reminders and statuses work, not how often wrong reminders occur in any given business. The figures and the example are illustrative rather than a client case.
Sources and further reading
- Automatic collection (last verified 10 October 2026)
- The Invoice object - Stripe API Reference (last verified 10 October 2026)
- Send customer emails (last verified 10 October 2026)
- Section 16 Quality of information - POPIA (last verified 10 October 2026)
Related Mellorca reading
- Online channels sell stock that the warehouse no longer has
- Why system timestamps put transactions in the wrong reporting period
- Why data lineage gets rebuilt by hand every time the auditors arrive