What is Project Accounting?
Ask a general ledger whether the firm made money last quarter and it answers instantly. Ask it whether the engagement that consumed your best team made money and it goes quiet. Both are financial questions, and only one of them can be answered by the system every firm already has, which is why people businesses invented project accounting.
Cost and revenue at the grain of the engagement
Project accounting records the economics of work at the level of the individual engagement: the project, the matter, the job. Each engagement carries its own running income statement, assembled from parts the company systems hold separately: time captured against the engagement and priced at the loaded cost of the people who worked it, direct expenses, revenue recognised on the engagement’s own terms, billing raised, and work in progress accrued between the two. The arithmetic at this grain is simple, and the numbers here are invented purely to illustrate it: an engagement recognises sixty thousand of revenue in a month, the hours worked on it cost forty one thousand loaded, expenses add three thousand, and the engagement contributed sixteen thousand that month. The value is not in the sum; it is in having a sum per engagement at all, month after month, so that drift is visible while the engagement is still moving.
Why the general ledger cannot answer
The general ledger is organised by the nature of money: accounts and cost centres. Payroll is a few lines. Rent is a line. Revenue is recorded by entity, perhaps by client. Nowhere in the chart of accounts does the engagement exist, so no query against the ledger, however clever, can say what a specific engagement earned or consumed. The engagement view requires a different data model: time records joined to loaded cost rates joined to revenue allocations, kept at a grain the ledger deliberately summarises away. Firms without project accounting answer engagement questions by spreadsheet archaeology, quarterly, painfully, and after the fact. The gap matters because finance naturally answers company questions while delivery keeps asking engagement questions, and a firm whose systems can only answer the first kind is running its actual work, the promises with names and teams and prices, on folklore and recollection.
Timeliness against accuracy
Every project accounting system lives on a trade-off between two virtues. The accurate number arrives at period close: timesheets complete and approved, allocations settled, revenue trued up. It is dependable and it is late. The timely number is available weekly or even daily, built from unapproved time, estimated cost rates and provisional revenue. It is useful and it is rough. The mistake is demanding one number that is both, because the steering value of engagement data decays fast: a cost overrun visible in week five can be answered with a staffing change, while the same overrun confirmed at quarter close is simply history with an explanation attached. Project accounting exists to make delivered work steerable while it is still moving, not to explain it after it has stopped. The working discipline is to run both views and label them honestly: a fast provisional view for steering, a settled view for the record, and no pretence that either can do the other’s job.
One concrete example
Clearly illustrative, no customer implied. A firm of a few hundred people runs its finances on a respected ledger and reviews engagement economics through a spreadsheet assembled each quarter. One engagement begins overrunning in the first month: the team quietly grows by two people and the scope conversation keeps being deferred. Nothing in the ledger flags it, because payroll is one line and the engagement is not a dimension. The overrun surfaces at the quarterly review, thirteen weeks in, by which point the margin the deal was sold at is unrecoverable and the review can only allocate blame. A weekly engagement-grain view, rough as it would have been, would have shown the cost run-rate crossing plan in week five, while restaffing and a scope conversation were still cheap options.
From engagement facts to engagement decisions
Project accounting is necessary and not sufficient. It produces the facts at the right grain: what this engagement earned, what it consumed, how that is trending. What it does not hold is what the firm did about it: the restaffing that was considered and rejected, the reprice that was discussed and deferred, who decided and against what evidence. Those decisions happen in meetings and evaporate, which is the difference between a system of record and a system of memory. The decision-intelligence layer treats the engagement facts as evidence, labelled by quality, a settled actual and a provisional estimate are both useful and are not the same thing, and records the decisions taken on that evidence so their outcomes can be scored later. Project accounting tells you the engagement is drifting. The decision layer remembers what you chose to do about it, and whether it worked, which is how the next drifting engagement gets a better answer, and how cost-to-serve stops being a quarterly surprise.
Common questions
What is project accounting?
Project accounting is the practice of recording revenue and cost at the level of an individual engagement, the project, matter or job, so that each engagement carries its own running income statement: recognised revenue, hours worked at loaded cost, direct expenses, work in progress and billing. Where the general ledger exists to state the financial position of the company, project accounting exists to make delivered work steerable while it is still moving, by showing what each engagement is earning and consuming as it happens.
Why can’t a general ledger answer engagement questions?
Because the ledger is organised by account and cost centre, not by engagement. Payroll is a handful of lines, revenue is recorded by entity or client, and the engagement dimension simply does not exist in the chart of accounts. Answering a question like whether a specific engagement is profitable requires joining time records, loaded cost rates and revenue allocations, which is a different data model. The ledger is not wrong; it was built to answer company questions, and engagement questions are a different grain.
What is the timeliness versus accuracy trade-off in project accounting?
Engagement numbers can be accurate or timely, and rarely both at once. The accurate version arrives after timesheets are complete, allocations are settled and revenue is trued up at period close, which is weeks after the fact. The timely version is available weekly or daily but leans on estimated cost rates, unapproved time and provisional revenue. For steering delivery, a roughly right number this week beats an exactly right number six weeks late; precision matters at close, timeliness matters in flight. The discipline is to use both and label which is which.
What decisions does project accounting enable?
The steering decisions of delivered work: restaffing an engagement whose cost run-rate has crossed plan, repricing or rescoping when the economics have moved, escalating a scope conversation while it is still a conversation, and choosing where senior attention goes. Project accounting supplies the engagement-grain facts those decisions need. Whether the decisions themselves get made, recorded and learnt from is a separate discipline, and firms with excellent project accounting can still lose the reasoning behind every choice it informed.