Start free
September 24, 202622 min read

Engineering Project Accounting: 3 Moves to Secure WIP and ASC 606

Engineer reviewing project costs at construction site

Engineering project accounting is job-level accounting that ties field activity, costs, and billings to each project so firms can recognize revenue correctly and manage profitability while the work is still happening, not three months after it ships. The immediate payoff is a defensible work-in-progress (WIP) schedule, revenue recognition that satisfies ASC 606, and job profitability numbers you can act on before a project bleeds margin. Getting there starts with three moves: structured job costing, a real WIP process, and cost-code discipline that survives contact with the field.

TL;DR:

  • Effective engineering project accounting requires accurate job costing, real-time WIP reporting, and disciplined cost-code management aligned with the project structure.
  • Connecting field time, payroll, and job costs into one system minimizes manual reconciliation errors and provides up-to-date financial performance data.
  • Proper management of scope changes with timestamped approval records prevents underreporting work-in-progress and reduces dispute risks.
  • Monitoring five key reports—job cost, profitability, WIP schedule, estimates vs actuals, and cash flow—enables proactive project management and early problem detection.
  • Implementing a phased rollout with parallel testing ensures data integrity and user adoption without disrupting active projects.
Designflow-build
Bring Project Accounting Together
DesignFlow Build combines project management, accounting, and field operations to reduce manual work and improve construction project visibility.
Explore DesignFlow Build

Table of Contents

What Engineering Project Accounting Actually Covers

Standard enterprise accounting answers one question: is the company profitable this quarter? Engineering project accounting answers a harder one: is this specific job profitable right now, and will it still be profitable at closeout? That distinction drives everything else in this guide.

Construction and engineering accounting is fundamentally a project-based financial system built to measure profitability, risk, and cost performance at the individual contract level, not just at the company level, according to a complete guide to construction accounting. A general ledger tells you total revenue and total expenses. A job-level system tells you which of your 40 active projects are quietly losing money while the other 39 mask the problem.

Engineering firms need this because their financial structure looks nothing like a retail or SaaS business. A few specifics that make project accounting non-negotiable rather than optional:

Standard charts of accounts do not capture retainage, job costing, or progress billing in a way that supports real cost control, and construction and engineering accounting requires its own specialized categories to do the job properly, according to guidance from the basics of construction accounting. Project accounting isn’t a reporting layer bolted onto your GL. It’s a parallel structure that PMs, controllers, and finance leads all feed and all rely on.

Job Costing: Cost Codes, Time Capture, and Data You Can Trust

Job costing only works if the cost structure underneath it is built correctly, and most firms get this wrong at the design stage, long before anyone opens accounting software.

Start with a work breakdown structure (WBS) that mirrors how your PMs actually think about the project (design phases, deliverables, disciplines), then map it to a cost breakdown structure (CBS) that finance can roll up into consistent reports. AACEi’s recommended practices call for aligning the CBS with the WBS and standardizing cost coding across projects so allocation and reporting stay accurate as jobs scale, per TCM Framework guidance. Skip this step and you’ll spend years reconciling inconsistent cost codes across projects that should be directly comparable.

A workable setup follows this sequence:

  1. Define cost code categories at the discipline or phase level (civil, structural, electrical, permitting) rather than the task level, which gets too granular to maintain.
  2. Standardize the code set across all active projects so a “design review” hour means the same thing on Job 104 as it does on Job 212.
  3. Integrate time capture with payroll so field and office hours flow into job costs automatically, instead of getting keyed in twice by two different people.
  4. Route procurement and subconsultant invoices through the same cost code structure, not a separate expense system that never talks to job cost.
  5. Reconcile weekly, not monthly, so a mis-coded expense gets caught while the paper trail is still fresh.

The most common failure point is disconnected time capture. When engineers log hours in one system and payroll runs in another, someone has to manually match the two, and that’s where cost codes drift, hours go missing, and job cost reports quietly become fiction. A reliable job costing process closes that gap by tying time entry directly to the cost code at the point of entry, not after the fact.

