A build-to-order performance-obligation and deferred revenue engine for Dynamics 365 Finance & Operations. Scoped to your contract types, quoted at a fixed price, then built and deployed to your environments. Built to order by ECOSIRE for Dynamics 365 F&O (build-to-order) — indicative price from $1399.00 USD; request a quote for a scoped proposal.
A build-to-order performance-obligation and deferred revenue engine for Dynamics 365 Finance & Operations. Scoped to your contract types, quoted at a fixed price, then built and deployed to your environments.
Built to order
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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 two to four weeks after specification sign-off, driven mainly by how many distinct obligation types and modification scenarios are in scope.
A short call to confirm the workflow, your platform version and where the integration boundaries sit.
You receive a written scope and a fixed price. Nothing is built until you approve it.
We develop against a copy of your configuration and test it there. Typically two to four weeks.
We install on your instance, hand over the source, and support it for twelve months.
Maintains the deferral schedules for bundled contracts in a workbook and re-keys the recognition journal every period. This moves allocation and scheduling into the ledger so the period-end entry is generated and traceable instead of typed.
Has to sign off revenue knowing the supporting schedule lives outside the system and is reconciled by hand. Stored schedules, logged recognition runs and retained pre- and post-modification allocations make the sign-off evidence-based.
Is asked to bolt revenue logic onto an already-customised F&O instance without creating upgrade risk. An extension-only build in its own model keeps the change isolated from Microsoft objects and from existing customisations.
| Criterion | ECOSIRE | Custom Build | Competitor |
|---|---|---|---|
| Standalone-selling-price allocation across bundled performance obligations | Included | Partial support | Included |
| Multiple recognition bases within a single contract (point in time, ratable, POC, milestone) | Included |
From $1399.00
Starting point — quoted to your scope
| Included |
| Contract modification with prospective or cumulative catch-up treatment | Included | Not included | Partial support |
|---|
| Variable consideration with explicit constraint and re-estimation | Included | Not included | Partial support |
|---|
| Percentage-of-completion obligations driven by F&O project progress | Included | Partial support | Partial support |
|---|
| Contract asset and contract liability tracked separately from trade receivables | Included | Not included | Included |
|---|
| Built as X++ extensions with no overlayering of Microsoft models | Included | Partial support | Partial support |
|---|
| Historical contract reconciliation against your existing schedule before go-live | Included | Partial support | Not included |
|---|
An X++ extension that imports bank statements into Dynamics 365 F&O and fuzzy-matches lines against payments, deposits and fees. Built to order for your legal entities after a scoping call and fixed quote.
A behaviour-aware treasury forecasting app for Dynamics 365 Finance & Operations. Built to order as an X++ extension after a scoping call and a fixed quote — nothing is pre-built or downloadable today.
A built-to-order forecasting and planning layer for Dynamics 365 Finance & Operations, with external demand signals, explainable forecasts and scenario comparison. Scoped and built by ECOSIRE after a fixed quote.
A build-to-order X++ extension that captures vendor invoices, extracts line data, matches them against purchase orders with tolerance rules and routes exceptions through F&O workflow. ECOSIRE builds it for your entity structure after a fixed quote.