Skip to Content
Author's profile photo Former Member

Revenue Recognition – The new IFRS Standard and its implications.

How SAP can help customers in coping with these changes with its Revenue Accounting Add On



Revenue is one of the most important figures present in the Financial Statements of an organisation. It helps the stakeholders to assess and measure the financial performance of the organisation and also helps them to predict the future financial performance of the organisation. It would not be an understatement to say that Revenues are the lifeblood of an organisation. Increasing Revenues, keeping costs unchanged or constant, generally signify that the organisation is performing well. Hence, measurement and recognition of Revenue is of utmost importance.

The business environment in which the organisations now operate is becoming increasingly dynamic and global in nature. Organisations enter into various kinds of contracts with parties that may or may not be in the same country as that of the organisation. Newer models of providing goods or services, like SaaS (Software as a Service) and IaaS (Infrastructure as a Service) requires the organisation to judge when the revenue is to be recognised. Also, since we are dealing with parties that are spread across the world, there is a need for a reporting standard that is acceptable throughout the world and therefore will allow the users of the Financial Statements to draw important conclusions from them.

Currently revenue recognition guidance differs in US GAAP and IFRS. US GAAP has complex, detailed, and disparate revenue recognition requirements for specific transactions and industries including, for example, software and real estate. As a result, different industries use different accounting for economically similar transactions.

IFRS on the other hand had limited guidance and the preparers found the standards sometimes difficult to apply as there was limited guidance on certain important and challenging topics.

On May 28, 2014, the FASB and the International Accounting Standards Board (IASB) issued (press release) converged guidance on recognizing revenue in contracts with customers. The new guidance is a major achievement in the Boards’ joint efforts to improve this important area of financial reporting.

As laid out by the Financial Accounting Standards Board, The objective of the new guidance is to establish the principles to report useful information to users of financial statements about the nature, amount, timing and uncertainty of revenue from contracts with customers.

By establishing comprehensive principles, the boards hope that preparers around the globe will find revenue guidance easier to understand and apply.


What is Revenue ?

Revenue in simple words is the income arising out of entity’s ordinary activities. Revenue is recognized by entity upon completion of its promise to transfer goods or services in a contract with a customer.

Under the Revenue Standards AS 606 and IFRS 15, Revenue has been defined as:-

Definition from ASC 606 – Revenue is Inflows or other enhancements of assets of an entity or settlements of its liabilities (or a combination of both) from delivering or producing goods, rendering services, or other activities that constitute the entity’s ongoing major or central operations.

Definition from IFRS 15 –  Revenue is Income arising in the course of an entity’s ordinary activities.–  Revenue is Inflows or other enhancements of assets of an entity or settlements of its liabilities (or a combination of both) from delivering or producing goods, rendering services, or other activities that constitute the entity’s ongoing major or central operations.

IFRS 15 further adds that Income is Increases in economic benefits during the accounting period in the form of inflows or enhancements of assets or decreases of liabilities that result in an increase in equity, other than those relating to contributions from equity participants.

The distinction between revenue and other types of income, such as gains, is important as many users of financial statements focus more on revenue than other types of income. Income comprises revenue and gains, and includes all benefits (enhancements of assets or settlements of liabilities) other than contributions from equity participants. Revenue is a subset of income that arises from the sale of goods or rendering of services as part of an entity’s ongoing major or central activities, also described as its ordinary activities. Transactions that do not arise in the course of an entity’s ordinary activities do not result in revenue. For example, gains from the disposal of the entity’s fixed assets are not included in revenue. 

Therefore, distinguishing between Revenue and Other Income is an important activity that depends on the circumstances and requires exercising judgement.

The core principle requires an entity to recognize revenue to depict the transfer of goods or services to customers in an amount that reflects the consideration that it expects to be entitled to in exchange for those goods or services.

What is IFRS ?

IFRS stands for International Financial Reporting Standards. IFRS has been developed with the aim of removing variations in the treatment of various accounting aspects and therefore bring standardization in Financial Reporting. It has been designed as a common global language for business affairs, so that company accounts are understandable and comparable across international boundaries. They are a consequence of growing international shareholding and trade and are particularly important for companies that have dealings in several countries. They are progressively replacing the many different national accounting standards. They are the rules to be followed by accountants to maintain books of accounts which are comparable, understandable, reliable and relevant as per the users internal or external.

