COMMERCIAL
Security register
Every retention and bank guarantee a counterparty holds against you, when it must come back, and the chase that gets it back. Release dates are computed from the trigger in the contract, not remembered — and when one falls due the register drafts the chase for your review.
Overview
Retention is your money sitting in somebody else’s account. It was withheld from progress claims you already earned, and it comes back on a trigger — practical completion, the end of the defects liability period, a date in the contract. Nobody upstream has a reminder set for that trigger. If you don’t either, the money quietly stays where it is. Unclaimed retention is the classic silent write-off: not disputed, not refused, just never asked for.
The security register exists to make that trigger visible. Record what is held, record how it is released, and the register computes the release date, moves the item to Due when it arrives, and offers you a chase. You reach it from the Registers band in the project sidebar under Security, at /projects/{id}/security. Every user on the project has it.
Across the top sits the hero strip: Money held against you with a count of items, Coming back with the number of open release windows, Past release with the number of items that should already have been returned, and Next release — the next date anything is due, or Not scheduledif nothing on the register has a computable trigger. That last value is the honest one to read first: “Not scheduled” usually means the release terms were never captured, not that nothing is owed.
The Security register for a project — the hero strip across the top showing Money held against you with an item count, Coming back, Past release and Next release; beneath it the lens strip (All, Held, Coming back, Past release, Closed) and the register table with columns for Security, Kind, Counterparty, Amount, Release, Release trigger, Release due, State and Chase, mixing cash retention and bank guarantee rows with Held and Due state badges.
What the register records
Two kinds of security sit on the register, and they behave differently when they come back.
| Kind | What it is | What coming back looks like |
|---|---|---|
| Cash retention | Money withheld from your progress claims and held by the counterparty. On Australian jobs this is typically a percentage of each claim up to a cap, with part released at practical completion and the balance at the end of the defects liability period. | A payment back to you — so it belongs on your cashflow forecast, and it is the kind that most often goes unasked-for. |
| Bank guarantee | An instrument lodged with the counterparty as security instead of cash. It costs you facility capacity for as long as it is out there, even though no money moved. | The original instrument returned so it can be discharged — not a payment. Until it comes back it keeps consuming your facility. |
Each row on the register carries: Security (what it is), Kind, Counterparty (who holds it), Amount, Release (the release terms), Release trigger, Release due (the computed date), State, and Chase. The drawer groups the same fields as What’s held, When it comes back and More details.
The lens strip above the table cuts the register down: All, Held, Coming back, Past release (items that passed their release date and have not come back) and Closed. Two of those are the ones you live in — Coming back for the month ahead, Past release for the money that is late.
Different money, different register
Retention withheld from a claim is not the claim. The claims register tracks what you claimed, certified and were paid; the security register tracks the slice that was deliberately held back and has its own, much later, return date. A claim can be fully paid while retention against it stays outstanding for years.How the release date is computed
Nobody should be doing this arithmetic in their head at month end. You record the trigger and the offset, and the register computes Release due (computed) from them. Three triggers are available.
| Release trigger | What it anchors to | Typical use |
|---|---|---|
| Practical completion | The project’s practical completion date. | The first tranche of cash retention, commonly released at or shortly after PC. |
| DLP end | The end of the defects liability period. | The balance of retention, and bank guarantees held through the defects period. |
| Date | An explicit date you enter. | Security with a hard expiry or a negotiated return date that is not tied to a project milestone. |
On top of the trigger you set days after trigger and a day type, because “14 days” in a contract rarely means fourteen squares on a calendar.
| Day type | How the offset is counted |
|---|---|
| Calendar days | Every day counts, including weekends and holidays. |
| Business days | Weekends and public holidays are skipped. |
| Working days | Counted as working days, per the day convention the contract uses. |
Copy the day type off the clause, not from habit
The gap between calendar and business days on a 90-day release is weeks, and the whole point of the register is that the date is right without anyone re-reading the contract. Take the trigger, the offset and the day type straight from the release clause when you record the item — that is the one moment the accuracy is decided.The lifecycle
Every item sits in exactly one state, and the state is what the hero strip and the lenses count.
| State | What it means |
|---|---|
| Held | The counterparty holds it and the release date is still in the future. Nothing is required of you yet. |
| Due | The computed release date has arrived. This is the moment retention normally starts being forgotten. |
| Demanded | You have asked for it back — the chase is under way and the ask is on the record. |
| Released | The money came back, or the guarantee was returned and discharged. The end state. |
| Expired | The security lapsed — closed without being returned. Recorded rather than deleted, so the history stays honest. |
Held and Due are open; Released and Expired are closed and fall into the Closed lens. Demanded is the state that proves somebody asked — which is exactly the fact that is missing when retention goes unrecovered.
The release chase
When items reach or pass their release date the register raises a needs you band above the table — “N items are past or near their release date” — with a single action: Start release chase. That is the register doing the part people don’t: noticing.
Nothing is sent automatically
Release requests are drafted for your review through the chase — nothing is sent automatically. The chase composes the ask and puts it in front of you; issuing it to the counterparty is always your action. The register states this on the drafts themselves: drafts are prepared for your review, nothing is sent.A chase runs as an escalation ladder rather than a single email. Each chase carries a status — Not chased before it starts, Chasing once it is running — a step level showing how far up the ladder it has climbed, and a next step date for when the following beat falls due. As it climbs it accumulates drafts, each one a prepared release request you can read and copy out.
An empty draft list is not a failure
Start a chase and you will often see “No draft yet — the first one is minted on the next escalation beat”. Drafting happens on the ladder’s schedule, not the instant you press the button. The chase is live; the first draft is simply pending its beat.The release chase on a cash retention item — the amber needs-you band reading that several items are past or near their release date with the Start release chase action, and the chase panel below showing status Chasing, the current step level, the next step date, and a list of prepared release-request drafts each with a copy action and the notice that drafts are prepared for review and nothing is sent.
Getting security onto the register
An empty register is the normal starting point: “No security on the register” — “Record the retentions and bank guarantees held against you — the register computes each release date and chases it when it falls due.” There are two ways to fill it, and on a project with an executed contract the first is faster.
Suggest from contract
Suggest from contractreads the project’s contract and proposes the security it finds — the retention percentage and cap, the release tranches, any guarantee requirement — each proposal carrying its clause reference, shown as Clause {ref} so you can check the source before you accept it. On the empty state the same action reads Find them in the contract.
Run Suggest from contract
The register reads the executed contract for the project and proposes the security it finds.
Check each proposal against its clause
Every suggestion shows the clause reference it came from. Read the clause for the trigger, the offset and the day type before accepting — those three fields decide every date the register computes afterwards.
Accept what is real
Accepted items land on the register as normal rows with computed release dates. Anything the contract does not actually impose you simply do not accept.
Add security manually
Add security opens the drawer for anything the contract does not cover — a guarantee lodged under a side deed, retention held by a client on a variation-only arrangement, security carried over from a predecessor contract.
What’s held
The kind (cash retention or bank guarantee), the counterparty holding it, and the amount.
When it comes back
The release trigger (practical completion, DLP end or an explicit date), the days after that trigger, and the day type. Release due is computed from these and shown in the drawer as you set them.
More details
The supporting context — references and notes that make the row readable to somebody who was not in the negotiation.
Record it when it is withheld, not when you want it back
The cheapest moment to capture a retention is the claim it was withheld from, while the percentage and the release clause are in front of you. Capturing it two years later, when somebody wonders whether anything is still outstanding, is the expensive version — and it is the version where the money is already lost.Counterparty exposure
Beneath the register sits the counterparty exposure panel: first-party facts about how each counterparty actually pays, drawn from your own record with them. It answers the concentration question the table alone cannot — who is holding most of my money, and what is their track record of giving it back?
It is a panel, not a second register. Read it when you are deciding how hard to chase, or how much security you are comfortable leaving with one party across several jobs.
Ask about it in chat
The assistant can read the security register directly through a read-only, permission-filtered lookup, so questions like “how much retention is still held on Northgate and when does it come back?” are answerable in chat. The answer comes from the register rows, not re-derived from documents — so what you hear in chat and what you see on the page are the same numbers.
The lookup respects your permissions: it only ever returns security on projects you can already see, and it cannot change anything. Recording, accepting suggestions and starting a chase all stay on the register.