Project Estimates and Revenue Recognition for Fixed-Price ETO Work in D365
In my last article on engineer-to-order I ended on a promise: the money side of a fixed-price ETO job, how the estimate and revenue recognition actually behave in Dynamics 365. This is that article, and it builds directly on using the Projects module for ETO. If the project is the spine of an ETO job, then the estimate is its nervous system. It is the number every status meeting circles back to, and it is what decides how much revenue and profit the job is allowed to show before a single unit has shipped.
WHY FIXED-PRICE NEEDS AN ESTIMATE, NOT JUST A FORECAST
A time-and-material project is simple to account for: you bill cost (plus margin) as it lands, and revenue follows invoicing. A fixed-price project cannot work that way, because the price is agreed up front and the cost arrives unevenly over months. If you let revenue track invoicing on a fixed-price ETO job, your profit lurches around with milestone billing dates and tells you nothing about how the job is really doing. The answer Dynamics gives you is the estimate: a periodic process that looks at how much cost has been incurred against the total expected cost, works out how complete the job is, and recognises revenue and work in process (WIP) accordingly. Estimates are a feature of fixed-price and investment projects specifically; a time-and-material project does not use them.
THE FORECAST IS NOT THE ESTIMATE
These two words get used interchangeably on the floor, and that causes real confusion, so it is worth being precise. The forecast is what you build before and during the job: forecast lines for hours, items, expenses, and fees that represent what you expect to spend and bill. It is your bid model and your baseline. The estimate is the period-end accounting process that consumes actuals and a cost-to-complete figure to produce recognition entries. The forecast feeds the estimate (it is one source of the total cost figure), but they are not the same object. You can have a perfectly good forecast and still get recognition wrong if the estimate process is set up badly, and vice versa.
BUILDING A CREDIBLE FORECAST
Everything downstream leans on the total estimated cost being believable, so this is where the care belongs. A few things I always check:
• Forecast by category, not in a lump. Separate hours, items, expenses, and subcontracted services so that when one line drifts you can see which one. A single blended number hides the problem until close.
• Tie the item and hour forecast to the engineered BOM and route once engineering has produced them. Before engineering is finished you are working with a rough order-of-magnitude figure, and that is fine, but flag it as such and tighten it the moment the structure firms up.
• Include the fees and the expenses that are easy to forget: freight, commissioning, travel, warranty provisions. On long ETO jobs these are not rounding errors.
• Keep a contingency line that is visible and owned, rather than padding every category quietly. Hidden padding makes the cost-to-complete impossible to reason about later.
HOW RECOGNITION ACTUALLY WORKS: THE COST-TO-COST METHOD
The most common completion method for ETO is completed percentage using cost-to-cost. The logic is straightforward once you see it. The system takes the actual cost posted to the project to date and divides it by the estimated total cost (the actual plus the cost still to complete). That ratio is the percent complete. It then multiplies the percent complete by the contract value to get the revenue that should be recognised to date, and the difference between that and what has already been recognised becomes this period's entry. Cost follows the same logic into WIP and out of it. The contract value is fixed, so the lever that moves recognised revenue each period is the percent complete, and the percent complete is driven entirely by cost. That is the whole reason cost-to-complete matters so much: it is not a side calculation, it is the thing steering the profit you report.
Dynamics also supports a completed-contract approach, where nothing is recognised until the job finishes and everything releases at the end. That is simpler and very conservative, but for a long ETO job it means months of a flat zero followed by a single large swing, which most finance teams dislike because it tells them nothing in the interim. Cost-to-cost gives a smoother, more honest picture provided the estimate is maintained.
POSTING AND ADJUSTING ESTIMATES
The estimate is run as a periodic process, normally at each period end. When you post an estimate, Dynamics calculates the recognition entries and posts the accrued revenue and WIP. A key behaviour to understand is reversal: estimates are typically posted and then reversed at the start of the next period, so that the following period re-estimates from fresh actuals rather than stacking entries on top of each other. This is what keeps the running recognition from double counting. Only the final elimination at project close clears WIP into profit and loss for good.
Adjusting is where judgement comes in. The default cost-to-complete is simply the total estimated cost minus actuals, which assumes your original total is still right. It rarely stays right on an ETO job. When you know the remaining work will cost more or less than the linear roll-up suggests, override the cost-to-complete per category. The moment you do that, the percent complete shifts, and recognition shifts with it. This is the correct behaviour: it is how the system reflects new reality. The discipline is to update the remaining estimate as soon as you know, not at close, because the alternative is taking profit you have not earned and then giving it back in an ugly final period.
WHAT THE CUSTOMER SEES VERSUS WHAT FINANCE SEES
This is the distinction that trips up the most people, so I want to be explicit. Billing and recognition are two separate timelines on a fixed-price project. The customer sees invoices raised against the contract, usually on-account milestone invoices: a deposit, progress billings, a retention release at the end. Those are governed by the contract billing schedule and have nothing directly to do with the percent complete. Recognition, on the other hand, is what the estimate process produces internally. The gap between the two is exactly what WIP and accrued revenue (or deferred revenue, when billing runs ahead of work) are there to hold. So you can be sixty percent complete by cost while having invoiced only a thirty percent deposit, and the balance sheet carries the difference. Confusing these two is the single most common source of "why does this project look unprofitable when we have billed most of it" conversations.
Note too that this is a different costing world from the standard-cost manufacturing I covered in timing cost recalculations around revision cutovers. There the costing object is the item and its frozen standard; here the costing object is the project and its estimate. The same revision can affect both, but the question you ask is different: not "what is the unit variance" but "does this change my cost-to-complete".
WHERE IT GOES WRONG
• Treating billing as recognition. If milestone invoices drive your profit view, the numbers will mislead. Let the estimate drive recognition and let billing follow the contract independently.
• A stale cost-to-complete. Leaving the remaining estimate on autopilot means you take profit too early when the job is running hot, then surrender it in a brutal final period. Re-estimate every period.
• Missing a foreseeable loss. The moment the total estimated cost exceeds the contract value, the whole expected loss is recognised immediately, not spread across remaining periods. Do not let a known loss sit hidden in an optimistic estimate.
• Wrong completion method for the deal. Completed-contract on a year-long job starves finance of information; cost-to-cost on a job with an unreliable estimate produces noise. Match the method to how trustworthy your estimate really is.
TAKEAWAYS
Revenue recognition on a fixed-price ETO project is not an accounting afterthought bolted onto the build; it is the same project, viewed through cost. Build the forecast by category and tie it to the engineered structure so the total cost is credible. Understand that cost-to-cost turns that cost into a percent complete and the percent into recognised revenue against a fixed contract value. Post the estimate each period, let it reverse, and above all keep the cost-to-complete honest, because that single number is what decides how much profit the job is allowed to show. Keep billing and recognition as separate timelines in your head, and the fixed-price ETO job stops being a black box and becomes something you can actually steer.
Next time I will look at subcontracting in D365 production: modelling an outside operation as a service on the route and BOM, the purchase order that sits behind it, and how to keep subcontract cost and lead time honest in planning.
In this series: previous article Using the Projects Module for ETO in D365: Projects, Planning, and Production
In my last article on engineer-to-order I ended on a promise: the money side of a fixed-price ETO job, how the estimate and revenue recognition actually behave in Dynamics 365. This is that article, and it builds directly on using the Projects module for ETO. If the project is the spine of an ETO job, then the estimate is its nervous system. It is the number every status meeting circles back to, and it is what decides how much revenue and profit the job is allowed to show before a single unit has shipped.
WHY FIXED-PRICE NEEDS AN ESTIMATE, NOT JUST A FORECAST
A time-and-material project is simple to account for: you bill cost (plus margin) as it lands, and revenue follows invoicing. A fixed-price project cannot work that way, because the price is agreed up front and the cost arrives unevenly over months. If you let revenue track invoicing on a fixed-price ETO job, your profit lurches around with milestone billing dates and tells you nothing about how the job is really doing. The answer Dynamics gives you is the estimate: a periodic process that looks at how much cost has been incurred against the total expected cost, works out how complete the job is, and recognises revenue and work in process (WIP) accordingly. Estimates are a feature of fixed-price and investment projects specifically; a time-and-material project does not use them.
THE FORECAST IS NOT THE ESTIMATE
These two words get used interchangeably on the floor, and that causes real confusion, so it is worth being precise. The forecast is what you build before and during the job: forecast lines for hours, items, expenses, and fees that represent what you expect to spend and bill. It is your bid model and your baseline. The estimate is the period-end accounting process that consumes actuals and a cost-to-complete figure to produce recognition entries. The forecast feeds the estimate (it is one source of the total cost figure), but they are not the same object. You can have a perfectly good forecast and still get recognition wrong if the estimate process is set up badly, and vice versa.
BUILDING A CREDIBLE FORECAST
Everything downstream leans on the total estimated cost being believable, so this is where the care belongs. A few things I always check:
• Forecast by category, not in a lump. Separate hours, items, expenses, and subcontracted services so that when one line drifts you can see which one. A single blended number hides the problem until close.
• Tie the item and hour forecast to the engineered BOM and route once engineering has produced them. Before engineering is finished you are working with a rough order-of-magnitude figure, and that is fine, but flag it as such and tighten it the moment the structure firms up.
• Include the fees and the expenses that are easy to forget: freight, commissioning, travel, warranty provisions. On long ETO jobs these are not rounding errors.
• Keep a contingency line that is visible and owned, rather than padding every category quietly. Hidden padding makes the cost-to-complete impossible to reason about later.
HOW RECOGNITION ACTUALLY WORKS: THE COST-TO-COST METHOD
The most common completion method for ETO is completed percentage using cost-to-cost. The logic is straightforward once you see it. The system takes the actual cost posted to the project to date and divides it by the estimated total cost (the actual plus the cost still to complete). That ratio is the percent complete. It then multiplies the percent complete by the contract value to get the revenue that should be recognised to date, and the difference between that and what has already been recognised becomes this period's entry. Cost follows the same logic into WIP and out of it. The contract value is fixed, so the lever that moves recognised revenue each period is the percent complete, and the percent complete is driven entirely by cost. That is the whole reason cost-to-complete matters so much: it is not a side calculation, it is the thing steering the profit you report.
Dynamics also supports a completed-contract approach, where nothing is recognised until the job finishes and everything releases at the end. That is simpler and very conservative, but for a long ETO job it means months of a flat zero followed by a single large swing, which most finance teams dislike because it tells them nothing in the interim. Cost-to-cost gives a smoother, more honest picture provided the estimate is maintained.
POSTING AND ADJUSTING ESTIMATES
The estimate is run as a periodic process, normally at each period end. When you post an estimate, Dynamics calculates the recognition entries and posts the accrued revenue and WIP. A key behaviour to understand is reversal: estimates are typically posted and then reversed at the start of the next period, so that the following period re-estimates from fresh actuals rather than stacking entries on top of each other. This is what keeps the running recognition from double counting. Only the final elimination at project close clears WIP into profit and loss for good.
Adjusting is where judgement comes in. The default cost-to-complete is simply the total estimated cost minus actuals, which assumes your original total is still right. It rarely stays right on an ETO job. When you know the remaining work will cost more or less than the linear roll-up suggests, override the cost-to-complete per category. The moment you do that, the percent complete shifts, and recognition shifts with it. This is the correct behaviour: it is how the system reflects new reality. The discipline is to update the remaining estimate as soon as you know, not at close, because the alternative is taking profit you have not earned and then giving it back in an ugly final period.
WHAT THE CUSTOMER SEES VERSUS WHAT FINANCE SEES
This is the distinction that trips up the most people, so I want to be explicit. Billing and recognition are two separate timelines on a fixed-price project. The customer sees invoices raised against the contract, usually on-account milestone invoices: a deposit, progress billings, a retention release at the end. Those are governed by the contract billing schedule and have nothing directly to do with the percent complete. Recognition, on the other hand, is what the estimate process produces internally. The gap between the two is exactly what WIP and accrued revenue (or deferred revenue, when billing runs ahead of work) are there to hold. So you can be sixty percent complete by cost while having invoiced only a thirty percent deposit, and the balance sheet carries the difference. Confusing these two is the single most common source of "why does this project look unprofitable when we have billed most of it" conversations.
Note too that this is a different costing world from the standard-cost manufacturing I covered in timing cost recalculations around revision cutovers. There the costing object is the item and its frozen standard; here the costing object is the project and its estimate. The same revision can affect both, but the question you ask is different: not "what is the unit variance" but "does this change my cost-to-complete".
WHERE IT GOES WRONG
• Treating billing as recognition. If milestone invoices drive your profit view, the numbers will mislead. Let the estimate drive recognition and let billing follow the contract independently.
• A stale cost-to-complete. Leaving the remaining estimate on autopilot means you take profit too early when the job is running hot, then surrender it in a brutal final period. Re-estimate every period.
• Missing a foreseeable loss. The moment the total estimated cost exceeds the contract value, the whole expected loss is recognised immediately, not spread across remaining periods. Do not let a known loss sit hidden in an optimistic estimate.
• Wrong completion method for the deal. Completed-contract on a year-long job starves finance of information; cost-to-cost on a job with an unreliable estimate produces noise. Match the method to how trustworthy your estimate really is.
TAKEAWAYS
Revenue recognition on a fixed-price ETO project is not an accounting afterthought bolted onto the build; it is the same project, viewed through cost. Build the forecast by category and tie it to the engineered structure so the total cost is credible. Understand that cost-to-cost turns that cost into a percent complete and the percent into recognised revenue against a fixed contract value. Post the estimate each period, let it reverse, and above all keep the cost-to-complete honest, because that single number is what decides how much profit the job is allowed to show. Keep billing and recognition as separate timelines in your head, and the fixed-price ETO job stops being a black box and becomes something you can actually steer.
Next time I will look at subcontracting in D365 production: modelling an outside operation as a service on the route and BOM, the purchase order that sits behind it, and how to keep subcontract cost and lead time honest in planning.
In this series: previous article Using the Projects Module for ETO in D365: Projects, Planning, and Production
No replies yet. Be the first to respond!