Country specific Financial Reporting framework also exist  like US GAAP, Indian GAAP Etc. In recent times, there has been an effort to converge these local GAAPs with IFRS so as to have a common Financial Reporting framework. Of course, a complete convergence will not be possible as there may exist scenarios in a particular country which IFRS may not cater to and hence standards will have to be modified accordingly to include these scenarios also.

The new Revenue Recognition standard is the result of almost a decade long collaboration between the FASB and IASB to develop a single and comprehensive framework for Revenue Recognition.

What has changed ?

The most striking change has been the introduction of the new 5 – Step Model for Revenue Recognition. The core principle remains the same and is that a vendor should recognise revenue to depict the transfer of promised goods or services to customers in an amount that reflects the consideration to which the vendor expects to be entitled in exchange for those goods or services.

The new standard also introduces new disclosure requirements as it was felt that the current disclosures related to revenue did not provide the users of Financial Statements with an idea about the  sources of revenue, and the key judgements and estimates that had been made in its recognition

The new 5 – Step Model is as follows :-

SAP Revenue Accounting

The new standard is surely going to have a great impact on all the organisations required to report according to IFRS and US GAAP. Since, the change deals with revenue, we can be sure it would have an organisation wide impact and many metrics such as sales based compensation and taxes will also be affected. Also, it might force an organisation to rethink what products to sell and also how to sell the products. Hence, the changes are not limited to accounting policies but also to the systems and how they capture information needed to comply with the new requirements.

To smoothen this transition, SAP announced the launch of its new product, SAP Revenue Accounting and Reporting (RAR). As per the SAP Press Release :

SAP Revenue Accounting and Reporting was developed closely with partners and customers, as well as SAP’s internal accounting department, by analyzing the standard and assessing how best to design a new solution to cover the new requirements. The end result is an application that automates the revenue recognition and accounting process and simplifies the tasks of revenue accountants in following the new accounting guidelines, structured into five specific steps for simplicity.

The five specific steps mentioned are the same as the 5 – Step Model.

Step 1 :- Identify the Contract(s) with customer

IFRS 15 Revenue from Contracts with Customers is applied to contracts with customers that meet all of the following five criteria:

– The contract has been approved in writing, orally, or in accordance with other customary business practices and the parties are committed to perform their obligations in the contract

– Each party’s rights regarding the goods or services to be transferred can be identified

– The payment terms for the goods or services to be transferred can be identified

– The contract has commercial substance (i.e. the risk, timing or amount of the vendor’s future cash flows is expected to change as a result of the contract)

– It is probable that the consideration for the exchange of the goods or services that the vendor is entitled to will be collected. For the purposes of this criterion, only the customer’s ability and intention to pay amounts when they become due are considered.

If these 5 criteria are not met then the revenue from such contracts cannot be recognized under the new Revenue Recognition Standard.

SAP RAR allows contracts maintained in SD application or any other external ERP application to be considered as Revenue Accounting Contracts. The Revenue Accounting Contract is the level for determination and allocation of the transaction price. Depending on sales organisation, document type and document item category, an item can be marked as relevant for Revenue Accounting.

The conversion of operation contracts (SD) into RA Contracts is done using a flexible business rules framework. (BRF+)

SAP RAR also allows two or more operation contracts to be combined into one RA Contract if they are entered into at (or near) the same time, and with the same customer or related parties, provided at least one of the following criteria is met :

– The contracts are negotiated as a package with a single commercial objective

– The amount of consideration in one contract depends on the price or performance of the other contract

– The goods or services that are promised in the contracts (or some of the goods or services) represent a single performance obligation

The SAP integration component sets reference ID and type to determine which RAI items should be in one RA Contract. By default the reference ID is set to the order number which leads to the creation of one Revenue Accounting contract for each SD order. This can be changed via a customer exit or contracts can be manually combined in the Revenue Accounting Module.

The Management will thus have to exercise judgement to identify contracts which can be treated as Revenue Accounting Contracts and whether they can be combined into a single RA contract.

