Chasing Your Own Debtor Book

1. What You Actually Need Off the Ledger

Export the aged receivables report and ignore most of it. Five fields carry the method:

• Customer. The unit of the conversation. Not the invoice, which is the mistake in section 3.
• Amount outstanding, per invoice. You need them separately to talk about them, and summed to rank.
• Days past due. Off the due date, not the issue date. A 30-day account issued four weeks ago is not late.
• A mobile number. The field that decides whether any of this is workable. Most ledgers hold a billing email and an office landline, which is the wrong end of the building.
• Last contact, and what was said. Almost never in the ledger. Section 5 is about making this exist.

Run the coverage check before anything else. If two thirds of your overdue rows have no mobile, you do not have a chasing problem yet, you have a data problem, and the fix is a field on the account-setup form rather than anything on this page.

2. Four Buckets, Not One Reminder Run

A single overdue list treats a customer who is four days late the same as one who broke a promise in June. They need opposite conversations.

• Just late, 1 to 14 days.Almost always an oversight: the invoice is in someone’s inbox behind forty others. A short, friendly nudge clears most of it, and the tone matters more here than anywhere else because these are customers who are about to pay you.
• Drifting, 15 to 44 days. The bucket that decides your debtor days. Nothing is wrong yet, which is exactly why nobody deals with it, and it is the one that quietly becomes the 90-day problem.
• Hard, 45 days and over with no contact logged. Something is going on and you do not know what. The job of the first call is to find out which: cash flow, a dispute nobody told you about, or a purchase order you never had.
• Broken promise. A date was given and it passed. This outranks every other bucket, because it is the only one where you already have a commitment to refer back to, and referring back to it is most of the call.

3. Which Invoice Gets Chased First

This is the section that matters, and the one most builds get wrong twice.

The first mistake is ranking by age. Age tells you how bad a row is. It does not tell you what fixing it is worth. A three-month-old $400 invoice will always sort above a three-week-old $40,000 one, and you will spend your week on the wrong end of the book. Rank by amount at risk, and let age break ties.

The second mistake is ranking invoices instead of customers. One customer with six overdue invoices is one conversation, not six. Ringing them six times is how a collections process turns into a complaint, and it also loses you the only leverage you have, which is the total.

One more rule, and it is a judgement rather than a formula: flag any customer whose balance is a large enough share of the book that chasing them is a relationship decision. Those are not collections calls and should not be automated. Someone who knows the account rings them.

4. The Opener Decides Whether You Get a Date

The purpose of the call is not to be paid on the call. It is to leave with a date. Everything in the opener should serve that.

• Name the invoice and the number. Vagueness reads as a mass mailout and gets treated like one.
• Say how far past due, without editorialising. “Thirty-eight days” is a fact. “Significantly overdue” is an opinion they can argue with.
• Ask one question that takes a date as an answer. “When can we expect it?” beats “Can you pay this?”, which takes yes or no and gets you neither.
• Do not apologise for calling. You are asking for money you are owed.
• Do not mention interest, fees or consequences unless they are real, written into your terms, and you intend to apply them. An empty threat is worse than no threat and it is the fastest way to a dispute.

The most useful thing an opener can do is make it easy to say the real reason. A large share of “we will get to it” is actually a dispute, a missing purchase order, or an invoice that went to the wrong person, and none of those get solved by another reminder.

5. A Promise Is an Object, Not a Feeling

This is the part that separates a build that works from one that feels busy. When somebody says they will pay, that has to become a record with fields, not a sentence in a note:

• An amount, which may legitimately be empty. “I will sort it this week” is a real outcome with no number in it, and forcing a number invents one.
• A date. The whole point. No date means you did not get a promise, you got a deflection, and the follow-up should be scheduled accordingly.
• A method, if offered. Bank transfer, card link, cheque in the post. It tells you when to stop expecting it.
• When it was captured, so a promise made in March is not still driving behaviour in June.

Then the promised date becomes the follow-up date. This sounds obvious and it is the single most common gap: a system records the promise, leaves the chase schedule where it was, and rings the customer the next morning anyway. Nothing destroys the credibility of an automated chase faster.

And a promise has to survive the next conversation. If a dispute was logged in April, a promise recorded in May must not overwrite it.

6. The Gate, Which Is the Step to Not Hand-Roll

Everything above is a weekend’s work and you should do it. This part is not, and the reason is not difficulty. Each of these is a rule that has to hold on every single contact, including the one made at 8:04pm by a script nobody has looked at since March.

• Calling hours in the debtor’s timezone, not yours and not the server’s. Australia has three, and more in summer.
• The Do Not Call Register, and knowing which of your debtors are exempt and why. An existing-business-relationship exemption is real and it has to be recorded as claimed, not assumed.
• Public holidays, which are per state and are not a lookup you want to maintain by hand.
• Disclosure when the caller is an AI, every time, at the start.
• A stop on payment. The invoice clears at 9am and nothing should ring at 10. This needs to be driven off the ledger, not off a nightly export.
• A record that survives: what was said, when, on whose authority, and which human approved any exception.

The gate has to sit underneath the ranking, not beside it. If a high score can promote a debtor past a check, the check is advice rather than a rule, and the first time that matters will be the time somebody is looking.

You can build this. What you cannot easily build is the part where it is still true in eight months, after the model changed, the script was edited by someone else, and the person who wrote the gate moved on.

