Payment Application Statuses in BuildQS: Draft, Submitted, Approved and Paid

Every payment application in BuildQS sits in one of four statuses, draft, submitted, approved, or paid, plus a small set of system variants for deposits, retention releases, and opening balances. The status controls what you can edit, what triggers retention and discount calculations, and what other applications you can change at the same time.

This guide walks through each status, explains how an application moves from one to the next, and covers two rules that catch most users out the first time: the newer-application lock, and how to revert an application back to draft once it has moved on.

The status ladder

draft → submitted → approved → paid

Most applications move forward through the ladder in that order. Approved and paid are a toggle pair, you can move an application back to approved from paid, for example if a payment is reversed.

Each step is more than a label. Moving out of draft locks the figures in: BuildQS captures the discounted value of every task completion on the application so the value shown to the client matches the value invoiced, even if you later change a discount on the project. Moving into paid records the date and flags the application as overdue if it passed its due date.

Draft

A draft application is your working version. While an application is in draft you can:

• Set or change completion percentages for each task
• Add or update Materials on Site
• Adjust the application date and payment dates
• Toggle the notified sum on or off
• Add or remove deposit deductions
• Edit application notes

Draft is the only status where BuildQS will recompute values live as you edit the project. If you tweak a phase or task discount while an application is in draft, the gross value shown in the summary updates immediately. None of those edits are visible to the client yet, drafts do not generate invoices or notices.

Before an application can leave draft for the first time, BuildQS requires the Master Valuation Schedule (MVS) to be approved at project level. The MVS is the agreed contract scope, phases, tasks, quantities, rates, that everything else is measured against. If you try to submit an application before MVS approval, the request is rejected with a clear error.

Submitted

When you move an application from draft to submitted, BuildQS:

1. Captures the discounted value of every task completion on this application and freezes it at the current rate. From this point on, the figures on the application are locked in even if the project's phase or task discounts are changed later.
2. Records the change in the activity log so you have an auditable trail of when the application was issued.
3. Triggers the per-application notice deadlines: payment due date, payment notice deadline, final date for payment, and pay-less notice deadline. These are all derived from the application date and the project's payment terms.

A submitted application is ready to go out the door. In the UK, submission is the moment the application starts to count under the Housing Grants, Construction and Regeneration Act 1996, the certifier has a fixed window to issue a payment notice, after which your applied-for sum may become the notified sum by default.

You can still edit completions and other fields on a submitted application as long as no later application has moved past draft. We will come to the lock rule shortly.

Approved

An approved application has been certified, usually by a quantity surveyor, contract administrator, or client representative, and the figures are agreed.

Two things change at this point:

• Only users with owner, admin, or project manager role on the project can modify the application. Viewers and standard users see it as read-only.
• The application is now part of the cumulative billed total used for the next application's "less previous applications" line.

You can move an approved application to paid when payment lands, or back to submitted if certification is disputed and needs to be reissued.

Paid

Marking an application paid is the final step in the standard lifecycle. BuildQS does several things automatically when you switch to paid:

• Records the paid date as today, unless you supply a specific date
• Compares the paid date to the payment due date and flags the application as paid late if it missed the deadline, with the exact number of days overdue captured for reporting
• Triggers any related Xero sync if the project is linked to Xero

If you later need to reverse the status, moving back from paid to approved clears the paid date and the overdue flag. This is the approved-paid toggle, both directions are allowed without losing data.

Reverting to draft

Sometimes you need to go back to draft after submission, maybe the certifier asked for a percentage adjustment, or you spotted a task that should have been billed at 60% instead of 50%. BuildQS supports reverting an application's status from anywhere on the ladder back to draft, with two caveats:

1. The expected payment date is cleared. Once an application is back in draft, the date stops counting toward overdue forecasting until it is resubmitted.
2. Reverting is blocked if a later application has already moved out of draft. This protects the cumulative totals: if App #3 was approved when App #2 was already at 80% complete, reverting App #2 would silently rewrite App #3's "less previous applications" line.

The Revert option appears in the status select on the application detail page and on the kanban card. If reverting is blocked, BuildQS shows the reason, for example "Locked, AFP #3 is approved. Change its status first.", naming the lowest-numbered application that is blocking the revert.

When later applications lock earlier ones

This is the rule that surprises most new users. As soon as a later application moves out of draft, BuildQS treats every earlier application as locked for edits.

The reason is simple: a later application's "less previous applications" line is the sum of all earlier net values. If you could keep editing App #1 after App #2 has been submitted, you would be silently changing the cumulative figure on App #2, retro-charging or retro-crediting the client without re-issuing the notice.

Locking applies to:

• Changing completion percentages on any task
• Editing Materials on Site
• Changing the application date, payment dates, notes, or notified sum
• Reverting the application to draft

Locking does not apply to:

• Updating just the expected payment date (cash flow forecast field)
• Moving the application forward through the status ladder, submitted → approved → paid, or the approved-paid toggle

That last point is important. If you submitted App #1 last month and have since approved App #2, you can still approve and pay App #1 in the normal way, those forward status changes do not affect the cumulative figure on App #2, so they are allowed.

Worked example: lock, unlock, re-lock

A subcontractor on a £180,000 office refurbishment has two applications open.

Step 1, App #1 is submitted. The contractor has applied for 50% of phase 1 work. App #2 has not been created yet.

• App #1 is fully editable. Nothing is locked.

Step 2, App #2 is created and bumped to 80% on phase 1, then submitted.

• App #2 is the latest application and is editable.
• App #1 is now locked for content edits because a later application (App #2) is no longer in draft.
• App #1 can still be moved forward (submitted → approved → paid) if certification comes in for it.

