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