Progress billing · Quebec
Construction payment application tracker: from requested amount to payment
After sending a customer a package that requests payment for completed work, use this tracker to follow the response, corrections, invoice, and cash received.
Key takeaways
A payment application is the package a contractor sends to a customer to request payment for work completed during a period. It can include a form, a breakdown of the work, and supporting documents. After submission, the customer or designated reviewer may accept the full amount, accept part of it, ask for a correction, or refuse it.
The tracker starts at that point. It preserves four separate amounts:
- the requested amount shown in the submitted package;
- the accepted amount stated in the decision for that package revision;
- the invoiced amount later recorded in the accounting system when the project procedure requires an invoice;
- the paid amount whose receipt is confirmed by the accounting system.
The difference between the requested and accepted amounts is a variance. Explain it without changing the submitted package. Give the next action an owner and a follow-up date.
A useful construction payment application tracker always answers five questions:
- What amount did we request?
- What amount did the customer accept, certify, or recognize?
- Why is there a variance?
- What happens next, and who owns it?
- What amount does the accounting system confirm as paid?
The model below starts after submission and defines everything needed to follow the package through payment. The construction progress-billing guide goes deeper into package preparation, but it is not required to use this tracker.
What happens after a payment application is submitted?
Consider a simple example. A contractor requests $10,000 for the month’s work. The customer accepts $8,000 and asks for a delivery ticket for the remaining $2,000. The submitted package still says $10,000. The decision says $8,000. The $2,000 variance stays visible with one action: send the delivery ticket.
At this point, there is still no proof that an $8,000 invoice was created or that cash was received. Those events happen later under the project’s contract and accounting procedure. The tracker connects four steps without treating them as the same thing: application submitted → decision received → invoice created, if required → payment received.
If the contractor corrects the package and submits it again, that creates a new internal file revision. Each revision keeps its own amount, date, and submission proof. A stable identifier groups revisions of the same application without erasing the history. This filing method does not decide whether the contract or an applicable rule treats the correction as a new request.
What belongs in a construction payment application tracker?
Create one row for each submitted payment-application revision. Give every application a stable identifier and each revision a distinct number. The active revision is the one used for current totals and next actions; every other revision stays visible in history. Record each variance on its own row in a Variances tab linked to the main tracker by the revision identifier.
Never replace a historical value with the next value. If you submit a correction, add a row, preserve the earlier revision and its submission proof, and mark it as superseded. Count only the active revision in requested-amount totals so that the same application is not counted twice.
Keep decisions, invoices, and payments linked to superseded revisions in the history. When a decision or the reconciliation to accounting records also applies to the active revision, add an explicit link and carry forward only the applicable result. Keep the original association unchanged. The requested amount shows what your team submitted. The accepted amount records the known decision. The paid amount comes from the accounting system.
One application can receive several decisions. A decision may cover one work line, supplement an earlier decision, or replace it. Record each decision separately with its date, source, affected lines and amounts, then state explicitly whether it replaces another decision. If the main tracker keeps one row per revision, store those events in a separate Decisions tab linked by the revision identifier. Carry only the result that still applies into the main row’s accepted-amount field.
Your customer may use another term, such as certified amount, recommended amount, recognized amount, or undisputed amount. Preserve the project term in the supporting document. Then use one stable internal field to compare projects.
Swipe horizontally to view all columns.
| Group | Essential fields | Purpose |
|---|---|---|
| Reference | Project, customer, contract, application, period, revision | Find the right record without opening every PDF |
| Submission | Date, channel, recipient, requested amount, submission proof | Preserve exact proof of what was sent |
| Decisions | Revision status, accepted amount, exact project term, date, source, respondent, affected lines, superseded decision when applicable | Separate the request from each decision and calculate the result that still applies |
| Variance | Amount, type, reason, affected line, required evidence, action status, detail link | Reconcile the decision without confusing the financial difference with an unresolved action |
| Action | Owner, next action, confirmed follow-up date | Prevent an application from losing its owner |
| Accounting | Accounting status, invoice number, before-tax invoiced amount, taxes, invoice total, paid amount, last payment date | Connect operational work to invoices and payments recorded in accounting |
Headers to copy into three tabs
Paste each line below into the first row of a separate spreadsheet tab. The labels are separated by tabs so that each label lands in its own column. The main tab keeps one row per submitted revision. The other tabs keep one row per decision and one row per variance.
Main tab
Application ID Revision ID Active revision Project Customer Contract Period Submitted on Channel Recipient Requested amount Review state Current accepted amount Project decision term Owner Next action Follow-up date Accounting state Invoice number Invoiced before tax Taxes Invoice total Paid amount Last payment date Submission proof
Decisions tab
Decision ID Revision ID Date Source Respondent Project decision term Affected lines Accepted amount for affected lines Superseded decision ID Notes
Variances tab
Variance ID Revision ID Amount Type Reason Affected line Required evidence Action status Owner Follow-up date Detail link
How do requested, accepted, and paid amounts reconcile?
Consider a fictional electrical specialty contractor. Taxes are excluded, so every requested, accepted, invoiced, and paid amount uses the same simplified basis. The example demonstrates tracking, not contractual, accounting, or tax treatment.
Payment application 08 requests $82,400. The customer confirms $74,900 for the cycle. It asks for another supporting document for $4,000 of materials and continues to review a $3,500 change.
Swipe horizontally to view all columns.
| Item | Amount | Status | Next action |
|---|---|---|---|
| Accepted work | $74,900 | Accepted | Track the project-specific invoice handoff |
| Materials | $4,000 | Not accepted this cycle | Attach the requested delivery ticket |
| Change | $3,500 | Under review | Link the calculation and expected decision |
| Requested amount | $82,400 | Submitted | Preserve the submitted revision |
The reconciliation is exact:
$74,900 accepted + $4,000 of unaccepted materials + $3,500 under review = $82,400 requested.
The fictional project then calls for a $74,900 invoice on that tax-excluded basis. The accounting system confirms two receipts, $50,000 and $24,900. The unpaid accepted amount is now zero. The $7,500 requested-to-accepted variance remains open until its two causes are resolved.
Swipe horizontally to view all columns.
| Control | Calculation | Result |
|---|---|---|
| Current difference explained | $82,400 − $74,900 | $7,500 |
| Paid amount | $50,000 + $24,900 | $74,900 |
| Accepted and unpaid | $74,900 − $74,900 | $0 |
| Composition of the current difference | $4,000 + $3,500 | $7,500 |
A holdback is the part of an amount that remains temporarily unpaid when the contract or an applicable rule requires it. A deduction is another amount removed under a separate decision, contract term, or calculation. A correction instead changes an amount that was wrong. Keep the three concepts separate.
Do not always calculate the accepted amount as the requested amount minus a refusal. Holdback, deduction, correction, or document-specific definitions can change the reconciliation. Take the value from the received decision and preserve each adjustment in a separate field.
Which states should you track after submission?
Use two axes. The first describes payment-application review. The second describes the invoice and payment. This separation prevents “accepted” from becoming “paid.”
Axis 1: payment-application review
- Submitted: the final revision and submission proof are preserved.
- Under review: the customer is reviewing the package or needs clarification.
- Partially accepted: an accepted amount and a detailed variance are known.
- Accepted: the project decision covers the request under the applicable vocabulary.
- Refused: the received decision accepts none of the requested amount.
- Superseded: a newer revision was submitted. The superseded revision stays in history but is excluded from active totals.
When a correction is required, record it in Next action. An application can be under review or partially accepted while also requiring a correction.
Axis 2: invoice and payment
- Accounting handoff to confirm: the decision is known, but the internal process is not complete.
- Accounting treatment complete: the accounting system contains the required invoice or other entry, with the applicable reference and amount.
- Partially paid: a receipt exists, but an accounting balance remains.
- Paid: the accounting system confirms settlement of the invoiced amount being tracked.
The contract, customer procedure, and accounting policy decide when an invoice is created. The tracker records the handoff. It does not decide the treatment.
How do you classify a variance without losing the next action?
A category supports reporting. A reason explains the specific case. Keep both.
Swipe horizontally to view all columns.
| Variance type | Evidence to link | Typical owner | Useful action |
|---|---|---|---|
| Missing document | Customer list, email, portal message | Billing | Provide the requested document and record receipt |
| Progress adjusted | Review comment, quantity record, photo | Project manager | Compare the line, quantity, and field evidence |
| Change under review | Instruction, submitted price, decision | Project manager | Keep it separate from approved contract value |
| Holdback | Contract or received calculation | Billing | Record the basis and value without inventing a release date |
| Deduction | Deduction notice, contract term, or received calculation | Controller | Record the amount, reason, and source separately |
| Amount correction | Customer decision, revised calculation, internal note | Controller | Reconcile the corrected amount and preserve the explanation |
| Administrative error | Returned form, portal requirement | Billing | Correct the revision without overwriting the submitted version |
Avoid “other” without an explanation. If one reason appears three times, create a stable category and add the related control to package preparation.
What weekly routine keeps the portfolio under control?
Reserve 15 minutes with the person who follows customer invoices and payments and with the relevant project managers. Sort by next action, not only by age.
1. Start with rows that have no decision
Verify receipt, the reviewer, and the next contact point. If the follow-up date has no confirmed source, mark it as an action to confirm.
2. Reconcile every partial acceptance
The accepted amount plus variances marked as explaining the current difference must equal the requested amount. This reconciliation is independent from whether each variance action is open or resolved. An unexplained difference becomes a task immediately.
3. Check the accounting handoff
When the project requires an invoice, compare the accepted amount and invoiced amount before tax. Then compare the invoice total with receipts including tax. Keep tax and other adjustments separate. The accounting system remains authoritative for invoices and payments.
4. Confirm receipts
Import or verify the paid amount in the accounting system. Do not treat a promise-to-pay email as proof of receipt.
5. Finish with four totals
- requested amount with no decision;
- variance actions that remain unresolved;
- accepted amount whose accounting handoff is still unconfirmed;
- invoiced amount unpaid according to accounting.
These totals are not a financial report. They show where operational work is blocked.
The operational total of unresolved actions is separate from the reconciliation total. A resolved variance can still explain the current requested-to-accepted difference until a new decision changes that difference.
What does the Quebec public-contract framework illustrate?
Quebec provides one precise example of separate monetary states. This example applies only to public construction contracts and related public subcontracts covered by that framework.
For those contracts, section 5 requires the request to state a total claimed amount and an itemized breakdown. Section 11 says a written refusal identifies the monetary portion refused, affected items, and reasons. Section 16 separately addresses certain deductions passed through the subcontracting chain. Review the official regulation in English and the official explanatory guide.
Section 8 adds an important correction rule. When the contractor and debtor agree to amend a submitted request, the amended document remains the same request and keeps the original submission date. The tracker can preserve a new internal file revision, but it must also preserve the identity and legal date required by the framework.
The structure supports one recordkeeping rule: do not reduce the full history to one balance. Preserve the requested amount, recognized portion, refused portion, deductions, holdbacks, and reasons in separate fields.
It is not a universal template. A private project, an uncovered contract, or another jurisdiction follows its own documents and rules. This tracker does not calculate a deadline or recommend a remedy. Get qualified advice for a legal or contractual question.
Free payment-application tracking checklist
At submission
- ☐ The final revision, requested amount, and submission proof are linked.
- ☐ The application has an owner and a next action.
- ☐ The follow-up date comes from a confirmed source or is clearly marked for confirmation.
At the decision
- ☐ The requested amount remains unchanged.
- ☐ The accepted amount comes from an identifiable decision.
- ☐ Every variance has an amount, type, reason, and supporting document.
- ☐ Holdback, deduction, and refusal are not merged.
At the accounting handoff
- ☐ The contract process and accounting policy were followed.
- ☐ The accepted amount and invoiced amount are reconciled before tax.
- ☐ The invoice total is reconciled with receipts including tax.
- ☐ Tax and other adjustments stay separate.
- ☐ The paid amount comes from the accounting system.
- ☐ The application closes only after variances and actions are resolved.
At the portfolio review
- ☐ No active row lacks an owner.
- ☐ No partial acceptance lacks a reconciliation.
- ☐ The four operational totals were reviewed.
- ☐ Repeated problems produced a new upstream control.
Which workbook can help prepare the application before tracking begins?
The downloadable English Aplon v1.2 workbook prepares and controls the source payment application before it enters the tracker described in this article. It does not track customer decisions, variances, invoices, payments, or next actions. Use the table model and checklist on this page for that post-submission follow-up.
Go to the form to receive the workbookA four-step workflow
- Set up the project, active period, goods and services tax (GST), Quebec sales tax (QST), and holdback, which is the portion kept temporarily when the project rules require it.
- Import the schedule of values, the table that divides the contract value into work lines, then choose a quantity, percentage, or amount method.
- Record the total reached since the project began for each work line, then link useful supporting documents.
- Produce the payment application with previous work, work added during the period, the total since project start, holdback, GST, QST, and the total payable.
Contract amendments that preserve history
An approved contract amendment, which some project documents call a change order, enters the contract value on its approval date. It does not silently rewrite an earlier period. The dashboard shows the revised contract value, cumulative progress, and remaining balance.
Visible controls
Input cells are distinct from calculations. The workbook flags duplicates, decreasing cumulative values, overruns, missing documents, and inconsistent holdback releases. An application reaches READY only when the required information is present.
Frequently asked questions
Should you replace the requested amount with the accepted amount?
No. The requested amount proves what was submitted. The accepted amount records a later decision. Preserve both and explain the variance.
How do you calculate the variance?
Start with requested amount − accepted amount, then reconcile the result to refusals, holdbacks, deductions, corrections, and items still under review. Use project evidence. Do not infer a decision from the calculation alone.
Does an accepted payment application become an invoice?
Not automatically. The contract, customer process, accounting policy, and applicable advice determine the handoff. The tracker should record the link without inventing the rule.
Which follow-up date should you use?
Use a date confirmed by the contract, customer, or internal procedure. This model does not calculate a legal or contractual deadline.
When should you close a row?
Close it when the accepted amount, variances, accounting handoff, and payment all reconcile and no action remains open. A paid application can remain open when a variance must move into another cycle.
Official sources and scope
Contract and public rules change. This article was checked against these official sources:
- Quebec: Regulation respecting prompt payments and prompt settlement of disputes for construction work
- Quebec: official explanatory guide
This content is for information only. It is not legal, tax, or accounting advice. The contract, applicable rules, and advice specific to your circumstances take priority.
Sources verified on September 1, 2026. To report a correction, contact Aplon.
A workbook for your next payment application
Track progress, holdback, GST, and QST in one Excel file.
Keep the workbook. Automate the cycle when you are ready.
Use the workbook now. When the manual handoffs become the bottleneck, Aplon connects field progress, review, approval, submission proof, and collection follow-up.
A person still approves every external commitment.See how Aplon controls the cycleMathis is building Aplon with trade contractors to make every payment application clearer, verifiable, and easier to track.