Revenue Recognition for ASC 606 & IFRS 15

The problem

ASC 606 and IFRS 15 are straightforward when a contract is one product delivered on one date. They stop being straightforward the moment you sell a bundle: hardware plus a twelve-month service plan plus an implementation project plus a discount applied across the whole deal. Now you need standalone selling prices, a defensible allocation of the transaction price across each performance obligation, a deferral schedule per obligation with its own recognition trigger, and a way to handle what happens when the customer changes the contract in month seven.

The revenue recognition capability in Dynamics 365 Finance & Operations covers the simple end of this well. Where teams run out of road is bundled goods-and-services contracts, allocation across obligations that recognise on different bases, variable consideration, and contract modifications that require either prospective treatment or a cumulative catch-up. At that point revenue schedules migrate to a spreadsheet, and the spreadsheet becomes the thing auditors test — while the ledger holds a number that has to be reconciled back to it every quarter.

ECOSIRE builds the missing layer inside F&O so contract revenue, deferrals and recognition run on ledger data with the five-step model documented per contract.

What ECOSIRE builds

All code is delivered as X++ extensions in your own model and package. Nothing overlayers Microsoft models. The build is scoped to the contract shapes you actually sell, not to a generic superset.

Performance obligation model

New tables represent the contract and its performance obligations, linked to the originating sales order lines, project contract or subscription record. Each obligation carries its own recognition method — point in time on delivery, ratable over a service period, percentage of completion tied to project progress, or milestone-based — plus its own start and end dates and its own revenue and deferred revenue accounts.

Standalone selling price and allocation

Standalone selling prices are maintained per item, item group, project category or service type, with effective dates and support for a range rather than a single value where your policy uses one. The allocation engine distributes the total transaction price across obligations in proportion to standalone selling price, so a bundle discount lands proportionally across every obligation instead of being absorbed by whichever line it happened to be typed against. The residual approach is supported where a standalone price genuinely is not observable, and the method used is recorded on the contract for audit.

Deferral schedules

Each obligation generates a schedule of recognition amounts by period. Ratable obligations can use daily proration or full-period recognition depending on your policy. Point-in-time obligations recognise on the delivery or packing slip event. Percentage-of-completion obligations read progress from the project module. Milestone obligations recognise when the milestone is marked complete. Schedules are stored, not calculated on demand, so a schedule can be inspected, explained and reproduced months later.

Recognition posting

A RunBaseBatch period-end job posts recognition journals from the schedule to the general ledger, moving amounts from deferred revenue to recognised revenue with ledger dimensions inherited from the source transaction. Runs are logged, idempotent per period, and reversible with a documented trail. Sub-ledger to general ledger reconciliation is a standard inquiry rather than a manual exercise.

Contract modifications

When a contract changes — an added obligation, a term extension, a price change, a partial cancellation — the engine determines the treatment against configured rules and either creates a separate contract, applies prospective reallocation of the remaining transaction price, or generates a cumulative catch-up adjustment. Both the pre-modification and post-modification allocation are retained so the change can be evidenced. This is the area where spreadsheet processes most often break down, and it is treated as a first-class feature rather than an afterthought.

Variable consideration and constraint

Where your contracts include rebates, volume discounts, penalties or performance bonuses, estimated variable consideration is captured per obligation with an explicit constraint, re-estimated on a schedule, and the change flows into the allocation and the remaining recognition schedule.

Contract assets, contract liabilities and disclosure

The engine maintains contract asset and contract liability balances distinctly from trade receivables, because the disclosure requires it. Data entities are published through the data management framework and OData so remaining performance obligation, revenue by recognition pattern and deferred revenue roll-forward can be pulled into Power BI or your disclosure workpapers directly from the ledger.

Who this is for

Companies on Dynamics 365 Finance & Operations that sell bundles combining goods and services, or that sell software, equipment or projects with attached support, subscription or implementation components. It suits organisations subject to ASC 606 or IFRS 15 audit scrutiny where the current process depends on a maintained spreadsheet and reconciliation back to the ledger.

It is not needed if you sell single-obligation transactions that recognise entirely on delivery — the native functionality already covers that cleanly.

How delivery works

This application is built to order. There is no download, no trial and no pre-built binary, because revenue recognition rules are specific to your accounting policy and contract structure.

1. Scoping call. We review your contract types, your revenue recognition accounting policy memo, sample bundled contracts, your current spreadsheet and how sales orders, projects and subscriptions represent those contracts in F&O today. Your policy drives the build; we do not impose one.

2. Fixed quote and specification. You receive a functional specification describing every obligation type, allocation method, recognition trigger and modification rule to be built, plus the reports and data entities, at a fixed price with a delivery date. Nothing starts until you approve it.

3. Build. Development runs in our own F&O environment on your target version, with checkpoints. Scope changes go through written change requests rather than being absorbed quietly.

4. Install in your test environment. We deliver the deployable package and deploy it into your sandbox through LCS or your Azure DevOps pipeline, or guide your team through it. Then the important step: we load real historical contracts and reconcile the generated schedules against your existing spreadsheet. Discrepancies are resolved before anything else happens.

5. Production. After sandbox sign-off the same package promotes to production through your normal release process. We support the first period-end recognition run.

6. Support window. A defect support period is included, covering behaviour that differs from the approved specification. Policy changes and new contract types are quoted as follow-on work.

Lead time is typically one working week after specification sign-off, driven mainly by how many distinct obligation types and modification scenarios are in scope.