The Collection Call You Have to Make

Do not make this call from memory. The call is short and it will go wrong the moment you have to check a figure while the customer is waiting, because the silence changes the conversation from a discussion into an audit. Six items, and each one has a specific job in the call.

The invoice document itself, not the total. The number is not what you need; the number is easy to read and reading it is what you do when you have nothing better. You need the line items, because the most common outcome of this call is the customer telling you about a line they do not recognise, and if you do not have the line in front of you you will either argue with them about it or fold immediately.

The allocation history, not just the outstanding balance. A balance of 47,200 might be one untouched invoice or four invoices with payments against them and something unexplained in the middle. Those are different conversations. Outstanding is a projection of allocations, recomputed rather than stored, so the list of allocations is the real fact and the balance is only a summary of it.

The last recorded promise, with its date, and whether the money arrived. This is your anchor. Referring to a date the customer themselves gave is a completely different conversation from asking for a new one out of nowhere, and it costs nothing to do and is skipped more than anything else on this list.

What you are willing to accept as an outcome today. Before the call, decide which of these you can live with: full payment on a named day, a named part payment, a schedule over named dates, or nothing this month with a named review date. If you decide it on the call you will agree to whatever you are tired of, and the conversation will drift toward the customer's preferred option because you are the one who is uncertain.

And who you are, and what your authority is. Whether you can agree to a payment schedule, whether you can offer a part payment against a disputed line, whether you can split an invoice. If you do not know your own limits before the call, you will discover them under pressure and the customer will price that correctly.

There are four answers you will get, and only one of them is refusal. Getting the category is the entire skill, and the categories are much easier to recognise than they feel when you have not slept.

Two things to notice about the categories. First, category three is far more common than people expect, and it is the only one where a small piece of work on your side ends the problem. Second, categories one and two are not answers at all, they are deflections, and the difference between a deflection and a refusal is often nothing more than whether the person on the call is willing to give you a name. If the call ends in category one or two without a name and a date, you have not had a collection call. You have had a call, and the outcome is identical to making none.

There is a fifth response that is not a category but functions like one, and it is the one to watch for. Silence is not refusal and it is not acceptance. Silence after a call usually means the call was not passed to anybody, because passing a call to a colleague is a piece of work and there is no reason to do it for a supplier. If you hear category two, assume the call was not passed until it is.

The assumption behind most escalation is that the amount is the problem: that a large outstanding balance creates pressure, and pressure produces payment. The assumption is almost always wrong, and acting on it is expensive, because the usual response to it is a discount.

Think about what the customer is actually deciding. They have an invoice sitting in a queue that somebody has to process, and the amount on it does not affect the effort of processing it. For a business of any size at all, the marginal cost of paying 47,200 is the same as the marginal cost of paying 4,720: a person, a run, an approval. What the amount does affect is the internal argument the customer has to have, and that argument is only interesting when the number is large enough to need a director. Below that threshold the invoice is not being weighed. It is being processed, or it is being ignored, and neither of those is a function of the size of the number.

So a large invoice is not collected by being larger. It is collected by being made easy and by having somewhere in the customer's process where it can stop being ignored. And a small invoice is not ignored because it is small. It is ignored because nothing about it reached a person with the authority to release it. This is why the practical priority order we described for chasing is not by amount at all, and why a written rule beats instinct on this specific question: the instinct is that bigger is more urgent, and the mechanism says urgent has nothing to do with big.

The corollary is uncomfortable. If the amount is not the problem, then offering a discount is treating a symptom that is not there, and it is the most expensive way to end a call, because it converts a processing problem into a margin problem permanently. The customer's finance team learns that asking produces a reduction, and that lesson generalises across every supplier and every invoice you send them next.

The most common imagined scenario is a customer who does not want to pay. It is the rarest of the four categories. Here is a constructed illustration of a call that looks like a refusal for two of its three minutes and is actually a document problem, followed by the arithmetic of what the customer was owed and what they sent.

The lines below are a constructed illustration written for this article so the shape of the exchange is visible. They are not a transcript of a real call, and no real customer, company, or person is depicted. Every figure below is constructed and the arithmetic is shown so you can check it by hand.