Linking job costing, payroll, and project management into one flow keeps financial performance current and cuts the manual reconciliation that plagues siloed systems, according to research on project-based accounting.

Pro Tip: Audit your cost code list once a quarter and retire any code that hasn’t been used in 90 days. A bloated code list is the number one reason field staff mis-code time, because nobody can find the right code fast enough to bother.

How WIP Reporting and ASC 606 Work Together

Work-in-progress reporting exists to answer one question at any point in the project: have you billed more than you’ve earned, or earned more than you’ve billed? Get this wrong and you either overstate revenue on paper or starve the project of cash it’s actually owed.

The math runs through a four-step chain that most controllers can do in a spreadsheet once they understand the logic: calculate the estimate at completion (EAC), divide costs to date by EAC to get percent complete, multiply percent complete by contract value to get earned revenue, then compare earned revenue to what’s actually been billed to find over-billing or under-billing, per the percentage-of-completion method breakdown.

Four-step WIP revenue calculation process

ASC 606 governs how that earned revenue gets recognized, and it applies a five-step model: identify the contract, identify performance obligations, determine the transaction price, allocate the price to each obligation, and recognize revenue as those obligations are satisfied. For engineering contracts, revenue is typically recognized over time, and input measures like cost-to-cost are the most common way firms measure progress toward completion, according to ASC 606 guidance for professional services firms.

The governance question that trips up most firms is simple to state and hard to enforce: who owns the cost-to-complete number? Cost-to-complete is the one subjective input in the entire calculation, and it needs to be timestamped, justified, and owned by the project manager every single reporting cycle to keep the WIP schedule auditable.

That change order question deserves its own scrutiny. Contractors should document performance obligations carefully and stay cautious about how they classify change orders, because misclassifying them as part of the base contract rather than a distinct obligation skews the revenue recognition math for the whole project, per guidance on contract modifications under ASC 606. A construction revenue recognition breakdown walks through how integrated systems reduce the manual WIP burden that causes most of these errors.

The Reports and KPIs That Actually Drive Decisions

Five reports carry the weight of engineering project accounting, and each one answers a different question. Run all five and you’ll catch a losing job months before it shows up in your quarterly numbers.

The value of these job-level reports over a company-wide P&L is speed. Specialized project accounting surfaces project-level profit drivers early enough to take corrective action, while enterprise financials alone tend to reveal problems only after they’ve compounded, according to the complete guide to construction accounting.

Set red-flag thresholds so variance triggers action instead of getting buried in a spreadsheet tab nobody opens. A cost variance beyond 10% on any major cost code should trigger a PM review that same week. A live job cost dashboard makes these thresholds visible daily instead of monthly, which is the difference between catching a problem and explaining one.

Month-End Close: Turning Project Data Into Numbers You’d Defend

A clean month-end close on project financials is a process, not an event, and it starts well before the books actually close.

  1. Reconcile job costs against the GL first, catching any expense that landed in the wrong cost code or the wrong project entirely.
  2. Collect cost-to-complete updates from every PM with active jobs, and require a brief written justification for any estimate that moved more than 5% from last cycle.
  3. Update the change-order log, confirming every approved change is reflected in contract value and every pending one is flagged as not-yet-recognized.
  4. Reconcile billings against earned revenue to update the WIP schedule and catch over-billing before it becomes a cash problem at contract closeout.
  5. Review retainage balances separately from AR, since retainage collected late can make a healthy job look cash-strapped on paper.
  6. Sign off by role: PM certifies cost-to-complete, accounting certifies costs-to-date, and finance leadership certifies the final WIP schedule before it goes to ownership or a lender.