Step 2 :- Identify the distinct Performance Obligations

Having identified the contract in step one, a vendor is then required to identify the performance obligations(s) contained in the contract. A performance obligation is a promise to a customer to transfer:

– A good or service (or a bundle of goods or services) that is distinct; or

– A series of distinct goods or services that are substantially the same and that have the same pattern of transfer to the customer.

A promise within a contract is a performance obligation if the contract contains either a good or a service that is distinct, or aseries of distinct goods or services that are substantially the same, have the same pattern of transfer to the customer and meet two criteria:

(i ) Each distinct good or service in the series is a performance obligation satisfied over time, and

(ii) The same method would be used to measure the vendor’s progress towards complete satisfaction of the performance obligation to transfer each distinct good or service in the series to the customer. Consequently, it is necessary to identify whether a good or service is distinct. 

In SAP RAR, Performance Obligations (POB) play an important role. It is the level where the Stand Alone Selling Price is defined, where the transaction price is allocated and the fulfillment determined.

Usually, the line items of the operational contract correspond to Performance Obligations. However, we can also combine several operation items into a single POB.

For example, A Smartphone and a Charger may exist as separate items in the operation contract, but we can configure the BRF+ framework in such a way that whenever these are sold together, the system will combine these two line items into a single POB named “Smartphone Pack”.

SAP RAR also has a concept of Linked POBs. This allows an organisation to record POBs that are not explicitly stated in the contract but are implicit. For example, A Manufacturer of a software has a policy of providing “free” software upgrades to customers who buy a premium version of the software.  The Manufacturer can configure the BRF+ framework in such a way that whenever the operation contract line item is the premium version of the software, the system will add a linked POB “Upgrade Right” to the RA Contract. In this, the premium software is the leading POB.

Performance Obligation are created from what SAP calls as Revenue Accounting Items (RAI). A RAI contains all data from operational items and events that are relevant for Revenue Accounting.

SAP RAR has performance obligation types. This contains data like what is the fulfillment type for the POB -Time Based or Event Based, What is the Fulfilment, What is the standard duration etc amongst other things. This allows this “Generic” template to be used for POBs of the same type. For example, a POB type can be “Cloud”and this can be used for all POBs related to cloud offerings.

Therefore, we can see that SAP RAR with the use of BRF+ offers a lot of options and flexibility to establish the rules regarding performance obligations. This will be a one time activity with occasional tweaks depending on the business requirements. Hence, organisations should devote time to identify the different performance obligations, their relationships with each other, whether they are distinct or need to combined into a distinct compound POB.

Step 3 :- Determining the Transaction Price

The transaction price is the amount of consideration that a vendor expects to be entitled to in exchange for the goods or services. This will often be the amount specified in the contract. However, the vendor is also required to consider its customary business practices and, if these indicate that a lower amount will be accepted then this is the expected amount of consideration. Although a number of estimates about the future may need to be made when determining the transaction price, these are based on the goods and services to be transferred in accordance with the existing contract. They do not take into account expectations about whether the contract will be cancelled, renewed or modified.

The vendor also needs to consider effects of the following:

– Variable consideration

– Constraining estimates of variable consideration

– The existence of a significant financing component in the contract

– Non-cash consideration

– Consideration payable to a customer.

The Transaction price cannot be maintained in SAP RAR. It is derived from the pricing conditions that have been maintained for the individual line items in operational contracts.

The term pricing broadly refers to the calculation of prices (for external use) and costs (for internal use). The term conditions represent a set of circumstances that apply when a price is calculated. The condition technique in Pricing has variable factors like – the customer, the product, the order quantity, the date – which determine the final price the customer gets.

In SD module, as stated, the pricing can be decided based on combinations of the customer, the product, the order quantity & the date. This gives the management a lot of options to decide what the price will be for a contract. However, a lot of thought will have to go into this while setting up these values, like, what will be the value of the contract when it is entered with a certain customer under a specific scenario and so on.

The estimates for variable consideration cannot be maintained by SAP RAR at present and the management themselves will have to input the value based on their calculations using the Estimated Value Method or the Most Likely Outcome Method. The price should be such which should not result in subsequent significant reversals of the revenue that was recorded.

