Project Accounting Software: How Finance Should Evaluate the Project Subledger

Search for project accounting software and the first page answers a slightly different question. Most of what ranks is work management with a billing module, scored listicles that rate task tracking, and product pages that describe dashboards. The finance requirement sits underneath all of it and rarely gets stated: a project is a cost object that has to survive into the ledger, into the tax computation and eventually into an audit file.

That gap is expensive, because project financials are not a reporting view. They are the source of revenue on contracts satisfied over time, the contract asset and contract liability balances that appear on the face of the balance sheet, and the margin the business is managed by. A product that tracks tasks well and classifies cost badly will produce all three, and all three will be wrong in the same direction.

The accounting and tax sections below were evidence-reviewed against official FASB and IRS material current to 22 August 2026. They define the data, control and evidence a system must support; they do not select a revenue or tax method for a particular contract.

What project accounting software has to control

Project accounting software governs the financial life of a piece of contracted work: the cost object and its breakdown, the estimate and the approved budget, the labor and material cost charged to it, the commitments raised against it, the progress measured on it, the amounts billed from it, the revenue recognized against it, and the balances the whole arrangement leaves on the balance sheet at period end.

The category test is not whether a product can show budget against actual. It is whether it can answer, for any contract on any date, five questions with evidence attached: what was committed, what was incurred, what was earned, what was billed, and what reconciles to the general ledger. A product that answers four of those and asks a spreadsheet to answer the fifth has not been implemented. It has been supplemented.

Those answers are financial statement inputs, not management information. Revenue on an over-time obligation, the contract asset, the contract liability and any loss provision all fall out of the same records. If those records sit in a tool finance does not control, a configuration nobody reviewed is setting accounting policy.

Project accounting versus project management software

Products reach this requirement from several directions, and the marketing labels do not separate them. Classify each candidate by the record it is allowed to own in your target architecture, not by the industry it sells into.

A working design usually combines two of these rows. What fails is buying two products that each believe they hold the authoritative project cost. Before comparing features, settle where the boundary between an accounting platform and an ERP actually falls for your operating model, because that boundary decides which row you are shopping in.

Decide the cost object before you compare products

Every later argument is a consequence of the cost object. Decide first what a project is in your accounting model: a contract, a performance obligation, a funded task, a phase, a cost code, a work package, or a billing element. These are separate objects with separate lifecycles, and collapsing them is the most common reason project reporting cannot be reconciled a year later.

The test that matters is survival. Take the lowest level at which the operating team manages cost and follow it through distribution, burdening, billing and posting. If the ledger accepts only a project number while the team works at cost-code level, that detail exists solely inside the project product, and any adjustment posted directly to the ledger will never appear in it.

Contract structure decides the top of the hierarchy. Under the revenue standard the unit of account is the performance obligation, not the project code, and one project can hold several. A product that models a single flat project with one revenue method will force either an artificial split of the work or a manual override at every period end. Place each object in its authoritative layer using the reference architecture for which layer may create each governed object before you shortlist.

Labor, materials and the cost that gets burdened

Three rates, not one

Labor is where project accounting products differ most and demonstrate least. A single hour carries at least three values: the pay rate that reaches payroll, the cost rate that charges the project, and the bill rate that reaches the invoice. Products that hold one rate and derive the others will misstate margin whenever the derivation is wrong, and the error is invisible because the report still balances.

Ask each candidate to show effective-dated rates and what happens to already-posted timesheets when one is corrected. A retroactive correction that silently restates a closed period is a control failure, not a feature.

Burden is an accounting decision the product implements

Direct cost is rarely the number the contract is priced or reported on. Oracle’s project costing documentation defines burdening as applying one or more burden cost components to the raw cost amount of each individual transaction, and states that project types control how burden transactions are created and accounted, with the option to account for individual components or the total burdened amount. That is company-stated behavior for one suite, but it names the two questions to ask everywhere: which components apply, and what actually posts.

Where federal work is involved the rate structure stops being a management choice. FAR Part 31 makes a cost allowable only when it satisfies reasonableness, allocability, CAS or otherwise generally accepted accounting principles, the terms of the contract, and the limitations in the subpart. It also defines indirect cost pools as groupings identified with two or more cost objectives but not with any final cost objective, and requires the allocation base to be common to all cost objectives in the grouping and to allocate on the basis of the benefits accruing to them. A product that cannot hold fringe, overhead and general and administrative pools separately, with an auditable base, is not a candidate for that work.

