Project Accounting 101: Basics for Project Managers

What does project accounting actually cover?

Six elements, and a project manager touches all of them.

Cost capture. Every hour, purchase order, subcontractor invoice and expense claim is coded to a project and usually to a phase or work package. This is the foundation; if the coding is wrong, everything downstream is decorative.

Budget and commitment control. The approved budget is the baseline. Commitments — signed purchase orders and subcontracts not yet invoiced — matter because they are money already spent in substance but not yet in the ledger.

Billing and progress. What has been invoiced, what is retainable, what has been certified by the client. Billing schedules rarely match progress exactly, which is the origin of most WIP puzzles.

Revenue recognition. The accounting rule for when revenue may be recorded. On short jobs it is usually delivery; on long jobs it is progress.

Margin analysis. Revenue minus direct cost, and then minus allocated overhead, at project level. A gross margin that ignores overhead is a contribution figure, not a profit figure.

Forecast at completion. What the project will cost and earn by the end, based on actuals to date. This is the number that drives decisions, and it is the one most often left stale.

> Important note: project accounting is not “the finance team’s spreadsheet”. It is a shared dataset. Finance owns the rules; the project team owns the accuracy of what gets coded.

How is project accounting different from financial accounting?

Financial accounting reports the entity to the outside world on a calendar basis. Project accounting reports a unit of work to the inside world on a scope basis. They use the same ledger but answer different questions.

The two must reconcile. A project accounting system whose total revenue disagrees with the financial ledger is not a control system, it is a rumour. The monthly reconciliation between project totals and the general ledger is the single most valuable habit in this discipline.

Why can a project look profitable at company level and lose money individually?

Because averages hide mix. If three projects run at 45% gross margin and one runs at minus 10%, the blended figure can still look healthy while one team is destroying value every week.

Consider a services firm with four active engagements and $4.0 million of quarterly revenue:

The company reports a 39.5% gross margin and management congratulates itself. Project D is losing $40,000 a quarter, its client is the most demanding, and it consumes the most senior staff. Without project-level accounting, D is invisible until it becomes a write-off. With it, D is a decision: reprice, rescope, or exit.

How does revenue recognition work on a long project?

Revenue is recognised when the seller satisfies a performance obligation, not when cash arrives and not when an invoice is raised. Under ASC 606 and IFRS 15 — the converged standards issued by FASB and IASB in May 2014, effective for public companies in 2017 and private companies in 2018 — the model has five steps.

For long-term construction and development contracts, the traditional method is percentage of completion: recognise revenue, costs and gross profit in proportion to progress. The common proxy is cost-to-cost — accumulated cost divided by total estimated cost. The alternative, completed-contract, defers everything until the end and is appropriate only where progress cannot be measured reliably or risk is exceptionally high. A related principle matters more than either: an expected loss on a contract should be recognised in full as soon as it is foreseen, not spread across the remaining months.

Worked example: cost-to-cost percentage of completion

A fixed-fee implementation contract is priced at $1,200,000. The approved cost budget is $900,000, implying a total gross profit of $300,000, or 25% of revenue.

At the end of month three, accumulated cost on the project is $270,000.

• Percentage complete = 270,000 ÷ 900,000 = 30%
• Revenue to recognise = 30% × 1,200,000 = $360,000
• Cost to recognise = $270,000
• Gross profit to recognise = $90,000 (30% of the $300,000 total)

Now compare that with billing. If the client has been invoiced $300,000 to date, the project has recognised $60,000 more revenue than it has billed. That $60,000 is a contract asset — unbilled revenue, often called WIP. If instead the client had been invoiced $400,000, the project would carry a contract liability of $40,000: cash received for work not yet performed.

Neither position is automatically good or bad. A contract asset means you are financing the client; a contract liability means the client is financing you. Both need watching, because both distort cash flow if they grow unchecked.

What is WIP and why does it decide your cash position?

Work in progress is the value of work performed but not yet billed. It sits between the delivery team, which knows what is done, and finance, which knows what has been invoiced. When those views diverge for more than a month, one of three things is happening: billing is lagging, progress is being overstated, or change orders are being delivered without paperwork.

A practical WIP review asks four questions per project:

1. What revenue have we recognised this period, and on what basis?
2. What have we billed, and does the billing schedule support that number?
3. Is the gap a timing difference or a dispute?
4. What is the aged portion — anything over 60 days — and who owns clearing it?

The aged portion is the dangerous part. Fresh WIP is normal in any progress-based contract. WIP that has not moved in three months is usually a change order nobody approved, or a progress claim the client is silently rejecting.

How do you calculate project margin so it means something?

Gross margin is revenue minus direct cost. Net project margin subtracts allocated overhead. Only the second one tells you whether the project is worth having.

The formula is simple; the discipline is in the inputs:

Project margin = (Recognised revenue − Direct cost − Allocated overhead) ÷ Recognised revenue

Three things trip teams up.