Documentation matters as much as the numbers themselves. A lender or surety reviewing your WIP schedule wants to see who approved each cost-to-complete estimate and when, not just the final figure. Keeping that audit trail intact is what turns a WIP schedule from an internal guess into a document sureties will actually trust. Assign every close task to a named role, not a department, or you’ll spend the first week of every month figuring out who owns what.

Software That Removes the Manual Reconciliation Problem

Most engineering firms don’t fail at project accounting because the concepts are hard. They fail because the data lives in five disconnected places: a scheduling tool, a payroll system, an expense app, a project management platform, and a spreadsheet someone built in 2019 that nobody wants to touch.

The features that actually matter when evaluating a system:

The integration flow that matters most runs field time through payroll into job cost and out to billing, all without a human re-typing the same number four times. Linking job costing, project management, payroll, and subcontractor management lets financial performance update in near real time and cuts the manual reconciliation that eats a controller’s week, according to research on project-based accounting systems.

When evaluating any system, vendor-agnostic, judge it against three questions: does it capture cost-to-complete input from PMs directly, does it produce an auditable WIP schedule without a spreadsheet export, and does it integrate time capture with payroll without a manual bridge. If your current setup requires someone to reconcile three systems by hand every month, you’ve outgrown spreadsheets, and real-time budget tracking is worth evaluating before your next fiscal year starts.

Rolling Out Project Accounting Without Disrupting Active Jobs

Implementation fails most often when firms try to fix everything at once, mid-project, across every active job simultaneously. A phased approach works better.

  1. Map your WBS to a clean CBS before touching any software, and retire duplicate or unused cost codes during this step, not after go-live.
  2. Assign a named owner for cost code governance so the structure doesn’t drift the moment the rollout team moves on to the next thing.
  3. Pilot with two or three projects, not your whole portfolio, and run the new WIP schedule in parallel with your existing process to compare results before you trust the new numbers.
  4. Reconcile the pilot’s WIP output against the old method line by line, and resolve every discrepancy before expanding.
  5. Train PMs on cost-to-complete discipline specifically, since that’s the input most likely to be rushed or copied from last month without real justification.
  6. Track adoption and reconciliation time as your rollout metric, not just whether the software is technically live.

Piloting with two to three projects and running parallel WIP schedules before full rollout is standard practice for measuring adoption and catching reconciliation gaps early, per implementation guidance from Miter. Firms that skip the parallel run almost always discover a systemic cost-code error three months in, after it has already touched a dozen reports.

Pro Tip: Give your pilot PMs a one-page cheat sheet mapping old cost codes to new ones. The single biggest adoption killer is a PM who can’t find the code they used to use and just picks the closest-sounding one instead.

How DesignFlow Build Approaches Project Accounting

The gap between “we track job costs” and “we trust our WIP schedule” is almost always a data problem, not an accounting problem. Field time gets keyed into one system, payroll runs in another, and job cost sits in a spreadsheet that’s already stale by the time anyone opens it.

DesignFlow Build connects field operations, project management, and accounting, including job costing by cost code, WIP, and certified payroll, into one system so the reconciliation gap between departments shrinks on its own instead of requiring a controller to chase it down every month. That structure matters most at month-end, when accounting needs current costs-to-date and PMs need to supply a defensible cost-to-complete: a single system of record means both sides are looking at the same numbers instead of two versions that need to be argued into agreement.

Implementation runs in 2 to 4 weeks, according to DesignFlow Build’s own figures, fast enough that a firm can pilot it on a handful of active jobs without disrupting the rest of the portfolio, following the same parallel-run approach recommended earlier in this guide.

Where Engineering Project Accounting Breaks: Scope Changes and Disputes

Scope changes are where project accounting takes the most damage, and not because the math is hard. It’s because the paperwork lags the work.

An engineer starts revised calculations on client verbal approval, weeks before a signed change order exists. By the time the change order gets executed, costs have already accrued against a scope that doesn’t officially exist yet in the accounting system. That gap creates two problems: the job cost report understates the true scope of work performed, and if a dispute arises later, there’s no clean paper trail connecting cost to authorization.

