User guide

How to use Customer Statements & Ageing, screen by screen.

Generating a statement

Invoicing → Customers → Statements → New. Pick the customer, the period, and generate.

What you get:

• an opening balance — what they owed at the start of the period;
• every movement in it: invoices, credit notes, payments, in date order;
• a closing balance;
• an ageing summary in six buckets, plus a total overdue.

The arithmetic reconciles

Opening + charges − credits = closing. Always.

There is a test that fails if that ever stops being true, which sounds like a low bar until you have received a statement whose total does not match its own lines. A document that cannot add up is a document nobody trusts, and the customer will ask about the arithmetic rather than about paying.

Ageing is from the due date

This is the thing to understand before you send one to a customer.

An invoice on 60-day terms issued 45 days ago is not due. It goes in the Not Due column, not in 31–60.

Ageing from the invoice date is the common mistake, and it is a bad one: the customer knows their own terms, so a statement claiming they are overdue when they are not is visibly wrong, and it costs the whole document its credibility.

Disputed invoices

Flag an invoice as Disputed and it appears on the statement with a badge, outside the ageing buckets.

That is deliberate. If the customer has raised a query, a statement that lists the invoice as simply overdue reads as either not listening or as pressure. It also means the "total overdue" figure is one you can actually stand behind in a conversation.

Branches

A branch's invoices appear on the head office's statement, following Odoo's parent/child contacts.

If you need the branch's own position, generate a statement for the branch contact.

Printing

Print produces the PDF — English and Arabic in one document, in one template.

Send it however you send things. This module does not email anybody by itself, which brings us to:

It does not chase

There is no dunning engine here. No reminder emails, no escalation levels, no cron that mails your customers.

Version 1.x had one, and it duplicated technovision_payment_reminders — a customer with both installed received two letters about one debt. Two modules competing to chase the same invoice is not a feature, so the engine was removed in 2.0.0.

The split now:

Neither depends on the other. When both are installed, the dispute flag here stops the other one chasing that invoice.

Your old reminder history

If you upgraded from 1.x, the historical reminder data is still in the database and nothing reads it. That is on purpose — it is your record of who was chased and when, and an upgrade should not delete it.

The server log names the three tables with their row counts if you would rather drop them by hand.