For a month-end work-in-progress (WIP) review, start by agreeing on the reporting cutoff, identifying the source records and listing unresolved differences. For a commercial general contractor, the useful handoff between the project manager and accounting is a review packet that shows where each number came from, what changed and who needs to resolve an exception.
Use this checklist to prepare that packet. Confirm with your designated accounting reviewer who determines the accounting treatment and who approves the final WIP schedule. This checklist organizes the project evidence for that review; it does not calculate recognized revenue or prescribe accounting treatment.
1. Agree on the cutoff and responsibilities.
Before collecting reports, record the reporting date, projects included and the person accountable for the final review. Name an owner for the project forecast, job-cost ledger, contract changes and billing records. One person may cover several roles, but every unresolved item needs an accountable owner.
Use a short cover sheet:
- Project identifier and name.
- Reporting cutoff and export dates.
- Project manager and accounting reviewer.
- Source systems and report versions.
- Date the packet is due and date the review is scheduled.
- Items carried forward from the prior review.
A report generated today may contain transactions through a different cutoff. Record both dates so the team can tell a changed reporting period from a changed project position.
2. Assemble the records behind the review.
Ask the accounting reviewer which records are required for your contracts and reporting method. Use the following as a starting list to confirm with that reviewer, rather than a list of records required for every contract:
| Record group | Evidence to collect | Question to resolve |
|---|---|---|
| Contract and changes | Current contract record, approved modifications and a separate unresolved-change list | Which changes are approved, pending or disputed? |
| Recorded job costs | Job-cost ledger or agreed cost report with cutoff and project identifiers | Can the reported cost be traced to the underlying records? |
| Commitments | Current subcontracts, purchase orders and approved changes | Does remaining committed scope use the same cutoff as recorded cost? |
| Remaining work | Current cost-to-complete assumptions and scope still to buy or perform | What changed in the estimate, and who reviewed it? |
| Billing and collections | Billing records, receivables and retainage detail required by the reviewer | Are billing, collection and cost records clearly distinguished? |
| Prior review | Approved prior packet and open-exception register | Which differences were resolved, and which remain open? |
Keep a reference to the original source rather than copying a number without its context. If access is restricted, identify who can supply the record and what the reviewer needs to verify. Do not put sensitive contract or customer information into an unrestricted shared worksheet.
3. Reconcile the sources before explaining the result.
Check the project identifier, scope and cutoff first. A total from one project phase should not be silently compared with a whole-project total. Similarly, a forecast that includes a late change should identify that difference when the ledger export stops before the change was recorded.
Trace material differences to their source. Look for duplicated records, missing records, reclassifications and changes in reporting scope. Record the discrepancy before deciding its treatment. A plausible explanation from a project meeting is useful context, but it is not the same as a completed correction or an approved accounting adjustment.
For the operational forecast, label actual cost, remaining commitments, remaining uncommitted work and change exposure separately. Ask the responsible reviewer to check for overlap between components. This operational check does not determine which amounts belong in the accounting WIP schedule. Our construction cost forecasting guide explains that operational reconciliation with an illustrative example.
4. Review exceptions with the project manager.
Use the meeting to resolve specific questions rather than read every total aloud. Start with changes since the prior review and items that lack supporting records.
- What changed in the remaining-work estimate, and what evidence supports it?
- Has a pending change become approved, been revised or been withdrawn?
- Does a timing difference explain the mismatch between two reports?
- Is a cost assigned to the correct project, phase and cost code?
- Is an unresolved item already represented elsewhere in the forecast?
- Which question needs a contract, accounting or leadership decision?
Keep the project explanation and accounting disposition in separate fields. The project manager can explain the work and assumptions; the designated reviewer decides what is accepted for the reporting process.
5. Use an exception register that closes the loop.
For each exception, record: ID; project; cutoff; source record; discrepancy; owner; required action; due date; status; resolution evidence; reviewer; review date. Use a status such as Open, Awaiting evidence, Ready for review or Closed. Agree on those definitions before the first review.
The following fictional examples show how to make an issue actionable. They are not customer records or examples of accounting treatment.
| ID / project | Discrepancy | Owner and next action | Closure evidence |
|---|---|---|---|
| WIP-01 / Project A | A change appears in the project forecast, but its approval status differs from the contract log. | PM: locate the approval record and reconcile the status for the shared cutoff. | Record reference and reviewer confirmation of the accepted status. |
| WIP-02 / Project B | Two reports use different export dates, and a cost difference has not been explained. | Project accountant: compare the reporting cutoffs and identify the records responsible for the difference. | Dated reconciliation and reviewer disposition; preserve any remaining exception. |
Assign an actual due date when using the register. “Finance to review” is not enough when several people could own the action. Close an item when the designated reviewer accepts its resolution and the supporting evidence and disposition are recorded, not simply because it was discussed.
6. Preserve the reviewed version.
Save the packet, source references and exception register with their reporting cutoff and version. Record who reviewed it and when. If a source is corrected after approval, retain the prior version and document the correction instead of silently replacing the evidence behind an earlier report.
Carry unresolved items into the next review with the same IDs. This makes it easier to distinguish a new issue from an old one that still needs attention. Compare equivalent project scope and reporting definitions before interpreting a month-to-month change.
Where project operations software fits.
Budgets, commitments, changes, actual costs and forecasts can form part of the project evidence your team prepares for the accounting reviewer. Jet.Build describes those connected records in its construction cost management software and construction reporting and dashboards pages.
During software evaluation, ask the provider to trace one project record into the report your team needs. Confirm the required accounting system, data fields, transfer direction, reconciliation process and responsibility for resolving failures. Public API documentation or an integration logo alone does not establish that your complete accounting workflow is supported.
Bring your current project cost report and month-end handoff requirements to a project cost workflow discussion. Confirm the operational workflow and integration scope before making an implementation decision.
Before handing the packet to the reviewer
- The project scope and reporting cutoff are recorded.
- Source reports are identifiable and accessible to the reviewer.
- Material differences are explained or listed as unresolved.
- Pending and approved changes are distinguishable.
- Remaining-work assumptions have a named reviewer.
- Each exception has an owner, required action and due date.
- The reviewed version and open items can be recovered next month.