Disputes tend to concentrate around three points: whether a change was in scope or out of scope, whether the client approved cost impact or just schedule impact, and whether retainage release conditions were actually met at the milestone claimed. Each of these gets resolved faster, and more favorably, when the accounting system has timestamped documentation rather than an email thread scattered across three inboxes.

The practical fix is procedural, not accounting theory: require a change order log that captures verbal approval, written approval, and cost impact as three separate timestamped events, even when they happen the same week. Firms that wait for the fully executed change order before logging any cost impact almost always underreport work-in-progress on the jobs where change orders are common, which is most engineering work involving field conditions, permitting delays, or client-driven design revisions.

Where Project Accounting Meets Earned Value Management

Earned value management (EVM) and project accounting ask overlapping but distinct questions, and firms that run both together get a sharper read on project health than either one delivers alone.

EVM compares planned value, earned value, and actual cost to calculate schedule and cost performance indices. Project accounting calculates percent complete and earned revenue for financial reporting. The two share an input, costs to date, but they serve different audiences: EVM tells a project manager whether the job is on schedule and on budget from an operational standpoint; the WIP schedule tells finance and ownership whether the job is on track from a revenue and cash standpoint.

Where they genuinely reinforce each other is in the cost-to-complete estimate. A PM running disciplined EVM has a schedule performance index and cost performance index that either support or contradict the cost-to-complete number they’re handing accounting for the WIP schedule that cycle. If EVM shows a cost performance index sliding below 1.0 but the PM’s cost-to-complete estimate hasn’t moved, that’s a signal worth questioning before the WIP schedule goes out the door.

Firms that run EVM purely as a scheduling exercise, disconnected from the accounting cost-to-complete process, tend to end up with two competing narratives about the same job: one from the PM’s schedule tracker, one from finance’s WIP schedule. Reconciling those two views every cycle, rather than letting them diverge quietly, is what makes both tools worth running.

Compliance and Regulatory Pressure Points for Engineering Firms

Engineering firms carry compliance obligations that general contractors often don’t, and project accounting needs to reflect them directly in job cost structure, not as an afterthought.

Certified payroll is the most immediate one on public or federally funded work, where prevailing wage rules require detailed, auditable time and pay records tied to specific job codes and classifications. A job costing structure that doesn’t separate labor classifications cleanly makes certified payroll reporting a manual reconstruction project every pay period instead of a byproduct of normal time capture.

Professional liability exposure adds another layer. Engineering deliverables carry design liability that construction trades typically don’t, and firms often need to track costs related to errors-and-omissions reserves or claim-related work separately from standard project costs, since commingling them distorts both the job’s true profitability and the firm’s liability exposure reporting.

Licensing and stamping requirements vary by state and discipline, and multi-state engineering firms sometimes need to track which licensed professional of record is attached to which deliverable for compliance and audit purposes, a detail that belongs in project documentation even though it rarely touches the cost report directly. Revenue recognition itself sits inside a compliance framework too: ASC 606 isn’t optional guidance for firms with outside audits, bank covenants, or bonding requirements. Lenders and sureties reviewing WIP schedules expect the five-step model applied consistently, not adjusted project by project to make the numbers look better in a given quarter.

Common Scenarios: What Project Accounting Looks Like in Practice

A civil engineering firm running a lump-sum design contract identifies mid-project that its cost-to-complete estimate no longer reflects actual spending pace. The PM had been carrying forward the same number rather than reassessing it, a common shortcut when workloads are heavy. Once accounting flags the stale estimate and forces a fresh cost-to-complete review, the revised WIP schedule shows the job is over-billed relative to earned revenue, not under-billed as the stale numbers implied.