Not every project cost is a project cost for accounting

This is the distinction most product comparisons miss entirely. FASB’s contract cost guidance at 340-40-25-7 identifies costs relating directly to a contract as direct labor, direct materials, allocations such as contract management and supervision, insurance and depreciation of tools used in fulfilling the contract, amounts explicitly chargeable to the customer, and costs incurred only because the entity entered the contract, such as payments to subcontractors. The following paragraph then requires general and administrative costs, the costs of wasted materials, labor or other resources not reflected in the contract price, and costs relating to past performance to be expensed as incurred.

So the project cost pool the operating team manages and the contract cost set the accounting policy recognizes are not the same population. The software has to hold both and label the difference. Ask directly: can this product flag a charged cost as excluded from contract cost while keeping it visible in project performance? If the answer is a report filter, the exclusion is not controlled.

Commitments are the number that is not in the ledger

A project is usually decided by committed cost long before incurred cost catches up. Once an order is issued or a subcontract signed, the money is spent in every practical sense, and none of it is a ledger balance yet. Products showing only actuals against budget report a comfortable position on a project that is already overspent.

Convert every commitment claim into observable behavior. Require the candidate to show an order raised against a project budget, the effect on remaining budget at the moment of approval, the relief of commitment on receipt and on invoice, the treatment of a partial receipt, the behavior of a change to the order, and the residual value when the order is closed early. Then ask which of those events posts, and which only updates a project view. The second group is not a lesser requirement: what the project view has to control before any of it posts decides the budget position an approver sees.

The closure rule deserves its own test. A commitment quietly cleared because a date passed removes a real obligation from the forecast without a decision, and the discipline that keeps an open order’s residual commitment under control applies at project level too. Require the reason, the approver and the retained history.

Billing methods are contract terms, not accounting policy

Billing arrangements vary more than product feature lists suggest, and a project product must hold the signed commercial terms, the billing plan and the fulfilment evidence as separate linked records rather than one invoice rule.

Retainage separates products quickly. Money withheld from a certified payment application is a real balance with its own release conditions, not simply an unpaid invoice. Ask where it sits, how release is triggered, and whether it is presented on the correct line. Where a project product sits alongside a dedicated invoicing platform, the separation of commercial terms from calculation described in the billing archetypes an enterprise contract can combine applies unchanged.

Revenue recognition is a measurement decision

The most consequential thing a buyer can misunderstand is that revenue is not a billing output. Under the revenue standard, control of a good or service transfers over time when the customer simultaneously receives and consumes the benefit, when performance creates or enhances an asset the customer controls as it is created, or when performance creates no asset with an alternative use and the entity holds an enforceable right to payment for work completed to date. For each obligation satisfied over time, the entity recognizes revenue by measuring progress toward complete satisfaction, applies a single method per obligation consistently, and remeasures progress at the end of each reporting period.

Two families of method are permitted. Output methods measure the value delivered to the customer directly, through surveys of performance, appraisals of results, milestones reached, time elapsed or units delivered, and FASB warns that a unit-based output method fails when work in process or finished goods the customer controls are left out of the measure. Input methods measure effort instead, using resources consumed, labor hours, costs incurred, time elapsed or machine hours against total expected inputs.

The point buyers miss sits in the input-method guidance. FASB states that an entity should exclude from an input method the effects of inputs that do not depict performance, and gives two adjustments explicitly: costs attributable to significant inefficiencies not reflected in the contract price, such as unexpected wasted materials or labor, and costs that are not proportionate to progress. For the second, where a good is not distinct, the customer obtains control significantly before the related services, the cost is significant relative to total expected cost, and the entity procures it from a third party without significant design or manufacturing involvement, the faithful depiction may be to recognize revenue only to the extent of that cost. In plain terms, a cost-to-cost percentage taken straight from the software’s cost total can be wrong, and the product must let you adjust the numerator and the denominator with an audit trail.

Vendors are explicit that the two clocks are separate when you read the documentation rather than the brochure. Oracle NetSuite’s help states that its Project Revenue Recognition feature lets you recognize deferred revenue independently from customer billing across future periods, requires Project Management, Charge-Based Billing and Advanced Revenue Management together, and supports as charged, percent complete and fixed amount project revenue rules. Acumatica states that it can automate revenue recognition based on percentage of completion, completed tasks or defined project milestones. Both are company-stated positions. Neither decides your policy.

