International Accounting Standards Board (“IASB”) has made effective IFRS 15 which covers Revenue Recognition of Contracts with Customers for annual reporting periods on or after January 1, 2018. IFRS 15 replaces IAS 18 Revenue (including Sale of Goods, Sale of Services and Royalties) and IAS 11 Construction Contracts and IFRIC 15 (Real Estate Sales), IFRIC 13 (Customer Loyalty Programs)
This article looks at the changes required under IFRS 15 and see how Microsoft Dynamics 365 for Finance and Operations Enterprise Edition ERP (referred to as Microsoft Dynamics 365 in this article) supports them. Let’s first understand IFRS 15 and what it does. IFRS 15 is highly prescriptive and will likely require significant changes in revenue recognition for entities reporting under the IFRS standard. The industries impacted are far ranging and include Construction, Architecture, Engineering, Professional Services, Property and Real Estate Development, Landlords, Retail, Contract Manufacturers, Hospitals, Medical Services Providers and Software companies. It is highly likely if you are reporting under IFRS that you are impacted by IFRS 15.
At a high level, IFRS 15 distinguishes between revenue recognized at a point of time and revenue recognized over a period of time, identification of distinct performance obligations and allocation of transaction price to these performance obligations, recognition of revenue from licenses and new guidance on royalty revenue. A summary of these changes is presented below.
Source: A Guide to IFRS 15 by Deloitte
The core principle is that an entity should recognize revenue commensurate with how the transfer of goods and services will happen to the customer. The revenue recognized should reflect the amount that the entity is entitled to in exchange for those goods and services. IFRS 15 uses a 5-step model in order to meet the core principle.
Source: A Guide to IFRS 15 by Deloitte
Let’s go through each of these steps and understand the complexities within them as well as how Microsoft Dynamics 365 can support compliance to IFRS 15.
Step 1 for IFRS 15: Identification of a Contract
- Recognizing a Contract. Per IFRS 15, a contract can be oral or written. An implicit contract is in place if your general business practice reflects that you do something even if it is not written into a contract.
Scenario 1: An Auto repair shop that charges CU 100 for an oil change and while not written into a contract but you generally do a free check-up for every car 30 days after an oil change then your contract obligations are the oil change and the free check-up and that will define the contract and you should put a value to each of these steps. The auto repair ship, you may value the oil change as 90 CU and the free check-up as 10 CU. That means in the past, the auto repair shop may have recognized the full CU 100 on completing the oil change with IFRS 15, the auto repair shop should only recognize CU 90 on completing the oil change and recognize the remaining CU 10 on completion of the free check-up.
Scenario 2: An IT Services Firm will generally begin work only after a written contract is signed with a customer. A customer has an aggressive timeline and to fast track the project issues non-binding Letter of Intent while the contract is being negotiated so that the IT Services Firm can begin work on the project. Since the IT Services Firm generally gets signed contracts with customers then it should not recognize revenue based on a Non-Binding Letter of Intent from the customer even though it began to perform services for the customer. This is because (i) its general practice is to have a signed contract and the revenue recognition would not be in line with its general business practice (ii) the Letter of Intent does not give the IT Services firm any collection rights.
Microsoft Dynamics 365 Support for Recognizing a Contract: In Microsoft Dynamics 365 contracts can be represented through two entities: Contracts which have underlying Projects and revenue recognition is driven by the Projects or Sales Orders. For a Professional Services Firm, a Contract and Project entity are a pretty straight forward way to create a contract. Projects can have multiple stages such as Created, In-Process, Completed. In Scenario 2 presented above, a project can be setup with status Created when there is an LOI and will move to In-Process status once the contract is signed. That will allow work to be performed but no revenue to be recognized in LOI stage and will allow revenue to be recognized once the contract is signed. Once In-Process, revenue can be recognized based on the percentage complete. Finally, once the project is complete, all work is done, billed and 100% of the revenue recognized then the project is closed with the status Complete.
IFRS Accelerator for Microsoft Dynamics 365: The IFRS Accelerator provides the ability to attribute value to items that do not have price tied to them while collecting the full amount from the customer on completion of only a portion of it. In the accelerator a Sales Order with an Oil change sales line will automatically create a second line for a Check Up which will have 10% of the value thus ensuring the contract is defined appropriately. However, in the Sales Invoice to the customer the customer will only see the primary line and not the attributed value line so that billing can function independently from Revenue Recognition. In this manner the full value of the contract can be collected on in the auto shop example on completion of the oil change, however only 90% of the revenue will be recognized on completion of the oil change and the remaining 10% when the free vehicle check-up is done.
- Collectability of Contracts: IFRS 15 states that collectability of contracts be factored in assessing revenues.
Scenario 3: An IT Services Business is entering a new country – Myanmar. For its first contract there that it has closed for 500,000 CU it expects to make significant concessions in the form of write offs during the course of the contract even though the written contract doesn’t state that to ensure it can get a happy and satisfied customer that it can leverage as a reference to win other deals. The business estimates the concessions it will make is in the range of 150,000 CU. IFRS 15 then requires the business to set the Contract value at 350,000 CU to allow for the unspoken investment write-offs it expects to make.
- Combining Contracts: IFRS requires that multiple contracts be combined into one if they are for the same customer (or related customers) and either have a single commercial objective; or have been negotiated together as a package; or the amount of consideration paid on one depends on the performance of the other contract; at least some of the goods and services in the contracts are a single performance obligation.
Scenario 4: An IT Services Business signs a Software Contract with a manufacturer to deliver an ERP system. The Customer adds related scope in the contract. For example, it decides to bring in 5 years of sales history as part of the implementation which was not in the original scope. The new change request should be combined with the original contract and revenue should be recognized for the combined contract as the ERP system may not go live without the new change request requiring the data migration to be completed. Similarly, the data migration work cannot be done in isolation without the performance of the ERP contract being completed.
Scenario 5: An IT Services Business signs a Software Contract with a manufacturer to deliver an ERP system. A few months later the customer decides it also wants to implement the HR functionality in the ERP system. The HR system is independent and will follow a separate timeline from the ERP system. Since the interdependency is low or negligible, the HR System implementation may be treated as a separate contract from the ERP System and each may have separate revenue recognition streams.
Microsoft Dynamics 365 Support for Combining or Separating contracts: In Microsoft Dynamics 365 a customer can have a single contract with multiple projects under it. Each project in turn can have sub-projects. If the contracts are two follow a single revenue recognition stream but have separate billing stream then a project, sub-project model is best as the budget can be aggregated into the parent project. If the two projects are to have different revenue recognition streams but linked to a single contract, then they can be created as two different Microsoft Dynamics 365 projects under a single customer contract. If the two projects are completely different contracts, then they can be created as two different projects under separate contracts for the same customer.
- Implicit Price Concessions: Any Implicit price concessions such as free extended warranty, free parts need to be unbundled and recognized as separate elements of the Contract. These are discussed in more detail with business examples in Scenario 6 and Scenario 7 below.
Step 2 for IFRS 15: Identify the Performance Obligations of a Contract
Step 2 requires identifying the various goods and services performed/ delivered under the contract. This seems simple but the trick is really in identifying the implicit services that may not be called out and attributing value to them. Examples of these are warranties, free parts/service or option to buy additional items at a discount under the contract. Similarly, the revenue recognition of Upfront fees / Joining fees are impacted.
IFRS Accelerator for Microsoft Dynamics: The IFRS Accelerator has a simple but elegant solution. It takes the cost of the various underlying elements to allocate the revenue of the contract. Where the cost is readily available as a standard cost or FIFO/ LIFO this is relatively simple but for other intangibles, a cost estimator is provided to be able to estimate cost based on labor, material, overhead. The combination of the estimate cost, actual cost, standard cost of the elements is then used to allocate the value of the contract. The IFRS accelerator has the ability to create service orders and attribute a value to those orders that can then be used for revenue recognition.
Scenario 6: A car sales person at a car dealer closes a contract for 30,000 CU for sale of a car and also throws in one year of free oil changes. The dealer cost of per oil change is 100 CU and 4 oil changes are required in a year. The dealer cost of the car is 27,000 CU. Total cost of the transaction is 27,400 CU. Per IFRS 15, The oil changes have an attribute price of approximately 110 CU per oil change (30,000*100/27,400). The IFRS accelerator will create four service orders at approximately 110 CU per oil change and recognize approximately 29,560 CU for the sale of the car.
Scenario 7: A Software company sells a dealer management software cloud subscription at 120,000 CU per year over 5 years for a total of 600,000 CU contract value. It also bundles in the implementation services for the Software to the customer. The contract now requires to be unbundled into its true components. The Software company estimates it will take 200 Project Management hours (cost rate of 100 CU per hour) and 2000 implementation hours (cost rate of 75CU per her to implement the software. The cost of the implementation is estimated at 170,000 CU (200 X 100 CU + 2000 X 75) The cost for the Cloud Subscription is 230,000 CU after accounting for the amortization and the hosting costs. The contract value is now allocated as below after taking into account these performance obligations.
Cloud Subscription: 445,000 CU (230,000/400,000 *600,000)
Implementation Services: 255,000 CU (170,000/400,000 * 600,000)
This means revenue for the Implementation Services component will be recognized as the implementation project progresses and revenue for the Cloud Subscription will be recognized at 445,000/60 CU per month assuming the company follows a month as a fiscal period.
To add complexity to this if the Cloud subscription cannot start till the implementation is complete then the recognition of that will have to be deferred till the implementation is completed to account for the interdependency. If the implementation is estimated to take six months, then zero subscription revenue may be recognized in the first six months followed by a monthly recognition of 445,000/54 CU per month for the remaining 54 months.
Step 3 for IFRS 15: Determination of the Transaction Price
The Transaction Price can comprise multiple elements and depends on
- Cash Consideration paid by customer
- Variable Consideration including Incentives, Rights of Return, Discounts and Penalties
- Non-Cash Consideration
- Contract Terms
- Payment Terms
- Consideration Payable to Customer e.g. future promised discounts
Source: A Guide to IFRS 15 by Deloitte
IFRS 15 is different from IAS 18 in that it is very specific about elements like variable consideration while IAS 18 is silent on it. IFRS 15 requires that the variable consideration not be included in the price or be recognized as revenue until there is high probability that the revenue based on variable consideration will not be reversed. Variable consideration can be valued by 2 methods
- Expected Value method: Using probability weighed amounts. When an entity has a large number of contracts with similar characteristics that are independent of each other, then the Expected Value method is a good model to use as it will better predict the outcome of the contracts in aggregate.
- Most Likely Amount: Using the most likely outcome and appropriate when the outcomes are binary e.g. Yes, or No.
Scenario 8: A System Integrator wins a fixed price contract at 5,000,000 CU (Five Million CU) to implement a new ERP system for a distributor. However, part of the contract terms is that if the System Integrator is not able to implement the system in 12 months from the contract date then it will refund /rebate 1,000,000 CU (One Million CU) to the Customer. In this scenario, the base consideration is 4,000,000 CU and the variable consideration is 1,000,000 CU. Revenue Recognition should be done based on the base consideration and the variable piece only recognized once the system is live (and if within 12 months from contract date).
Microsoft Dynamics 365 Support for Contract Transaction Price for IFRS 15 Compliance
Microsoft Dynamics 365 offers an elegant set of functionalities for allowing for the correct transaction price to be recognized. Some examples are provided below.
- Customer Rebates: Functionality exists to offer rebates on contract. Accruals of negative revenue can be posted when sales invoices are posted to reflect the true revenue even though the rebate is not issued to the customer. This is a good example of an Expected Value method.
- Project Contract based Revenue Recognition: The budget can be adjusted once the milestone has been completed for variable consideration. For example, in Scenario 8 the Project budget would be set at 4Million CU to reflect only the base consideration and revenue would be recognized based on the percentage complete of the project because the most likely amount for the variable consideration is zero. However, once the variable consideration milestone has been hit - go-live in this scenario – then the variable consideration can be added to the budget as the most likely amount has now changed. The budget for Scenario 8 would be increased from 4 Million CU to 5 Million CU if the ERP System go-live is delivered in 12 months and revenue would proportionately increase to reflect the variable consideration on completion of that milestone. However, if the go-live happens after 12 months then the budget would remain at 4 Million CU as the variable consideration has not been earned and the most likely amount remains at zero.
Step 4 for IFRS 15: Allocate Transaction Price to the Performance Obligations
IFRS 15 requires the Transaction Price / Contract Price to be allocated to every performance obligation of a contract by determining the stand-alone price of the distinct good or service underlying each performance obligation and then allocating the transaction price in proportion to the stand-alone prices of the performance obligations.
There are 3 approaches available to determine the stand-alone price. Each component in a contract/ sale can be valued based on any of these approaches
- Market Observable: If a product is sold as a stand-alone by the organization or by competition then a market observable price can be used. It is effectively the price the market is willing to pay for the good or service. The stated list price may or may not be the stand-alone observable market adjusted price. Generally, the stand-alone price is the price at which the product or service is generally sold. So, if the list price is 500 CU but the product or service is generally sold as a price of 350 CU when sold by itself then the market observable stand-alone price for that product is 350 CU.
- Cost Plus Margin: The cost of the goods is determined and then a reasonable operating margin is applied to determine the price. In Scenario 6 above, we used cost of the individual items as a way of allocating the sales price.
- Residual Approach: This values everything else in the contract using one of the two approaches above first and then the balance of the contract is allocated to the remaining performance obligation.
It is common however, that a bundle of goods and services may be sold at a discount from the sum of the parts. If that is the case, then the individual stand-alone selling price is determined and the transaction price is allocated based on the individual stand-alone selling price.
Scenario 6B: Let’s take a different approach to Scenario 6 that was calculated using the Cost plus approach. A car sales person at a car dealer closes a contract for 30,000 CU for sale of a car and also throws in one year of free oil changes. The dealer cost of per oil change is 100 CU and 4 oil changes are required in a year. The dealer cost of the car is 27,000 CU. Total cost of the transaction is 27,400 CU. However, we know that the stand-alone market observable price of the oil change for this car is 150 CU as the dealer regularly services this car at that price. We also know that the dealer generally makes an 8% gross profit on the cars. We can ue a cost plus margin for the car (27,400 *1.08) and use the market observable price for the oil change. We value the contract as below
|Performance Obligation||Price||Mechanism used|
|4 Oil Changes||600 CU||Market Observable|
|Car||29,592 CU||Cost Plus Margin|
Since the Total is above the Selling Price we can now allocate back the pricing as below
|Performance Obligation||Attributable Price|
|4 Oil Changes||(30,000/30,192 *600) =596 CU|
|Car||(30,000/30,192 *29,592) 29,404 CU|
We can do a sanity check and see this still falls into the target market observable price for the oil change and also the general target margin for the car and is an acceptable allocation where neither performance obligation has an unfair allocation compared to the other obligations.
IFRS Accelerator for Microsoft Dynamics: The IFRS accelerator allows you to identify the mechanism used for a sales contract at a header level or for each line level. For example, you could say the entire contract’s price allocation is to be done based on cost plus margin and then the accelerator will use the standard cost/ FIFO/ LIFO depending on the cost model for the item and come up with the individual costs for each component and allocate the sales contract price using the costs of the individual components. Alternatively, you can specify at a line level the mechanism to be used and the individual components are valued accordingly. Only one component can use the residual mechanism in a contract.
Step 5 for IFRS 15: Determine when to recognize revenue
Revenue is recognized when the performance obligation is satisfied and goods or service are transferred to the customer. Key to this is whether the revenue should be recognized over a period of time or a point in time. For contracts where the work is being done in a customized fashion for the customer e.g. a construction, software implementation, work may be recognized over a period of time provided the supplier maintains the ability via the contract to enforce collection for worked performed to date in case of termination of the contract. If the contract is not written such that work performed can be collected on then point in time revenue recognition should be used which would be generally when the contract is complete.
Microsoft Dynamics 365 Support for Revenue Recognition for IFRS 15 Compliance
The Projects Entity in Microsoft Dynamics 365 support both Point in Time Revenue Recognition as well as based on WIP/ Percentage Complete for Fixed Price Projects. The Revenue Recognition Principle for a Point in Time will be Completed Percentage whereas for a point in time it is Completed Contract. Thus, depending on the type of Contract and how it is written the appropriate revenue recognition model can be used.
Microsoft Dynamics 365 for Operations also has multiple billing rules that supports collectability based on the contract. You can set up the following types of billing rules:
- Unit of delivery – Invoice a customer when you complete a unit of delivery. You define the units of delivery in the contract.
- Progress – Invoice a customer when you complete a specified percentage of the project. You can set up a billing rule to automatically calculate the percentage of work completed, or you can manually calculate the percentage of work completed and the amount to invoice the customer.
- Milestone – Invoice a customer for the full amount of a project milestone when the milestone is reached.
- Fee – Invoice a customer for your services plus a management fee, which is typically a percentage of the cost of services.
- Time and material – Invoice a customer for the value of time and materials that are used on a project.
For more information on automating IFRS 15 compliance in your organization using Microsoft Dynamics, please email us at [email protected].
Sandeep Walia is the President of HITACHI Solutions Asia Pacific. He has over 20 years of ERP, CRM and Software implementation experience.
Microsoft Dynamics 365 for Finance and Operations and Microsoft Dynamics 365 are registered trademarks belonging to Microsoft Corporation.
The above content only reflects the views of the author and is not reflective of the views of Hitachi Solutions.