An invoice can be correct while its due date is misunderstood. Sales says “thirty days”, finance assumes “month-end” and the customer expects a different date. For an Odoo project in Belgium or France, clarifying this language helps prevent disputed reminders and misleading cash forecasts. Here is our approach to preparing payment terms in Odoo Enterprise.
One invoice, several due dates
Odoo’s documentation distinguishes an instalment plan, which spreads payment of one invoice, from an invoicing policy that produces multiple invoices. It also describes splitting receivables by due date. This distinction helps teams clarify the requirement before choosing a configuration.
Approve an explicit calculation rule
We recommend starting with the customer agreements actually in use. For each payment term, record the reference date, payment share, date calculation and customer-facing wording. A short label is not enough: ask the agreement owner to write two or three examples with specific dates.
Separate a customer’s usual terms from an exception negotiated for one order. Make finance responsible for approving due dates and sales responsible for confirming the commercial agreement. For Belgian and French teams, review French and English labels together to ensure they describe the same calculation.
A practical scenario for checking balances
Fictional Underside acceptance scenario: an invoice totalling €1,200 is dated 28 September 2026. The agreement requires 25% on that date and the balance thirty days later. The expected result is €300 on 28 September and €900 on 28 October. These dates illustrate a requirement to test, not recommended contractual terms.
- Check amounts and dates on the invoice and in the data used for payment reminders.
- Repeat the scenario with invoice dates at month-end and in February to expose confusion between calendar days and month-end calculations.
- Record a partial payment of €200, check its allocation and confirm a total outstanding balance of €1,000.
- Test an amount that requires rounding and verify that the instalments still add up to the invoice total.
- Check an exception on one order without accidentally changing other customers’ terms.
Keep the expected result, actual result and corrective decision for every test. Review the document sent to the customer as well as internal screens. A successful test should let another person reproduce the same balance without a verbal explanation.
Migrate open invoices without resetting their age
During an Odoo migration, we recommend reconciling opening balances with a statement fixed at the cutover date. Preserve references, original due dates and allocated payments in the control records. Do not mechanically replace an old due date with one calculated from the customer’s new payment terms.
Compare totals by customer, then compare the ageing breakdown. Two imports can have the same total yet produce very different reminders if dates have changed. Identify disputed invoices and payments in progress so they are not processed twice.
Underside’s analysis: check interfaces too
If an external application creates invoices, decide which system supplies the rule and which calculates due dates. Test an unknown payment term, a missing date and repeated delivery of the same invoice. Assign responsibility for correcting errors and recording the correction. These controls are Underside project recommendations, not a promise of automatic functionality.
Start with a few representative customers, then track manual due-date corrections and disputed reminders. Continue with our guides to Odoo Invoicing and data migration.
Official source and scope
Reference: Odoo 19 documentation on payment terms and instalment plans. Check the screens in your installation. This article covers configuration and acceptance testing; the examples and recommendations are Underside’s analysis.
Prepare your invoicing checks with Underside, starting with a customer agreement and an open invoice.