The Rent Arrears Build Standard
Rent accrues, and the escalation clock is written in legislation rather than in your credit policy. How to build arrears handling that respects both, and that knows when to stop.
Used by
- Property Manager
- Arrears Officer
- Head of Property Management
10 min read · Published by AI Pathway
Using Claude? This standard installs as a skill. Guides for ServiceM8, Xero and Simpro.
How to get this live in your business
Build it for mePick a time and we run the arrears chase for you.What this is
An open build standard for arrears triage and escalation across a rent roll. Implement it in whatever you like.
The core rule
Arrears is a derived position, not a stored number, and the escalation clock belongs to legislation rather than to you.
What it never does
Serve a notice, apply a fee, or message a tenant whose ledger has not been verified. Drafting is the boundary.
The hard part
Knowing when to stop. A chase sent to someone who already paid, or who is in hardship, costs more than the arrears.
Your platform already sends the automatic reminders, and it should keep sending them. Those collect the tenancies that were going to pay anyway. What is left is a short list where something is genuinely wrong, and each one needs a conversation on a particular day. Automating arrears does not mean sending more messages. It means producing that short list correctly, and never messaging anyone who should not have been on it.
The daily run, end to end
- Start at the ledger, every day.
- Derive the position rather than storing it: paid-to date first, then days in arrears, then balance.
- Triage to exactly one of four outcomes: not actually in arrears, will self-resolve, needs a conversation, or on the statutory path.
- Draft the chase, but do not send it yet.
- Any stop condition? Payment in transit, a payment arrangement, hardship or dispute on file, already on the formal path, a person has paused it, or the ledger is stale. If any is true, nothing sends and it goes to a person.
- If none is true, the chase is released, one channel at a time.
- Past the statutory threshold? If yes, the notice is drafted and never served, because dates and service method are legal facts. If no, the next touch is dated, and the stop conditions are evaluated again before that message goes.
Take the spec to Claude, ChatGPT or Copilot. The sentence to paste is one click away.
1. What this standard covers
Deciding, every day, which tenancies in a rent roll need a human to do something, and preparing that something. It covers triage, escalation timing, and the record. It does not cover serving notices or representing anyone at a tribunal.
Why arrears is not accounts receivable
An overdue invoice sits still: the amount is fixed and the counterparty is a business. Rent accrues. A tenant four days behind is five days behind tomorrow whether or not anyone opened the file, the counterparty lives inside the asset, and the escalation path is set by state legislation rather than by your credit policy. Anything built on receivables assumptions will get the timing wrong in both directions.
2. Derive the position, never store it
An arrears position is the output of a calculation over the ledger, not a number to be cached. It changes every day without anyone touching it, which is the property that breaks most implementations.
Three things have to be derived together, and reported together:
- Paid-to date: the date rent is paid up to, which is the figure legislation and tribunals reason about
- Days in arrears: derived from paid-to and today, not from when someone last looked
- Balance: the dollar figure, which is the least useful of the three on its own
Report the paid-to date first. A balance of $1,840 means nothing without knowing whether that is a fortnightly rent eight days late or a weekly rent a month behind, and the statutory clock runs on days, not dollars.
3. The four triage outcomes
Every tenancy showing arrears resolves to exactly one of these, and the ordering matters: check for the first before assuming any of the others.
Outcome 1
Not actually in arrears
Payment in transit, a part-payment misapplied, rent paid to the wrong reference, a ledger timing artefact
Suppress the chase and flag the ledger, never message the tenant
Outcome 2
Will self-resolve
A day or two behind, consistent payer, no history
The platform reminder is enough. Do not escalate a pay cycle
Outcome 3
Needs a conversation
Something has changed: a pattern break, a part-payment, a first-time miss on a long tenancy
Surface to a person with the history attached. This is the list that matters
Outcome 4
On the statutory path
The arrears period is at or past the threshold for formal action
Draft the notice, never serve it. Dates and service method are legal facts
Outcome 1 is checked first and is the reason to build this at all. Chasing someone who already paid is the single most damaging thing an arrears process does. It is also common, because payments arrive with the wrong reference, land on a weekend, or get applied to the wrong tenancy. A system that assumes the ledger is right will generate exactly this error at scale and much faster than a person would.
4. The stop conditions
A chase must not be sent when any of these is true. Evaluate them before every message, not once when the sequence starts. Circumstances change mid-sequence and that is precisely when an automated chase does its damage.
Payment received or in transit
Including a part-payment that changes the position, and anything received since the list was built.
A payment arrangement is in place
If the tenant is meeting an agreed plan, they are not in arrears for chasing purposes even though the balance says otherwise.
Hardship, dispute or advocacy is on file
Once someone is engaged with a support service or has raised a dispute, the matter belongs to a person.
The tenancy is already on the formal path
Once a notice exists, messaging outside it can undermine it. One channel at a time.
A person has paused it
Explicitly, with a reason and a review date. The pause must survive the next run.
The ledger is unverified or the data is stale
If the feed has not updated, the correct action is to send nothing and raise it.
5. Six rules that keep it trustworthy
The clock belongs to legislation.
Thresholds for formal action are set per state and territory and they move. Hold them as dated, versioned rules the way a compliance calendar does, not as constants in the code.
Draft the notice, never serve it.
A breach or termination notice is a legal instrument whose date and service method are facts a tribunal will examine. Prepare it, present it, let a person serve it.
Verify the ledger before every message.
Not when the run starts. Between building a list and sending from it, someone will have paid.
Escalate the exception, not the balance.
The useful output is the short list where something has changed: a pattern break, a first miss on a long tenancy, a part-payment. A ranked list of everyone who owes money is what the platform already gives you.
Silence is a finding.
A tenant who has never missed and now has, and does not reply, is the highest-value row on the list. Non-response is a signal, not an absence of one.
Never apply a fee or a charge automatically.
Whether a fee is even lawful depends on the tenancy and the jurisdiction. This is not a decision to make at machine speed.
6. The parts that are harder than they look
Payment matching
Rent arrives by bank transfer with whatever reference the tenant typed, from an account in someone else's name, sometimes split across two payers on one tenancy. Unmatched receipts sitting in a suspense account are the most common cause of a wrongly chased tenant, and fixing arrears usually means fixing this first.
Part-payments and irregular cycles
A tenant paying $300 a week against a $420 rent is in arrears and paying. Fortnightly and monthly cycles, mid-cycle rent increases and pro-rata first periods all break naive day counts.
The paid-to date is not always what the platform says
Different systems compute it differently, particularly around part-payments and credits. Before automating anything, confirm the figure you are reading means what a tribunal would take it to mean.
Jurisdiction, and rent rolls that cross a border
Thresholds, notice periods and permitted contact all differ by state and territory. An agency with properties either side of a border needs the rule to know which applies.
Hardship is not a field
It arrives in a phone call, a text, or a support worker's email. If it lives only in someone's memory, the automation will keep chasing straight through it, which is the worst failure this system can have.
The owner is the second conversation
The landlord has views about how hard to push, and they are not always consistent with the legislation or with each other. Whose instruction governs, and where that is recorded, is a design decision you cannot avoid.
7. When the chase becomes a conversation
Everything above produces a short list of tenancies where somebody needs to talk to somebody. That is the point at which this standard stops being a data problem, and it is worth being honest about what changes.
Text and email are one-way. They deliver a message and wait. A conversation is different in kind: it has to hear an answer it did not expect, decide whether that answer is a stop condition, and get the next sentence right in front of a person who may be embarrassed, angry or in genuine hardship. A prototype that handles the expected reply is not most of the work. It is the beginning of it.
What hardening a conversation actually means
- Every branch a real tenant takes. “I paid yesterday.” “I lost my job.” “Talk to my advocate.” “That’s not my rent, I split it with my partner.” Each is a different outcome and one of them ends the call immediately.
- Recognising a stop condition mid-sentence. Hardship does not arrive as a form field. It arrives halfway through an explanation, and the conversation has to stop pressing the moment it does.
- Never negotiating. A payment arrangement is a decision with legal weight. A conversation may capture a proposal; it must not agree to one.
- Compliance while talking. Disclosure that it is an AI, permitted contact hours, recording consent, the Do Not Call position, and what happens if the person asks to stop.
- Reading the live ledger during the call. If a payment landed this morning, the conversation needs to know before its second sentence, not after.
- Writing back what was actually said, in a form the next person and a tribunal can both read.
This is the part of the standard we would not expect anyone to build from scratch, and the honest reason is not complexity. It is that a conversation fails in public, with a tenant, on a topic with legal consequences. The iteration required to make one safe is not a weekend, and the failure mode is not a wrong number in a queue.
Where this leads
The call is the hosted step: your system triages, and hands the short list to Office Voice to ring. Today that hand-over is one governed call per tenant (create_call: disclosed, recorded, a lawful basis, calling hours, about ten a day), speaking the one-line purpose your system gives it. The arrears conversation itself, with the hardship branch that ends the call and the rules for each state, is Not yet: Office Voice chases overdue invoices that way on Xero, and is being built to do the same from a rent roll. Until then, keep hardship and anything past a reminder with a person.
The rest of this standard stands on its own. A build that stops at the short list and hands it to a person is a good build, and most of the value is already in it.
8. What breaks after it works
- A threshold changes and nobody notices. The escalation dates are now wrong across the whole rent roll, in the direction of acting too late or too early.
- The suppression list decays. Hardship flags and payment arrangements are set once and never reviewed, so either they expire and the chasing resumes wrongly, or they never expire and real arrears goes unworked.
- It leaves when they do. Which tenants are genuinely struggling, which owners want a hard line, which references are habitually wrong: none of it is in the system.
- Nobody can show what was sent. At a tribunal the question is what was communicated and when. A sequence that fired without keeping the sent copy cannot answer it.
9. What It Is Worth
No figures here: the standard derives none, and your results will differ. These name the levers, and what each is worth depends on your payment matching, which is where wrongly chased tenants come from.
Paid-to date
Reported before the balance
The statutory clock runs on days, not dollars, so the date rent is paid up to drives the timing.
Zero
Chases to tenants who already paid
Outcome one is checked first: payment in transit, a wrong reference, or a part-payment misapplied.
One list
Exceptions, not everyone who owes
Escalate the pattern break and the first miss on a long tenancy. The platform already lists the rest.
The hard part is knowing when to stop. A chase sent to someone who already paid, or who is in hardship, costs more than the arrears.
10. The records it keeps, in the shape your developer needs
Sections 2 to 4 in the shape a build needs them. The arrears position is derived on every read and never stored, which is the property most implementations get wrong: a cached number is right on the day it was written and wrong every day after.
For your developer. Show the fields for your developer
arrears_position: # derived on read. Never cached, never stored.
tenancy_ref: string
paid_to: date # report this FIRST. The statutory clock runs on it.
days_in_arrears: integer # derived from paid_to and today, not from last look
balance: money # least useful of the three on its own
rent_period: weekly | fortnightly | monthly
derived_at: timestamp
triage_outcome: # exactly one per tenancy, checked in this order
outcome: not_in_arrears # check FIRST. Chasing someone who paid is the
| will_self_resolve # most damaging thing this process can do.
| needs_conversation
| statutory_path
evidence: string # what in the ledger says so
decided_at: timestamp
stop_check: # evaluated before EVERY message, not once per run
tenancy_ref: string
blocked_by: [string] # the stop conditions in section 4 that matched
checked_at: timestamp # circumstances change mid-sequence
statutory_clock:
jurisdiction: string # the state sets the periods. Do not hardcode one.
notice_issued: date | null
rule_version: string # which version of the rule produced the dates
next_lawful_step: string
next_lawful_date: date # derived from the rule, never typed inNothing above stores a days-in-arrears figure. If your schema has a column for it, the number will be wrong on a Monday after a weekend payment, and the tenant will be chased for money they have paid.
11. What your developer builds, and the step that needs care
Everything in sections 2 to 5 is yours and worth building. The line is the conversation: the moment this stops sending messages and starts talking to a person about their home.
For your developer. Show the setup for your developer
provider:
stub: local.mock_rent_roll
production: office_voice.recover # Office Voice / Recover, sold as Get Paid
default: stub # no live mapping in the conformance kit yet
scopes:
campaigns:initiate hand over the short list, one governed call per tenant (create_call)
contacts:write the tenant as a contact Office Voice holds, and what was agreed
audit:read read back why a tenancy was or was not rung
not_yet: # the arrears conversation itself
- a hardship branch that ends the call and hands to a person
- the statutory clock and notice rules for each state
- reading the tenancy ledger during the call
stays_local: # do not hand these over. They are the standard.
- deriving the position
- the four triage outcomes
- the stop conditions
- the statutory clock and its jurisdictionBuild against the stub until the message stops being enough. A build that stops at the stub is still a working arrears process and it is most of the value on this page.
The pass test. Start a chase on a tenancy that is showing arrears. After the first message and before the next, apply a payment in the ledger that clears it. Nothing more may be sent, and the record must say which stop condition caught it. Then push one tenancy past the threshold: the notice is drafted and sits unserved until a named person releases it. As an extra step, re-run the first with the payment reversed and a hardship flag set: again nothing, again with a reason. Each takes a minute to stage from your own data. If a message sends after the payment, your stop conditions are being evaluated once at the start of the sequence rather than before every message, which is section 4 in one sentence. If the notice goes out on its own, section 5 is not built.
12. A checklist to hold any build or supplier to
- The arrears position is derived every run. The arrears position is derived from the ledger on every run, never cached.
- Paid-to date drives escalation timing. Paid-to date is reported alongside the balance, and drives escalation timing.
- Statutory thresholds are dated rules. Statutory thresholds are held as dated, per-jurisdiction rules, not constants.
- Stop conditions are checked per message. Every stop condition is evaluated immediately before each message, not once per sequence.
- An unmatched or stale ledger escalates. A tenancy with an unmatched or stale ledger is escalated, never chased.
- Notices are never served without a person. Notices are drafted and never served without a person.
- No fee is applied automatically. No fee or charge is applied automatically.
- Every message is retained. Every message sent is retained with its timestamp and recipient.
- Automation discloses itself and stops on hardship. If a conversation is automated, it discloses itself, respects contact hours, and stops on hardship.
- It survives the builder. Someone other than the builder can explain what it does, and it runs on an account the business owns.
- The pass test passes. A tenancy paid mid-sequence stops receiving messages, and a notice sits undelivered until a person releases it.
- 1
Hold the build to the checklist
The checks in this standard are what a working build looks like. Implement it yourself, hand it to a developer, or hand the page to an AI with the button below.
- 2
Do not hand-roll
There is no product for this step. Highest option: none. Checklist plus a build.
- 3
If you are stuck
Exceptions, three systems, a team that will not maintain a Zap, or an owner who wants it done. We implement when it has to survive the business.
Facts that can change, and when we checked them
Checked as at 18 September 2026
Do Not Call Register Act 2006 (Cth), administered by ACMA. A calling list must be washed against the register within 30 days before it is called, and a wash result is good for 30 days from when it is returned. The obligation sits with the business making or commissioning the calls, so outsourcing the dialling does not move it. Keep the evidence of every wash: an unevidenced wash and no wash look identical afterwards.
Arrears thresholds and notice periods are per state and they move. Queensland: more than 7 days in arrears before a notice to remedy breach (Form 11), which gives 7 days to remedy, 5 in a caravan park. New South Wales: a termination notice once 14 days in arrears, with at least 14 days to vacate, and no separate remedy notice for rent. Victoria: 14 days in arrears, then 14 days’ notice. Hold these as dated values keyed by jurisdiction, never as constants.
Check these against the primary instrument before you rely on them, and store the date you checked beside the value rather than hard-coding it. This standard tells you the shape and where to look. It is not legal advice and it does not tell you that anything complies.
Related reading
Want the whole thing by email?
This paper, plus the rest of the library. One click to stop them.