The tax computation is a third clock

United States tax accounting for long-term contracts can require a separate percentage-of-completion and look-back computation under section 460. The current IRS instructions for Form 8697 also describe exceptions whose availability depends on contract type, expected completion period and inflation-adjusted gross-receipts tests, with rules changed for certain contracts entered after 4 July 2025. Those thresholds and classifications belong to the tax function, not the project-system configuration. The software requirement is narrower and durable: preserve contract-level cost, revenue, completion and revision history in a form the tax calculation can use without reconstructing prior years manually.

Change orders and claims move the transaction price

Change is normal on project work and is treated as an afterthought in most product demonstrations. FASB is direct about what a change order is: a contract modification is a change in the scope or price of a contract that is approved by the parties, described in some industries as a change order, a variation or an amendment, and approval may be written, oral, or implied by customary business practice. Until a modification is approved, the existing contract accounting continues.

The harder case follows immediately. A modification can exist even where the parties dispute scope or price, or have agreed a scope change without settling the price. That is the ordinary condition of a construction or engineering project, and it means unpriced and unapproved change orders are an accounting population, not a note in a log. Estimated recovery on them is variable consideration subject to a constraint, and the estimate feeds both the transaction price and the progress measure.

The buyer test is therefore specific. Show a change order in each state: requested, priced, approved, disputed and rejected. Show which states affect the budget, the commitment, the billing schedule, the transaction price and the estimate at completion. Show who may move a change between states, and show the retained history when a value is revised. A product that models change as a budget edit cannot support the accounting.

WIP, over- and under-billings and the contract balance

Project work produces balance sheet positions that general accounting software has no reason to create. FASB requires the contract to be presented as a contract asset or a contract liability depending on the relationship between performance and payment, with unconditional rights to consideration presented separately as a receivable. A contract liability arises where the customer has paid or payment is due before transfer. A contract asset is the right to consideration for goods or services already transferred, excluding amounts presented as a receivable, and it is assessed for impairment.

Those definitions are the accounting form of the work in progress schedule contractors have always kept: cost and estimated earnings in excess of billings on one side, billings in excess of cost and estimated earnings on the other. Whether a product produces that schedule at contract level from posted data, rather than an export, is a fair proxy for whether it is a project accounting product at all.

Some vendors now automate the posting rather than the report. Sage states that a work in progress feature for its construction product automatically creates over and under billing general ledger transactions and keeps a record of the data in the system, in a post dated 27 August 2024. Treat that as company-stated and test it: ask which journal is created, in which period, with what reversal behavior, and how a revised estimate at completion restates a position already posted.

Two further balances deserve named handling. Retainage receivable is conditional on more than the passage of time in many contracts, which affects whether it is a receivable at all. A provision for a loss contract has to be recognized once the estimate turns negative, and the trigger should be visible in the system rather than discovered at year end.

Margin and the estimate at completion

Everything above converges on one number. The estimate at completion drives percentage complete, revenue, margin and any loss provision, and it is the number with the least system discipline around it in most implementations. A forecast anyone can change, at any time, with no record of who changed what and why, is not evidence.

Require four controls before approval. Estimates are versioned, with the prior value and change reason retained. Authority to revise sits with a named role, separately from the ability to charge cost. Every revision is dated to a period, so the revenue effect is attributable. And the system separates a re-forecast of remaining work from a reclassification of cost already incurred, because the two carry different accounting consequences.

The ownership discipline that keeps a corporate forecast challengeable rather than quietly repaired applies to project estimates for the same reason: once finance edits an operating estimate on the owner’s behalf, the evidence for challenging it is gone.

Integrations, reconciliation and the controls that matter

The project subledger touches more systems than any other finance module: payroll for labor cost, procurement for commitment, payables for supplier cost, receivables for the invoice, revenue for the recognition entry, and the general ledger for all of it. Convert each into a named interface with named failure behavior, then require a control total per handoff and a reconciliation a reviewer can run. The control totals a subledger handoff has to carry are the same here, with the project dimension added to every one.

