You close the month, build the schedule, and the WIP never ties out. The costs-to-date column does not foot to the job-cost general ledger, or the recognized revenue does not match the income statement, and you spend the afternoon hunting a variance you have chased before. This is a WIP reconciliation problem, and it almost never has a single cause — it has four recurring structural ones, and each has a specific fix. This post walks the diagnosis, shows the exact WIP adjustment journal entry that trues up an over- or under-billing position, and explains why the same variance keeps coming back.
The numbers below are synthetic — round figures from a fictional general contractor, Meridian Construction Group, on its Harbor Point Tower job. They are the same figures used across the WIP Ready series, so the math ties out across posts.
What "ties out" actually means in a construction WIP
A WIP schedule ties out when two conditions are both true: costs-to-date on every active project match the corresponding job in the general ledger, and recognized revenue for the period matches the income statement. If either condition fails, the WIP is not reconciled, and a WIP that does not reconcile is not suitable for bonding review or audit support under ASC 606.
The two checks are independent, and you have to pass both:
- Tie-out check 1 (costs): WIP costs-to-date = job-cost general ledger (GL), by project.
- Tie-out check 2 (revenue): WIP recognized revenue = income statement revenue, by period.
Here is why those two checks are not bookkeeping niceties. Under ASC 606, a construction contractor using the cost-to-cost method recognizes revenue in proportion to costs incurred relative to total estimated cost (FASB ASU 2014-09; Foundation Software). That means every revenue line on the WIP schedule is derived from the costs in the GL. Any divergence between the two is a revenue recognition error, not a cosmetic spreadsheet discrepancy. The AICPA frames the same dependency from the financial-statement side: the WIP schedule is the artifact that drives revenue recognition, recording revenue as costs are incurred relative to total project costs (AICPA-CIMA).
So "tie out" is not a clerical step at the end of the close. It is the test of whether your revenue is real.
Why doesn't my WIP tie out? (Four structural causes)
Most WIP reconciliation failures trace to one of four causes: costs posted late or to the wrong job, billings recorded in the wrong period, revenue recognized off a stale estimate-to-complete, or a timing difference between when the WIP was pulled and when the GL was closed. Each cause has a specific fix. Reconciliation failure is a named, recognized problem in construction accounting — a CPA-firm review of common WIP mistakes lists lack of reconciliation among the five that hurt contractors most (BerryDunn).
1. Miscoded or late costs hit the GL after the WIP was built
A cost posted after the WIP cutoff, or coded to the wrong job, breaks the costs-to-date = GL check directly. The WIP shows lower costs than the GL carries; percent complete is understated; earned revenue is understated; and the WIP looks more underbilled than the project actually is. This is the most common cause in high-volume subcontract environments, where invoices and accruals land continuously.
The mechanism is well documented: "If labor hours from last week are not yet posted to the job, the cost-to-date figure is understated. If materials received but not yet invoiced are not accrued, the picture is incomplete" (WhippleWood CPAs). The blunt version of the rule is worth keeping on a sticky note: a WIP report is only as accurate as the data going into it, and timely, disciplined cost entry is a prerequisite for the report to mean anything (WhippleWood CPAs).
2. Billings were posted in the wrong period
A billing posted in month N+1 for work invoiced in month N creates a timing mismatch the WIP cannot hide. The WIP shows a billing the GL has not yet received, or the GL carries a billing the WIP was built before. The project's over/under-billing position no longer agrees with the accounts-receivable subledger, so the balance-sheet account (billings in excess of costs, or costs in excess of billings) is wrong before anyone books an adjustment.
This is the check most controllers skip under deadline pressure, because billings feel like the clean number. They are not, when the cutoff is loose.
3. Revenue was recognized off a stale ETC
This is the most insidious cause, because the WIP math is internally consistent — the percentage-of-completion calculation is correct — but it is correct on the wrong denominator. Under the ASC 606 cost-to-cost method, that denominator is the estimated cost at completion (EAC), which equals costs-to-date plus the estimate-to-complete (ETC) the project manager submits each cycle (Foundation Software). If the ETC has not been updated since last month, the EAC is wrong, the percent complete is wrong, and the earned revenue that flows to the income statement is wrong, even though every formula on the sheet checks out.
This is exactly where a reader wants the mechanics, so here they are: read how a stale ETC throws off your EAC and percent-complete. The cost-to-cost method "only produces accurate calculations if estimates are kept current," and that ongoing estimate is the ETC entered each cycle (Foundation Software). A stale ETC is the cause that survives a clean-looking reconciliation, because the costs tie out and the revenue tie-out looks internally consistent — it just disagrees with what a correct EAC would produce.
4. Cutoff/timing: the WIP and the GL were pulled at different points in the close
The WIP was built Friday afternoon; the final period-end journal entries were not posted until Monday. The GL snapshot does not match the WIP snapshot, so the two foot to different totals even though nothing is miscoded. Minor timing drift looks harmless in any single month, but it accumulates month over month if the close sequence is not disciplined, and it is the variance that reappears every period because nothing structural ever changed.
The WIP reconciliation checklist (before you touch a journal entry)
Before booking an adjusting entry, confirm the numbers you are reconciling are from the same period and the same source of record. WIP reconciliation should be performed before the adjusting entry is booked, not after — booking an entry to fix a timing difference that will self-correct next period creates reversing-accrual noise and can mask the underlying data-currency problem (AICPA-CIMA).
Work this WIP schedule reconciliation in order:
- Confirm the WIP cutoff date equals the GL period-end: the same day, not a Friday WIP against a Monday close.
- Pull the job-cost detail report from the GL by project and compare it to the WIP costs-to-date line by line.
- Identify unposted or miscoded costs: AP accruals, subcontract invoices in transit, labor not yet burdened and posted.
- Confirm the billings on the WIP match the AR subledger for the same period.
- Re-run percent complete with the current ETC and check whether the resulting earned revenue matches the income statement revenue line.
- Document the variance: is it a timing difference that will self-correct next period, or a permanent difference that requires a journal entry?
Step 6 is the one that determines what you do next. A timing difference and a permanent difference look identical in the variance column and call for opposite responses.
The WIP adjustment journal entry: what it looks like and when to book it
The WIP adjustment is a period-end accrual entry, not a correction to contract revenue. It reclassifies the timing difference between what a project has billed and what it has earned. Booked correctly, it brings the over- or under-billing balance on the balance sheet into agreement with the WIP schedule. It does not change total contract revenue; it moves a billing-timing difference between two balance-sheet accounts: billings in excess of costs (a current liability for overbilled projects) and costs in excess of billings (a current asset for underbilled projects).
First, the worked example, so the entry amount is not an abstraction. Harbor Point Tower carries the canonical Meridian figures, and every number recomputes from the inputs:
| Field | Amount |
|---|---|
| Contract value | $1,000,000 |
| Costs incurred to date | $300,000 |
| Estimate to complete (ETC) | $450,000 |
| Estimated cost at completion (EAC = costs + ETC) | $750,000 |
| Percent complete (costs ÷ EAC) | 40.0% |
| Earned revenue (contract × % complete) | $400,000 |
| Billed to date | $450,000 |
| Over/(under) billing (billed − earned) | $50,000 overbilled |
Costs of $300,000 plus a $450,000 ETC give an EAC of $750,000. Percent complete is $300,000 ÷ $750,000 = 40.0% exactly. Earned revenue is $1,000,000 × 40.0% = $400,000. Harbor Point Tower has billed $450,000, which is $50,000 more than the $400,000 it has earned, so the job is overbilled by $50,000. That $50,000 is the WIP adjustment journal entry amount. (For the full over/under-billing derivation and the underbilled mirror case, see how over/under billing is calculated and adjusted.)
Here is the entry in both directions. Both assume period revenue was recorded at amounts billed, so each adjustment trues recognized revenue to earned revenue and records the balance-sheet position:
OVERBILLED PROJECT (billings exceed earned revenue) — Harbor Point Tower:
Billed $450,000, earned $400,000 → $50,000 overbilled
DR Revenue $50,000 [income statement — reduces over-recognized revenue]
CR Billings in Excess of Costs $50,000 [current liability — increases]
UNDERBILLED PROJECT (earned revenue exceeds billings) — illustrative, different job:
Billed $300,000, earned $400,000 → $100,000 underbilled
DR Costs in Excess of Billings $100,000 [current asset — increases]
CR Revenue $100,000 [income statement — increases under-recognized revenue]
For Harbor Point Tower, the overbilled entry reduces the $50,000 of revenue recognized ahead of work performed and records it on the balance sheet as a current liability (billings in excess of costs), where it sits until the project's invoices catch up with the work performed. The underbilled entry does the reverse, on a separate illustrative job: it records earned-but-unbilled revenue as a current asset, costs in excess of billings, and increases recognized revenue to match. In both cases the position label and accounts are the ones a US surety and a construction CPA read on sight (Foundation Software).
When not to book the entry
If the mismatch is a timing difference — a late cost that is already on its way to the GL and will post in the normal course — do not book a WIP adjustment and reverse it next month. That creates reversing-accrual noise and hides the real problem. The cleaner answer is to hold the WIP close until the late costs post, or to accrue the cost to the correct period with a reversing accrual entry, and leave the over/under-billing balance alone. Book the WIP adjustment only for a genuine period-end over/under-billing position, never for costs in transit.
Why this keeps happening, and the structural fix
A WIP schedule that is built by exporting from a project-management system and pasting into a spreadsheet captures the data at one moment in time. Any cost or billing change after that export creates a silent divergence from the general ledger. The structural fix is a WIP that reads from the source of record in real time. Most WIP reconciliation failures are not math errors — they are data-currency failures.
The hand-built WIP is the default across the industry: even firms on Procore "export data from Procore and build custom WIP schedules in Excel," and Procore itself ships no native WIP report (pivotxl; Procore Community). The spreadsheet is stale the moment it is built. A cost coded Friday, a billing posted Monday, an ETC the PM revised after the export — each one invalidates the snapshot without changing a visible cell. The WIP looks complete. It just disagrees with the GL.
A WIP that always reads live from the cost and billing ledger cannot have a cutoff mismatch between the WIP and the GL, because the WIP is the GL view — both are drawing from the same source of record at the same moment. That removes causes 1, 2, and 4 by construction, and it surfaces cause 3, the stale ETC, as the one input a system cannot fix on its own, because the ETC is a judgment the project manager owns.
This is the gap WIP Ready closes. WIP Ready reads cost and billing data live from Procore at the moment you review the schedule, and it captures each project manager's ETC as a timestamped, attributed submission rather than a number chased over email. It never calculates the ETC for you. The PM owns that number, the way an auditor and a surety expect. The result is a WIP whose costs and billings cannot drift from the source of record between the export and the review, leaving the ETC as the one number you actually have to manage.
What does a WIP that doesn't reconcile tell your surety?
A WIP schedule that does not reconcile to the general ledger is not a WIP schedule — it is a set of project estimates formatted like one. When a surety underwriter compares the WIP and the financial statements and the two disagree, it raises a single question: which document is accurate? That question, unresolved, constrains bonding capacity, because the underwriter cannot determine the contractor's true financial position.
Sureties run this reconciliation check deliberately. The WIP "must reconcile with the financial statements," and a disconnect (financials showing profit while the WIP shows jobs losing money) makes the underwriter question both documents (Grit Insurance). The cost is concrete: a clean, current WIP gives the surety confidence, and that confidence translates into higher bonding limits and faster approvals, while a sloppy or outdated one does the opposite (Grit Insurance). A surety's own published advice to contractors is to use integrated, real-time job-cost data for exactly this reason (NASBP). For the full picture of how an underwriter reads these documents, see what a surety underwriter reads in your WIP schedule. A WIP that consistently reconciles is a bonding asset; one that consistently does not is a bonding liability.
Frequently asked questions
What does it mean for a WIP to "tie out"? A WIP schedule ties out when costs-to-date on each project match the job-cost general ledger, and recognized revenue for the period matches the income statement. Both checks must pass. A WIP that fails either check is not reconciled to the financials and is not suitable for bonding review or audit support. (AICPA-CIMA)
What are the most common reasons a WIP does not reconcile to the GL? The four most common causes are: costs posted to the wrong job or after the WIP cutoff, billings posted in the wrong period, revenue recognized off a stale estimate-to-complete (ETC), and the WIP and GL snapshots being taken at different points during the close. (BerryDunn; WIP Ready)
What is the WIP adjustment journal entry? The WIP adjustment is a period-end accrual that trues recognized revenue to earned revenue and records the over- or under-billing balance in the correct balance-sheet account. For an overbilled project, debit Revenue and credit Billings in Excess of Costs (a liability). For an underbilled project, debit Costs in Excess of Billings (an asset) and credit Revenue. It reclassifies a billing-timing difference; it does not change total contract revenue. (Foundation Software)
How do I know whether to book a WIP adjustment or just wait for the late cost to post? If the mismatch is a timing difference — a cost already on its way to the GL that will post in the normal course — waiting, or booking a reversing accrual, is cleaner than booking a WIP adjustment and reversing it next period. Book the adjustment only for genuine period-end over/under-billing positions, not for costs in transit. (AICPA-CIMA)
How does a stale ETC cause a WIP to not tie out? Under the ASC 606 cost-to-cost method, percent complete equals costs-to-date divided by estimated cost at completion (EAC), where EAC equals costs-to-date plus the estimate-to-complete (ETC). A stale ETC distorts the EAC, which changes the computed percent complete, which changes recognized revenue. The WIP's revenue line then disagrees with what a correctly updated EAC would produce. (Foundation Software)
Why does a WIP that does not reconcile affect bonding capacity? Surety underwriters verify that the WIP schedule agrees with the financial statements as part of their review. A disconnect between the two raises the question of which document is accurate, which reduces the underwriter's confidence in the contractor's financial management and can constrain bonding capacity. (Grit Insurance)
What is the structural fix for a WIP that repeatedly fails to reconcile? The root cause is usually a data-currency gap: the WIP was built on a snapshot of cost and billing data that had already changed in the underlying system. The fix is a WIP that reads directly from the source-of-record system in real time, so there is no cutoff mismatch between the WIP and the GL. (WIP Ready)
How WIP Ready helps
A WIP that refuses to reconcile, month after month, is rarely a math problem. It is a currency problem: the costs, the billings, or the ETC moved after you built the schedule, and the snapshot went stale without telling you. WIP Ready reads your cost and billing data live from Procore at the moment you review the WIP, and it captures each PM's ETC as a timestamped, attributed submission — so the only number you have to chase is the one a project manager actually owns. It never writes back to your accounting system and never calculates the ETC for you; it is a reporting layer that keeps the WIP and the source of record in agreement. If a recurring tie-out variance is eating your monthly close, see how the workflow runs at wipready.com.
