Revenue recognition – A simplified approach
What is Revenue recognition?
As per the latest book keeping principles and legal regulations like US-GAAP, IAS, FRS and SOX, Revenue should be realized and recorded in books at the time when the ownership of the goods/services is transferred from selling entity to receiving entity (Usually called as Customer). Event of ownership transfer is determined based on the contractual obligations and incoterms (International commercial terms) used in the sale process.
Why is this so important?
Real revenue figures at any given point is important from both internal and external stake holders point of view. Internal stakeholders like management would be interested to see what is actual realized revenues at any given point in time and external stake holders like share holders of the company would be interested to know the revenue position/growth of the company compared to historical figures. So, it is very important to record and disclose correct revenue figures in each period.
Gist of Standard SAP solution:
Let us see the approach of standard SAP solution.
SAP has released complex, efficient and reliable solution for revenue recognition from Sales module.
Below are different methods available.
- Revenue recognition at the point of billing (standard method)
- Time-related revenue recognition (the revenues are realized between specific set dates)
- Service-related revenue recognition (the revenues are realized on the basis of a specific event, e.g. the goods issue for a delivery)
- Credit/Debit memo request with reference to preceding document
- Service based revenue recognition, billing related (only for IS-M solution)
Different methods can be used based on business requirements.
Since the process is triggered from sales cycle, revenue recognition method is assigned to item category of sales document. From FI side, two interim accounts are to be defined.
1. Differed revenue account
2. Unbilled revenue account
Once the billing cycle starts and if the revenues are not related to that particular period (This is decided based on different approaches like proof of delivery, events etc), this revenue is recorded to interim accounts. When the revenue actually becomes realizable (Standard t-codes to be run to check this), revenue from interim accounts is transferred to actual revenue account.
With standard SAP solution, there are Pros like reliable solution, downstream support provided by SAP, product experts to implement the solution and cons like once solution is implemented, it is irreversible, business process/ways of working changes might be required to meet the prerequisites of revenue recognition.
Detained user documentation and how to implement standard revenue recognition solution is explained in OSS note 777996.
Alternate simple approach with custom solution:
If the business is not ready to adapt for changes in ways of working and implement the complex standard solution, below alternate approach can be followed.
Based on the business requirement, logical checks (To restrict the revenue recognition functionality for required scenarios) can be placed in delivery user exit MV50AFZ1 and update planned delivery date. To arrive at the date, required calculations can be done in user exit based on characteristics like incoterms, ship from country, ship to country, route etc. When invoice is created for the delivery, billing exit RV60AFZC can be used to update billing date which is copied from planned delivery date.
Based on the calculations, if the billing date (Planned delivery date) is coming in future period, billing document will not be released to accounting as the future period is not yet open and hence accounting books are not updated. Transaction VFX3 can be set up as batch job to release these billing documents to accounting. So, open billing documents for which period is open will automatically be released to accounting through this job. Job frequency can be decided by business. If the billing date is coming as current month, document would be automatically released to accounting and revenues are recorded in books in same period.
If planned delivery date is already being used for some other purpose in the current set up, new delivery text can be created for this purpose. Also, if there are any legal implications to send the invoice print outs, proforma invoice can be created for the same.
Please note that due date would be affected through this logic as billing date is updated with future date based on the calculations. It makes sense to consider correct baseline date for due date calculation based on ownership transfer.
This solution might not be foolproof. But can be effectively used when customers are reluctant to implement standard solution because of what ever valid reasons.
Your valuable comments are most welcome
Valuable Info...Many Thanks.
Thanks a lot Sanil, Naresh 🙂
Very useful Document.
Thanks for sharing.
Keep up the good work. 🙂
Best of Luck. 🙂
Thanks Ranu 🙂
Thank you very much.
all the best Erwin
This was the simplest approach we could design when customer was not ready for standard solution.
Thank you Vinod for providing an insight into Rev Rec.
With our client, the service related RR is set up for RR (with proof of delivery as specific even) and we experience following issues:
a. RR booked twice for same SO (that is SO LIs are appearing twice while running VF44)
b. RR happening before Delivery -
Would like to know how the rev rec tables are affected during a RR cycle - right from the start of creation of SO and at each phase till its completion upto the release to accounting.
Analysis is under progress - with our config set up done on item cat - if you have any thoughts please share.
I never worked on standard SAP revenue recognition solution. I suggest you to get in touch with SAP for this issue. I read implementation guide. SAP would completely validate and review the changes and ensure that there are no issues with set up.
Very nice article but I have one question with the alternate approach that you have given. If I understood it correctly, you are basically creating the SD invoice but you are blocking the accounting document from getting posted. But, with this approach, though you are creating the SD invoice, you cannot send the invoice to the customer. I mean, the output conditions in the SD invoice (like EDI, Print etc) are only proposed when the billing document is passed to accounting, right?
With the traditional revenue recognition, you won't have this issue. Please correct me if I am missing something.
As per my knowledge, once billing is created, outputs are triggered irrespective of accounting document is created or not. To be double sure, I will check this again.
It is correct to say that outputs are triggered irrespective of accounting document is created or not. It is the requirement of the business and the way the output type is set up - in the case of EDI, it is the data interchange how it happens through the intermediate document.
A small Doubt regarding Revenue Recognition:
Subscription was created for 1000$ on 12 Sep and the same amount was passed to revenue recognition followed by a billing doc, later on the billing doc was cancelled and the amount on the subscription was changed to 800$, now when the same sub was invoiced for 800$ and when tried to release it to accounting, system is thrown the control line item error message.
Can We Reverse the Revenue Recognition Document ?
Are you using standard revenue recognition solution? If yes, I am afraid that I couldn't help here as it is not active in our system 🙁
You may check process document given by SAP or search in SAP market place for any OSS notes.
If you are using normal invoicing process, please let me know further details of error.
Also, I would suggest to post this as question in forum so that it is visible to the larger group of audience.
Very well presented.
Arvind Leo Pereira
Thanks Arvind 🙂
Thank you Vinod, very nice blog
Thanks Rishab 🙂
Thanks for a very helpful information.
Just a quick question. What if the sale is associated with a duration? Example a contract that is valid from 01.01.2016 to 31.12.2016.
Is there any alternate solution available other than going for SAP rev rec functionality?