Period control is the test people forget. Ask what happens when a timesheet is submitted against a closed accounting period, whether a project period can be closed independently of the general ledger period, who may reopen either, and what the reopening leaves behind. Then ask the same about a retroactive rate change and a revised estimate.

Where the operational system is separate, verify the direction of authority explicitly rather than assuming it. Procore positions its financial management as staying in sync with your accounting system, connecting the systems that manage scope and schedule to the system used to manage project costs, rather than replacing it. That is a clear company-stated boundary, and exactly the kind of statement that belongs in the design document before contracting.

Representative project accounting products, checked 21 August 2026

The table below is a neutral scope map, not a ranking and not a shortlist. Inclusion required an accessible official product page or vendor documentation describing project financial capability, checked on 21 August 2026. The review covered documented scope only: it did not test configured software, implementation effort, integration depth, security operation, commercial terms or customer results. Sage Intacct’s project accounting and construction product pages returned an access error to this review on that date, so Sage is represented by a dated Sage publication instead. Products whose official pages could not be reached that day are not listed, and their absence carries no judgement.

The mix of ERP subledgers, industry project ERPs, services automation and a construction platform is deliberate, because the right answer is frequently a combination. What matters is assigning each product a role, and naming the record it may write, before anything is contracted.

Build the evaluation scorecard

Apply mandatory gates before any weighted score

Set pass-or-fail gates and apply them first. A candidate that fails one of these has not earned a weighted score:

• a cost object hierarchy that posts to the ledger at the level the business manages;
• separate pay, cost and bill rates, effective-dated, with controlled retroactive correction;
• indirect cost pools and allocation bases that can be evidenced to a reviewer;
• commitment created, relieved, changed and closed with a retained reason;
• progress measured independently of the billing schedule, on an adjustable and audited basis;
• change orders held in distinct states with a versioned value history;
• contract asset, contract liability and retainage produced from posted data;
• versioned estimates at completion with named revision authority and period attribution;
• project period control that cannot silently reopen a closed accounting period.

A failed gate stays visible. Reject the option, redesign the architecture around it, or record owned remediation with a funded date and an acceptance test. Do not convert a failed gate into a small deduction.

Weight the remaining fit

These weights are a starting model, not a benchmark. Approve any change before scoring begins, and keep commercial terms out of the capability score.

Run scripted tests on your own contracts

Use real contracts, including the difficult ones. Require the proposed implementation team to perform each step in a configured environment and export the evidence.

1. Multi-obligation contract: load one contract holding two performance obligations with different measures of progress, and prove revenue is measured separately for each.
2. Cost-to-cost exclusion: charge a rework cost caused by internal inefficiency, exclude it from the progress measure while keeping it in project cost, and show the audit trail.
3. Uninstalled materials: charge a significant third-party good the customer controls before the related service, and show revenue limited to that cost where policy requires it.
4. Retroactive rate change: correct a labor rate after posting and show the effect on cost, on billing and on the closed period.
5. Commitment lifecycle: raise, partially receive, change, then close an order early, and show remaining budget and residual commitment at each step.
6. Unpriced change order: approve a scope change with no agreed price, then show the effect on transaction price, progress and the estimate at completion.
7. Estimate revision into loss: revise the estimate at completion so the contract becomes loss-making, and show the provision, its period and who authorized it.
8. Contract balance output: produce contract asset, contract liability and retainage positions at a date from posted data, and reconcile them to the ledger.
9. Period control: submit a timesheet and an invoice against a closed period, then reopen and reclose, and show what evidence remains.
10. Full evidence export: export the complete project record with stable identifiers, versions, approvals and timestamps, then reload it independently.

Score observed evidence rather than presentation quality, and record each result as pass, conditional pass, fail or not tested. A conditional pass needs a named dependency, owner, cost and date.

Make the approval decision

Approve a product when every mandatory gate passes, the scripted tests produce exportable evidence, each project object has one owning system, the progress measure can be adjusted and defended independently of the billing schedule, and the contract balances come out of posted data. Reject or reshape the design when the candidate cannot separate billing from revenue, cannot hold a change order approved in scope but not in price, or cannot reconcile its project reporting to the ledger without a spreadsheet in the middle.

The selection record should name the owning system for each project object, the revenue method chosen for each contract type and why, the tests that passed conditionally with an owner and a date, and the evidence finance will review before the first contract is billed from the new system in production.