Revenue recognition for software products can be a complex topic, but following these few simple guidelines will make consulting with your accountant a more pleasurable experience.
It’s all about accounting
A fundamental principle of revenue recognition states that money is considered revenue only if a product or service has been fully and completely delivered.
NitroPDF produces and sells software that creates and edits PDF files. A customer can submit payment and have the product fully delivered instantaneously. According to the AICPA Statement of Position (SOP) No. 97-2 on Software Revenue Recognition, this type of exchange deserves revenue recognition because:
- Two parties agreed to the exchange
- A price was set
- Payment was collected
- Delivery was completed
Levels of complexity
However, things become cloudier when differentiating between a product where payment and delivery are simultaneous and a product or service in which there is a lag between payment and delivery.
You will notice that Nitro also offers an upgrade service for 12 months. With this service, “delivery” can potentially occur anytime within the next 12 months.
Does this require the software manufacturer to amortize the revenue over a certain period of time?
You need to consult your own professional accountant, but based on our previous understanding that revenue recognition is dependent on complete fulfillment and the fact that Nitro collects money for a service whose performance is delayed, I suspect that the International Accounting Standards Board (IASB) probably would want this type of revenue amortized over the time period.
So what happens when I sell software that is fully delivered and a service whose delivery is delayed in the same transaction? Welcome to alligator infested waters, mate!
The topic is too complex to treat fully in one post, but it’s important to note that when products and services are sold together, it results in changes to revenue recognition requirements. Here are some types of sales that you need to coordinate with your accounting department on:
- SaaS products
- Software and customization (if significant enough, even non-refundable up-front payments for the software license do not allow up-front revenue recognition)
- Software and services (installation, training, customization and modification)
- Software and physical products
Handling revenue recognition in ecommerce
From a practical standpoint, revenue recognition in ecommerce abides by the same rules as sales made through other channels. Finance leads the project to decide how a company wants to apply the revenue recognition rules to the products sold.
Generally, an external auditing firm is consulted for advice before any decisions are made. Within the company’s accounting system, the products are configured with the necessary revenue recognition values. As orders are submitted from the field, the accounting system should sync with the transaction information.
From an ecommerce perspective, the important part is to ensure that the products in the ecommerce system are configured properly so that when a sale is made the transaction is reported back to the accounting system with the correct link.
Guidance from your accounting team is required for correct revenue recognition in ecommerce transactions. Ensure that your ecommerce system is integrated tightly and correctly with your accounting system so that you don’t have a nasty surprise from auditors later.
What is your advice to others about handling revenue recognition in ecommerce transactions? Are there any gotchas that you’ve learned?