Job cost and WIP

Project Financials contains project budget, commitments and direct-cost workflows. Company Accounting > Job cost forecast can review supported posted job-cost actuals together with a project’s assigned entity and forecast inputs.

Assign a project to an allowed accounting entity and review its source records before saving a dated PM cost-to-complete estimate. The view identifies when current source records cannot support a requested historical result. A project cost code with actuals or commitments but no budget line appears with a budget of 0, marked Not budgeted.

Accounting > Job cost inquiry lists the posted job cost actuals you can see, filtered by project, cost type and date, with the total actual cost and a link from each row to its journal entry by entry number. The project list shows only projects in your entities. On the forecast, choosing a project fills in its assigned entity.

Accounting > WIP computes a WIP snapshot for an entity at an ended period: contract is the SOV of prime contracts marked executed plus approved prime change orders, cost to date is posted job cost, billed to date is posted AR on income accounts less posted credit memos (retainage included; retainage releases, reversed invoices and other-income lines excluded), and estimated cost is the job cost forecast. When the last PM cost-to-complete for the period-end date is approved, or the period is soft-closed, the forecast is frozen at the period end: WIP for that period reads the frozen estimate and contract value, so budget, commitment or SOV edits after the period end no longer stop or change it (saving a new PM input unfreezes it; the earlier frozen forecast is kept in history, marked superseded, never deleted). A PM input cannot be dated in a soft- or hard-closed period, or on or before a period whose WIP is posted. With no PM input, a cost code’s estimate is the greater of its revised budget and actual plus remaining commitments, so budget not yet spent or committed is never forecast at zero (the line is flagged); saving a PM input with a blank cost to complete chooses actual plus remaining commitments instead, and needs approval like any other input. A PO receipt accrual counts against its purchase order once (the bill that follows clears the receipt), and use tax on a bill is job cost that does not use up the commitment. Job cost posted after the freeze, such as a late bill dated in the period, is added to the frozen estimate, so it never raises percent complete against a stale estimate. Without a frozen forecast, contract value is as of the period end: SOV lines created later and change orders approved later are left out, and if one was edited after the period end the recompute keeps the value an earlier revision of that period captured (flagged on the row). With no earlier revision, today’s value is used and listed as an exception. Inactive or completed jobs whose last posted WIP row is final drop out. Every PM cost-to-complete must be controller-approved first, or the preparer overrides a job’s estimate with a reason, which the snapshot keeps. An override can also enter uninstalled materials (stored, customer-controlled materials in cost to date), which are left out of percent complete and earn no margin. Through the API, an override can also enter cost that does not show progress, such as wasted material or rework the owner will not pay for: that cost stays in cost to date but is left out of percent complete. Pending prime change orders show as a memo column. When approved-scope work is not priced yet, an API override can include an estimate for each pending change order in the contract value (variable consideration). Enter the amount you expect not to reverse, or 0 to leave it out, with a rationale. The snapshot keeps each amount and rationale, and the approver signs them off with the snapshot. Each job uses its revenue method: cost-to-cost, or as invoiced for T&M and cost-plus jobs (revenue equals billings). Retainage receivable and the cash position (AR receipts less AP payments on the job; payroll and other direct cash costs are not included) are shown per job. A job whose retainage is paid only on completion or acceptance can be marked conditional (API), and WIP then shows that retainage as a contract asset. Accounting settings record whether loss provisions are measured per contract or per performance obligation. Each WIP row is one contract with one performance obligation, so the amount is the same either way.

Jobs with posted job cost or billings that the snapshot leaves out (not assigned to the entity, or no executed prime contract), and rows using today’s contract value, are listed on the snapshot as exceptions, and the approver must acknowledge them with a note. A job that cannot compute (for example a pending PM input or a forecast source problem) does not stop the others: it is listed as could not compute, and approval stays blocked until a new revision resolves it with a fix or an override. Computing does not hold up other postings; if job cost or billings are posted into the period while it runs, or after the snapshot was computed, compute, approve and post refuse it as stale: compute a new revision.

Open a snapshot from its revision number to review it: every job row with its calculation trace, the change in earned revenue against the prior revision, links to the forecast and job cost, overrides for several jobs at once with a recompute, a CSV export and the audit trail. The approver can approve, return an approved revision to draft, or reject it.

Each recompute is a new revision. A controller other than the preparer approves it, and posting books underbillings (1210), overbillings (2210) and loss provisions (2220) on the WIP journal at the period end, reversing automatically on the first day of the next period. Posting the same revision again changes nothing; posting a later revision replaces the earlier one. The WIP schedule report and the analytics earned revenue and over/under billing tiles show the posted snapshot in force on a date (an approved revision appears once posted), and the close integrity check ties 1210, 2210 and 2220 to the posted snapshot. The job cost close check also fails until WIP is posted for the period (when assigned jobs have activity) and no job cost or billings were posted after it was computed.

Three surety reports read the posted WIP rows. Each job’s figures on a date are its latest posted row on or before that date. Completed contracts lists jobs whose project completion date falls in the range, with contract, cost, gross profit and GP % against the original estimate (fade) and the revenue and cost recognized this year. WIP to GL reconciliation adds completed and in-progress earned revenue and cost for the year and compares them with job-tagged GL contract revenue and job cost; a difference is flagged, and the close check for job cost also requires year-to-date GL contract revenue to tie to WIP earned for each job in WIP (a job with no posted WIP row before the fiscal year, such as its first snapshot after go-live, ties job to date instead). A project manager grant sees only its own projects in these reports. Backlog roll-forward shows opening backlog plus new awards plus change orders and adjustments, less revenue earned, equals closing backlog. Signed work not yet in a posted WIP snapshot is not included.

WIP uses cost-to-cost percent complete. Historical source completeness is not certified, so review the inputs before approving, and apply your company’s revenue-recognition policy. See Accounting overview.