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.