Determination of transaction price, hence, is a very crucial step in the 5 – Step Framework.

Step 4 :- Allocating the Transaction Price to performance obligations

Once the transaction price for the contract has been determined, the next step is to allocate it to the performance obligations present in the RA Contract. The objective of this step is to allocate the transaction price to each performance obligation (or distinct good or service) in an amount that depicts the amount of consideration to which the entity expects to be entitled in exchange for transferring the promised goods or services to the customer.

The starting point for the allocation is to use the stand-alone selling prices of each performance obligation as a base.

The Stand-Alone Selling Price (SSP) is the price which the vendor expects to receive if the goods and services forming part of the performance obligation are sold separately to a customer. Although a contractually stated price or a list price for a good or service may represent the SSP, this may not always be the case.

The best evidence of a SSP may be the directly observable price of such goods or services when sold to similar customers and under similar conditions.

When a SSP is not directly observable, it is estimated.

Approaches that can be used for estimating the SSP are:-

  1. Adjusted Market Assessment – Estimating the price that a customer in the particular market would be prepared to pay, which might include referring to prices charged by the vendor’s competitors for similar goods or services, and adjusting those prices as necessary to reflect the vendor’s costs and margins.
  2. Expected cost plus margin – Estimating the expected costs of satisfying a performance obligation and adding an appropriate margin.
  3. Residual Method – It involves deducting observable stand-alone selling prices that are available for other goods or services to be supplied from the total contract price. However, the use of this approach is restricted to those goods or services for which there is a wide range of selling prices (meaning that these cannot be observed from past transactions or other observable evidence), or in circumstances in which the selling price is uncertain because no selling price has been set for the good or service and it has not previously been sold on a stand-alone basis.

Irrespective of the approach being used, the objective is to arrive at an estimate that closely matches an amount that the vendor expects to receive for selling the goods and services to a customer under similar conditions.

In SAP RAR, the SSP can be maintained for the good and services sold by the entity. The SSP has to be maintained in BRF+. When the line items from the operation contracts are transferred to the RA Module, the SSP for these line items are derived by the system from BRF+. The allocation of transaction price to performance obligations is then done on the basis of the SSP derived.

These capabilities are what makes SAP RAR a great add on to the ERP system. The SSPs have to be configured in the BRF+ once with only occasional tweaks over time to be done so as to reflect a correct SSP. The allocation is also performed automatically with no manual interventions. This reduces the audit risk. Also, a clear audit trail is also available.

An example showing allocation done by SAP RAR on the basis of SSP.

SAP RAR can also deal with Multiple Element Arrangements so as to properly reflect the transaction price that should be allocated to the POBs in such an arrangement.

An example can be taken of a company offering a mobile phone with a 2 year service contract at 20$ with monthly charges of 20$ to be paid over 24 months. Now, we can easily conclude that the SSP of the mobile will definitely be higher than 20$. SAP RAR will help us in allocating appropriate transaction prices to the POBs of this contract.

SAP RAR, as stated earlier, can also recognize implicit obligations that a vendor must fulfill. For example, A vendor may offer an upgrade right to the next version of the software when it comes out for the smartphone. This upgrade right also has a cost and consequently a SSP. SAP RAR, can also allocate transaction price to such implicit obligations. Continuing the current example, let us assume the vendor also offers an upgrade right for free.

SAP RAR also has the capabilities to deal with Residual SSP approach.

As stated earlier, there may be situations when the SSP is not identifiable for a particular good or service and in that case, the SSP is estimated by subtracting the sum of all identified SSPs from the total transaction price.

For example, A vendor is selling a completely new good for which there are no directly observable SSPs.

In cases where, the Residual SSP becomes negative as a result of sum of SSPs becoming greater than the total transaction price, a NIL amount will be assigned by the system.

SAP RAR supports setting of tolerances with respect to the SSP. 

SSP tolerance allows you to define how much the transaction price can deviate from its SSP before triggering a price allocation. This is useful in situations when the transaction prices of your sold items are not exactly the same as, but are very close to, their standalone selling prices. In this case, your items are sold almost at fair value, and therefore you do not want to perform price allocation on this contract.

