Work in progress (WIP) and recognition for projects in Business Central

Projects in Business Central (formerly Jobs) capture revenue and cost across a span of time. Until completion, accounting standards usually require some form of work in progress (WIP) recognition — moving incurred costs out of P&L into a balance sheet account and recognising revenue based on percentage of completion. BC handles this through the WIP calculation engine on the Project Card.

The four WIP methods. On each project, the WIP Method field selects how WIP is computed:

• Cost Value — recognises cost based on percentage of completion; revenue follows separately.
• Sales Value — recognises revenue and cost in proportion to billable progress.
• Cost of Sales — recognises cost matched to invoiced amounts.
• Percentage of Completion — recognises both revenue and cost at the calculated completion %.
• Completed Contract — defers everything to completion.

The choice depends on the contract type (fixed price, time and material, milestone) and the accounting policy. Service firms usually use Percentage of Completion or Sales Value; construction firms often use Completed Contract for shorter projects and Percentage of Completion for longer ones.

WIP postings. WIP doesn't change Project Ledger Entries directly; it creates G/L entries against:

• WIP Cost Account — balance sheet inventory-like account holding incurred-but-unrecognised cost.
• Recognised Costs Account — P&L cost as recognised by the WIP method.
• WIP Sales Account — balance sheet account holding billed-but-unearned revenue (when invoicing exceeds recognised revenue), or earned-but-unbilled (the reverse).
• Recognised Sales Account — P&L revenue as recognised.

The journal pattern is symmetric: at every WIP run, BC reverses prior WIP entries and posts current values; the net movement reflects the period's earned revenue and cost.

Running WIP. The Project Calculate WIP action computes WIP per project, optionally per task. The Project Post WIP to G/L action posts the calculated values to the general ledger. Most teams run these as monthly close steps. Important: WIP entries reverse and re-post each period — the WIP G/L balance is always "the current cumulative WIP value", not an accumulation of period entries.

Completion %. For methods that depend on completion %:

• Cost-based completion — actual cost to date / estimated total cost. The Cost Completion % field on the project card.
• Schedule-based — manually entered or driven by milestone task statuses.
• Quantity-based — actual quantities posted / planned quantities, summed across tasks.

The estimated total cost must be maintained continuously; a project where the estimate hasn't been updated for six months will show wrong WIP regardless of method.

Project tasks and WIP totals. WIP can be calculated at the task level — each task carries its own WIP Method and accounts. This matters for projects with mixed-type tasks (a fixed-price phase followed by a time-and-material phase). The project header's WIP is the sum across tasks.

Recognising milestones. For milestone billing, the typical setup is:

• Task WIP Method = Completed Contract.
• A task WIP Total field equal to the milestone amount.
• The milestone task is marked complete only when the milestone is achieved.
• WIP recognises 100% of that task's revenue at completion.

WIP and invoicing decoupled. A project might be invoiced ahead of work (deposit, milestone billed early) or behind work (T&M billed in arrears). WIP accounts capture the timing difference:

• Invoiced more than recognised → liability balance (deferred revenue) on WIP Sales.
• Recognised more than invoiced → asset balance (accrued revenue) on WIP Sales.

The WIP sales account thus carries both directions depending on the project. Some teams split into two accounts (Deferred Project Revenue, Accrued Project Revenue) for cleaner balance sheet presentation, but BC's standard logic uses one.

Common pitfalls.

• Stale estimates. Estimated total costs not updated → completion % wrong → WIP wrong.
• WIP not posted. Calculation runs but post step forgotten; P&L shows incurred cost, no recognised revenue.
• Mixed WIP methods on one project. Result is hard to audit; standardise by project type.
• Closing a project before final WIP. Final WIP needs to reverse all balance sheet WIP and recognise everything to P&L. If the project is set to status Completed before WIP is run one last time, balance sheet WIP stranded.

Audit and disclosure. WIP balances are scrutinised in audits — overstating WIP overstates assets and revenue. Auditors look for:

• Aged WIP balances (project hasn't moved for 12 months — write off?).
• Negative WIP that doesn't match a billing-ahead pattern.
• Inconsistency between estimated costs and actuals trending.

A clean monthly WIP close, with reviewed estimates and a documented method per project, makes the audit fast.