Now the arithmetic, constructed so you can check it. Invoice I-336: taxable value 20,000, GST at 18 percent used only so the total is checkable, which is 20,000 multiplied by 0.18, giving 3,600. Total on the invoice: 20,000 plus 3,600, which is 23,600. The customer sent a payment for 20,000, not 23,600. The gap is 23,600 minus 20,000, which is 3,600 — exactly the tax component. The amount of the payment equals the taxable value precisely.

That is not a coincidence and it is not a dispute about whether the tax is owed. It is what happens when somebody pays the value of the goods and stops there, either because the tax is being handled through a different route in their process or because the document that would have shown the tax as a separate line was the very document their system rejected. Either way, the customer has sent you 20,000 of a 23,600 invoice and the remaining 3,600 is not a disagreement about money. It is a consequence of the document problem.

This distinction is the whole outcome of the call. Treated as a bad debt, 3,600 goes into a write-off and the 20,000 is collected with no relationship damage. Treated as a payment dispute, the customer argues about the tax, the conversation moves to a question that is not yours to answer, and the document is still wrong. The honest sequencing is: fix the document, confirm what was rejected and why, send the corrected document, then check what the customer can now process. If the tax treatment itself is in question, that is a question for your own chartered accountant and for nobody else, and this is precisely the case where the correct answer is to stop and defer rather than to interpret the invoice on the call.

One more thing about the timing. That invoice had been sitting for three rejected attempts, which is three cycles of a customer doing exactly what they were supposed to do. Every one of those attempts was information the business did not have, because a rejected document in the customer's portal is invisible from yours. The only reason this call happened at all was that somebody finally made it. Nothing in a system can see the rejection. What a system can do is make the outstanding amount and the failed attempts of chasing visible enough that somebody is prompted to make the call, which is a much smaller and more defensible claim than promising to get the money back.

A collection call has succeeded or failed by the time you hang up, and the test is simple: do you have a next step with a date on it, and do you both know whose it is. If the answer is no, the call failed even if it was pleasant, and the failure compounds because you will have to make the same call again.

Close by summarising, out loud, so the customer hears their own answer. Say the category back to them and the next step, and ask them to confirm it. It feels artificial and it is the single highest-value thirty seconds in the call, because the summary is what you will both rely on in three weeks, and a customer who has said a date out loud is markedly more likely to hit it than one who has merely implied it. Where the customer gave a date, write it into the payment promise record immediately, with the invoice, the date, and who took the commitment. Where the customer gave a name, write that too, because the person who gave a name on the phone is the person you call next time and a department is not.

Then record the category itself, not just the outcome. The pattern across a customer is the useful thing, and it takes one field. A customer who is category three three times running has an internal process problem and needs a different approach from one who is category one, because category one is solved by a reminder and category three is solved by sending something. If you never record which category you got, the next call starts from nothing and you will spend the first two minutes re-deriving what the last one already established.

Finally, decide what the call means for the relationship while you are still thinking about it, and write that down too, because it is the one judgement on the call that cannot be reconstructed later. Sometimes a customer is worth more than the invoice and the right move is a smaller payment now and a larger order later. Sometimes a customer who is slow to pay is telling you something about how they will treat a support request. Both of those are real and neither is visible on any report, and the note is the only place they exist.

What this system will not do is make the call for you. There is no dunning sequence that fires a reminder on day seven and day fourteen, no automated escalation that raises an invoice to somebody senior on its own, no card on file, and no auto-debit. Each of those would be convenient and each of them takes a decision away from the one person who can tell whether this particular customer is having a bad month. What it will do is hold the outstanding amount, the allocation history, the last promise, and the note from the call on the same invoice record, so that the person who dials next week has everything this call produced and is not starting over.

If the chase needs to happen on a schedule rather than from memory, that is a process you run yourself: NoxOrigin has no rule engine and no run history, so nothing here will fire a reminder on its own. The point is the same as everywhere else in this article: the reminder should be a decision somebody made, and the follow-up should be a record, not an act of memory.