ERP project accounting tags every relevant transaction (timesheets, purchases, stock issues, expenses, invoices) to a project and its tasks, so the business can compare budget, committed cost, actual cost and forecast for each project, and recognise revenue on a basis its accountants accept. It answers one question continuously: is this project making the money we expected?
Construction firms, engineering contractors, agencies, consultancies and installers all live or die by project margin. Spreadsheet job costing usually reports that margin weeks late, after the money is spent. This guide covers how to structure projects in an ERP, how to capture costs and commitments, the basics of revenue recognition, the reports that matter and a worked example.
What does ERP project accounting include?
Project accounting combines a project structure, budgets, cost capture from other modules, billing and revenue, and reporting. The structure is the foundation, because every other module posts against it.
| Component | What it holds | Fed by |
|---|---|---|
| Project and tasks | Project, phases or work breakdown structure, cost codes | Project managers |
| Budget | Original budget, approved changes, revised budget by cost code | Estimating, project managers |
| Commitments | Approved purchase orders and subcontracts not yet invoiced | Procurement |
| Actual costs | Labour from timesheets, materials, supplier invoices, expenses, equipment | Payroll, inventory, payables |
| Billing | Milestones, time and materials, progress claims, retentions | Finance |
| Revenue | Revenue recognised by period on the agreed basis | Finance |
| Forecast | Estimate to complete and estimate at completion | Project managers |
If your projects have specific contract structures, cost codes or billing rules, our custom ERP software page explains how a system is built around them, and project dashboards are often delivered as business dashboards on top of the ERP data.
How should projects be structured in an ERP?
Use a consistent hierarchy: project, then phases or work packages, then cost codes. Keep it shallow enough that people post to the right place without guessing.
- Project: one per contract or engagement, linked to a customer, entity and project manager.
- Phases or tasks: stages of work that matter for billing or tracking, such as design, procurement, installation and commissioning.
- Cost codes: a company-wide list (labour, materials, subcontract, equipment, overheads) so projects can be compared.
- Change orders: each approved variation has its own reference, budget and price, so you can see original scope against changes.
A standard cost code list across projects is what makes portfolio reporting possible. Allow projects to add tasks, but not to invent cost codes.
How do budgets and commitments work in project accounting?
A budget sets what each cost code is expected to cost. A commitment is money already promised (an approved purchase order or subcontract) but not yet invoiced. Tracking commitments is what turns project accounting from a history report into an early warning.
The key formula is:
Exposure = actual cost to date plus open commitments
If exposure on a cost code is approaching budget while work remains, the project manager knows before the invoices arrive. Purchase orders should be coded to a project and cost code at the request stage, because the procurement module is where commitments are created and approved.
Budget control options to decide:
- Warn or block: warn the requester when a purchase would exceed the cost code budget, or block it until a budget transfer or change order is approved.
- Budget transfers: moving budget between cost codes needs approval and a record.
- Revised budget: original budget plus approved change orders, kept separate so you can see how scope moved.
How are project costs captured?
Costs reach the project from other modules, so project accounting is only as good as the coding at source. Each cost type needs a capture route.
| Cost type | Capture route | Common problem |
|---|---|---|
| Labour | Approved timesheets valued at a cost rate | Late or unapproved timesheets; wrong rate |
| Materials | Stock issued to project, or direct purchase delivered to site | Materials bought for one job used on another |
| Subcontract | Subcontract orders and progress claims | Claims not matched to commitment |
| Expenses | Expense claims coded to project | Missing project code |
| Equipment | Internal hire rates per day or hour | No agreed internal rate |
| Overheads | Allocation by rule at period end | Arbitrary or changing allocation rules |
Labour cost rates usually come from payroll, so agree with HR and finance whether projects carry actual pay, a standard rate per grade, or a rate that includes employer costs and overheads.
How does revenue recognition work for projects?
Revenue is recognised under the accounting framework that applies to you: IFRS 15 Revenue from Contracts with Customers under IFRS, or ASC 606 under US GAAP. The two were issued as a converged standard in 2014 by the IASB and FASB, and IFRS 15 replaced IAS 11 Construction Contracts.
Both use a five-step model: identify the contract, identify the performance obligations, determine the transaction price, allocate it to the performance obligations, and recognise revenue when or as each obligation is satisfied. Revenue may be recognised over time or at a point in time, and for obligations satisfied over time the entity chooses a measure of progress.
What this means for the ERP, without turning it into accounting advice:
- Billing and revenue are separate. An invoice is not revenue. The system must track amounts billed and revenue recognised independently.
- Measure of progress is configurable. Common bases include cost incurred against total estimated cost (an input method) or milestones and surveys (output methods). Your accountants choose the basis; the ERP calculates it consistently.
- Contract assets and liabilities. When revenue recognised exceeds billing, or the reverse, the difference is reported on the balance sheet. The ERP should produce that schedule per project.
- Estimates drive revenue. If progress is cost-based, a wrong estimate to complete changes revenue, so forecast updates need review and approval.
Illustrative example (hypothetical figures, cost-based progress):
| Item | Amount |
|---|---|
| Contract price | 500,000 |
| Original cost budget | 400,000 |
| Approved change order: price | 50,000 |
| Approved change order: cost | 40,000 |
| Revised price | 550,000 |
| Revised budget | 440,000 |
| Actual cost to date | 220,000 |
| Estimate to complete | 240,000 |
| Estimate at completion | 460,000 |
| Progress (220,000 divided by 460,000) | About 47.8 percent |
| Revenue to date at that progress | About 263,000 |
| Billed to date | 300,000 |
| Forecast margin (550,000 minus 460,000) | 90,000 |
Two things stand out. The forecast margin has fallen from the 110,000 implied by the revised budget to 90,000, because the estimate at completion exceeds the revised budget by 20,000. And billing is ahead of revenue by about 37,000, which the ERP should report as a contract liability. Whether cost-based progress is appropriate for a contract is a judgement for your accountants.
What reports should ERP project accounting produce?
The reports should let a project manager act this week and let finance close the month. These are the core set:
- Project cost report: budget, revised budget, committed, actual, estimate to complete and estimate at completion by cost code
- Project profitability: revenue, cost and margin to date and at completion, against the original estimate
- Work in progress schedule: revenue recognised against billing per project, showing contract assets and liabilities
- Change order log: submitted, approved and rejected variations with value and status
- Labour utilisation: hours by person, project and billable status
- Portfolio view: all projects ranked by margin erosion or forecast overrun
Our guide to business dashboard KPI design covers how to present these without burying the warning signs.
When is ERP project accounting not the right approach?
Full project accounting is more than you need when projects are short, small or billed simply.
- Short fixed-fee jobs: a job costing feature in accounting software may be enough.
- Pure time and materials billing with no fixed budgets: a timesheet and billing tool integrated with the ledger may suffice.
- No discipline in coding: if timesheets and purchases are not coded to projects at source, the reports will be wrong whatever the system.
- Specialist industry tools already fit: some construction and professional services platforms handle project control well; integrating them with the ERP may beat replacing them.
Industry detail differs. Our sibling guides on ERP for construction companies and ERP for professional services firms cover sector-specific needs.
Project accounting requirements checklist
- Project hierarchy and company-wide cost code list agreed
- Budget, change order and budget transfer process with approvals
- Purchase orders and subcontracts coded to project and cost code at request
- Timesheets approved weekly, valued at agreed cost rates
- Billing types supported: milestone, time and materials, progress claims, retentions
- Revenue basis agreed with accountants, with billing and revenue tracked separately
- Estimate to complete updated and approved each period
- Work in progress schedule and project profitability reports defined
- Multi-entity and multi-currency needs recorded
How to start
Pick three recent projects, one profitable, one that lost money and one typical, and write down how their costs, changes and billing flowed. That exercise exposes the requirements faster than any workshop. Use our software requirements brief template to record them, then discuss the project with us. Timeline Digital builds 2 to 3 key modules as a free pilot before the full project starts, so you can test project cost reporting on your own projects before committing.