Invoices
| Invoice # | Items | Due Date | Amount (Inc GST) | Status | Payment Date | |
|---|---|---|---|---|---|---|
| #BB-2026-0179 | 3 | 12 Jan 2026 | $5,940.00 | Paid | 26 Jan 2026 | |
| #BB-2026-0181 | 2 | 29 Jan 2026 | $3,245.00 | Paid | 11 Feb 2026 | |
| #BB-2026-0184 | 4 | 02 Mar 2026 | $12,969.00 | Paid | 02 Mar 2026 | |
| #BB-2026-0188 | 3 | 04 Mar 2026 | $7,788.00 | Paid | 19 Mar 2026 | |
| #BB-2026-0193 | 2 | 22 Mar 2026 | $4,620.00 | Overdue | – | |
| #BB-2026-0197 | 5 | 09 Apr 2026 | $9,130.00 | Overdue | – | |
| #BB-2026-0201 | 2 | 24 Apr 2026 | $2,915.00 | Outstanding | – | |
| Balance Due (Inc GST): | $16,665.00 | |||||
Every invoice here is stored as either Paid or
Outstanding, because those are the two values a person sets. Two rows
nonetheless read Overdue, and that word is not written against either record.
It is produced by isOverdue(), which returns false for anything already paid and
otherwise compares due_date to now, at the moment the page renders.
This view was rendered on 10 April. BB-2026-0193 and BB-2026-0197 are past their due dates by then, so they show as overdue; BB-2026-0201 is not due until 24 April, so it still reads as the stored Outstanding. Load the same page on the 25th and that third row changes without a single write happening in between. Nothing can go stale and nothing has to be backfilled.
The trade is that overdue cannot be queried in the database as a stored value, which is the right side of that trade for a figure whose truth changes with the calendar. The stored status stays a statement by the operator about what they intend to chase, which is also why recording a part payment does not move an invoice into a partial state on its own.
Brontiq Books is a real, shipped product. This screen is drawn from it, and every client, contact, email, invoice number, date and figure on it is invented. Invoice BB-2026-0197 carries the same $9,130.00 here as on the invoice editor, and these three totals are the same ones the statement screen reconciles to.