What Got Shipped Today - 31/8/26 - Provisional sums draw down properly, retention stops reading zero, a Xero bill can finally be unlinked

31 August 2026 Features The Provisional Sum register becomes a register of drawdowns, and the allowance lives on the contract As a Contract Administrator, the PS register showed me allowances and drawdowns mixed together, and the first button in front of me consumed an allowance whole. I wanted the contract to hold the allowance and the register to hold the spend, the way variations already work. Before. Provisional sums lived in one list that was doing two jobs. Creating an allowance, attaching it to the head contract and drawing money against it all happened in the same drawer, so a CA looking at the register could not tell at a glance what had been allowed and what had been spent. Worse, a brand-new PS still presented the old per-line Approve control, and pressing it drew the allowance down in its entirety. There was no partial draw, and nothing warned you that was about to happen. After. The two jobs now sit on the two surfaces that should own them. The Head Contract Provisional Sums tab owns the allowance lifecycle: create, attach against the contract reserve, see Allowance, Drawn and Remaining per PS, and close out. Contract data lives on the contract. Every allowance now carries its own running position. Allowance is what the contract set aside, Drawn is what has been committed against it across all approved drawdowns, and Remaining is what is left to spend. Here the allowance has been over-drawn, so Remaining sits at zero and the over-run is carried by a variation. The PS Register is now purely a register of drawdowns, one row per draw across the project, with number, parent PS, contract, cost and sell, and status. It reads exactly like the Head Contract Variations register reads for VOs. A New Drawdown flow asks you to pick the attached allowance first, then takes you into the pricing you already know. Every newly attached PS is now born in the drawdown ledger, so the old consume-it-whole behaviour is grandfathered to historical records only. And when a draw would take you past Remaining, you get told what happens next (a variation raised for the over-run, or an adjustment to the contract sum) instead of it happening quietly. Impact. A provisional sum is a promise to spend money you have not priced yet, and the two questions a CA is asked about it are always "how much was allowed" and "how much is left". Splitting the surfaces means both are answerable in one look, and partial drawdowns stop being a trap. The register also finally matches the mental model builders already carry from variations, which is one less thing to teach. Known limitations. Connecting drawdown approval to the DoA approval workflows is not in this release. Provisional sums show the full build-up from allowance to net contract sum, and the margin basis is now yours to set As a Commercial Manager, when a PS was drawn down the client saw an allowance and I saw a cost, and the margin sat nowhere anyone could point at. When a client assumed the allowance was the full spend available, I had nothing on screen to show them otherwise. Before. Nothing in the platform showed how a provisional sum allowance turned into a net adjustment to the contract sum. The allowance, the actual purchase cost, the builder's margin and the resulting adjustment existed as separate numbers in separate places, so the conversation about who owed what happened in a spreadsheet or a phone call. A builder could lose the margin on a drawdown and never see it happen. After. A PS record now carries a readable six-line build-up. The whole arithmetic in the order it actually happens: the allowance you started with, what the item really cost, the margin you are entitled to, any procurement costs, the margin adjustment, and the single net figure that moves the contract sum. The footer states which margin basis produced it and benchmarks your effective margin against the contractual rate. Alongside it, the margin basis is now configurable, because contracts do not agree on it. Some apply the percentage to the actual cost of the work. Others only permit it on the variance between the allowance and the final value, on the reasoning that the fixed part of the contract sum already carries profit and attendance. Both are now supported, and a margin of zero is treated as a legitimate contract position rather than an error. Set the house position once in workspace settings, and any head contract can override it. Both settings lock at that contract's first approved drawdown, so the rules cannot shift underneath drawdowns that have already been priced. Because the platform now knows your contractual rate, it can tell you when a drawdown departs from it, in either direction. Price a drawdown under your contractual rate and you are told before you save, not at the final account. This is the failure that quietly costs builders margin on provisional sums, because PS lines are entered at zero margin out of habit. It warns the other way too. The contractual rate is a ceiling as well as a floor, and a drawdown priced above it is disputable at the final account, so you get told while you can still change it. Where your head contract is set to adjust via variation, the build-up renders on the generated variation and the PS shows the roll-up across its drawdowns. Impact. Prime cost and provisional sums are one of the most common causes of misunderstanding in a building contract, and the misunderstanding is almost always the same one: the client reads the allowance as the budget. Putting the arithmetic on screen, in the order it actually happens, gives you something to show rather than something to explain. Making the basis configurable means the number is right for AS4000, ABIC and NZS3910 customers rather than right for one of them. The approved payment schedule, and anything you upload to it, now reaches the Xero bill As an Accounts payable operator, the schedule I approved and emailed to the subcontractor never made it onto the bill in Xero. Anything I uploaded to the schedule's Documents tab disappeared into the same silence. My only workaround was to re-upload the file against the claim instead. Before. Three gaps stacked on each other. The payment schedule PDF was rendered in your browser, emailed, and never written anywhere the sync could reach. Documents uploaded to a payment schedule's Documents tab were dropped by the Xero reconcile entirely, which only ever looked at the claim, so the upload succeeded, the file count went up, and the bill stayed empty. And there was no way to produce the schedule PDF into that tab in the first place. The result was a bill in Xero carrying the subcontractor's invoice and nothing else, with no indication anything was missing.After. A new Attach PDF button sits in the payment schedule drawer's Documents tab, beside Upload Documents. It generates the schedule PDF, from the same published template that Generate & Send uses, and files it into that schedule's own Documents. It works on a schedule you accepted last month, not just one you accepted a moment ago. Underneath it, the Xero reconcile now reads the payment schedule record as well as the claim. Documents already sitting on schedules are picked up on the next sync without anyone re-uploading them, and the same file linked to both the claim and the schedule is not duplicated on the bill. Impact. The bill your accounts team pays from should carry the evidence of what was certified, not just what was invoiced. Two documents on one bill, the subcontractor's invoice and the approved schedule, is what makes a payment run auditable without opening the platform. Because the reconcile backfills, bills pushed before today pick their documents up too. Known limitations. A bill holds a maximum of ten attachments, and claim documents and schedule documents now share those slots. The attachment appears on the sync run following the upload rather than the same one. A Xero bill can now be unlinked from a subcontract claim As a Commercial Manager, once a subcontract claim carried a Xero link it was stuck with it forever, even when the bill on the other end had been deleted or belonged to a different claim entirely. The record read "synced" whatever the truth was, and nothing in the platform could clear it. Before. Head contract claims got a gated way to clear a stale Xero link and re-push. Subcontract claims and payment schedules never did. Once the link was written, the push filtered that record out, nothing anywhere cleared the field, and the record reported itself as synced permanently. Two live situations needed a way out: claims wrongly linked to another claim's already-paid bill, and dozens of payment schedules holding a link to a bill that had since been deleted in Xero, unable to ever push again. After. Unlink now exists on the subcontract side, and it clears the link on both the claim and its payment schedule together, along with the attachment markers, so the next push does not believe the new bill already carries its documents. It is gated, not a free-for-all. The link can be cleared when the Xero document is voided, deleted or gone from the org, and now also when the linked bill is demonstrably carried by a different live record. Every other status still blocks, with a message that tells you why. After unlinking, the record is parked out of background pushes until a person deliberately sends it, so you cannot accidentally create a second bill. Unlink also clears the Paid status the bad link caused, which matters more than it sounds: a record reading Paid with no bill behind it cannot be pushed at all, so without this it would unlink into a dead end. Impact. Every integration eventually mis-links something. The difference between a recoverable platform and an unrecoverable one is whether an operator can undo it without a database script. Money that was genuinely owed and reading as paid becomes visible again, and schedules pinned to bills that no longer exist can move. Known limitations. Xero has no way to delete an attachment through its API, so a document uploaded onto the wrong bill still has to be removed by hand in Xero. Improvements When an approval has nobody to route to, you now find out As a submitter, I sent something for approval and it sat. There was no approver resolved on that step, nothing told me, and nothing told anyone else either. It just waited. Before. An approval step that resolved to an unassigned project-team slot could end up holding a role that matched zero users. The step waited indefinitely and notified nobody. The rescue that would have escalated it to the highest authority only ran on the first step, so any later step in a chain could fall into the same hole. A resolution warning was being recorded internally and read by nothing. Separately, when the backend call that flips a record out of Pending Approval failed, it failed silently, so the approval could read Approved while the register still showed the record pending. After. The highest-authority rescue now applies to every step in the chain, not just the first. Where no approver can be resolved, the warning is surfaced to you at submit time rather than written into a log. And when the status sync behind an approval fails, that failure is now visible on the record instead of swallowed. Impact. Approvals fail loudly or they fail invisibly, and invisible is what costs a week. This closes the gap between "the approval says it went through" and "the record still says pending". Fixes Retention Held on head contract progress claims now reads the ledger, not the latest invoice Retention Held was showing $0.00 on head contract Progress Claims to Client, captioned "still held by client", against claims certified into the hundreds of thousands. The retention was being held correctly the whole time. Retention is withheld the moment a claim is certified, but the card was reading its figure off the most recent tax invoice instead of off the retention ledger. On a contract with certified claims but no invoice raised yet, the card had nothing to read and showed $0.00, and would have kept showing $0.00 no matter how much was actually held. Nothing was under-billed, and served claim documents and Xero invoices carried retention correctly. The card now reads the same ledger the invoice figure is computed from, so the card, the invoice and the Retentions view cannot disagree. Two further problems turned up in the same investigation, both affecting every customer, both now fixed: A head contract created directly into Active never got a retention register. That register was only created when a contract moved from Draft to Active through the normal screen, so contracts that were imported, migrated or set up by hand during onboarding silently held nothing when a claim was certified. No error, no warning. The register is now created at the point of certification, and a contract that holds $0 while retention is configured writes a warning that shows up in monitoring rather than on a customer call. Every claim document generated by the platform printed retention as $0. An internal naming mismatch meant the document generator could never find the figure, so it printed zero and the net payable total never deducted it. This affected every head contract on the platform. If retention rules were entered on a contract after claims had already been certified, nothing goes back and recalculates those claims. Worth a look at any contract where retention was configured late. Subcontract claims are sequenced by claim date, so cumulative retention adds up Claims were listed in claim-number order. Claim numbers are handed out when a claim is created, not for the period it covers, so a claim raised late for an earlier month gets a higher number and lands after the month that follows it. That is why a list could read 26, 26, 26, 25, with September ahead of August. That was not a display preference. Retention Held to date is a running total added up down that list, so the wrong order in produced the wrong total out. Claims now sort by claim date everywhere they are listed or totalled: the Claims & Schedules tab, the Progress Claims register, and the Retention module's linked-claims preview. Same date falls back to created date, then claim number, so the order is always stable, and a claim with no date sorts last. The CSV export now matches what is on screen, where it used to come out in a different order entirely, and the table order now matches how the claim PDF picks the previous claim, so screen and document can no longer disagree. Known limitations. This corrects the ordering and the running total. It does not recalculate retention already recorded against each individual claim. Retention is worked out when a payment schedule is accepted, and the cap is consumed by whichever claim was accepted first rather than the earliest-dated one, so on a subcontract where claims were accepted out of date order the total held is right but the row that shows as reaching the cap may still be off by one. The Xero push no longer adopts a bill that belongs to another claim When a subcontractor re-sent the same invoice number for a later claim, the push did not create a new bill. It adopted the bill the earlier claim was already linked to, and if that bill was paid, the new claim and its payment schedule immediately read Paid. Silently: no error, no warning, nothing in the register. The push matched on invoice number, contact and amount, and where an invoice had been split into two equal instalments all three legitimately agreed. Three correct matches were read as proof of identity when none of them was. The push now asks the question that actually settles it, whether the Xero bill is already carried by a different live record, and blocks when it is, naming the record that holds it. Linking to a bill your accounts team entered in Xero first still works exactly as before; only a bill another claim already owns is refused. Where it refuses, the message tells you both totals so you can see why it matched, and gives you a way forward rather than a dead end. Subcontract claim and payment schedule now show the same schedule of values A subcontract claim's SOV items and the linked payment schedule's schedule of values could show different amounts against the same line, so the claim read one figure and the schedule read another for the same work. The two now read from the same place. Spotted something, or want something? Tell us through the feedback portal in the platform. Every item above started as somebody saying so.