# How payment terms are decided on an invoice

> An invoice states the term the client agreed to — their own configured terms, falling back to the business default. The single exception is an invoice that allows less time than agreed, which states the shorter real period. An invoice never advertises more time than was agreed, and the due date is a separate fact the label never overrides.

URL: https://biloh.com.au/docs/explanation/how-payment-terms-are-decided
Category: Explanation | Audience: operator | Updated: 2026-08-20

## Two different facts

Every invoice carries two things people routinely conflate:

- **The due date** — the calendar date the client must pay by. A single date.
- **The payment term** — the credit period the client agreed to. A policy, like "7 days" or "30 days".

They are related, but they are not the same fact, and one cannot honestly be recovered from the other.

## Where does the term come from?

It cascades:

1. **The client's own configured terms**, set on the client record — either an explicit number of days or a named type such as due on receipt, 7 days, 14 days or 30 days.
2. **The business default**, when the client has none of their own.

That is the whole cascade. There is no per-invoice payment-terms field, because a term is an agreement with a client rather than a property of one document.

## Why isn't the due date used to derive it?

It is tempting to subtract: due date minus issue date equals the term. This is wrong, and on some invoices it is badly wrong.

The due date is the **stored result** of the cascade above, calculated when the invoice was created. Deriving the term back out of it is circular — you recover the number you already had, dressed up as a fresh fact.

It breaks completely on a **back-dated invoice**. When you bill work performed weeks ago, the issue date is set to the service period while the due date runs from today. The gap between them is an artefact of when you got around to invoicing. Subtracting produces a number that describes nothing about the client's agreement, and it is always larger than the truth.

The failure mode is specific and expensive: a client on 7-day terms is told, in writing, that they have forty or seventy days. That is not cosmetic. It is a document that undermines your own collection position, in your own words, in the client's inbox — and it is worst on exactly the invoices most likely to be chased.

## The rule

**State the agreed term. Never advertise more time than was agreed.**

With one exception, which runs in the same direction:

**If this invoice allows *less* time than agreed, state the shorter real period.** An operator who deliberately set an earlier due date meant it, and a shorter statement never overstates. So an invoice due in three days for a client on 14-day terms says "3 days".

## What happens to the due date?

Nothing. The date the client must pay by is untouched by any of this — it is set at creation and it governs. Only the sentence describing it changes.

That separation is what lets you do the sensible thing with a catch-up invoice: give the client a generous due date for old work **and** state their real terms, without the document contradicting itself.

## How do I tell where a number came from?

The resolved term carries its own provenance:

| Source | Meaning |
|---|---|
| `agreed_client` | The client's own configured terms |
| `agreed_tenant` | The business default, because the client has none |
| `invoice_shorter` | This invoice allows less time than agreed, so the shorter real period is stated |
| `none` | No term configured anywhere |

If an invoice says something you did not expect, this tells you which rung of the cascade produced it before you go hunting for a fault.

## What should I change if the terms look wrong?

Almost always the **client record**, not the invoice. Set the client's terms once and every future invoice for them inherits it. Set the business default and every client without their own terms inherits that.

## Related

- [Backfilling work you already did](/docs/concepts/backfilling-work-you-already-did)
- [Verify an email actually reached your client](/docs/how-to/verify-an-email-reached-your-client)
- [Migrate a client book from another system](/docs/how-to/migrate-a-client-book-from-another-system)