Change a customer's payment terms
Changing how long a customer has to pay.
Before you start
Section titled “Before you start”Check the term you want already exists. Payment terms are a list your company maintains — each entry has a name and a number of days — and you choose from that list rather than typing a number onto the customer. If the term you need is not there, it has to be added to the list first.
- Go to and open the customer.
- Find the payment terms field on the customer’s record — .
- Choose the term you want.
- Save.
New invoices for that customer will be dated due according to the new term.
What this actually changes
Section titled “What this actually changes”The due date on the customer’s invoices. That is the whole of it.
Payment terms are also carried across to your accounting system if you have one connected, so the invoice arrives there with matching terms rather than needing correcting at the other end.
What this does not change
Section titled “What this does not change”The aging columns on a statement. This is the one that causes confusion, so it is worth being direct about.
A statement’s columns are fixed: Current, 30 days, 60 days, 90+ days. They are not calculated from the customer’s payment terms. Move a customer from 7 days to 15 and the statement will still be headed 30/60/90 — for that customer, and for every other one.
They are answering different questions:
| Payment terms | How long this customer has to pay. A promise about the future. |
| Aging columns | How long money has been outstanding. A description of the past. |
A customer on 15-day terms whose invoice is 40 days old appears in the 30-day column, the same as anyone else 40 days overdue. That is correct — the column is measuring elapsed time, not lateness relative to their terms.
Good to know
Section titled “Good to know”Terms are per customer, they drive the due date, and they have no effect on the aging columns. The terms you can choose from are the ones in your payment-terms list — see Before you start.
If something goes wrong
Section titled “If something goes wrong”The term you need is not in the list. It has to be added to the payment-terms list first. Ask your system administrator.
Existing invoices did not change. Whether a change re-dates invoices that already exist has not been confirmed. Treat the change as applying to new invoices, and check an existing one if it matters.
Related
Section titled “Related”Internal: how this page was verified draft
- Checked by
- kenneth on 2026-07-31
- How
- schema-check, source-check
- Where
- none · logged in as not-applicable
- Against
- schema: PaymentTerm (Id, Name, Days) — a lookup list; TucClient.PaymentTermId references it, so terms are chosen per customer
- schema: PaymentTerm also carries QboId, XeroDay and XeroType (migration 20260615144057_PaymentTermFields.sql), i.e. terms map to an accounting system where one is connected
- accounts ClientApp/src/pages/InvoiceBuilderPage/constants.ts — invoices expose 'due_date' and 'payment_terms' as separate fields
- same file — statement figures map to tblStatement.Age0-Age3 as Current/30/60/90+, with no reference to PaymentTerm
- Likely to change
- medium — The customer record is exposed to the planned menu reorganisation, and which tab holds this field has not been confirmed on screen.
- Re-check by
- 2026-10-31
- Config-dependent
- 2 item(s) called out on this page
- Screenshots
- 1 still to capture
- Open questions
- Which tab of the customer record holds the payment terms field. Account Details is the expectation but has not been confirmed.
- Whether changing terms re-dates invoices that already exist, or only applies to new ones.
- Whether a term can be created from the customer record, or only chosen from an existing list.