Configuration
Every setting in Customer Statements & Ageing, and what each one changes.
There is very little to configure, which is the point. A statement is a derivation of your ledger, not a thing with opinions.
On the customer invoice
| Field | What it does |
|---|---|
| Disputed | Shows on the statement with a badge, outside the ageing |
| Excluded from statements | Leaves the document off entirely |
Disputed is not the same as excluded
A disputed invoice still appears. It is listed, badged, and kept out of the ageing buckets so it does not inflate what the customer is being told they are overdue on.
Sending somebody a statement that ignores a query they have already raised is how an account is lost. They know about the invoice; pretending it is simply unpaid reads as either sloppiness or pressure.
An excluded invoice does not appear at all. Use it for documents that are genuinely not part of the customer's account — a mis-posted entry being corrected, an internal adjustment.
Excluding an invoice does not make the customer owe less. It makes the statement stop claiming they do, which is a different thing and only correct when the document really is not theirs.
The dispute flag reaches further than this module
If technovision_payment_reminders is installed, flagging an invoice as disputed also stops that module chasing it.
Neither module depends on the other and neither knows the other exists. The flag is on the invoice, where it belongs, so both read it.
Ageing buckets
Fixed: Not due, 1–30, 31–60, 61–90, 91–120, 120+, and a total overdue.
They are measured from the due date, not the invoice date, and this is the one thing about the module worth understanding before you send a statement to a customer. An invoice on 60-day terms issued 45 days ago is not overdue. A statement that puts it in the 31–60 bucket is wrong, and — worse — it is obviously wrong to the person reading it, who then stops believing the rest of the document.
Branches and head offices
A branch's invoices appear on the head office's statement, following Odoo's own parent/child contact structure.
This is the default because the alternative quietly understates the figure: a head office asking what the group owes should not be told a number that leaves out three of its own sites.
Currency
The statement is produced in one currency, converting at each document's own date.
A customer trading with you in two currencies gets one statement in one currency. Multi-currency statements — one per currency, or a combined statement with both — are not implemented, and the single-currency figure is honest about what it is rather than mixing units.
Language
The PDF is bilingual by construction: English and Arabic in one template, not two.
Two templates drift, and the one that drifts is always the one the customer reads. One template means a change to the layout changes both halves or neither.
Groups
| Group | Can |
|---|---|
| Statements User | Generate, flag disputes, print |
| Statements Manager | The above, plus exclusions and configuration |
The user group implies account.group_account_readonly rather than using sudo(), so multi-company record rules still apply. Somebody who cannot see another company's invoices cannot see them on a statement either — which would otherwise be a neat way around the rules.