Accrued revenue (Revenue recognition)

Introduction

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

Setup

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:

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:

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.

Process

The service item is added to a service item. Pay attention to the Revenue schedule column far to the right:

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.

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:

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.

Conclusion

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.

Revenue recognition and deferred cost blog series

Bundles (Revenue recognition)

Introduction

Update 2023: The bundles in the sales order are gone, I have not been able to use them for a few months, because the Revenue recognition module may not be activated anymore: Removed or deprecated features in Dynamics 365 Finance – Finance | Dynamics 365 | Microsoft Learn

The Revenue recognition module acquired by Microsoft from Armanino LLC comes with some real-world goodies which do not necessarily have to do with the IFRS regulations but address evergreen Trade & Logistics topics. One of them is a bundling /de-bundling of products.

The problem is well introduced in an older popular blog of mine. In short, the customer is sold a bundle (e.g. the proverbial cat in the sack) with a total price. The customer doesn’t need to know exactly what a single cat costed versus a single sack. Internally the revenues still need to be allocated among the products.
The solution (3) described in the blog is exactly what was implemented in Dynamics 365 in August 2019: an automatic BOM explosion for kits/bundles. The exploded components in the sales order are posted individually into the General Ledger – all with their unique GL accounts and accounting rules – while the sales invoice obscures the details and only presents the bundle and the total price to the customer.

You have to enable the Revenue recognition module first, which is available but hidden in all versions since Dynamics 10.0.5. Check out this source to learn how to do it.

Step by step

Once the module is activated, a new checkbox Bundle appears prominently on the General tab on in the Released product form:

A bundle item must be stock-able, it must be marked with the Bundle = Yes, and it must possess an active and approved bill of material (BOM) with the components inside. The bundle components may be either tangible products or services items, yet those must be stock-able too:

The bundle item is then added to the sales order normally:

The BOM of the bundle is automatically exploded whenever a sales confirmation is posted (to be honest, this is not ideal as we encourage our users to preview sales confirmations first).
The stock parameters, VAT settings etc. are taken from the individual components’ item master. This can be both right and wrong: in the case of a hypothetical ‘chicken in the sack’ the VAT rate for the chicken may indeed differ from the sack. However, in the case of a supplementary service (e.g. transportation) the service shares the fate (i.e. the tax rate) of the master product being shipped, according to the European legislation.

The total bundle price (note the Bundle net amount column far to the right) is allocated to the components in the ratio of their quantities in the BOM and the standard sales prices (not ideal, as the price of a component may vary). The divisor is the total of all components’ (sales prices * quantity) found in the BOM.
In the below example, the promotional sales price of 950 USD for a “Surface Pro tablet with an extra guarantee” is split at the ratio of 899*1/99,89*1 = 9:1 between the tangible Surface SKU and a service item:

Obviously, the bundle components are picked individually by the Warehouse management, which stands out in comparison to a Retail kit i.e. a “kit from the stock” scenario.

The sales confirmation and the sales invoice printouts only show a summary line with the master bundle item and its description:

In contrast, the Delivery note (aka Packing slip) contains all the lines (to remove intangible service lines from the delivery note one may use the classic Quantity = Picked only mode):

This makes sense, as the Delivery note (repurposed to a Commercial invoice) may need to be presented to the customs authorities on export/import operations.

That said, the bundles are well supported in the sales business documents, but not necessarily in the T&M or PSA project invoices.

Conclusion

A bundle/kit explosion T&L functionality implemented by partners myriad times through a customization is now available at the D365 Finance / SCM application core, which is great news. Yet the Revenue recognition module has more to offer: how about an accrual of the revenue from the above guarantee service? Check out the upcoming blog.