The standalone selling price tolerance allows you to specify a range, instead of a single value, of standalone selling price. The system performs price allocation only when at least one of the items in the contract is sold at a price beyond its specified price range.

In SAP RAR, you can define SSP tolerance as an amount or as a percentage for each of the performance obligations.

An example where tolerance is set as percentage and as an amount for different POBs and the tolerance is breached.

Hence, we see the capabilities of SAP RAR with respect to the allocation of transaction price to performance obligations under various scenarios.

Step 5 :- Recognize revenue when each performance obligation is satisfied

Revenue is recognised as or when goods or services are transferred to a customer. A vendor satisfies each of its performance obligations (that is, it fulfils its promises to the customer) by transferring control of the promised good or service underlying that performance obligation to the customer.

The application of the control criterion to all types of transactions for providing goods or services is one of the main changes in IFRS 15 compared with current practice.

Under the control model, an analysis of risks and rewards is only one of a number of factors to be considered and this may lead to a change in the timing of revenue recognition in certain industries.

Control in the context of IFRS 15 is the ability to direct the use of, and obtain substantially all of the remaining benefits from, an asset. It includes the ability to prevent other entities from directing the use of, and obtaining the benefits from, an asset. Indicators that control has passed include that the customer has:

– A present obligation to pay

– Physical possession of the asset(s)

– Legal title

– Risks and rewards of ownership

– Accepted the asset(s).

For each performance obligation, a vendor determines at contract inception whether control transfers over time or at a point in time. If it is determined that a vendor does not satisfy a performance obligation over time, the performance obligation is deemed to be satisfied at a point in time.

Hence, Fulfilment Events are classified into two categories:-

– Time Based

– Event Based

In SAP RAR also the fulfilment events can be either be Time Based or Event Based. For Time Based Fulfilment, the start date, duration and end date are transferred from the operation contracts. This can also be manually maintained in Revenue Accounting Module. Event Based fulfilments can be triggered by Invoice issue, Goods issue or Manual fulfilment. Manual Fulfilment caters to contracts in which revenue is dependent on the Percentage of Completion or events other than goods issue or invoice issue.

SAP also has plans to support further types of events like proof of delivery in future releases of the Revenue Accounting and Reporting Add on.

Revenue Recognition in SAP RAR – Examples

EXAMPLE 1 – A vendor enters into a contract worth $480 with a customer to provide software support service for a period for 12 months starting on 1st January 2016. This is a time based contract with a specified start date and duration.

The revenue for the contract will be recognised evenly over the duration of the contract.

EXAMPLE 2 – A vendor enters into a contract worth $200 with a customer to provide Audio Equipment on rent for a day. The Audio Equipment is required for a convention being organised by the customer on March 15, 2016. The Sales order is created on January 01, 2016. The Invoice will be issued on March 15, 2016.

In this case, the Invoice issue will trigger revenue recognition. This is a value based Invoice and not a delivery based Invoice hence Goods Issue will not be required.

EXAMPLE 3 – A Vendor enters into a contract worth $6000 with a customer to deliver 60 Units of Good X. Deliveries have to be made over the course of next 12 months. The delivery of goods will be sufficient evidence of control of the asset having transferred to the customer.

The revenue in this case, will be recognised every time the goods are delivered. Here, the goods delivery will trigger revenue recognition.

The Invoice was issued on January 1st, 2016.

EXAMPLE 4 – A Vendor enters into a contract worth $500 with a customer for the sale of a Smartphone and a Service Contract of 24 Months. The sale of smartphone will be immediate and for a price of $20. The service contract is for $20 a month. The SSP of the Smartphone is $140 and SSP of the service contract is $360. The Invoice will be issued immediately.

This a scenario involving both event based and time based fulfilments. The SAP RAR module will first allocate the transaction price based on SSP and then the revenue will be recognised based on the fulfilment events.

The revenue for the remaining 12 months will be recognised in the next year when they fall due.


The thing to remember here is that the fulfilment data is also transferred from the Operational systems. The Billing Plan and delivery schedule has to be carefully maintained in the operational system. Whenever Goods Issue is created in the operational system the same is updated in the Revenue Accounting Module and the revenue is recognised.

