Construction Retention Tracking: Which Withheld Amount Is Ready for Release?

A construction payment app should distinguish money previously withheld from the amount now requested for release and the money actually paid. Marking a job complete should not quietly clear every retained balance. Before commissioning a retention register, decide which agreement, work item and reviewed condition supports each proposed release.

This is a software-planning guide, not a statement of construction law or a recommended contract term. Retention arrangements, release conditions, notices, accounting and payment obligations need review by the appropriate commercial, legal and accounting specialists. A product guide cannot establish what your particular agreement permits.

Start with the withheld balance, not another progress percentage

Imagine a fictional fit-out contractor with amounts retained against several work items. One item is ready for a reviewed partial release while another remains unresolved. A single project-wide “finished” badge cannot explain how much should be requested against either item.

Ask the app to identify the underlying agreement, the retained amount associated with each relevant item and the records from which that balance came. Keep money retained on earlier applications distinguishable from any new retention arising in the current period. Your accounting team should determine the actual calculation and treatment.

This differs from milestone billing. A milestone concerns an agreed stage becoming billable. Retention release concerns a previously withheld amount becoming part of a particular release request. The two can be related without being the same event or using the same approval.

Use the product example within its actual scope

The official Procore retention-release guide describes a subcontractor-invoice workflow. It directs users to the invoice's Schedule of Values and the relevant line items, where they enter an amount in the Total Retainage Released column.

Its examples distinguish releasing the entire withheld amount from releasing only part of it. The guide describes the Total Retainage value reducing by the entered release amount. It also says that saving preserves the invoice's current status and displays a banner with the total being released on that invoice.

Those details support a useful commissioning distinction: entering and saving a release amount is not evidence that an external payment has reached the subcontractor. They do not prove that your own app already has the same calculation, permissions or integrations. Nor does the guide supply a release rule that applies to every contract or country.

Record the basis for a proposed release

For your custom workflow, ask the responsible reviewer to define what evidence and authority are required. A completion record, an inspection result or another document may be relevant under the reviewed arrangement. Do not make an uploaded attachment automatically prove that every condition has been met.

Show what is requested, which retained balance it draws on and what remains unresolved. Record who reviewed the proposal and the exact scope of the decision. An expected review date can help the team follow up, but it should not be presented as a confirmed entitlement or payment date without the appropriate basis.

If the proposal changes after approval, show which version was approved. A partial release decision should not turn into authority for the whole balance simply because someone edits the amount on the same record.

Keep requested, included and paid states apart

Agree how an approved release becomes part of the downstream payment application or invoice. Preserve a reference to that document and make the remaining retained balance explainable. If a document is cancelled or corrected, let the accounting process determine the adjustment instead of deleting the earlier release history.

Specify how concurrent drafts are handled. Two people preparing requests should not each consume the same remaining amount without a visible conflict. Also decide how a request under review affects the available balance; a draft reservation and a posted release need different meanings.

Payment confirmation belongs to the responsible financial system. A release approved internally, included in an invoice and actually paid are separate facts. The dashboard should make their relationship visible rather than label all three “released” without explanation.

Accept a partial-release cycle, not just a screen

For an individual business-app discussion, bring invented agreements and retained-balance examples rather than confidential project documents. Demonstrate a partial release, a rejected request, a changed approved proposal and competing drafts against the same balance.

Then follow one approved release into its downstream document and a separate payment record. The acceptance question is whether the team can explain the remaining retention without treating completion, invoice preparation or a saved entry as proof of payment. These are requirements to test during development, not a claim that a live construction or payment workflow was exercised for this article.