Most invoice screens are archives: a list of numbers, a status word, a date. You open five of them to find the one that needs you. The Biloh invoice list is built for the opposite job — deciding, in one pass, what needs chasing today and what can wait.
Three things make that possible on the row itself: the business is named the way you know it, the ageing is stated in words rather than a date you have to subtract from, and drafts declare their own age.
What is each row telling me?
A row carries four facts, in the order you actually use them:
| On the row | What it is |
|---|---|
| Invoice number + business name | The trading name — the name you'd use on the phone |
| A muted second line | The registered legal entity, when it differs from the trading name |
| Amount, and amount still due | Total, plus the outstanding balance when part-paid |
| The ageing phrase | 14 days overdue, due in 3 days, due today, or draft · 6 days old |
The ageing phrase is the part that changes how the list reads. due 2026-09-02 asks you to do arithmetic against today's date, in your head, for every row. 14 days overdue does not. Overdue rows render the phrase in red; everything else stays quiet.
Drafts get their own phrase because a draft has no meaningful due date — it has an age. A draft that has been sitting for six days is the row most likely to be costing you money, and on a date-sorted archive it is invisible.
What does the summary strip tell me?
Above the filters, a single line states the position:
9 drafts · 4 awaiting payment · $2,140.00 outstanding · 1 overdue
Underneath it, in smaller type: Across the 100 most recent invoices.
That second line is deliberate. The strip counts exactly the rows the feed returned, and it says so. A summary that implied it covered your whole ledger would be a number you could act on and be wrong about, so the scope travels with the figure. outstanding counts issued invoices only — a draft is not money owed yet.
How do I narrow the feed?
Five filters, applied instantly with no page reload:
- All — everything
- Drafts — not yet sent
- Awaiting payment — sent, partially paid, overdue or disputed
- Overdue — past its due date with money still owing
- Paid — settled
Filters compose with the search box, so Overdue plus a typed name gives you one client's late invoices. Search matches the invoice number, the trading name and the legal name — you can find a business by either name, whichever one you happened to remember.
Can I take a payment without leaving the list?
Yes. Any invoice that is open and still owing carries a Record payment… action on the row. It opens a panel over the list, records against that invoice, and returns you to the feed with the row updated — no navigation, no losing your filter.
Payments recorded this way go through the same governed path as everywhere else, so the audit trail and the outstanding balance stay in one place. See how payment terms are decided for what governs the due date in the first place.
Is an invoice "overdue" the moment it passes its due date?
On every read surface, yes.
There are two notions of overdue in any billing system: the stored status on the record, and the actual position today. The stored status only changes when a scheduled sweep runs. The list, the invoice detail page and the MCP tool therefore derive the display position live, against today in your tenant's timezone — never UTC, which for an Australian operator would show yesterday as today for most of the working morning.
The practical consequence is the one that costs money: filtering for overdue returns stored-overdue invoices and sent invoices already past their due date. An operator chasing late payers cannot miss an invoice merely because a sweep has not reached it yet. The stored status field still reports exactly what is persisted — the derivation is display-only and mutates nothing.
Can my assistant read this list too?
Yes, and it gets the same fields — not a thinner version. Asking an AI assistant connected over MCP "list the unpaid invoices and tell me who each one is for and how late it is" returns the trading name, the legal name, the live overdue position and the ageing phrase on every row, resolved in one batched read.
That matters for a specific reason: before this shipped, the invoice tool returned a client id and no name at all, so an assistant working your receivables was less informed than you were. The exact field list is in the invoice list field reference.
What if I'd rather see legal names first?
Change a setting, not the product. Two tenant-level tunables govern the naming on operator surfaces:
directory.entity_display_name_preference—trading_first(the default) orlegal_firstdirectory.show_legal_name_secondary— whether the second line appears at all
Both are editable in Settings and by your assistant over MCP, on every plan. Neither changes what prints on a tax invoice. The reasoning is in trading name versus legal entity.