Payments and arrears
Ask the application who has paid, who has not and who paid the wrong amount.
How an agentic application answers the question every operator asks about their clients: who has paid, who is overdue, who short paid and which payments cannot be matched.
Direct answer
Can software actually do this?
An agentic application can answer this because it reads the customer, agreement, invoice and payment records itself, applies your billing rules to every account and returns a reviewable list with the reason each account appears. The arithmetic stays in ordinary software. The agent handles the untidy part: matching payments, explaining short amounts and separating what is settled from what needs a decision.
How it gets asked
The request, in the words people already use.
These are not prompts to be learned. They are the sentences a manager says to a colleague, which is the standard an agentic application should meet.
- “Summarise all our clients and tell me who has paid this month.”
- “Who is overdue, and how far behind are they?”
- “Who paid, but paid the wrong amount?”
- “Which payments have arrived that we cannot match to an invoice?”
- “Show me arrears by site, worst first, with the reason for each one.”
Where this comes up
The current situation
The answer already exists. It is just spread across four systems.
Almost every operator can eventually produce this list. The customer sits in one system, the agreement in another, the invoice in the accounting package and the money in a bank feed. Somebody exports each of them on a Monday morning, lines them up in a spreadsheet and works out what happened. The answer is correct for about a day, and the reasoning behind it lives only in that person.
- The list is rebuilt by hand every week and never quite matches last week.
- Short payments are noticed late, usually after the next invoice compounds them.
- Unreferenced payments sit in a suspense account until someone has time to investigate.
- Only one or two people can produce the answer, so it stops when they are away.
- Chasing decisions are made from a total, without the history that explains it.
What the answer depends on
The application has to read all of this, not one system.
The reason this work stays manual is rarely difficulty. It is that the answer lives in several places and only a person currently holds them together.
Customers and agreements
Who the client is, what they hold, at which site, on which rate and from which date. Rate changes and unit or property moves matter more than the current price alone.
Invoices and schedules
What was raised, for which period, on what terms and whether a credit note or adjustment has since been applied.
Received payments
Standing orders, card payments, direct debits and transfers, including the reference the payer actually used rather than the one you asked for.
Credits, refunds and write-offs
Deposits held, goodwill credits and anything already agreed but not yet reflected in a simple balance figure.
Communication history
Previous reminders, disputes, promises to pay and agreed payment plans, so an account is not chased for something already settled by conversation.
What the application does
The job, step by step.
Each step is either ordinary application code or a bounded piece of reasoning. Knowing which is which is the difference between a system you can operate and a demonstration.
Establish who is asking
The application resolves the person, their role and the sites or portfolios they may see. The scope of the answer is decided before any record is read.
Assemble the period and the population
It selects the accounts in scope for the question: active agreements, the billing period requested and any account with an open balance carried forward.
Read the ledger, not an impression of it
Invoices raised, payments received, credits applied and the resulting balance come from the accounting source of truth through a typed read, with the figures unchanged.
Match money to obligations
Payments are reconciled against invoices using your allocation rules. Anything that does not match cleanly is separated rather than forced into a category.
Classify each account with a reason
Settled, part paid, overdue, overpaid, unmatched or disputed. Each classification carries the specific evidence that produced it.
Explain the exceptions
For accounts that are not simply paid or unpaid, the agent reads the agreement and message history and states the likely cause: a rate change, a unit move, a duplicated payment, an agreed plan.
Return a reviewable answer
The result is a list a person can act on, sorted by what needs attention, with a link from every line back to the records it came from.
Hand the next action to a person
Chasing, refunding, writing off or rescheduling is proposed, never performed silently. Approval is required in proportion to the consequence.
Worked example
What a useful answer actually looks like.
Summarise every client at the Northgate site for September: who has paid, who has not, and who paid the wrong amount.
Illustrative accounts and figures, written to show the shape of a useful answer. Codemind does not publish customer data, and this is not a report from a client system.
| Account | Status | Why it appears |
|---|---|---|
| Bay 12 · Harding | Paid in full | Invoice 4471 settled on 2 September by standing order. Amount and reference both matched. No action. |
| Bay 27 · Nadeem | Short paid by £18.00 | Paid £132.00 against a £150.00 invoice. The unit was upgraded on 14 August and the new rate was applied correctly, but the standing order still pays the old amount. This will recur next month. |
| Bay 31 · Okafor | Overdue, 9 days | Invoice 4488 unpaid. Two late payments in the previous six months. A promise-to-pay date of 30 August was recorded in a call note and has passed. |
| Bay 40 · Reyes | Paid, unmatched | A payment of £95.00 arrived on 4 September with no reference. Amount and date fit this account, but nothing confirms it. Held for a person to allocate. |
| Bay 52 · Sinclair | Overpaid by £40.00 | The September invoice was paid twice, once by card and once by transfer. The credit is on the account and needs a refund or carry-forward decision. |
| Bay 63 · Ashworth | Paid, on an agreed plan | Behind on the original schedule but paying to a plan agreed on 11 August. Appears here so it is not chased by mistake. |
The same question can then be narrowed without rebuilding anything: only this site, only accounts more than thirty days behind, only the accounts where somebody has already promised to pay, or only the short payments that will happen again next month.
Stays in ordinary software
What must never depend on a model.
- Invoice totals, tax, credits and the resulting balance.
- The rule that decides when an account is overdue and by how many days.
- The allocation rule that closes an invoice once a payment is confirmed.
- Which sites, portfolios and accounts each role is permitted to see.
- The audit record of every read, proposal and approved action.
Where reasoning earns its place
What genuinely needs judgement.
- Working out why a payment is short by reading the agreement history rather than only the number.
- Proposing a likely match for a payment that arrived without a usable reference.
- Grouping accounts by the reason they need attention instead of by balance alone.
- Noticing an account that is technically paid but has changed behaviour.
- Writing the summary in the language of the operation, not as a database extract.
Control boundary
What keeps this safe to run.
Autonomy is not a setting. It is the sum of the scope, the tools and the approvals the application has been designed to enforce.
The first release answers questions. It does not allocate payments, issue refunds or change a balance.
Site, region and role scope are applied by the application before context is assembled, not requested politely in a prompt.
Each classification links to the invoice, payment or note behind it, so the answer can be checked rather than trusted.
Allocation, refund, write-off and plan changes are proposals with a named approver and a recorded decision.
Who asked, what scope was applied, which records were read and what was proposed or approved is durably recorded.
Deliberate limits
What it does not do.
- It does not calculate the balance. The ledger does, and the agent quotes it.
- It does not allocate an unmatched payment on a guess. It presents the candidate and waits.
- It does not see accounts, sites or portfolios outside the asker permission.
- It does not write off, cancel or reschedule anything without an approval that is recorded.
- It does not replace your accounting system, and it does not become the source of truth.
How you know it works
The evidence to require.
- The total of the returned list reconciles to the ledger for the same period.
- A sample of accounts is checked by the person who previously produced the report by hand.
- Every exception carries a reason that a finance colleague agrees with.
- Unmatched and disputed items are counted, not hidden inside a total.
- Disagreements are logged as a dataset and used to improve the rules or the context.
A sensible first release
Narrow enough to trust, complete enough to be useful.
The first version should be able to fail without costing anything, while still producing an answer somebody would miss if it disappeared.
One site or one portfolio, one billing period, read-only.
The classification rules written down and agreed with whoever owns collections today.
A typed read against the accounting system and the operational records, with no write capability.
A weekly comparison against the existing manual report until they agree.
Only then: proposals for chasing, allocation or plan changes, each behind approval.
Common questions
Questions about payments and arrears.
The questions that should be settled before anyone builds this.
Can this work with Xero, QuickBooks, Sage or our existing system?
Usually, through their APIs, and the same pattern applies to an internal database. What matters is whether the system exposes invoices, payments, credits and the customer link reliably enough to reconcile, and whether the plan you are on includes API access. That is confirmed during discovery rather than promised in advance.
Does the AI work out the balances?
No, and it should not. Totals, tax, credits and the definition of overdue stay in ordinary application code and the accounting system, where they can be tested. The agent reads those figures and explains the situation around them. If a model is doing the arithmetic, you cannot audit the answer.
What happens when a payment does not match any invoice?
It is reported as unmatched, with the candidate accounts it might belong to and the evidence for each. A person allocates it. Automatic allocation on a probable match is how suspense balances quietly become wrong, so it stays a proposal until someone with the right permission confirms it.
How is this different from a report or a dashboard?
A report answers the question it was built for. This answers the question you actually asked, including follow-ups, and it explains each line rather than only counting it. A dashboard tells you arrears are £4,200. This tells you which six accounts that is, why each one is there and which two will recur next month.
Do we need to replace our current systems first?
No. This job is mostly a read across systems you already run. Replacement is a separate decision. If the underlying records are inconsistent, that becomes visible quickly, which is useful in itself, but it is usually cheaper to fix the specific gaps than to rebuild everything before starting.
Related use cases
How Codemind builds it
Start with the job
Bring the request, the systems and the person who does it today.
You do not need a specification. We will separate what belongs in ordinary software from what genuinely needs reasoning, and describe a first release that can prove itself.