What Got Shipped Today - 12/8/26

Published 12 August 2026 A commercial day, and a big one. The invoice to payment schedule workflow collapsed from ten clicks to two with approval authority resolved from the delegation of authority matrix, the Budget Register stopped carrying forecast for cost codes that left the forecast months ago, and the front door got noticeably faster. Features Invoice to payment schedule is now one workflow, and nobody picks the approver User Story As a contract administrator processing a subcontractor claim, I walked ten clicks from upload to payment and chose my own approver on the way, so I can now push to the payment schedule and let the delegation of authority matrix decide who signs it off. Before. Approval sat on the invoice record. A claim came in, you assigned a record type in the confirm modal, assigned it again in the coding tiles, hit "Complete Review & Assign Approver", picked an approver from a modal, and clicked Authorise Payment yourself. Ten clicks from upload to money authorised, with the approver chosen by the person coding the record. The status chip sat on "Needs Review" the entire way, an entity mismatch flag could be ignored for the full session, and the banner could claim a subcontract match that did not exist because a purchase order's confidence score had been inherited onto it. After. The Invoice Register does coding and matching only. One action, Push to Payment Schedule, creates the subcontractor claim and the draft payment schedule together, with attachments carried across, and it behaves identically whether KAI matched the document or you matched it by hand. The button stays disabled until amount, invoice number, invoice date, record type and contract match are all present, and the tooltip names whatever is missing. Record type is asked once. A flagged entity mismatch blocks progression until it is resolved. The status ladder now tracks the record honestly: Needs Review, Coded, Pushed to Schedule, In Approval, Authorised. Record type is now asked once, and KAI pre-selects it from the match it already made. Confirming here is the only type decision in the workflow, and it unlocks Push to Payment Schedule in place of the old Complete Review and Assign Approver step. Approval then happens on the payment schedule, where it belongs. You certify line by line, adjust down, add clause reasons, and hit Submit for Approval. The engine resolves the chain from the delegation of authority matrix against the scheduled amount, not the claimed amount, and shows you the resolved route read only. There is no approver picker anywhere in the workflow. Authorise Payment now lives only in the final approver's own queue. If the scheduled amount changes after submission the chain re-resolves and any approval given against the superseded figure is cancelled. Impact. The payment schedule is the statutory instrument under SOPA in Australia and the CCA in New Zealand. The scheduled amount is what the builder is liable to pay, so authority to commit that money should resolve against it rather than against whatever the subcontractor asked for. Until today the platform resolved authority against the wrong number, or more often against whoever the coder happened to select. Two clicks, and the audit trail now records who approved, at what authority, and against what amount. Notes. The new flow switches on for a workspace once a Payment Schedule approval workflow is configured for it, so it arrives as you set it up rather than all at once. Records that were mid-pipeline under the old buttons carry a migration path rather than being stranded, including a banner naming the originally assigned approver for supplier invoices caught between the two flows. Improvements Cost Forecasting line items gets the full control bar User Story As a commercial manager reviewing a forecast, the first thing I need to know is which cost codes are bought and which are not, so I can now sort and filter for it instead of reading the committed column down forty rows by eye. Before. Cost Forecasting line items had a search box and a Show Categories checkbox. The Budget Register, which is the same set of cost codes viewed differently, had a full control bar. The two screens behaved like different products, so nothing you learned on one transferred to the other. After. Every column header sorts. Filter chips cover procurement state (not committed, partially committed, fully committed) and budget state (over budget, under budget, high remaining percentage, low remaining percentage, high forecast to complete risk), and they compose with search and Show Categories. A column and filter panel handles show, hide, reorder and reset, and remembers your setup per project. A Hide Zero toggle suppresses rows with no budget, no actuals and no forecast. A density selector switches between comfortable and compact. Default sort stays cost code ascending, matching the Budget Register.Impact. Bought cost codes and unbought cost codes need completely different treatment in a forecast review, and one should carry almost no forecast while the other carries all of it. Sorting by committed surfaces the mismatches in a single click. A noticeably faster front door User Story As anyone who logs in, the wait to see my workspaces and the wait to create an opportunity were both long enough to notice, so I can now get moving without watching a spinner. Database connections are now pooled across the workspace, users and opportunity endpoints, and lifecycle lookups are batched rather than run one at a time. Workspace listing on login is materially quicker, the users endpoint is 4-5x faster, the last long wait in the opportunity creation flow is gone, and the Commercial Dashboard's duplicate backend calls have been removed. Impact. Nothing about what the platform does changed. How long you wait to do it did. Fixes The Budget Register no longer carries a forecast for a cost code that left the forecast User Story As a commercial manager, my Budget Register and my approved forecast disagreed by 60,000 on the same project on the same day, with nothing on screen explaining why, so I can now trust them to match. Before. When a cost code's budget was zeroed, it dropped out of the forecast entirely. The forecast to complete and forecast final cost values an earlier approval had written into the Budget Register were left behind. One project carried a cost code with no budget, no commitments and no actuals, still reporting a 60,000 forecast and a 60,000 overrun, with no way for a user to clear it because the code was no longer editable in the forecast. Everything downstream inherited the inflated figure. After. On forecast approval, the write back is reconciled against the full cost code set rather than only the codes present in the forecast. Any cost code with previously written values that is no longer in the forecast has those values cleared to zero, and the same applies where a budget has been zeroed or a code has been removed from the register. Impact. The Budget Register is the control basis the WIP report and the Commercial Dashboard read for forecast final cost. An orphaned value there inflates the forecast on every one of those surfaces, silently. The margin bridge names the cost code instead of printing a database key User Story As a commercial manager taking the Financial Summary into a project review, one bar on the margin bridge was labelled with a raw database identifier, so I can now read a chart that says what it means. Before. Snapshots stored the cost code's internal key rather than its name, so labelling a bridge bar meant looking that key up against the live cost code list. Where the cost code had since been zeroed or removed, the lookup returned nothing and the raw identifier was printed instead, on the chart axis, the bar label, the drill in modal title and its subtitle. The same design would quietly relabel history whenever anyone renamed a cost code. After. The cost code and its name are stored in the snapshot at approval time, and bridge labels render from the snapshot rather than from a live lookup, so the record is self contained and immutable in the way a snapshot is supposed to be. Where a historical name genuinely cannot be resolved you get a readable fallback, never a raw key. Existing snapshots are backfilled where the cost code still resolves, so historical bridges read correctly too. Impact. The Financial Summary is the page that feeds the board pack. It should never surface a database identifier, and a snapshot that depends on mutable data to stay readable is not really a snapshot. A notice issued without a sender organisation no longer vanishes from the issuer's own list User Story As a contract administrator issuing an RFI, the notice went out, the recipient received it, and it disappeared from my own register with no error at all, so I can now be certain that what I send stays visible to me. Before. If a notice was issued without a sender organisation recorded against it, it silently dropped out of the issuer's view. The email still went out, the recipient still saw it normally, and inbound replies still updated the status behind the scenes. Where the issuer's own company was not also on the recipient list, which is the normal case for an RFI, the notice was absent from the register entirely and opening it directly returned nothing. Where the company happened to be a recipient, the notice opened but the issuer only actions (Close, Issue CI, Issue Site Instruction) were missing. Two things put empty values into that field: RFIs raised from DS Site, where the ingest treated the sender organisation as optional, and a front end window between roughly mid June and end of July where the composer stopped supplying it. After. The composer now attaches the sender organisation to any draft that is missing one before issuing, and the back end refuses to issue a notice without it and says so clearly. Both halves are needed: the first rescues the drafts already sitting in workspaces, the second closes the hole for every route that can issue a notice. Impact. A notice you cannot see is worse than one that fails to send, because you have no reason to look for it. Around one in eight live notices and roughly a quarter of unissued drafts were affected, and every one of those drafts would have minted a fresh broken notice the moment somebody issued it. Known limitations. Existing records that already have no sender organisation are being corrected separately. This fix closes the leak. Subcontractor compliance tabs stop loading forever when there is nothing to show User Story As anyone opening a subcontractor's compliance record, a company with no documents showed "Loading insurance documents..." indefinitely, so I can now see plainly that there is nothing there. Before. All four Compliance sub tabs (Insurance Docs, Business Docs, Safety Docs and Workers) could not tell "never fetched" apart from "fetched and genuinely empty". A company with no documents therefore re-requested them in a tight loop, roughly every five seconds, forever, while the tab sat on a loading message that would never resolve. After. The tabs distinguish the two states properly. An empty result renders as empty, an error renders as an error with a manual Try Again, and neither loops. Impact. A subcontractor with no insurance documents on file is exactly the case a compliance check exists to catch, and it was the one case the screen could not report. HSEQ quality defects and inspection test plans show the data that is actually there User Story As a commercial project manager, my HSEQ dashboard reported zero quality defects while the register underneath it listed them, and my inspection test plans register did not show plans I knew existed, so I can now rely on both. Before. The Quality Defects tile on the HSEQ dashboard reported no defects found while the Defects and Punch List register held real entries, and the Inspection Test Plans register did not display test plan data that existed in the project. After. Both surfaces now read and render the underlying records correctly, and the dashboard count agrees with the register beneath it. Impact. A safety and quality dashboard that under reports is worse than no dashboard, because it is the surface people check instead of looking. Something here you would change, or something missing you need? Tell us through the feedback portal in the Deep Space web app. Every entry above started as someone telling us it was wrong.