Step 3, The certifier asks for App #1's percentage to be adjusted from 50% to 55%.

• The contractor cannot edit App #1 while App #2 is submitted.
• The contractor reverts App #2 to draft. App #2 is now editable; App #1 also unlocks.
• The contractor updates App #1 to 55%, re-saves, and approves it.
• App #2 is re-submitted. App #1 re-locks for content edits but remains approved.

The reverting flow is the safety valve that lets you correct historical valuations without having to delete and re-create applications. BuildQS records every status change in the activity log, so the audit trail is preserved.

Special application types

Standard applications follow the lifecycle above. BuildQS also supports three variants that behave slightly differently.

Deposit applications

A deposit application is an advance payment, typically a percentage of the contract value invoiced up front and offset against future applications. Deposits skip the newer-application lock and the MVS gate, because they are independent of the work-completion totals. Deposit deductions on later applications reduce the net due so the contractor does not get paid twice for the same work.

Retention release applications

A retention release application releases retention that has been held on the project, usually at defined milestones, for example 50% at practical completion and 50% at the end of the defects liability period. BuildQS auto-creates retention release drafts via a daily scheduler so you do not have to remember the dates. These applications carry no new completion percentages; they simply move held retention back to the contractor as a separate payment.

Opening balance applications

The opening balance (application #0) represents work that was already billed before the project was set up in BuildQS, for example when migrating from a spreadsheet mid-project. It locks in the previously-certified cumulative total so that subsequent applications start their "less previous applications" calculation from the right baseline.

Variations, credits, and refunds

Variations cover anything that was not in the original Master Valuation Schedule, extra work agreed during the project, scope reductions, dayworks, credit notes, and refunds. BuildQS treats variations as a separate task type that sits alongside the regular contract tasks, with its own approval gate and date.

Variations have to be approved before they appear anywhere

Every variation needs to be marked approved before it shows up on any payment application. While a variation is unapproved, you can still set it up on the project's master valuation page (give it a description, quantity, rate, variation date, and a reference number), but it will not appear on any draft, submitted, approved, or paid application until you approve it. This is the safety valve that stops half-agreed scope changes from leaking into a live valuation.

Approved variations appear on drafts immediately

Once you approve a variation, it shows up straight away on every draft application that is currently open on the project. The standard workflow is:

1. Add the variation on the project's master valuation page.
2. Approve it (and confirm the variation date).
3. Open the next draft application, the variation is there as a new task row, ready for you to set a completion percentage.

Drafts are the right place to bill new variations because draft figures are still being computed live, and BuildQS will roll the variation into the gross value, the retention basis, and any project or phase discount as you set the completion.

Already-submitted applications stay frozen

An approved variation does not retroactively appear on applications that have already been submitted, approved, or paid. Specifically, an approved variation only shows on a non-draft application if its variation date falls on or before the application's date, or if that application already has a billing entry recorded for it. This preserves the audit trail: an application that has already been issued to the client does not silently sprout new line items when you approve a variation on the project later.

If you need to bill an approved variation against a sealed application, the same revert-to-draft flow described above applies, revert the later application, edit, and re-submit.

Negative variations are how BuildQS handles credits and refunds

There is no separate "credit note" or "refund" type in BuildQS. To refund a client, reduce an already-billed sum, or issue a credit, add a variation with a negative quantity or rate. When approved, the negative variation flows through the next draft application as a negative line, pulling the gross value down and reducing the net amount due.

A few things follow from this:

• Negative variations interact with retention by default. If a negative variation reduces the gross value of an application, it also reduces the retention basis for that application, so retention is calculated on the net work rather than on a gross that does not match what is being billed.
• Negative variations can have their own discount. A negative variation that represents an agreed credit can carry its own discount percentage. By default the discount is not applied to negative values (this is an opt-in flag on each variation), so a credit note keeps its full agreed value unless you explicitly say it should be discounted too.
• They are still variations. The same approval gate and date rules apply, a negative variation has to be approved before it appears on any application, and it only flows into already-issued applications if the date lines up.

For the maths behind project, phase, task, and variation discounts (including how the discounted value gets snapshotted at submission), see Payment Application Discounts in Construction Explained.

Frequently asked questions

Can I edit a submitted application?

Yes, as long as no later non-deposit application has moved out of draft. You can edit completion percentages, materials, dates, and notes on a submitted application until a later application is submitted, approved, or paid.

Why is my application stuck, I cannot submit it?

The most common reason is that the Master Valuation Schedule has not been approved. BuildQS requires the project's scope to be locked in before any application can leave draft. Go to the project's master valuation page and click Approve, that unlocks submission for every current and future application on the project.

Can I revert an approved or paid application back to draft?

Yes, as long as no later application has moved past draft. The revert flow is available in the status select on the application detail page. Reverting clears the paid date and any overdue flag if the application was previously paid.

What happens to my completion values when I submit an application?

BuildQS captures the discounted value of each task completion at the moment of submission, and freezes those values on the application. If you later change a phase or task discount, the historical applications keep the values they were issued at, but new drafts will use the new rate.

Do later applications recalculate when I revert an earlier one?

Yes, once you revert an earlier application and edit it, all later applications recompute their "less previous applications" line from the updated cumulative total. This is why BuildQS blocks edits to an earlier application while a later one is sealed. Reverting the later application first protects the audit trail and keeps the cumulative figures consistent across the project.

BuildQS replaces Excel valuation spreadsheets with structured payment application workflows for UK subcontractors. The status lifecycle described here is enforced server-side so that every team member, every audit log entry, and every Xero export agrees on what the application looked like at each point in time.