Skip to content

How invoicing fits together

Four separate things decide what your customers receive. They are easy to confuse, and confusing them is usually why something looks wrong.

ThisDecides
Invoice templateWhat an invoice looks like — logo, which details appear, which columns
GroupingHow many invoices a customer gets for the same period
StatementWhether an invoice also shows the customer’s overall balance
Payment termsThe due date printed on the invoice

They do not affect each other. Changing the template does not change how many invoices are produced. Changing payment terms does not change the aging columns. Keeping those separate in your head saves a lot of time.

A template is a layout. You can have more than one, and you can point a particular customer at their own — useful when one customer insists on seeing their reference numbers, or postcodes, or waiting times, and nobody else needs them.

A template has a header area, an information area, the table of job lines, a summary and a footer. You choose which fields go in each. Fields are grouped by where they come from: your company’s details, the customer’s details, the invoice’s own details, the job details, the totals, and statement figures.

See Create an invoice template for one customer.

By default a customer gets one invoice covering everything in the period. Grouping splits that up. There are four ways:

ModeWhat you get
One invoice per jobEvery job becomes its own invoice
Group by referenceOne invoice per distinct reference; jobs with no reference each get their own
Split at an amountA new invoice starts whenever the running total would pass a limit you set
Separate one referenceTwo invoices — everything matching a reference you nominate, and everything else

Grouping only ever splits jobs that are finished and not voided, and it does nothing at all if there is only one job.

See Choose how a customer’s invoices are grouped.

A statement answers a different question from an invoice. An invoice says “here is what this work cost”. A statement says “here is where your account stands overall” — what was brought forward, what is current, what is 30, 60 and 90+ days old, and the total outstanding.

You can have that summary printed onto the invoice itself by turning on one setting in the template.

See Show a statement on invoices.

Payment terms, and why they don’t move the aging columns

Section titled “Payment terms, and why they don’t move the aging columns”

This one catches people out often enough to be worth stating plainly.

Payment terms are a per-customer setting: a number of days. They decide the due date on that customer’s invoices. Change a customer from 7 days to 15 and their next invoice is due a week later.

The aging columns on a statement are fixed. They are always Current, 30 days, 60 days and 90+ days. They group what is owed by how long it has been outstanding, and they do not shift because you gave someone longer to pay.

So if you change a customer’s terms and expect the statement’s columns to change, nothing will happen — and nothing is broken. They are answering different questions. Terms are a promise about the future; the aging columns are a description of the past.

See Change a customer’s payment terms.

Internal: how this page was verified draft
Checked by
kenneth on 2026-07-31
How
source-check, schema-check
Where
none · logged in as not-applicable
Against
  • InvoiceTemplate + InvoiceTemplateBlock/BlockField/DetailColumn; per-customer assignment via TucClient.InvoiceTemplateId, tenant default tblSetting.InvoiceTemplateId
  • accounts Core/Application/Services/InvoiceService.cs ApplySplittingRulesAsync — the four grouping strategies
  • PaymentTerm (Name, Days) referenced by TucClient.PaymentTermId; surfaced on invoices as the payment_terms field
  • tblStatement Age0-Age3 mapped to Current/30/60/90+ in accounts InvoiceBuilderPage/constants.ts
Likely to change
medium — Invoice grouping is new and not yet released to customers, so this page describes something not everyone can use yet.
Re-check by
2026-10-31
Open questions
  • Whether an invoice run offers a per-run choice of grouping, or only uses the rule saved against each customer. The engine reads a saved per-customer rule; no per-run override was found.