7. Try It Now: The Prompt

Everything above is the method. This is the method as something you can paste into Claude, ChatGPT or whatever you already use, along with an aged receivables export. It is deliberately the ledger half only: it buckets, ranks and drafts openers, and it stops before deciding that anybody may be rung, because that decision needs a register, a timezone and a consent record, none of which are in your export.

You are helping an Australian business chase its own overdue invoices.
I will paste an aged receivables export below.

Step 1. Tell me what share of rows have a usable mobile number, and what share
have only an email or nothing. Do not guess or fill gaps. If coverage is poor,
say so plainly, because it changes which buckets are workable.

Step 2. Sort every overdue invoice into exactly one bucket:
  - JUST LATE: 1 to 14 days past due. Usually an oversight.
  - DRIFTING: 15 to 44 days. The one that quietly becomes 90.
  - HARD: 45 days or more with no contact logged.
  - BROKEN PROMISE: a payment date was given and passed.
Put a row in BROKEN PROMISE over any other bucket if both apply.

Step 3. Rank inside each bucket. Rank by amount at risk, not by age alone: age
tells you how bad it is, amount tells you what it is worth fixing. Within a
customer, group every open invoice into one conversation, never one per invoice.
Say which customers carry a share of the book large enough that ringing them is
a relationship decision, not a collections one.

Step 4. For the top 20 conversations, write a two-sentence opener. Each must
name the specific invoice or invoices, state the amount and how far past due,
and ask one question that can be answered with a date. Do not apologise for
calling, do not threaten, do not mention interest or fees.

Step 5. List every row you deliberately excluded and why, in one line each.

Do not decide who may be contacted. Do not write anything that implies a
consequence you have not been told is real.

Two things to expect. The coverage answer in step one will be worse than you hope, almost always on mobile numbers, and that is the honest starting point rather than a reason to stop. And the exclusions in step five are the part worth reading closely: if you disagree with what it left out, your bucket rules are wrong, and rules you do not believe are rules you will quietly stop using.

8. Keep the Ranking, Hand Over the Call

Section 7 leaves you with a ranked list and an opener for each name. If you want the calls made by something that already holds the gate in section 6, the ranking stays yours and the conversation becomes ours. Build against a stub until it has to ring somebody, then change one line:

provider:
  stub:       write the ranked conversations to a file and read them yourself
  production: office-voice

scopes:
  contacts:read        the open book: what is outstanding and still needs a decision
  contacts:write       record a promise to pay. Contacts nobody
  campaigns:read       chase runs, and how many were skipped
  audit:read           read back why each contact was or was not lawful

Keys are minted in the product, by an account owner. If you are a bookkeeping or accounting practice, one key reads your whole client book, and you can narrow a key to named client orgs when you create it. That narrowing only ever subtracts: an org that later leaves the account stops being reachable by an old key.

# What is still open, across every client org the key reaches.
curl -H "Authorization: Bearer ovk_live_..." \
  "https://office-voice.com/api/v1/contacts?kind=lapsed_promise&limit=100"

# The debtor rang YOUR office and gave a date. Send it back, so the
# chase stops and the follow-up moves with it.
curl -X POST https://office-voice.com/api/v1/promises \
  -H "Authorization: Bearer ovk_live_..." \
  -H "Content-Type: application/json" \
  -d '{"tenant_id":"...","thread_ref":"INV-1042","amount":2400,
        "date":"2026-09-30","method":"bank_transfer"}'

Note what is not in that list: there is no endpoint that starts a call. That is deliberate rather than missing. Dialling stays behind the gate, configured in the product, because an API that lets a script decide who gets rung is an API that can be pointed at a purchased list at 9pm. The full reference is at office-voice.com/help/api.

9. Parts That Are Harder Than They Look

Not warnings. These are the four places a working build usually stalls, so you can recognise them as normal rather than as a sign you got it wrong.

• Mobile coverage is the binding constraint. Ledgers hold billing emails and office landlines. The fix is upstream, on the account-setup form and in conversation, and it takes months to pay off, which is why section 1 says check it first.
• Part payments break your buckets. A customer pays half. Is that invoice still overdue, still the same age, still the same bucket? Decide before it happens, because it will happen in the first week.
• Disputes hide inside “we will get to it”. Until you capture the reason, your aged report says the problem is time when it is actually a missing purchase order or a job somebody is unhappy with.
• Stop-on-payment is harder than it sounds. Off a nightly export you will ring somebody the morning after they paid, and that single call costs more goodwill than the other forty earned.

10. What Breaks After It Works

This section is the honest one, and it is the reason a build standard is worth publishing at all. A self-built version of everything above genuinely works. Here is what happens to it over time.

• It leaves with whoever built it.The rules live in one person’s head and one spreadsheet under their login, and this is a role that turns over.
• Nobody knows whether it ran. A quiet week and a broken week look identical from the outside. Receivables is the worst place for that, because the number moves slowly enough that you will not notice for a month.
• It degrades without failing. An export changes a column name, the broken-promise bucket matches nothing, and the system cheerfully reports zero broken promises. A false negative is worse than an error, because an error gets looked at.
• The gate is the first thing to rot. Not because anyone removes it, but because a holiday table goes stale, or a new workflow is added beside it rather than under it, and nobody re-runs the pass test in section 8.

None of that is an argument against building it. It is an argument for knowing which parts you want to still be true after you stop paying attention to them.