To Conclude, SAP RAR is capable of dealing with a multitude of scenarios.

Revenue Postings in SAP RAR

SAP has followed a basic principle in SAP RAR that the operational source systems shall remain unchanged as far as possible in order to avoid adjustments in the billing posting logic and account determination. Therefore in order to accommodate the differing revenues determined in the Revenue Accounting Module, Invoice Postings have to be corrected.

The various type of accounts used in the SAP RAR Module to record the correct revenues and costs are :-

1)   Revenue Adjustment Account

2)   Receivables Adjustment Account

3)   Revenue Adjustment Account – Linked POB

4)   Unbilled Receivables/ Contract Assets

5)   Deferred Revenue/ Contract Liabilities

6)   Recognized COGS

7)   Deferred COGS

In SAP RAR, the Invoice Posting is completely negated and revenues are then posted on the basis of fulfilment events. The cost is also recognised when the revenues are recognised. This ensures that the matching principle is followed by the organisation.

SAP RAR can also recognise Contract Assets and Contract Liabilities

Contract Asset is an entity’s right to consideration in exchange for goods and services that the entity has transferred to a customer, when that right is conditioned on something other than the passage of time.

Contract Liability is an entity’s obligation to transfer goods or services to a customer for which the entity has received consideration from the customer.

EXAMPLE – Taking forward the example of the Smartphone Contract mentioned earlier and adding an Upgrade Right in it also;

The journal entries would be as follows under the current scenario:-

Summary of Revenue and COGS for the contract at the end of month 1

Keeping in mind the requirements of the new revenue standard, the contract situation plays out as follows in the SAP Revenue Accounting Add On.

Based on the POBs present in the Revenue Accounting Contract, BRF+ will derive the SSPs for the POBs and these will be then used to allocate the transaction price to the various POBs.

Let us have a look at the revenue that will be recognised under the SAP RAR module for each period of the contract.

It will be as follows:-


Summary of Revenue and COGS for the contract at the end of month 1

In the next month, while recognizing revenue, the contract liability will be first adjusted as follows :-

The entry for recognising revenue related to Upgrade Right will be as follows:-

EXAMPLE – An example for Contract Assets is as follows:-

On January 1st, 2016, A vendor enters into a contract with a customer to transfer products A and B for a price of $1000. Good A has to be delivered first and payment for Good A is conditional on the delivery of Good B.

The allocations that have been identified for Goods A and B are $400 and $600 respectively.

Entries will be as follows:-

Through these examples we can see the impact of the new Revenue Recognition Standard both in terms of the timing and measurement of revenue.

Disclosures under the new Revenue Standard

The new revenue standard requires a number of disclosures intended to enable users of financial statements to understand the nature, amount, timing, and uncertainty of revenue and the related cash flows. The disclosures include qualitative and quantitative information about contracts with customers, significant judgements that were made in applying the revenue guidance, and assets recognised from the costs to obtain or fulfill a contract.

The disclosures are required for interim financial statementsalso.

Some of the disclosures that would be required under the new revenue standard are as follows:-

  1. Disaggregation of Revenue
  2. Reconciliation of Contract Asset and Liability Balances
  3. Performance Obligations – General Disclosures
  4. Remaining Performance Obligations
  5. Costs to obtain or fulfill contracts
  6. Other Disclosures like significant judgements used, methods used to recognize revenue etc

The current release of SAP Revenue Accounting and Reporting comes with the following Built – In                 Reports:-

  1. Posted Amount by Contract
  2. Posted Amount by Performance Obligation Type
  3. Disaggregation of Revenue by Customer
  4. Disaggregation of Revenue by Customer Group
  5. Disaggregation of Revenue by Performance Obligation Type

Closing Thoughts

The new Revenue Recognition Standard is a move towards greater comparability and transparency in the Revenue Recognition Process with a help of a principle based standard that is applicable across industries and around the globe. The impact of the new standard will extend beyond just accounting policy.

