Revenue recognition for services firms on Dynamics 365

Services firms recognise revenue as work is performed, not when the invoice goes out. Under IFRS 15 and ASC 606 that principle is formal: identify the performance obligations, allocate the transaction price, and recognise as each obligation is satisfied — over time for most services. Dynamics 365 supports this well or barely depending on which product and which deployment mode a firm is on, and that choice is often made by the delivery team before finance has seen it. This guide sets out what each option actually does.

The three contract shapes

Time and materials. Revenue equals approved hours times the contract rate. Recognition follows delivery; the only timing question is whether to accrue revenue on approved-but-uninvoiced time at period end.

Fixed price. The firm commits to an outcome for a price. Revenue is recognised over time by progress — percentage of completion based on cost or hours — or, less often, at milestones. This is where systems differ most.

Retainers and subscriptions. A fixed fee per period for a capacity or a service. Recognised evenly over the period regardless of hours delivered, with deferred revenue for advance billing.

Most firms have all three, often on the same client.

Project Operations: it depends on the deployment

Lite deployment (Dataverse only, with a separate accounting system) manages contracts, time, expense, and invoicing. It does not do revenue recognition. Invoices are the only financial output, so a fixed-price project billed at three milestones shows three lumps of revenue in whatever ledger the invoices land in. Firms on Lite that need over-time recognition do it in the accounting system or in a spreadsheet from Project Operations' actuals. That is workable for a small firm with mostly T&M work and unacceptable for one with material fixed-price revenue and an auditor.

Project Operations with Finance and Operations (the resource-based and stocked deployments) posts actuals into the F&O project accounting module, and that is where recognition lives:

• T&M: revenue accrues when time and expense post, on the accrue-revenue setting of the project group, and reverses when the invoice posts. Unbilled revenue sits on the balance sheet between the two. Works out of the box.
• Fixed price: the project uses an estimate project with a completion method — completed contract or percentage of completion, with the percentage derived from cost or from a manually entered completion. Period-end estimate runs post revenue, WIP, and cost of sales. This is the real percentage-of-completion engine and it is capable, but it needs finance to configure cost templates, define which cost lines count as progress, and run the estimates as part of close.
• Retainers: modelled as fixed-price with on-account billing, or increasingly through F&O's subscription billing feature, which handles deferrals and recurring invoices and is Microsoft's direction after the older revenue recognition feature was marked for deprecation.

The deployment types guide covers the choice; the recognition requirement should be one of the inputs to it, and often is not.

Business Central

Business Central's projects (formerly jobs) have WIP methods per project: cost value, sales value, cost of sales, percentage of completion, and completed contract. The WIP calculation batch posts the accounting entries at period end. It is a proper over-time recognition mechanism for an SMB firm and the WIP and recognition for jobs guide walks it. Its limits: one method per project, progress driven by cost or a manually entered percentage, and no concept of performance obligations below the project. Firms whose contracts bundle several obligations at different progress rates split them into separate projects or tasks with separate WIP treatment.

What the standards change about contract design

IFRS 15 and ASC 606 are usually treated as an accounting problem. In Dynamics 365 they are a data-model problem, because recognition is driven by the structure of the contract lines.

• One performance obligation per contract line. In Project Operations, the contract line is the unit that carries billing method, price, and the mapping to project tasks. A fixed-price line covering two deliverables with different completion profiles cannot be recognised correctly; split it.
• Allocation of discounts. A bundled discount must be allocated across obligations. Neither Project Operations nor BC allocates automatically across lines; the allocation is done when the contract is priced and entered per line.
• Variable consideration — success fees, penalties — has no first-class home. Treat it as a separate line with its own recognition treatment, or hold it outside the system until it is probable.
• Contract modifications are the hard case. A change order that adds scope to an existing fixed-price line changes the percentage of completion retrospectively. Project Operations handles it through the contract line's revised value and the estimate project picking up the new total; it does not restate prior periods, which is usually correct under the standard but needs finance to be looking.

Month-end sequence

For firms on Project Operations with F&O, the close order that avoids rework: approve all time and expense, post them to F&O, run project invoicing, run the estimate process for fixed-price projects, review WIP and unbilled revenue by project, then close the period. Running estimates before all time is posted understates progress and creates a correction next month.

For BC firms: post all project journals, run WIP calculation, review, post WIP to GL, close.

What needs a partner or a spreadsheet

Multi-element arrangement allocation with standalone selling prices, automated contract modification accounting, and disclosures such as remaining performance obligations are not in any Dynamics 365 product for services contracts. Larger firms use a revenue-management ISV or handle it in the consolidation layer. Smaller firms keep a schedule. Either way, the decision to do fixed-price work at scale is a decision to run the estimate process properly, and firms that skip it discover the gap at their first audit rather than their first month-end.