Uncoded time. Hours that land in “admin” or “internal” instead of the project make the project look better and the company look worse. In a 40-person consultancy billing 1,600 project hours a month, mis-coding 5% of hours — 80 hours at a $95 cost rate — moves $7,600 of cost per month out of projects and into overhead. Over a year that is $91,200 of invisible margin.

Forgotten overhead. A project that uses 30% of the design team’s capacity should carry roughly 30% of that team’s cost, not zero. Without allocation, every project looks profitable and no project pays for the bench.

Change orders. Work requested verbally, delivered enthusiastically, and never priced. A single unbilled change of 60 hours at a $140 rate is $8,400 of revenue that never appears anywhere until someone audits the project.

Worked example: fully loaded margin

A project bills $500,000. Direct cost is $320,000 — labour at cost, subcontractors, licences. The project used 2,000 of the firm’s 10,000 available delivery hours, so it carries 20% of a $400,000 overhead pool.

• Allocated overhead = 20% × 400,000 = $80,000
• Gross margin = (500,000 − 320,000) ÷ 500,000 = 36.0%
• Net project margin = (500,000 − 320,000 − 80,000) ÷ 500,000 = 20.0%

A 36% gross margin looks like a strong project. At 20% net, it may be barely above the firm’s cost of capital once sales cost and payment terms are included. The same arithmetic applied across the portfolio is how you discover that your best-looking client is your least profitable one.

Which mistakes destroy project accounting fastest?

Most failures are operational, not technical. Six recur:

• Cost codes created per project with no standard. If every project invents its own structure, you cannot benchmark, and benchmarking is the point.
• Late timesheets and mis-coded expenses. A timesheet submitted three weeks late corrupts two reports; an expense coded to the wrong project is usually found at year end.
• Billing lag. Work delivered in March, invoiced in May. The revenue is real; the cash is not, and the client’s memory of the approval has faded.
• Change orders without paper. The most expensive form of goodwill in professional services.
• A forecast at completion that nobody updates. The estimate made at kickoff is not a forecast; it is a hope with a date attached.

What does a project manager need to do, and how often?

You do not need accounting depth. You need a weekly and monthly rhythm.

Weekly: every team member’s time coded to the right project and phase; expenses submitted with a project reference; any scope change written down, even if the price comes later.

Monthly: reconcile the project’s recognised revenue and cost against finance’s ledger; review WIP and its aged portion; update the forecast at completion using actuals, not the original plan; review margin against the approved business case.

At milestones: confirm the billing trigger has actually been met, re-forecast remaining cost, and check that approved change orders have been added to both the contract value and the budget.

At close: compare final cost against the original estimate, and record the reason for the variance in a form the next estimator can use. That last step is what turns project accounting into an estimating asset instead of a compliance chore.

Do you need specialised accounting software?

Not necessarily, but you need the data in one place. Enterprise ERP systems handle multi-entity revenue recognition, tax and statutory reporting, and they are the right answer for a firm with complex contracts and auditors. Lightweight project tools handle the delivery side well but usually stop short of recognition rules. The gap in the middle — where cost codes, actuals and progress live — is where most firms lose visibility.

The practical test: can a project manager see, in one view, the approved budget, committed cost, actual cost to date, revenue recognised and the current forecast at completion? If answering that requires three exports and a meeting, the process will decay within a quarter, because nobody sustains a monthly ritual that takes two days.

Doitify covers part of that middle layer: project budgets, tasks and sub-tasks with owners and time estimates, cost and finance management modules, project documents, and work and performance reports. Transparency note: Doitify is our product. It is not a statutory accounting system and does not replace your ledger or your auditor; teams that need formal ASC 606 disclosure still run that in their accounting platform. What it does is keep the operational actuals close to the plan, which is the raw material project accounting depends on.

What are the limits of project accounting?

Three honest trade-offs.

Granularity costs money. Tracking at work-package level gives better insight and takes more administrative effort. A ten-person firm tracking 400 cost codes will spend more on coding than it gains in visibility. Match granularity to contract size.

Allocation is always a judgement. Overhead allocation by headcount, by hour, or by revenue produces different margins for the same project. Pick a method, document it, and apply it consistently; the absolute number matters less than the trend.

Accounting lag is real. Even a good monthly close is historical by the time it lands. Project accounting tells you what happened; it does not tell you what is happening. Pair it with delivery signals — burn rate, milestone completion, defect trends — to get a forward view.

Conclusion

Project accounting is not a finance specialism you need to master. It is a discipline of attribution: every hour and every invoice lands on the right project, every month the numbers reconcile, and the forecast at completion reflects what you know now rather than what you hoped in January.

Start with three moves. Standardise cost codes so results are comparable. Reconcile project totals to the ledger monthly, and treat any unexplained gap as a defect. Review WIP ageing alongside margin, because a profitable project that never bills is a cash problem wearing a good report.

Do those three things and the question changes from “did we make money this quarter” to “which work is worth doing next quarter”. That is a far more useful question, and it is the one project accounting exists to answer.

If this post on project accounting was helpful, you might also enjoy Best Task Management Software for Teams in 2026 and How to Calculate Sprint Velocity: Formula, Steps, and Best Practices.