What Got Shipped Today - 19/8/26 - The Invoice Register knows when cash moved, served claims keep their proof

19 August 2026 Today's work all points at the same thing: the platform should be able to tell you what actually happened, not what someone intended to happen. Cash that moved. A claim that was served. A notice that is waiting on you. Features The Invoice Register now knows when the cash has actually moved User story As a contract administrator, I had to open Xero to find out whether a bill was actually paid, because the Invoice Register told me the same thing forever, so I can now read the real payment state on the register itself. Before The Invoice Register stopped at "Payment Authorised" and stayed there. It did not matter that the bill had landed in Xero, or that it had been paid weeks ago, the row never moved. The Claims and Schedules tab knew the claim was paid. The register did not. One record sat at "Payment Authorised" for 36 days after its bill was settled. After The register reads the real Xero state. Paid records show Paid, and they carry Xero's actual payment date, not the date the sync happened. There is a new Paid filter so you can pull up everything that has been settled, and everything that has not, without reading down a list. Impact The question "is that one paid, or do I need to check Xero?" stops being a question. When a CA is moving quickly through the register, the status column is now the answer rather than the start of an investigation. It also means the two places that talk about the same claim finally agree with each other. Known limitations Payment state arrives with the Xero sync, so a bill paid in Xero a minute ago updates on the next sync rather than instantly. Serving a payment claim now creates the record that proves you served it User story As a commercial manager, I served claims and ended up with nothing on file showing what went out or when, so I can now serve a claim and have the served document and the serve date recorded against it automatically. Before Serving was a status change and nothing more. The claim moved from Draft to Submitted, and that was the entire trace. No document was generated, nothing was attached, no recipient was recorded. Claims could sit fully certified with zero documents and zero attachments against them. If you needed to show what you served and when, there was nothing to show. After Serving a payment claim generates the claim document at its published template version, attaches it to the claim, and writes the serve into the claim's record. Impact Under the Construction Contracts Act 2002 in New Zealand and the security of payment regimes across Australia, serving is the legally operative event, and the served document plus the serve date are your evidence. Until now the platform recorded the intent and lost the proof. Now the proof is created as a by-product of doing the work properly, which is the only way it reliably gets created at all. Known limitations Emailing the claim as part of the same serve step is a follow-up. For now, serving captures and attaches the document, and sending remains its own action. Improvements Unread notices now surface in the sidebar User story As a project engineer, I only found out a notice was waiting on me if I happened to open the Notices page, so I can now see the count from anywhere in the project. Before The Notices page carried an unread indicator, but the sidebar said nothing. Invoice Inbox had shown a count on its menu item for a long time. Correspondence had no equivalent, so a notice sitting unread was invisible unless you went looking for it. After Notice carries a count of the items awaiting you, matching the "Awaiting me" tab so the badge and the page tell the same story. Correspondence carries the rolled-up total when the section is collapsed. The badge clears as items get read or actioned, and caps at 99+. Impact Notices are deadline-driven under ANZ contract frameworks. An unread notice is not a tidiness problem, it is a commercial exposure with a clock on it. Putting the count where people already look means the clock gets noticed while there is still time to act on it. Fixes Bulk and nightly claim pushes no longer strand rows at "Payment Authorised" User story As a contract administrator, claims I pushed in a batch looked untouched on the register even though they had gone through, so I can now trust the register whether I pushed one claim or fifty. Before Pushing a claim on its own advanced the register row correctly. Pushing claims through the bulk sync or the nightly run did not. Those rows stayed at "Payment Authorised" even though the bill had reached Xero, so the register under-reported reality specifically for the people processing the most volume. After Bulk and nightly pushes advance the register row the same way a single push always did. Impact The register no longer punishes you for working in batches. This was the quieter half of the payment-status problem, and it hit hardest on the busiest projects, where nobody has time to reconcile a register against Xero row by row. Spotted something that should work differently, or something that should exist and does not? The feedback portal is built into the platform, and it is read. A good portion of what shipped today started as somebody telling us the screen was lying to them.