Accrued revenue (Revenue recognition)


Let’s build upon the yesterday’s business case. A guarantee, a maintenance, an insurance, a rental service is backed by a contract and span over a period of time, as opposed to a single delivery of goods. If the service is pre-paid at the beginning of the contract period, then the revenue should be allocated over time. This is known as

  • EN: Accrued revenue or deferred revenue/income
  • DE: Passive Rechnungsabgrenzung
  • RU: Доходы будущих периодов
  • FR: Régulation passif


Once the Revenue recognition module is activated, there is a bit of configuration to be done.

First of all, a general journal (General ledger > Journal setup > Journal names or Revenue recognition > Setup > Journal names) of the novel type Revenue recognition must be created. It is used to preview the periodic (monthly) revenue recognition before posting. The journal name is then selected as a default Revenue recognition journal name in General ledger parameters (this seems to be an innovation relative to the original Armanino module).

Next, the Item group of the service must be provided (Revenue recognition > Setup > Inventory and product setup > Posting) at least one additional account: Deferred revenue. It is a liability (we owe something to the customer for a service not yet rendered in full), a passive balance account.

In the case of a back-to-back contract if we are reselling a 3rd party [financial] service to the customer, the service has a cost price. It must be spread over time along with the revenue. This can be reflected by buying the service item ‘to the stock’ and treating it as a tangible item. The sales order produces COGS, and to accrue this expense we may need a separate account Deferred cost of goods sold. It is an asset (the services supplier owes something to us), an active balance account.

Finally, a Revenue recognition > Setup > Revenue schedules must be created:
Revenue schedule

  • Occurrences: the number of periods to allocate;
  • Recognition basis: the revenue may be allocated to calendar periods equally (1/12, 1/12, 1/12, 1/12, …) or in the proportion of the days in the month (31/365, 28/365, 31/365, 30/365…), or non-uniformly (then the allocation percentages are entered by the user in the Revenue schedule details);
  • Recognition convention: when to start recognizing. Sadly, if you choose Actual start date, and the service was billed on the 3rd etc. of the month, the revenue is going to be recognized on every 3rd on the following months;
  • Auto hold: any new revenue recognition records are put on hold and must be manually unlocked before taken over into the revenue GL journal;
  • Automatic contract terms: apparently, this option did not exist in the original Armanino ISV module. It pre-populates the start and the end date of contract in the sales order line, based on the number of occurrences and the length of the period.

If the service always brings about deferred revenue, the revenue schedule may be assigned to the Released product on the Revenue recognition tab:
Default revenue schedule
The selected revenue schedule is then automatically applied to every new sales order line with this item. It works even with bundle components. Furthermore, a default Revenue schedule may be assigned to the whole item group to pre-populate the items.


The service item is added to a service item. Pay attention to the Revenue schedule column far to the right:
Sales order line contract terms
It is pre-populated with the default Revenue schedule from the item master, or it may be amended / entered ad-hoc by the user. Next, the begin and the end of the contract must be specified in the Contract terms field group. With the Automatic contract terms on, the terms are evaluated automatically, starting from the day of today.

The allocation may be pre-viewed: check the Expected revenue recognition schedule on the Manage button ribbon. The expected revenue is persistent and rebuilt on every sales order confirmation.

Now deliver and bill the sales order. The revenue (and COGS) are posted not into the P&L but the BS accounts chosen before. Any due revenue from the current and the past periods (imagine the service was billed in the middle of the contractual period) is “caught up” with the first periodical revenue recognition.
Deferred revenue voucher
A Revenue recognition schedule has been set up for the sales order (Manage ribbon or the Revenue recognition > Inquiries and reports > Revenue recognition inquiry). The financial dimensions in the schedule are retrieved from the sales order header and lines. The percentages are taken from the revenue schedule details.

Once a month the user should check the Unprocessed revenue recognition schedules (workspace Revenue recognition > Workspaces > Revenue management) and apply the action Create journal:
Revenue recognition workspace: Create journal
The system is going to pick up any outstanding revenue records up to the As of date (i.e. catching up the revenue if the service was billed in the middle of the contractual period) and produce a GL journal with both the revenue and the COGS.

This journal (Revenue recognition > Journal entries > Revenue recognition journals) is left for approval and posting by the accounting department.


In the past, one of the few options to get an Accrued revenue was to use the straight-line revenue recognition mode in the Project accounting module, but the Revenue recognition module now offers a better, user-friendly solution that supports sales orders.
In the future, this offer may be rounded up by the Deferrals, providing a comparable user experience for the Accrued expenses.


  1. This is great and a module we are working with now. That said it is frustrating that it is only available for revenue when we require some of this functionality for expense deferrals. To that note I wonder what your views are on options now with reference to your earlier blog where you discussed making Rdeferrals available in other countries – do you believe it is possible to extend this functionality to expenses whilst we suggest and wait for MS to do this themselves as you have also suggested.

    • The RDeferrals module has been successfully “un-caged” some time ago. The trick was to identify all the programming artefacts (menu items, tables, extended data types, enumerations) and extend them, adding the ISO2 country codes in which you operate. Most of the artefacts bear the prefix RDeferrals, a few of them called Ledger* or something similar (e.g. the enumeration Vendor/Customer/Bank/Project/etc in general ledger journals).

      I am sure Mr. W. of the K. company going to be more than happy to sell the source code to you: fully programmed, infused with the multi-currency ability, ported to extensions, tested and working in Dynamics 365 for Finance 10.x. Buying a solution ready to be used will be much cheaper than developing it yourselves.

  2. Hi, When the sales order invoice is posted, how to make sure that the deferred cogs get hit instead of cogs? In my case costs are double counted because of that. First when sales order invoice is posted and later when we recognise the revenue?

    • This is not normal. If you take a look at my screenshot taken on the invoice posting, it used the deferred COGS account. Your invoice voucher is not correct for some reason; a bug? I have taken my screenshot in a standard system. There is no known parameter to trigger this. As soon as the revenue recognition is used, it reverts both the COGS and revenues.

Leave A Reply