Though the 2018 effective date seems far away, what businesses have to understand is that they cannot change their accounting policies, systems, processes and internal controls overnight. An Analysis will have to be done to assess the accounting and disclosure requirements that the organisation will now have to comply with respect to their revenue transactions. This Analysis will allow the organisations to determine the changes that will be required to the systems, processes and controls. New systems, processes and controls will have to be designed that meet the new requirements. A close collaboration between stakeholders like Top Management, Operational Managers, IT Department, Sales Department, Auditors etc will have to be established. The Implementation of these redesigned systems, processes and controls will be a key challenge. The employees will also have to be educated in the new methodologies.

SAP with its Revenue Accounting and Reporting Add On has attempted to build a software which, without causing a huge disruption to the existing ERP systems, allows an organisation to comply with the accounting and disclosure requirements of the new revenue standard. A lot of work will go into setting up the business rules framework which acts as the brain of the Revenue Accounting and Reporting Add On. The rules will have to be developed for identifying relevant contracts, determining performance obligations, setting the transactions prices and standalone selling prices for these performance obligations and finally configuring the revenue recognition and posting setups.

As they say, a tool is only useful if the wielder knows how to use it. The organisations will have to start the assessment process quickly so that when the 2018 effective date comes calling, they are ready.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Tudor Riscutia
      Tudor Riscutia

      Hello Siddharth,

           Great article! I like that you provided a lot of business insight and examples.

           I have one question though, how is this different from FS-PER? Have you seen this solution?



      Author's profile photo Former Member
      Former Member
      Blog Post Author

      Hello Tudor

      Thank you for the appreciation. I was hoping that an overview using business examples would be helpful in explaining the implications and our response to it. I am glad it was helpful.

      With respect to FS-PER, I have not worked on it, but from what I know, it deals with Cost and Revenue Allocation for Financial Products. In this, I think the allocations will only happen at a statistical level without any impact on the actual accounting entries. More of an analytical tool.

      Revenue Accounting and Reporting actually affects the accounting entries and as a consequence Financial Reporting also.

      Just my 2 cents ! 🙂

      Cheers !

      Author's profile photo Tudor Riscutia
      Tudor Riscutia


      FS-PER is more a modelling tool.. but for whatsoever reason, they decided to push it on the cost and revenue allocation. In really, there are existing RFC adapters for read/writing data from FI-GL using the standard BAPIs.

      But you are right, FS-PER is focused more on the analytical side.

      Best regards,


      Author's profile photo Former Member
      Former Member


      Your Rev Rec example 1 (page 11) says that a contract worth $480 would be allocated evenly at $20/month for 12 months. Shouldn't this be $40/month or am I missing something? Thanks.


      Author's profile photo Former Member
      Former Member
      Blog Post Author

      Hello Mark

      Thank you for the comment.

      In the time based fulfillment example, the Transaction is of $480 over 24 months. For the sake of convenience, I only displayed what would happen in the first 12 months. Hence Monthly revenue comes out to be $20.

      I hope this clears your doubts.

      Best Regards


      Author's profile photo Shiva Ram
      Shiva Ram

      Hi Siddharth,

      Very good information with examples.

      I have a question, if an existing process is running as revenue recognition from sales and distribution, can that be included in RAR process?






      Author's profile photo Former Member
      Former Member
      Blog Post Author

      Hello Shiva

      Thank you for the appreciation. 🙂 Yes, it would work with a revenue recognition process running in SD Module.



      Author's profile photo Former Member
      Former Member

      Hello Siddharth,

      Very interesting article, good read and structure.

      A Question.

      Is there any interaction planned with procurement. Say you were to be a re-seller of an SAAS product. The end-customer side is very well represented in your examples. The cost can be identified and released when applicable, but what if you are not the source of the service/product.

      Procurement of such a service could be liable to a Vendors interpretation of gradual payment, not necessarily in line with the model you offer your customers.

      Thank you for your consideration.

      Best Regards





      Author's profile photo Minakshi Karan
      Minakshi Karan

      Hi Siddharth,

      Thanks a lot for such a great article, exhaustive one. One of the BEST till date in terms of the concept - being explained very clearly with help of examples.

      Best regards,


      Author's profile photo venu gopal
      venu gopal

      Hello Siddharth,


      Thanks a lot for your good infrmatin..