Short answer. Every customer has an account: one entry per document, invoice, credit note, receipt, cheque, discount, and never a balance edited by hand; the balance is the sum. Every receipt is allocated, that is, assigned to specific invoices, and every invoice knows its remaining amount; a deposit stays unallocated until the invoice it will pay. A cheque has states, received, deposited, cleared, bounced; it settles invoices conditionally, and a bounce reopens them. The age of an overdue is counted from each customer’s own due date, not from the invoice, in buckets, not due, 1–30, 31–60, 61–90, over 90 days. The reminder is a sequence written by the manager, pre-due reminder, message at due date, call, block, handover to the manager, run by the application every night and stopped by a payment or a dispute. The credit limit is compared with exposure, pending cheques included, at the moment the order is taken, and an overrun blocks or requires a named approval. The ageing report comes out dated, and the entries go to accounting.
This guide is for the distributor and the wholesaler whose retailers pay at thirty or sixty days, the shopkeeper who keeps a credit notebook for regulars, the founder based in France who discovers their Algerian company’s receivables a month after the fact, and the manager who wants to know at 8:00 whom to chase and whom to stop delivering. It does not repeat how an order is taken in the field or how a retailer orders alone, described in the pre-sales guide and the B2B ordering guide, where limit and receivables appear as features; it describes the construction that makes them true, and it extends our software engineering page. It does not cover tax rules or late-payment penalties: delays and consequences are what the company decides, and the accountant says how entries must come out.
One customer’s account: documents, allocation, balance and exposure
The figure follows a single customer, a hardware store, on 10 November. Everything the application knows about their credit fits in two columns and an allocation.
The account is a series of entries, one per document: three invoices with their thirty-day due dates, this customer’s terms; a cash receipt with a numbered receipt sent by SMS, following the checkout guide; a credit note linked to an invoice, issued by the after-sales flow of the complaints guide; a cheque deposited at the bank. Nobody edits a balance: an entry is added, and the balance is the sum. Allocation assigns every receipt to specific invoices: the cash settles part of the first invoice; the cheque settles the rest of the first and all of the second, subject to clearing; the credit note reduces the third. Every invoice knows its remaining amount, and the statement sent to the customer says so per invoice, not as a lump.
The book balance is 55,000 dinars. Exposure is 132,000: a deposited cheque is not money until the bank has cleared it, and it is added back. The limit of 150,000, set by the manager for this customer, is compared with exposure: today’s order, 30,000, would take exposure to 162,000, and the order is blocked or sent to the sales manager for approval, who sees the reason and the missing amount, under the rights described in the roles and approvals guide. Customer, documents and amounts are a constructed example.
«A deposited cheque is not money: it settles the invoice conditionally, counts in exposure, and a bounce reopens it.»
The overdue board: six customers, five buckets, one average time
The figure shows what the manager sees at 8:00: who is late, by how much, since when, and what the application has already done.
Age is computed from the due date, not the invoice date: a thirty-day customer is not late the day after delivery, and a cash customer is. The buckets, not due, 1–30, 31–60, 61–90, over 90 days, are a common convention; the manager may choose others, but they no longer change afterwards, so that weeks compare. Under each name, the state of the reminder the application runs or has run: pre-due reminder sent this morning, call planned today for the rep, orders blocked, dispute handed to the manager.
The tile computes the average collection time, receivables divided by credit sales per day, following the common DSO formula, receivables divided by average daily sales: 9.64 million of receivables against 21.6 million of credit sales over ninety days give about forty days. It is recomputed every night by the jobs of the background jobs guide and shown in the manager’s dashboard with a single written definition, so that it does not change meaning depending on who reads it. Customers and amounts are a constructed example.
Customer credit, in five layers
Allocation is the accented layer: without it, you know how much the customer owes, not since when nor for what.
Customer account. One entry per document, immutable; a correction is a new entry, credit note or reversal, never an edit. The customer is the one from the single file of the single customer guide, because receivables split across three records of the same customer are not receivables. Allocation. At the counter, the application proposes the assignment, oldest invoices first, and the cashier confirms or chooses; a deposit “on account” stays unallocated, visible, and is assigned to the next invoice; an overpayment becomes a credit note. Cheques and states. Received, deposited, cleared, bounced; allocation is conditional until clearing, confirmed by the bank statement imported following the integration guide; a bounce reopens invoices, puts the customer back in the reminder sequence and warns the rep.
Age and reminders. Buckets from the due date; the sequence written by the manager and run every night, through the channels of the notifications guide; a payment stops it, a dispute pauses it, and exceptions, a big customer who is not blocked, are recorded decisions of the manager, not oversights. Limit and blocking. A limit per customer, sometimes per customer group; compared with exposure at order time, in the field as on the portal; an overrun blocks or requires a named approval, and the order keeps the trace of who approved.
The reminder sequence, in six beats
The delays are those of a typical company; the manager sets them, and the code does not know them.
D-3, reminder: WhatsApp or SMS, with the amount, the due date, the invoices concerned thanks to allocation, and a payment link to the page of the online payment guide when the customer pays by card. D+1, overdue: the invoice is marked late, a short message goes out, and the rep sees the state on their round. D+7, call: a call task is created for the rep, and the outcome is entered as a dated promise or a dispute; an undated promise does not exist, and a broken promise restarts the sequence.
D+15, block: new orders are blocked or sent for approval, and a per-invoice statement is sent, printable following the printing guide. D+30, manager: the file is handed to the manager with the statement, the promises and the exchanges. Payment or dispute: the sequence stops by itself on payment, and a dispute pauses it until resolved; nothing depends on an employee’s memory. A collections agent built as in the WhatsApp agent guide can hold the first two beats, never the block nor the handover to the manager.
«The reminder is a sequence written by the manager and run by the application, stopped by a payment or a dispute, never by forgetting.»
Six real situations, and what the application does
Every row is a sentence heard at a distributor, a wholesaler or a shop, and the answer is a construction, not an instruction.
The customer owes 400,000 and disputes it: the statement lists every invoice with its remaining amount and every receipt with its assignment; no lump sum is negotiated, a list is read. The cheque bounced: the invoices it settled conditionally reopen, the reminder restarts, and the rep is warned before their next visit. The rep delivers a blocked customer: exposure is compared with the limit at order time, in the field as on the portal, and the overrun requires a named approval, following the pre-sales guide.
The customer pays a deposit “on account”: the unallocated receipt is visible as such and is assigned to the next invoice; the balance does not lie. Three customers chased twice, ten never: the sequence is written and run at night, and exceptions are recorded decisions of the manager. The accountant asks for receivables again: the ageing report comes out dated, exported, and entries go to accounting through the integration guide; the founder in France reads it in the remote management guide.
Holding customer credit in 2027, in weeks
Seven weeks, the first without code, and two for the account and allocation, because everything else depends on them.
- What the manager sees: at 8:00, who is late, by how much, since when, what the application has already done, and the files handed to them.
- What the rep can no longer do: deliver beyond the limit without approval, collect without a receipt, promise without a date.
- What is measured: average collection time, receivables per bucket, promises kept, bounced cheques, orders blocked and approved.
Week 1, rules: with the manager and the accountant, terms per customer, limits, the reminder sequence and its delays, who approves an overrun, and how entries must come out. Weeks 2 and 3, account and allocation: entries per document, proposed and confirmed assignment, remaining per invoice, bilingual statement. Week 4, cheques: states, conditional allocation, bounce that reopens and reminds. Week 5, take-over: opening balances per customer, open documents, unallocated receipts to assign, with the same dry run as any import.
Week 6, reminders and limit: sequence run at night, call tasks, blocking at order, approvals. Week 7, measurement: average collection time, receivables per bucket, promises kept, accounting export, Monday review. Prices and terms per customer come from the engine of the quote and invoice guide; this guide only adds what happens after the invoice.
- Why allocate? Is the balance not enough?
- A balance says how much, not since when nor for what. Without allocation, no reminder can say which invoice it is claiming, no dispute can be settled on a list, and the age of overdues is wrong. Allocation assigns every receipt to specific invoices, and every invoice knows its remaining amount.
- How are cheques handled?
- As documents with states: received, deposited, cleared, bounced. A cheque settles invoices conditionally, counts in exposure until cleared, and a bounce reopens the invoices and restarts the sequence. Clearing is confirmed by the imported bank statement.
- Who sets reminder delays and limits?
- The manager, in the first week, with the accountant, per customer or per customer group. The application runs them; it does not know them in its code, and they change without development. This guide does not cover late-payment penalties or tax rules.
- And the deposit “on account”?
- It stays an unallocated receipt, visible as such, until the invoice it will pay; it reduces exposure but not the remaining amount of a specific invoice. An overpayment becomes a credit note linked to the customer.
- How is the average collection time computed?
- With the common DSO formula: receivables divided by average credit sales per day, over a written period, ninety days in the example. It is recomputed every night with a single definition for the whole company.
- Can current receivables be taken over?
- Yes, through opening balances per customer, open documents and unallocated receipts to assign, with a dry run and refused lines raised to the manager. It is the fifth week of the typical calendar.
- How long to set this up?
- Seven weeks in the typical calendar, the first without code and two for the account and allocation. A shopkeeper with a few dozen credit customers takes less; a distributor with hundreds of retailers, cheques and reps takes all seven.