Everybody knows which customers are late. Nobody can say it from the system.
The invoices are right. They came off the sales orders, they carry the correct terms, and every payment that has arrived is sitting against the invoice it paid. What is missing is not accuracy, it is the standing view and the standing habit: which balances are thirty days out and which are ninety, who was chased last week and with what wording, and which customer is about to be chased twice by two people because the first reminder lived in a sent-items folder. So the aging gets rebuilt in a spreadsheet on Monday, the chasing runs out of an inbox, and the moment anyone is on holiday the collections process is the part of finance that quietly stops.
Follow-ups log a note or message in Odoo -- nothing is emailed or posted to the ledger automatically. Registering a payment is a separate, human-approved step.
What you get with accounts receivable
One receivables ledger, and the invoice-to-cash half of it working out of the box. Customers live on the partner record with their contacts, banking details, payment terms, receivable account, fiscal position and their own transaction history, no separate CRM required to hold them. Invoices are raised from sales orders as those orders are fulfilled, and scheduled jobs exist to send the ready ones. Where one customer has placed several orders inside a billing period, the orders consolidate into a single invoice for that customer rather than several. Payments are registered against open invoices, one payment can settle several invoices, and payment terms and the amounts left to settle are tracked on the ledger itself.
Where accounts receivable comes from
Three different places, and the difference is worth checking before you sign anything.
The invoice-to-cash half above is Odoo itself, nothing to add, no tier to reach, no per-user fee, and it runs on a deployment you own.
The aged-receivable view and the dunning policy are not in the stock product; Odoo's own live in a paid edition. Each has a free replacement the Odoo community publishes and keeps current, one adds the aged-receivable report, the other the levelled dunning policy stock Community is missing. We install them onto the same system you own, and the code stays yours.
That pattern is the product, not an exception to it: on this stack a missing piece is a free install onto software you already hold; on the system you are leaving, the same piece is a module and a per-user renewal, and that difference is the product. (Which half ships and which is an install is drawn out in the FAQ below.)
What the agent adds to accounts receivable
Your team stops rebuilding the chase list by hand every week and stops writing the same reminders from memory.
Once a week the agent reads every overdue customer invoice, skips any that already carry an open reminder activity, so running it twice never chases the same customer twice, sorts the rest into three tiers by how late they are, and writes one personalised chase email per invoice. A person reads the drafts. On approval, it puts a dated follow-up task on each invoice inside Odoo, so the next person to open that customer can see that the chase was made and when the next one is due.
That is the whole of it, and the boundary is the promise, not a limitation of it. No email is sent. The invoice does not change, not its status, not its outstanding amount, not its payment state. Nothing is collected. What you get back is the written work and the diary entry; the sending and the collecting stay with the person whose relationship it is.
This workflow is advisory. It writes a follow-up activity and a message draft and nothing else, it posts nothing to the ledger and moves no money. Del AI has completed no migrations, so nothing on this page describes something that has run for a customer.
What is dunning in accounts receivable?
Dunning is the structured chasing of invoices that are past due: a sequence of reminders, escalating in tone and in who signs them, sent on a schedule tied to how late the balance is. It is distinct from simply knowing that an invoice is overdue, which any ledger can tell you. Dunning is the policy layer on top, that a balance seven days late gets a soft reminder from the AP contact, thirty days a firmer one, sixty days a call and a copy to the account owner, plus a record on the customer of which stage they have reached, so the next reminder follows the last one instead of repeating it. The reason it is usually automated is not speed. It is consistency: an unautomated dunning process runs as well as the memory of whoever happens to be looking, which is why receivables collection degrades quietly during holidays and handovers rather than failing visibly.
Why do overdue invoices get chased inconsistently even when the ledger is accurate?
Because the ledger and the chasing are two different kinds of record, and most accounting systems only hold the first. A general ledger records events that have happened, an invoice was issued, a payment arrived, a balance is outstanding, and it will tell you correctly and instantly which balances are past due. What it typically does not hold is the state of the pursuit: who was contacted, on what date, in what language, at which escalation stage, and what is due to happen next if nothing arrives. That state has to live somewhere, so it ends up in a sent-items folder, a shared inbox or a spreadsheet column, where it is invisible to everyone except its author. The result is not inaccuracy, it is unevenness, the same customer chased twice in a week by two people, and a larger one not chased at all because the person who usually does it was away.
What should an AR agent do about an invoice that is overdue?
There is a real design choice here, and it is worth deciding deliberately rather than inheriting. One design has the agent send the reminder itself on a schedule. The other has it prepare the reminder, pick the right customers, apply the right escalation stage, write the message, check nobody has already been chased this week, and hand it to a person to send. The first is faster and the second is safer, and the difference is not really about the software: an outbound message that appears to come from your finance team is a customer relationship event, carries the sender identity and the suppression rules with it, and lands on someone who may be mid-dispute, mid-renewal or on a payment plan the ledger does not know about. The honest way to evaluate any vendor here is to ask which of the two they built, and then to check whether the answer is in the product or in the marketing. Ours drafts and stops: it writes the chase and logs a dated follow-up on the invoice, and a person sends every message. Oracle markets the opposite instinct on NetSuite's own accounts receivable page: "Automated dunning and collection notices reduce days sales outstanding (DSO)", and, on the same page, "companies can automatically send reminders in multiple languages and currencies before or after payment is due." That is a coherent position and a genuine capability. It is also a system sending mail to your customers on a rule, and it is worth knowing which of those two products you are buying.
Does Odoo do dunning and aged receivables without an add-on?
No, and the distinction between the two halves matters. Odoo's stock Community edition holds customers, invoices, payment terms, payment application and a partner ledger, so invoicing and cash application work with nothing added. It has no aged-receivable report and no dunning engine, not a limited version of either, but none at all. Odoo's own answers to both live in its paid edition. Free replacements for both are published and kept current by the Odoo community: one adds the aged-receivable report, the other the credit-control policy and dunning levels. They install onto the same deployment, which the customer owns, so the question a buyer should ask is not whether the capability exists but whether it arrives as a free install or as a paid tier.