A MEP engineering firm working cost-plus on a hospital renovation processes a client-approved verbal change order for revised ductwork routing three weeks before the written change order is executed. Because the firm’s change order log captures verbal approval as a separate timestamped event, the cost impact shows up in that cycle’s WIP schedule as a pending, unrecognized obligation rather than disappearing into unassigned overhead. When the written change order finally clears, the revenue recognition catches up cleanly instead of requiring a retroactive correction.

A structural engineering firm running several small time-and-materials projects notices its estimates-vs-actuals report shows one specific cost code, structural analysis review, consistently running 25% over budget across four unrelated jobs. That pattern points to an estimating assumption problem, not a project execution problem, and the firm adjusts its bid template for that task type going forward rather than treating each overrun as an isolated incident.

What Firms Get Wrong About Project Accounting

Most engineering firms treat project accounting as a reporting function, something the controller produces after the work is done. That’s backwards, and it’s the single biggest reason WIP schedules turn out unreliable. The controller can only be as accurate as the cost-to-complete estimate a PM hands over, and PMs who aren’t held accountable for that number treat it as a rough guess rather than a real financial commitment.

The fix isn’t better software alone, though a construction ERP that ties field data to job cost removes a lot of the friction. The fix is treating PM cost-to-complete estimates with the same rigor as an auditor’s sign-off, because functionally, that’s what they are. Firms that get this right consolidate to one operational system of record and stop tolerating spreadsheets as a parallel truth. My recommendation for any firm starting this work: fix job-cost data quality first, align PM and accounting workflows second, and only then evaluate new software, because a clean system built on dirty data just produces dirty reports faster.

— Keith

Where DesignFlow Build Fits Into Your Project Accounting

If your firm is still stitching together job cost data from a scheduling tool, a payroll export, and a spreadsheet, DesignFlow Build replaces that patchwork with one system where field time, job costing, and WIP inputs update in the same place. That’s the specific job it solves: real-time cost-to-complete inputs from the field, job costing by cost code that maps to your existing WBS, and revenue recognition support built for the ASC 606 math this guide just walked through.

Designflow-build

Pricing runs on a per-seat model, with Pro-tier office seats at $100 per month and field seats priced separately for crews entering time and cost data on-site. If you want to see how job costing, WIP, and payroll actually connect in one system rather than three, the construction ERP overview is the place to start, or request a demo directly through the pricing page to walk through your current cost code structure with the team.

Sources

FAQ

What does project accounting actually do for an engineering firm?

Project accounting tracks costs, revenue, and profitability at the individual job level instead of just at the company level, giving finance leaders and PMs a real-time read on whether each project is actually making money. It produces the job cost reports, WIP schedules, and profitability data that a company-wide P&L can’t surface until much later.

Do you need a CPA to work as a project accountant?

No. Most project accountant roles at engineering and construction firms don’t require a CPA license, since the work centers on job costing, WIP schedules, and internal cost control rather than audited financial statement preparation. A CPA becomes more relevant for roles overseeing external audits, revenue recognition compliance under ASC 606, or bonding and lending relationships.

Can I work in project accounting with an engineering degree instead of an accounting degree?

Yes, and it’s fairly common. Engineering degree holders often move into project controls or project accounting roles because they already understand scope, change orders, and technical cost drivers, then pick up the accounting mechanics like WIP calculations and cost-to-cost methodology on the job.

Can a project accountant earn $500,000 a year?

That figure is far outside typical project accountant compensation, which centers on controller and senior finance leadership pay bands rather than entry or mid-level accounting roles. Earnings anywhere near that level would require a senior executive position, such as a CFO at a large firm, combined with equity or bonus structures, not a standalone project accounting title.

How is engineering project accounting different from standard accounting software?

Standard accounting software tracks revenue and expenses at the company level using a generic chart of accounts. Engineering project accounting requires job costing by cost code, WIP schedules with percent-complete calculations, and revenue recognition tied to performance obligations, features a platform like DesignFlow Build’s construction ERP builds in natively rather than bolting on.