Fixed-Price Estimates and Revenue Recognition in D365: Cost to Complete for ETO Projects

I ended the ETO projects article with a promise: the money side. Fixed-price estimates, revenue recognition, and the cost to complete number that drives what the customer, the auditor, and your own management see. This is the point in an engineer-to-order implementation where the supply chain consultant and the finance consultant have to sit at the same table, and the part most often configured on autopilot and regretted at the first year-end audit.

WHY FIXED-PRICE CHANGES THE QUESTION

On a time-and-material project the accounting is almost trivial: cost goes in, you bill it with a margin, and revenue follows the invoice. Fixed-price work breaks that link. The customer pays agreed milestones on agreed dates, and those dates have very little to do with how much of the job you have actually done. If you recognised revenue whenever you invoiced, the P&L would show a spectacular month every time a milestone lands and ugly losses in between. So the real accounting question becomes: how complete is this job, defensibly, right now? Everything below is machinery for answering that question every period and posting the result.

THE BUILDING BLOCKS

Five pieces of setup decide how the whole process behaves, and all of them exist before the first estimate is posted.

• The project forecast. Hours, items, expenses, and fees forecast against the project, held in a dedicated forecast model. This is the denominator of everything: total expected cost and total contract value. If the forecast is fiction, every number downstream is fiction too.

• The revenue recognition method. The project group decides whether the project runs on completed percentage (revenue recognised progressively as the job advances) or completed contract (everything held as WIP and recognised at the end). For long ETO jobs, completed percentage is usually the only method that gives management a usable monthly P&L.

• The estimate project. A fixed-price project carries an attached estimate project, which is where completion is calculated and estimates are posted. Several fixed-price projects can share one estimate project when they are commercially one deliverable and should be assessed together.

• The cost template. The most underrated object in the module. It groups project cost lines and decides two things: which cost categories count toward completion, and whether the completion percentage is calculated automatically from cost or entered manually. Almost every revenue distortion I have been asked to diagnose traces back to this object.

• The period code. How often estimates run. Monthly, aligned with the financial close, is the sensible default.

COST TO COMPLETE: THE NUMBER EVERYTHING HANGS ON

The completion percentage in a cost-based setup is a simple ratio: actual cost to date divided by total expected cost, where total expected cost is actual cost plus cost to complete. Actual cost is a fact; cost to complete is a judgement, and that judgement is the single most important number in fixed-price accounting. Dynamics gives you several ways to derive it when you create an estimate: take the remaining forecast (total forecast minus actuals), carry the previous estimate forward and adjust it line by line, or set it to zero for the final estimate. Whichever method you choose, the discipline matters more than the option: cost to complete must be re-examined every period by someone who actually knows the state of the job, not rolled forward mechanically from the original bid.

ETO adds a specific trap here. Engineered jobs are usually material-heavy, and the big material receipts land early. If material categories count toward completion, the arrival of the main steel or the long-lead drives can push calculated completion to 40 or 50 percent while engineering will tell you the job has barely started. The fix lives in the cost template: exclude or separate long-lead material lines from the completion basis, drive completion from hours only, or switch to manual completion based on assessed physical progress. This is the project-world cousin of the timing discipline I described for standard cost recalculations: the numbers are only as good as the moment you choose to measure them.

THE ESTIMATE CYCLE IN PRACTICE

A healthy month looks like this. Actuals post through the period as production consumes material and reports hours, on project-linked production orders as described in the ETO article. Before close, the project manager updates the forecast so cost to complete reflects reality, including any engineering changes that landed mid-month. You create the estimate, and the system calculates completion and the revenue to accrue. Then you review it: completion against last period, margin against the bid, and anything moving more than a few points gets explained before it gets posted. Posting recognises the period revenue as accrued revenue and holds the corresponding balances as WIP. If something was wrong, you reverse the estimate, fix the forecast or the transactions, and run it again; reversal is routine maintenance, not an admission of failure.

BILLING IS NOT REVENUE

Meanwhile, invoicing runs on its own track. The milestone schedule lives as on-account transactions on the project contract, and you invoice them when the contract says so. Posting an on-account invoice does not touch revenue in a completed percentage setup; it accumulates as invoiced on-account, a balance sheet position that says the customer has paid for more (or less) of the job than you have recognised. The gap between the two tracks is normal and informative: invoiced ahead of recognition means the customer is funding the job; recognised ahead of invoicing means you are. What is not normal is treating the two tracks as the same thing.

ELIMINATION: CLOSING THE LOOP

When the job is done (delivered, accepted, no further cost expected) you run the final estimate with cost to complete set to zero and completion at 100 percent, and then eliminate. Elimination clears the WIP and accrued positions and settles everything to the profit and loss accounts; under completed contract this is the moment all revenue and cost appear at once. Two practical notes. First, decide before go-live what 100 percent means for your business: ETO contracts often carry retention, warranty, and commissioning obligations, and the setup should be explicit about whether those sit inside the project or outside it. Second, do not let finished projects sit un-eliminated. The balance sheet quietly fills with stale WIP, and the eventual cleanup is always more painful than the monthly discipline would have been. If a late cost arrives after elimination (warranty rework is the classic), you can reverse the elimination, post the cost, and eliminate again.

WHAT GOES WRONG

• Cost to complete rolled forward from the bid. Completion creeps past 100 percent, revenue gets clawed back at the end, and the margin collapse surprises everyone except the project manager.

• Material in the completion basis. Front-loaded revenue on every material-heavy job, then a long flat stretch where work happens and revenue does not. Fix the cost template.

• Manual completion without governance. Manual percentages are legitimate, but without a documented basis they become a smoothing instrument, and auditors are very good at noticing smoothing instruments.

• Skipped periods. Estimates run quarterly to save effort, then a catch-up estimate moves the P&L violently and nobody trusts the reporting again.

• Time-and-material thinking on fixed-price jobs. A fully invoiced project can still be a loss-making one; only estimate-versus-actual tells you which it is.

TAKEAWAYS

Fixed-price revenue recognition in Dynamics is not exotic. It is a small set of objects (forecast, estimate project, cost template, period code) wrapped around one judgement, cost to complete, exercised on a fixed rhythm. Configure the cost template so completion reflects physical progress rather than purchasing timing, keep the forecast alive as scope moves, post estimates every period, keep billing and recognition mentally separate, and eliminate promptly when the job is done. Do that, and the project P&L becomes something management can steer by, instead of a number that lurches at every milestone.

Next time I will look at cycle counting in D365 Advanced Warehouse Management: counting policies and thresholds, scheduled count plans, count work on the mobile device, and how to keep inventory accuracy high without shutting the warehouse down to do it.

In this series: previous article Using the Projects Module for ETO in D365: Projects, Planning, and Production