You are on page 1of 117

Technical Guide on

Revenue Recognition for


Software

Research Committee
THE INSTITUTE OF CHARTERED ACCOUNTANTS OF INDIA
(Set up by an Act of Parliament)
NEW DELHI
COPYRIGHT © THE INSTITUTE OF CHARTERED ACCOUNTANTS OF INDIA

All rights reserved. No part of this publication may be translated,


reprinted or reproduced or utilised in any form either in whole or in
part or by any electronic, mechanical or other means, including
photocopying and recording, or in any information storage and
retrieval system, without prior permission in writing from the
publisher.

First Edition : January, 2009

Price : Rs. 100/-

ISBN : 978-81-8441-164-5

Published by : The Publication Department on behalf of


Dr. Avinash Chander, Technical Director,
The Institute of Chartered Accountants of
India, ICAI Bhawan, Indraprastha Marg,
New Delhi -110 002

Printed at : Sahitya Bhawan Publications, Hospital


Road, Agra 282 003
January / 2009 / 2000 Copies
Foreword

The software sector plays a pivotal role in the overall economic


development of the country. India is a country where the software
industry has developed so rapidly that it has made India one of the
world’s most powerful software manufacturers and exporters. As a
result, the size of the industry both in terms of number of players
operating in the sector and the scale of revenue is increasing. In
the changing scenario, a need was being felt for bringing out a
pronouncement to address the industry-specific accounting issues
relating to revenue recognition of software with a view to bring
about establishment of sound accounting practices. It is heartening
to note that the Research Committee has formulated this ‘Technical
Guide on Revenue Recognition for Software’. I would like to
congratulate Shri Harinderjit Singh, Chairman, Research Committee,
and other members of the Research Committee for formulating
this Technical Guide.

I hope that this endeavour of the Research Committee will go a


long way in establishing sound accounting practices and provide
guidance to the members as well as to the others concerned.

New Delhi Ved Jain


President
Preface

A variety of revenue recognition principles are being followed in


the Software Industry. There is a need for establishing uniform
and sound accounting principles for revenue recognition of various
types of contracts entered into by the software companies.
Therefore, the Research Committee of the Institute of Chartered
Accountants of India has decided to bring out this Technical Guide.

The Technical Guide provides guidance on application of the


principles of Revenue Recognition, to various types of revenue
relating to the software industry including guidance on accounting
of revenue for customised software, off-the-shelf software, multi-
element contract, postcontract customer support (PCS), non-PCS
service, arrangement with resellers and application service
providers.

I would take this opportunity to place on record my sincere


appreciation for the contribution made by CA. Gargi Ray, special
invitee on the Research Committee, for preparing the basic draft
of the Technical Guide and CA. Sunder Iyer, member of the
Research Committee, for giving invaluable comments and
suggestions on the draft of Technical Guide.

I firmly believe that this Technical Guide will go a long way in


establishing the much needed software industry specific revenue
recognition accounting principles.

New Delhi CA. Harinderjit Singh


Chairman
Research Committee
Contents

Foreword

Preface

1. INTRODUCTION 1

Scope of the Technical Guide


General Description of Contracts in
Software Industry

2. REVENUE RECOGNITION CRITERIA 13

Agreements in a Software Industry


General Criteria for Revenue Recognition
Delivery under Various Kinds of Arrangements
Fixed or Determinable Fees and Collectability

3. REVENUE RECOGNITION WHEN RIGHT


OF RETURN EXISTS 27

Criteria for Revenue Recognition


Specific Right of Return Arrangements in
Software Industry

4. CUSTOMISED SOFTWARE 35

Principles for Recognising Revenue from


Customised Software
Recognition of Revenue and Costs
Measuring progress to Completion under
Proportionate Completion Method

5. MULTIPLE-ELEMENT ARRANGEMENTS 43

Determination of Multiple-Elements in a Contract


General Guidelines for Revenue Recognition
for Multiple-Element Arrangements
Measurement and Allocation of Arrangement
Consideration
Specific Objective Evidence
Accounting for Free Software
Maximum Number of Copies
Right of Return in a Multiple-Element
Arrangement
Specified versus Unspecified Additional
Software Products

6. POSTCONTRACT CUSTOMER SUPPORT (PCS) 72

General Guidelines for Revenue Recognition


of PCS for Perpetual Licenses
PCS Considerations for Term Licenses
Determining Fair Value for PCS Arrangements
PCS Arrangements involving a Maximum Charge
PCS offered in Arrangements involving Significant
Customisation or Modification
PCS Renewals based on Users Deployed
Fair Value of PCS with Usage-Based Fees

7. NON-POSTCONTRACT CUSTOMER SUPPORT


SERVICES 82
8. ARRANGEMENTS WITH RESELLERS 84

Form of an Arrangement
Delivery
Fixed or Determinable Fees and Collectability
Rights of Returns or Exchange and Price
Protection
Unspecified Additional Products in Software
Arrangements
Reseller’s PCS Arrangements
Prepaid Royalties

9. APPLICATION SERVICE PROVIDERS 94

Upfront Fees

Contingent Revenues

APPENDIX I Glossary 101


1

Introduction
1.1 Determination and reporting of revenue are the critical aspects
of revenue recognition. The timing of revenue recognition (i.e. the
accounting period in which the sale is recorded in the financial
statements) is critical to determine net profit or loss for an
accounting period. Many of today’s revenue generating transactions
are complex and involve considerable uncertainty. Accordingly,
the implementation of the revenue recognition principles is no
longer considered a routine matter. The area requires considerable
judgment.

1.2 Recognising the need for establishing uniform and sound


accounting practices for revenue recognition of various types of
contracts entered into in the Software industry, Research Committee
of the Institute of Chartered Accountants of India has decided to
bring out this Technical Guide on Revenue Recognition of Software.

1.3 Accounting Standard (AS) 9, Revenue Recognition, inter-


alia, states that, revenue recognition is the recording of the sales
in the financial statements of an enterprise. Paragraph 4 of AS 9
defines, ‘Revenue’ as the gross inflow of cash, receivables, or
other consideration arising in the course of the ordinary activities
of an enterprise from the sale of goods, from the rendering of
services, and from the use by others of enterprise resources yielding
interest, royalties and dividends. Paragraph 7 of AS 9 inter-alia
states also that revenue from service transactions is usually
recognised as the services are performed.

1
Revenue Recognition for Software

SCOPE OF THE TECHNICAL GUIDE


1.4 The Technical Guide deals with the following aspects of
revenue recognition

• General description of the type of contracts and their


nature
• Evaluation of revenue recognition criteria
• Revenue recognition when right of return exists
• Customised software
• Multiple-Element arrangements
• Postcontract Customer Support (PCS)
• Non- PCS Services
• Arrangements with resellers
• Application Service Providers

1.5 This Technical Guide does not apply, however, to revenue


earned on products or services containing software that is incidental
to the products or services as a whole. Indicators of whether
software is not incidental to a product or services, as a whole
include, but are not limited to:

(a) Software being a significant focus of the marketing effort


or is sold separately,

(b) Vendor providing postcontract customer support, and

(c) Vendor incurring significant costs on creating or


developing the software.

A mobile has a software installed in it. This software is not


updated with new versions of mobiles getting released. It is not
marketed separately.

2
Introduction

Software is incidental to the product. Hence, no portion of the


revenue would be recognised for the software separately.

Training materials are developed and stored on a CD and


marketed for an educational course. These contain interactive
questions and adjust the level of questions according to the
need of the user. The entire course is marketed as a product.

The product focuses on the software-reliant interactive features


and is marketable separately. Hence, this software is not
incidental to the product and revenue could be recognised
separately.

GENERAL DESCRIPTION OF
CONTRACTS IN SOFTWARE INDUSTRY
1.6 Contracts entered into in the software industry are of a special
nature and revenue recognition varies in each type. Broadly,
contracts may be classified into the following categories:

Application Development and Maintenance


Services
1.7 Companies often commit significant information technology
(IT) resources (e.g. people, applications, facilities, technology, etc.)
to develop, acquire and maintain application systems that are critical
to the effective functioning of key business processes. These
systems, in turn, often control critical information assets and should
be considered an asset that needs to be effectively managed and
controlled. IT processes for managing and controlling these IT
resources, and other such activities are part of a life cycle process
with defined phases applicable to business application development,
deployment, maintenance and retirement. In this process, each
step or phase in the life cycle is an incremental step that lays the
foundation for the next phase for effective management control in
building and operating business application systems.

3
Revenue Recognition for Software

1.8 An application is an integrated set of software programs that


provide the functionalities to realise the key business expectations
of a particular functional area or business process. The
implementation process for business applications begins when an
individual application is initiated as a result of one or more of the
following situations:

• A new opportunity that relates to a new or existing


business process.

• A problem that relates to an existing business process.

• A new opportunity that will enable the organisation to


take advantage of technology.

• A problem with the current technology.

Application Development
1.9 Development is the service by which user requirements are
elicited and software satisfying these requirements is designed,
built, tested and delivered to the customer. Development service is
used when a new application is being developed or a major
enhancement is being done to an existing application. The stages
in application development include feasibility requirements, design,
selection (in case of packaged systems), development, configuration
(in case of packaged systems), and implementation and post-
implementation.

Application Maintenance
1.10 Application maintenance refers primarily to the process of
managing change to application systems while maintaining the
integrity of both the production source (original source code) and
executable code. Once a system is moved into production, it seldom
remains static. Change is an expected event in all systems
regardless of whether they are vendor-supplied or internally
developed and, hence, application maintenance is required.

4
Introduction

1.11 Maintenance is the service of enhancing and optimising


deployed software as well as correcting defects. Software
maintenance phase involves changes to the software in order to
correct defects and deficiencies found during field usage as well
as the addition of new functionality to improve the software’s
usability and applicability to address the changed requirements.
Scope of the maintenance could include one or more of the
following:

• Major enhancements – They have impact on a large


section of the system. These typically involve addition
of new modules, interfaces, data tables and modification
to existing system components for seamless integration.
Typically, it will follow development life cycle stages
apart from some addition like impact analysis or
regression testing, etc.

• Minor enhancements – They have minor impacts on


the system functionality. These result in modification of
a program or a set of programs or new programs or
simple database changes.

• Bug-Fix – They do not involve any functionality change


and do not have any impact on the system. Many a
times writing few lines of code or doing minor
modifications to existing programs would suffice to fix
the bug.

• Level 3(L3) Production support – It is the group of


activities done to support existing application(s) in the
production/QA environment, sometimes referred as
production parallel environment. The objective of such
a support is to ensure the availability of the existing
application(s) for the users of the applications. A sub-
set of these activities is also directed towards, providing
application and user support (for L3 activities only),
analysing problems and conducting user acceptance
test (UAT), migration of new enhancements from
development environment to the production/QA
5
Revenue Recognition for Software

environment. It can also be of various kinds like batch


support (data processing in batches), research, data
migration, performance improvement, code clean up,
etc.

1.12 Level 3 definition does not include Level 1 and Level 2


support activities which are the basic level support activities.

Business Process Management (BPM)


1.13 It is a systematic approach to improving an organisation’s
business processes. BPM activities seek to make business
processes more effective, more efficient, and more capable of
adapting to an ever-changing environment. BPM is a sub-set of
infrastructure management, the administrative area of concern
dealing with maintenance and optimisation of an organisation’s
equipment and core operations. A business process is a set of
coordinated tasks and activities, conducted by both people and
equipment that will lead to accomplishing a specific organisational
goal.

Information Management (Business Intelligence)


1.14 It is a broad category of applications and technologies for
gathering, storing, analysing, and providing access to data to help
users make better business decisions. Information Management
applications include the activities of decision support systems, query
and reporting, online analytical processing (OLAP), statistical
analysis, forecasting, and data mining.

1.15 Information Management applications can be:

• Mission-critical and integral to an enterprise’s operations


or occasional to meet a special requirement.

• Enterprise-wide or local to one division, department, or


project.

• Centrally initiated or driven by user demand.


6
Introduction

Consulting Services
1.16 Consulting Services comprise advisory services to help clients
assess various options, redesign and rebuild their operations,
enhance their business, or financial process or technology
performance, impact their financial performance, address
competitive needs, help them take informed decisions and enable
them to meet their business objectives. Consulting services typically
involve definition and design of solutions. The list of services may
include

• Business or Management Consulting

• Business Strategy, including Transformation Strategy


and

ƒ Operational Strategy
ƒ Change Management Strategy
ƒ IT Strategy
ƒ Sourcing Strategy

• Process Consulting

ƒ Process Evaluation and Process Outsourcing


Approach
ƒ Process Reengineering and Process Design
ƒ Quality Consulting

• Technology Consulting

ƒ IT Architecture – Enterprise Architecture, SOA


ƒ Technology Evaluation
ƒ Package Evaluation
ƒ Infrastructure Consulting
ƒ Application and Infrastructure Portfolio
Management

7
Revenue Recognition for Software

ƒ Business Intelligence (BI) Consulting including


Corporate Performance Management

• Industry Specific Solutions

Engineering Services
1.17 Engineering services are offered to organisations that are
primarily engaged in:

• Developing Products, Systems/Sub-systems and/or


Platforms

• Providing Engineering Services including System


design, Engineering and Integration

• Technology Programs, Missions and Activities

• Developing and Managing Engineering Assets and


Infrastructure

1.18 The key activities include –

• Strategic Planning for Technology Programs/Activities.


Services required under this involve the definition and
interpretation of high-level organisational engineering
performance requirements such as projects, systems,
missions, products etc., and the objectives and
approaches to their achievement. Typical associated
tasks include, but are not limited to an analysis of
mission, program goals and objectives, requirements
analysis, organisational performance assessment,
special studies and analysis, training, localisation/
internationalisation and outsourcing.

• Research and Development Activities including basic


and advanced research covering typical areas such as
materials, methods, processes and technologies.

8
Introduction

• Concept Development and Requirement Analysis.


Services required under this involve abstract or concept
studies and analysis, requirements definition, preliminary
planning, the evaluation of alternative technical
approaches and associated costs for the development
or enhancement of high level general performance
specifications of a product, system, project, mission or
activity. Typical associated tasks include, but are not
limited to requirements analysis, cost/cost-performance
trade-off analysis, feasibility analysis, regulatory
compliance support, technology conceptual designs and
architecture and training.

• Product/System Design, Engineering, Integration,


Prototyping and Support for Manufacturing. Services
required under this involve the translation of a system
(product or subsystem, program, project, activity)
concept into a preliminary and detailed design
(engineering specifications, engineering design and
embedded platform/software), performing risk
identification /analysis /mitigation, traceability, and then
integrating the various components including embedded
software to produce a working prototype or model of
the system. Typical associated tasks include, but are
not limited to computer-aided design, embedded
software development, design studies and analysis, high
level detailed specification preparation, design data
management/configuration management and document
control, fabrication, assembly and simulation, modeling,
training and outsourcing.

• Test and Evaluation. Services required under this


involve the application of various techniques
demonstrating that a prototype system (sub-system,
program, project or activity) performs in accordance
with the objectives outlined in the original design. Typical
associated tasks include, but are not limited to testing
of a prototype and first article(s) testing, environmental
testing, independent verification and validation, reverse
9
Revenue Recognition for Software

engineering, simulation and modeling (to test the


feasibility of a concept), system safety, quality
assurance, software functionality, physical testing of
the product or system, training, internationalisation/
localisation and outsourcing.

• Product/System Sustenance and Lifecycle Support.


Services required under this involves the analysis,
planning and detailed design of all engineering specific
logistics (example hardware and software requirements)/
production support including material goods, personnel,
and operational maintenance and repair of systems
throughout their life cycles. Typical associated tasks
include, but are not limited to ergonomic/human
performance analysis, feasibility analysis, logistics
planning, requirements determination, policy standards/
procedures development, long-term reliability and
maintainability, training, and outsourcing.

• Acquisition and Lifecycle Management. Services


required under this involve managing product
information and definition across the entire lifecycle
right from ideation, requirements, design,
manufacturing, to end of life including configuration/
change management. The services for manufacturing
include process design, manufacturing execution and
systems to monitor, track, control process and analyse
data for decision support. The asset management
activities comprise of planning, budgetary, contract and
other systems/program management functions required
to procure and/or produce, render operational and
provide life cycle support (maintenance, repair, supplies,
and engineering specific logistics) to technology-based
systems, activities, sub-systems, projects, asset/
infrastructure etc. Typical associated tasks include, but
are not limited to operation and maintenance, program/
project management, technology transfer/insertion,
training, and outsourcing.

10
Introduction

Infrastructure Management (IM)

1.19 IT Infrastructure (“the plumbing”) is defined as the sum of


an organisation’s IT related hardware, software, data
telecommunication facilities, procedures, policies and
documentation. It refers to the equipment, networks, software,
data centers, desktops, and accompanying applications, as well
as the services people use to access, create, disseminate, and
utilise digital information. It includes all IT assets used in storing,
securing, processing, transmitting, and displaying all forms of
information. The significant objectives of IM are to ensure
availability, performance, compliance and security for the
organisation’s IT assets, so that the business applications and
business processes run smoothly. Key functions of IM include
design functions like sizing, capacity planning and Disaster
Recovery and Business Continuity Plan (DR/BCP), consolidation
strategies, as also supporting large global operations on a 24x7
basis across countries and continents.

1.20 Engagements usually involve design and operations


management as well as process and technology transformation
yielding order-of-magnitude benefits in costs and overall services
to business. Key IM services include datacenter management
(servers, hosting, storage, collaboration platforms), network
management (design and operation of switches, router, firewall,
VPN, voice equipment for both telecoms and enterprise networks)
and application operations (24x7 support, Level 1/Level 2 support,
middleware support, environment management, service desk,
configuration management).

1.21 In addition, there are various specialised areas including


Infrastructure Optimisation and Consolidation, Performance
Engineering and Capacity Planning, Mission-critical Server and
Network Configuration, Network Audit, Integration, Identity
Management, Migration (Platforms, domains, databases), Security
(operations setup, policy, advisory, implementation), Network
Operations Centers (global command centers with plasma screens
and round-the clock monitoring and management), Network
Testing, Enterprise Operations Support (SAP Basis etc), Enterprise
11
Revenue Recognition for Software

Systems Management tools design and implementation, IT Service


Management (Infrastructure operations) Process consulting, based
on industry best-practices, IT Controls and Compliance
Management Consulting, implementing solutions around
Information Risk Management and Assure IT, IT Infrastructure
Off-shoring Transition Management, Consolidation /Convergence
consulting (data centers, networks, platforms, tools), and
Virtualisation.

Package Implementation
1.22 This comprises a broad set of activities supported by multi-
module application software that helps a manufacturer or other
business manager to manage the important parts of its business,
including product planning, parts purchasing, maintaining
inventories, interacting with suppliers, providing customer service,
and tracking orders. It can also include application modules for
the finance and human resources aspects of a business. Typically,
any package uses or is integrated with a relational database
system. The deployment of a package can involve considerable
business process analysis, employee retraining, and new work
procedures.

Validation Services (Testing)


1.23 Validation is a process of exercising and evaluating the
software system or its component under specified conditions to
verify that it satisfies specified requirements and to detect defects.
Usually, the requirements include such topics as functional
correctness, completeness, security, availability, reliability,
efficiency, portability, maintainability, compatibility, and usability.

12
2

Revenue Recognition Criteria

2.1 Software arrangements range from those that provide a


license for a single software product to those that, in addition to
the delivery of software or a software system, require significant
production, modification, or customisation of software. The principles
of AS 9, Revenue Recognition, are applicable to all types of software
arrangements. Softwares are generally of two major types namely
‘off-the-shelf software’ and ‘customised software’. Off-the-shelf
software is software marketed as a stock item that customers
could use with little or no customisation. Software should be
considered off-the-shelf software if it can be added to an
arrangement with insignificant changes in the underlying code and
it could be used by the customer simply upon installation. Software
developed as per customer specification is referred to as
customised software. This chapter deals with general criteria for
recognition of revenue; specific situations for recognition of revenue
have been dealt in the subsequent chapters.

2.2 Paragraph 5 of AS 9, states that the amount of revenue


arising on a transaction is usually determined by agreement
between the parties involved in the transaction. Generally, in
software industry an agreement is considered to have come into
existence when there is an evidence of an arrangement in this
regard.

13
Revenue Recognition for Software

AGREEMENTS IN A SOFTWARE
INDUSTRY
2.3 Generally, a written contract signed by two parties is
considered as an evidence of an arrangement. However, practices
vary in the software industry regarding the use of written contracts.
Evidence of an arrangement should generally be consistent with
the vendor’s customary business practices.

2.4 Vendors ordinarily have formal written policies defining what


constitutes an arrangement in their business. These policies should
be applied consistently in determining what constitutes an evidence
of an arrangement. The evidence of an arrangement should
generally be the final form of the arrangement (i.e. drafts, letters
of intent, etc., would not satisfy the requirement).

2.5 Customary business practice plays an important role in


determining whether an evidence exists. Vendor’s customary
practice for documenting contracts may vary among the customer
groups. In that case it may be necessary for the vendor to document
each method as to what constitutes evidence of an arrangement
for each customer group.

If the vendor’s practice is to ship its product after receiving an


online authorisation from the customer, this may then constitute
an acceptable evidence of an arrangement. If the vendor usually
signs a written agreement then an online-authorisation or signing
the purchase order may not suffice for revenue recognition
purposes. Written contracts should generally be signed by both
the parties before the Balance Sheet date prior to revenue
recognition. Contracts that are signed after the balance sheet
date and back-dated to “as of” or “effective as of” the balance
sheet date may not constitute acceptable evidence of
arrangement.

The vendor’s third quarter ends on December 31. The vendor


customarily obtains signed contracts from its customers for each
software order. The customer calls on December 29 to say that

14
Revenue Recognition Criteria

it has just obtained 100 new computers and would like to order
100 copies of a software product from the vendor. As a result
of the proximity of the order to quarter’s end, a signed licensing
contract is not entered into until after the end of the quarter,
even though the vendor ships the software to the customer on
December 30. In lieu of a signed contract, the vendor obtains a
“non-cancelable letter of understanding” from the customer,
which includes the significant terms and conditions of the
licensing arrangement and states that the parties agree to finalise
a mutually acceptable licensing contract within a certain period
of time after the delivery of the software. The vendor’s customary
business practice is to obtain written contracts.

Does evidence of an arrangement exist on December 31?

If the vendor intends to obtain a signed licensing contract or


has a business practice of obtaining a signed contract, the only
acceptable evidence of an arrangement can be a contract signed
by both the customer and the vendor. Distinguishing between
terms that are significant and those that are insignificant may
not be appropriate in an assessment of whether the evidence
exists; therefore, in this case, the evidence does not exist as of
December 31.

Master Agreements

2.6 Master agreements define all of the basic terms and


conditions for transactions between the parties and will be signed
by both parties. To obtain the products under the master
agreement, the customer may need to issue a second
communication in the form of a purchase order or send an
electronic request that will specify the software products, quantities,
and requested delivery date. In these cases, the master agreement
and the additional communication would constitute the total
arrangement. The vendor would have to determine what the
customary business practice is for the second communication in
order to establish whether a valid arrangement has been entered
into.
15
Revenue Recognition for Software

Assume that on June 30 the vendor receives a purchase order


for Product X that exceeds the number of units covered by the
master agreement. Does the evidence of arrangement exist on
June 30?

It is not likely that the evidence exists on June 30 for the units
that exceed the authorised amount in the master agreement. If
the vendor and the customer intend to enter into a new master
agreement for future transactions and such an arrangement
has yet to be finalised, for the portion of the shipment that
exceeds the volume specified in the existing master agreement
the evidence of arrangement may not be considered to have
come into existence.

Side Agreements

2.7 Master agreements may be complemented with side


agreements including cancellation, termination or other provisions
that affect revenue recognition and, therefore, should also be
carefully studied.

GENERAL CRITERIA FOR REVENUE


RECOGNITION
2.8 Generally, revenue is recognised when all the following
conditions are met:

(a) Significant risks and rewards of ownership have been


transferred to the buyer, which in software industry are
generally considered to be transferred when the delivery
has occurred,

(b) The seller’s price to the buyer is fixed or determinable,


and

(c) Collection is reasonably assured.

16
Revenue Recognition Criteria

DELIVERY HAS OCCURRED


2.9 One of the conditions is that revenue cannot be recognised
until significant risks and rewards of ownership have been
transferred to the buyer which may be considered to be transferred
by occurrence of delivery. Delivery means a transfer of software
accompanied by documentation to the customer. The transfer may
occur in one of the following ways:

(a) A physical transfer of tape, disk, integrated circuit, or


other medium.

(b) Electronic transmission.

(c) Making available to the customer software through


facilities such as a computer service bureau.

2.10 If one or more undelivered elements are necessary for


functionality of delivered product or element, then delivery may be
considered to be complete after the delivery of such undelivered
elements.

DELIVERY UNDER VARIOUS KINDS OF


ARRANGEMENTS
Bill and Hold Arrangements

2.11 Delivery is delayed at buyer’s request although buyer takes


title and accepts billing. Assuming other revenue recognition
conditions are satisfied, revenue is recognised if all the following
indicative conditions are met:

• Risks have passed on to the buyer.

• Buyer has made a fixed commitment to purchase and


buyer has requested for a bill and hold arrangement.

• Fixed schedule for delivery of the goods exists.


17
Revenue Recognition for Software

• Seller does not need to perform any specific


performance obligation.

• Inventory on hand is identified and ready for delivery to


the buyer.

Multiple Copies of Software

2.12 In these arrangements either the customer has the right to


use multiple copies of a software product under a site license or
the vendor sells multiple copies of a product to a reseller for a
fixed fee.

2.13 In case of multiple copy arrangements, revenue is


recognised upon delivery of the first copy or the product master,
provided other conditions for revenue recognition are satisfied.
The duplication of software is incidental to the delivery of the first
copy. The estimated costs of duplication should be accrued at
that time.

A vendor enters into an agreement with the customer whereby


the customer pays a non-refundable fee of Rs.100,000 for 1,000
copies of Product D. On June 30, the vendor ships to the
customer a fully functional version of Product D on a CD.
Pursuant to the terms of the arrangement, the customer may
request that the vendor duplicate Product D for branch offices.

Is it appropriate for the vendor to recognise the Rs.100,000 fee


on June 30?

It is likely that duplication in this arrangement would be incidental


and involve little effort by the vendor. The fee is non-refundable,
even if additional duplication is not requested by the customer.
The vendor should recognise the Rs.100,000 fees on June 30,
provided other conditions for revenue recognition are also
satisfied and accrue the estimated costs of duplication.

18
Revenue Recognition Criteria

Multiple Licenses

2.14 Licensing fee is a function of the number of copies delivered


to, made by, or deployed by the user or reseller. As duplication is
not incidental, revenue is recognised as and when each copy of
the single license is delivered provided other conditions for revenue
recognition are also satisfied.

Delivery of Licensed Software

2.15 Delivery may be considered to be complete for revenue


recognition purposes upon the commencement of the license term
even if the license is delivered earlier and payment is also received.
In situations where a customer extends/renews a pre-existing,
currently active software license for the same product(s), the
arrangement fee allocated to the extension/renewal should be
recognised when all other revenue recognition criteria are met
and not at the commencement of the extension/ renewal period. If
the customer’s existing license lapses then extension or renewal
should be accounted as a new arrangement for the purpose of
revenue recognition.

Electronic Delivery of Software Developed

2.16 Assuming that all other criteria are met, revenue recognition
is appropriate under arrangements wherein the product will be
delivered electronically at the point at which the customer has
possession of or full access to the software (whichever comes
earlier). Arrangements involving electronic delivery of software
often include the use of permanent or temporary “keys” or
authorisation codes.

2.17 Authorisation codes, also referred to as “access codes” or


“keys”, are often used by software vendors to prevent unauthorised
access to software and to allow customers’ access to otherwise
restricted software. Permanent keys may be used to control access
to the software, or duplicate the software. Temporary keys may
be used for the same purposes and are generally used to enhance
19
Revenue Recognition for Software

the vendor’s ability to collect payment or to control the use of


software for demonstration purposes.

2.18 Delivery of a key is not necessarily required to satisfy the


vendor’s delivery responsibility and, therefore, the software vendor
may recognise revenue on delivery of the software if all the
following indicative factors are satisfied including all other
requirements for revenue recognition:

• Customer has licensed the software and the software


is fully functional (excluding reproduction through
permanent keys or additional keys).

• Payment is not contingent upon the delivery of the


keys.

• Vendor has a history of successfully enforcing


payments.

2.19 If a temporary key is used to enhance the vendor’s ability


to collect payment, the delivery of additional keys, whether
temporary or permanent, is not required to satisfy the vendor’s
delivery responsibility if all the above indicative conditions are met
and the use of a temporary key in such circumstances is a
customary practice of the vendor. However, if the issuance of
temporary keys indicate that the software is only for demonstration
purposes, it is clear that the fees is not fixed or determinable on
delivery and revenue recognition should be postponed.

A vendor enters into an arrangement with the customer for


Product C on June 29. The vendor e-mails the customer a fully
functional version of Product C on June 29. The customer does
not open the e-mail to receive Product C until July 1.

Has the delivery criterion been met on June 29?

The delivery criterion has been met on June 29. The customer
has full access to the software on June 29. Assuming that all
other revenue recognition criteria have been met, revenue
20
Revenue Recognition Criteria

recognition would be appropriate at the point that the customer


has full access. The fact that the customer did not utilise such
access does not impact the timing of revenue recognition.

A vendor includes ten optional functions on a compact disc


(CD-ROM) on which its software product is licensed. Access to
those optional functions is not available without a permanent
key. Users can order the optional functions and receive
permanent keys to enable the full use of those functions.

Although the user has received a fully functional version (except


for the keys) of the optional functions on the CD-ROM, the user
has not agreed to license them. Because no evidence of an
arrangement exists revenue for the optional functions may not
be recognised when the CD-ROM is delivered. Revenue for
each individual optional function should be recognised by the
vendor when the user purchases it by placing an order, evidence
of such order exists, and the key is delivered to the user.

Delivery other than at Customer’s Location

2.20 This arises in cases where the software is to be physically


delivered. Delivery is not deemed to be complete until the software
is delivered to customer location or location specified by the
customer. When delivery is made to agents, engaged by the
vendor, revenue should be recognised only when the software is
delivered to customer and not to his agent provided other conditions
for revenue recognition are also satisfied.

Delivery when the Seller’s Remaining Obligation


is Inconsequential or Perfunctory

2.21 Provided other conditions for revenue recognition are also


satisfied, revenue can be recognised in its entirety. The obligations
are inconsequential provided the failure by seller does not give the
buyer the right to reject the delivered products or gets right to

21
Revenue Recognition for Software

refund and there is sufficient evidence that the seller performs


these functions reliably and in timely manner.

Delivery Subject to Customer’s Acceptance

2.22 Revenue should not be recognised until there is reasonable


certainty about customer’s acceptance of the software, provided
all other revenue recognition criteria are met. In this regard, the
following aspects may be noted:

• Revenue recognition may not be deferred for items


sold as a standard model which are quality checked.

• If payment terms are tied to customer acceptance,


revenue should not be recognised until the payment is
made or becomes due.

• If vendor delivers the software for trial and evaluation


purposes, the revenue should not be recognised until
earlier of formal acceptance of the product or the lapsing
of the acceptance time period occurs.

• Generally, formal sign off is obtained for evidencing


customer acceptance. However, the same is not always
necessary for revenue recognition provided the seller
objectively demonstrates that the criteria for acceptance
has already been tested and satisfied.

FIXED OR DETERMINABLE FEES


AND COLLECTABILITY
2.23 Fixed fee means a fee required to be paid at a set amount
that is not subject to refund or adjustment. A fixed fee includes
amounts designated as minimum royalties. If a vendor cannot
conclude that a fee is fixed or determinable at the outset of an
arrangement, revenue should be recognised as the payments
become due, assuming all other criteria for revenue recognition
are met.
22
Revenue Recognition Criteria

2.24 Fee is not fixed or determinable if amount is based on


number of units distributed or copied or expected users of the
product. A sales price or fee that is variable until the occurrence
of future events (other than product returns) is not fixed or
determinable until the future event occurs. Revenue from such
transactions may not be recognised until the sales price or fee
becomes fixed or determinable. Similarly, if there are refund
privileges, revenue may not be recognised till the refund privileges
expire. Till that time, the amount received may be credited to a
liability account.

Determination of Fees under Rights in the Nature


of Warranties

2.25 Such rights allow the customer a right of return or


replacement if the product is defective or fails to meet the vendor’s
published performance criteria.

2.26 If the vendor has previously demonstrated that products


meet the criteria, revenue may be recognised after giving due
consideration to the cost of defective goods. Cost of defective
goods could be estimated based on a demonstrated history of
substantially similar transactions. If, however, the vendor has not
previously demonstrated that the delivered product meets the
specifications, recognition of revenue should be deferred until it
can be shown that the specifications have been achieved.

A vendor and a customer enter into a software agreement


pertaining to Product A. The vendor’s standard license
agreement contains the following provision: “The customer has
30 days from delivery to accept Product A. If the customer
does not accept Product A due to a defect in Product A, the
vendor has 15 days to cure the defect in Product A.” The
vendor is an established software company. Since the
introduction of Product A three years ago, there have been an
extremely small number of situations in which there has been a
defect in Product A. In all of these limited situations, the defect

23
Revenue Recognition for Software

was caused during shipment, and the vendor cured the defect
by shipping a new Product A. No concessions have been granted
in relation to the acceptance provisions. Also, there have been
no cases in the vendor’s history in which Product A was not
ultimately accepted by a customer.

Is the collection of fees probable upon the delivery of Product


A?

Although all the facts and circumstances would have to be


evaluated, it is likely that the vendor would be able to mitigate
the uncertainty surrounding the stated acceptance clause for
fee collectability and the license fee would be considered to be
fixed or determinable. Revenue may be recognised upon the
delivery of Product A, assuming that all other revenue recognition
criteria have been met.

2.27 If arrangement includes right to return or refund, then revenue


may be recognised only if the conditions for future returns or
refunds can be reasonably estimated. The existence of any
extended payment terms may indicate that the fee is not fixed or
determinable. If a software vendor does not have an established
business practice of granting extended payment terms and
collecting on such terms without forfeitures, refunds, or concessions,
revenue from arrangements with extended payment terms may be
recognised as the payments become due, assuming that all other
revenue recognition criteria are met.

2.28 However, if a vendor has standard business practice of using


extended payment terms and a history of successfully collecting
under the original payment terms without making concessions, it
may be concluded that extended payment terms are fixed or
determinable and the vendor should recognise all of the revenue
upon the delivery of the software, assuming that all other revenue
recognition criteria have been met.

Vendor V licenses software to customer Z with payment terms


of “due in 180 days.” V has been licensing this same software

24
Revenue Recognition Criteria

(including upgraded versions as available) over the past two


years. V’s typical payment terms for this software are “due in
thirty days.” However, V has provided payment terms of “due in
180 days” in connection with the sale of this software to
approximately 15 percent of its customers and has no history of
providing refunds or other concessions to these customers.
With the exception of the payment terms, the license agreement
with Z is the same as V’s standard license agreement.

Vendor V may consider the license fee to be fixed or


determinable and record revenue when all other revenue
recognition criteria have been met. Because V has established
a past practice of providing extended payment terms and has
no history of providing refunds or other concessions, the license
fee could be considered fixed or determinable. Factors such as
the volume of transactions (15 percent in this case) and the
similarity between the transaction with Z and previous
transactions provide sufficient evidence that the fee is fixed or
determinable.

Determining whether Fee is Fixed or Determinable


under Customer Cancellation Privileges

2.29 Fees from licenses cancelable by customers are neither fixed


nor determinable until the cancellation privileges lapse. If such
fees expire ratably over the license period then they may be
considered to become determinable ratably over the license period
as the cancellation privileges lapse. Cancellation privileges do not
include warranty clauses or short term rights of return.

2.30 No portion of the fee (including amounts otherwise allocated


to delivered elements) may be considered to meet the criterion of
collectability if portion of the fee allocable to delivered elements is
subject to forfeiture, refunds, or other concession if any of the
undelivered elements are not delivered.

25
Revenue Recognition for Software

Collection is Reasonably Assured

2.31 Probability of collection is the other condition to be met for


revenue recognition. To a large extent this condition depends on
credit worthiness of the customer. The assessment of collectability
is determined on the facts at the time of revenue recognition and
should be preferably documented. In the event that the fee included
within the arrangement is not considered to be collectible,
recognition of revenue may have to be deferred until collection
becomes reasonably assured.

2.32 It may be noted that determination as to whether fee is fixed


or determinable is made only once at the inception of the
transaction. In case collection is reasonably assured at the inception
of the transaction then revenue may be recognised, provided the
other revenue recognition criteria are met. However, if subsequent
to the sale a potential risk arises of collection of debts based on
current events surrounding customer or order, then a provision for
such bad or doubtful debt may have to be created.

26
3

Revenue Recognition when


Right of Return Exists

3.1 This section discusses the criteria for recognising revenue


on a sale in which a product may be returned, whether as a matter
of contract or as a matter of existing practice.

3.2 The product may be returned for a refund of the purchase


price, or for a rebate to be given against future or other purchases,
or in exchange of other products. The purchase price or rebate
may include amounts related to incidental services, such as
installation.

CRITERIA FOR REVENUE RECOGNITION


3.3 If an enterprise sells its product but gives the buyer the right
to return the product, revenue from the sales transaction should
preferably be recognised at time of sale if the following indicative
conditions are met:

(a) The seller’s price to the buyer is substantially fixed or


determinable at the date of sale.

(b) The buyer has paid to the seller, or the buyer is obligated
to pay to the seller and the obligation is not contingent
on resale of the product.
Revenue Recognition for Software

(c) The buyer’s obligation to the seller would not be changed


in the event of theft or physical destruction or damage
of the product.

(d) The buyer acquiring the product for resale has economic
substance apart from that provided by the seller.

(e) The seller does not have significant obligations for future
performance to directly bring about resale of the product
by the buyer.

(f) The amount of future returns can be reasonably


estimated.

3.4 If the above-mentioned indicative conditions are not fulfilled


at the time of sale, the revenue and costs of sales should preferably
be recognised either when the return privilege has substantially
expired or if those conditions subsequently are met, whichever
occurs first. Till that point, the recognition of the entire revenue
should generally be deferred. This accounting is not required to be
followed for like-kind exchanges.

3.5 Even though the ability to make a reasonable estimate of


the amount of future returns depends on many factors and
circumstances that will vary from one case to the other, the following
are some of the major factors identified that may impair the ability
to make a reasonable estimate:

(a) The susceptibility of the product to significant external


factors, such as technological obsolescence or changes
in demand.

(b) Relatively long periods in which a particular product


may be returned.

(c) Absence of historical experience with similar types of


sale of similar products, or inability to apply such
experience because of changing circumstances, for

28
Revenue Recognition when Right of Return Exists

example, changes in the selling enterprise’s marketing


policies or relationships with its customers.

(d) Absence of a large volume of relatively homogeneous


transactions.

SPECIFIC RIGHT OF RETURN


ARRANGEMENTS IN SOFTWARE
INDUSTRY
3.6 As part of an arrangement, a software vendor may provide
the customer with the right to return software or to exchange
software for products with no more than minimal differences in
price, functionality, or features.

3.7 The accounting for returns is significantly different from the


accounting for exchanges.

3.8 Arrangements that provide users with the right to exchange


software for other products should be evaluated to determine if
the exchange right would be accounted for as a return, an exchange
(i.e., like-kind exchange), or an additional software product as
discussed below.

3.9 If the software is not returned physically and the customer


contractually is entitled to continue to use the previously delivered
software, the arrangement should be accounted for in the manner
prescribed in the section hereinafter titled “Additional Software
Products”.

3.10 The determination of whether an exchange right would be


accounted for as an additional software product would be based
on factors such as whether the customer contractually is entitled
to continue using the originally delivered software rather than
returning the software physically to the vendor. If the arrangement
contractually permits the customer to continue using the originally
delivered software, the exchange right would be generally

29
Revenue Recognition for Software

accounted for as an additional software product because the


customer is entitled to use two products rather than one.

3.11 If the software is not returned physically and the customer


contractually is not entitled to continue to use the previously
delivered software, the transaction may be accounted for as a
return or an exchange, as discussed in the following paragraphs.

3.12 Rights to exchange software for products with no more than


minimal differences in price, functionality, or features are not returns
and, thus, are accounted for as like-kind exchanges. That is, the
exchange right has no effect on the revenue recognition related to
the delivered product. That accounting applies only to exchange
rights granted to end users of the software.

3.13 Conversely, exchanges by users of software products for


dissimilar software products or for similar software products with
more than minimal differences in price, functionality, or features
are considered returns, and revenue related to arrangements that
provide users with the rights to make such exchanges should be
accounted as explained in the following paragraphs.

3.14 If an enterprise sells its product but gives the buyer the right
to return the product, revenue from the sales transaction is
recognised at the time of sale only if general revenue recognition
criteria given in paragraph 3.4 are met provided a liability is
created for the estimated amount of returns.

3.15 The determination of whether a product has more than


minimal differences in price, functionality or features should be
based on the relevant facts and circumstances on a case-by-case
basis. Factors indicating that there may be more than minimal
differences in price, functionality, and features may include the
following:

(a) The product to be received has a different name than


the product to be surrendered.

30
Revenue Recognition when Right of Return Exists

(b) Marketing materials for the product to be received


promote significantly different functionality and features
than the product to be surrendered.

(c) The product to be received operates outside the


performance domain of the product to be surrendered.

(d) In independent transactions, the product to be received


is sold for a significantly different price than the product
to be surrendered.

ABC Corp. enters into an arrangement with a customer to deliver


Product A, a basic word processing software product, for a
non-refundable fee of Rs. 5000. In addition, ABC grants
customer the right to exchange Product A for Product B. Product
B is also a word processing software product and contains
essentially the same basic features and functionality of Product
A except that Product B also contains a grammar-check feature
that permits the user to check the grammatical consistency of
text. Product B is sold for Rs. 5200 in separate transactions.
Customer is not entitled to continue using Product A if Product
A is exchanged for Product B.

Generally, Product B would not be considered to have more


than minimal differences in price, functionality, and features
from Product A. Accordingly, assuming all other revenue
recognition criteria have been met, ABC could recognise revenue
of Rs. 5000 upon delivery of Product A. If customer exercises
the right to exchange Product A for Product B, it would not be
required to account for such exchange.

3.16 In addition to the factors indicating that there may be more


than minimal differences in price, functionality, and features, if the
vendor expects to incur a significant amount of development
costs related to the other products, the other products would
be considered to have more than minimal differences in
functionality.

31
Revenue Recognition for Software

Right of Exchange for Product not Available at the


Time of Delivery of Initial Product

3.17 A software arrangement may provide a user with the right to


exchange software for unspecified software products. Since the
future products are unspecified, it is unlikely that the vendor will
have evidence to conclude that the exchange right will qualify for
like-kind exchange accounting where the products will have no
more than minimal differences in price, features, and functionality
from the initial product. Such rights should be generally be
accounted for as rights of return.

ABC Corp. enters into an arrangement with a customer to deliver


Product A, a basic word processing software product, for a
non-refundable fee of Rs. 7500. In addition, ABC Corp. grants
the customer the right to exchange Product A for Product B,
which is expected to be released within the next 30 days. Product
B, which also is a word processing software product, contains
the same basic features and functionality of Product A except
that Product B also contains features and functionality that permit
the user to perform desktop publishing. ABC Corp. management
with relevant authority has determined that Product B will be
sold for Rs. 10,500, and it is probable that this price will not
change before introduction.

ABC Corp. can reasonably estimate that 40% of customers will


exercise the right to exchange Product A for Product B. The
customer is not entitled to continue using Product A if Product
A is exchanged for Product B.

Generally, Product B would be considered to have more than


minimal differences in price, functionality, and features from
Product A, and ABC Corp. would account for the right to
exchange Product A for Product B as a right of return.
Accordingly, assuming all other revenue recognition criteria have
been met, ABC Corp. would recognise revenue of Rs. 7500
upon delivery of Product A to customer and establish a provision
for returns of Rs. 3000 (Rs. 7500 x 40%) against revenue.

32
Revenue Recognition when Right of Return Exists

3.18 However, in situations where the (1) exchange right can be


exercised multiple times, and (2) the period of the exchange right
is potentially unlimited (e.g., the exchange right can be exercised
as long as the customer is a Postcontract Customer Support (PCS)
subscriber) or when the exchange right is significant in relation to
the economic life of the software, the arrangement should generally
be accounted for as a subscription. Under subscription accounting,
the entire fee would be recognised ratably over the term of the
arrangement beginning with the delivery of the first product.

ABC Corp. enters into an arrangement with a customer to deliver


Product A and grants the customer the right to receive full
credit for the license fee of Product A if the customer returns
that product and licenses any product introduced by ABC Corp.
in the Product A family over a two-year period. This return
provision can be exercised only once and the estimated
economic life of the Product A software is five years. If Product
A is returned, the customer is no longer entitled to use that
product.

Because the exchange right granted to the customer can be


exercised only once and is exercisable for a period of two
years, which is not considered significant in relation to the five-
year estimated economic life of Product A. ABC Corp. would
account for the right to exchange Product A for Product B as a
right of return.

If ABC Corp. can estimate the amount of future returns and the
remaining general criteria of revenue recognition when right of
return exists are met (as given in Paragraph 3.4), ABC Corp.
would recognise revenue upon delivery product A (provided
that all other general revenue recognition criteria are met), after
creating liability for estimated returns. If the general criteria,
when right of return exists are not met (e.g., ABC Corp. is
unable to estimate the amount of future returns), no revenue
should generally be recognised until the exchange period expires
in two years or the general criteria are met, whichever occurs
first.

33
Revenue Recognition for Software

ABC Corp. enters into an arrangement with customer to deliver


Product A and grants the customer the right to receive full
credit for the license fee of Product A if the customer returns
that product and licenses any product introduced by ABC Corp.
in the Product A family over a four-year period. This right can
be exercised an unlimited number of times during the four-year
exchange period. The estimated economic life of the Product A
software is five years. If Product A (or another product
subsequently acquired under the exchange provision of this
arrangement) is returned, the customer is no longer entitled to
use that product.

Because the exchange right granted to the customer can be


exercised multiple times and is exercisable for a period of four
years, which is considered significant in relation to the five-year
estimated economic life of Product A, ABC Corp. should be
accounted for the arrangement as a subscription. Accordingly,
the entire fee would be recognised ratably over the four-year
period (assuming that all other general revenue recognition
criteria are met) beginning with the delivery of Product A.

34
4

Customised Software

4.1 Software developed as per customer specification is referred


to as customised software.

4.2 Certain arrangement to deliver software or software systems


may include both software and service element. The services may
include training or installation services. If an arrangement includes
such services, a determination must be made as to whether the
service element can be accounted for separately as the services
are performed. Generally, for determining whether the service
element may qualify for separate accounting as a service certain
indicative factors may have to be established. These include
determination of fair value of the service element, services not
being essential to the functionality of any other element of the
arrangement and the contract being described in such a manner
such that the total price of the contract would be expected to vary
as a result of the exclusion of such services.

4.3 If an arrangement includes services that may qualify for


separate accounting based on the indicative factors given above
then revenue should be allocated between the software and service
element. Revenue allocated to the service element may be
recognised as and when the services are performed or, if no
pattern is discernable then on a straight line basis over the period
during which the services are performed. If the nature of the service
element does not qualify for separate accounting based on the
Revenue Recognition for Software

above indicative factors then the entire arrangement would have


to be accounted for as customised software.

4.4 The following are the illustrative factors which may indicate
that the service element is essential to the functionality of the
other elements of an arrangement:

• The software is not off-the-shelf software.

• The services include significant alterations to the


features and functionality of the off-the-shelf software.

• Services are always provided along with the software


and the software contains significant amount of new
codes.

• Building complex interfaces is necessary for the vendor’s


software to be functional in the customer’s environment.

• The timing of payments for the software is coincident


with performance of the services.

• Milestones or customer-specific acceptance criteria


affect the realisability of the software-license fee.

• Services of the vendor are considered as a key


differentiating factor by the customer.

4.5 The two common methods used under AS 9 to measure


revenue for customised software are the proportionate completion
method and the completed service contract method.

PRINCIPLES FOR RECOGNISING


REVENUE FROM CUSTOMISED
SOFTWARE
4.6 Classification of customised software- Based on pricing,
arrangements for customising software can be classified into:
36
Customised Software

(a) fixed-price or lump-sum contracts,


(b) cost-type (including cost-plus) contracts,
(c) time-and-material contracts, and
(d) unit-price contracts.

4.7 A fixed-price contract is a contract in which the party rendering


the service agrees to a fixed contract price, or a fixed rate per unit
of output, which in some cases is subject to cost escalation clauses.

4.8 A cost-plus contract is a contract in which the party rendering


the service is reimbursed for allowable or otherwise defined costs,
plus percentage of these costs or a fixed fee.

4.9 A time-and-material contract is a contract to perform all acts


required under the contract for a price based on fixed hourly rates
for some measure of the labour hours required.

4.10 A unit-price contract is a contract to perform all acts required


under the contract for a specified price for each unit of output.

RECOGNITION OF REVENUE AND COSTS


4.11 As per Para 7 of AS 9, Revenue Recognition, revenue from
service transactions is recognised as the services are performed.
Revenue from customised software can be recognised based upon
the principles of revenue recognition for a rendering of services by
applying the proportionate completion method or the completed
service contract method.

4.12 Revenue on contracts on time and material basis are usually


recognised as the services are performed based on the fixed hourly
rates and the labour hours expended as per the proportionate
completion method.

4.13 The determination of appropriate methods of accounting i.e.


proportionate completion or completed service contract methods
should be made based on careful evaluation of circumstances.
As per paragraph 7(ii) of AS 9, Revenue Recognition completed
service contract method of accounting is applied when either the
37
Revenue Recognition for Software

performance constitutes execution of a single act or when services


are performed in more than a single act and the services yet to be
performed are so significant in relation to the transaction taken as
a whole that performance cannot be deemed to have been
completed until execution of those acts.

4.14 As per paragraph 7(i) of AS 9, Revenue Recognition,


proportionate completion method of accounting is followed when
performance consists of the execution of more than one act. The
application of proportionate completion method involves three key
areas of estimates and uncertainties viz., determination of revenue,
cost and the extent of progress towards completion.

Revenue

4.15 Determination of contract revenue requires a careful analysis


of the contracts, particularly, if the contract includes guaranteed
maximums or assigns mark ups to costs.

4.16 An important issue in cost-plus contracts is determination of


amounts of chargeable expenses that should be reflected as
revenue. These expenses often include, but are not limited to,
expenses related to photocopies, telecommunications and facsimile
charges. The contract may contain certain clauses which need to
be evaluated to determine whether such chargeable expenses
would be included as a part of revenue.

Generally, if the chargeable expenses are not included as a part


of revenue than the vendors may have to reflect such recoveries
as reduction of costs.

Costs

4.17 Contract costs should be identified, estimated, and


accumulated with a reasonable degree of accuracy in determining
income earned. At any time during the life of a contract, total
estimated contract cost consists of two components: costs incurred
to date and estimated cost to complete the contract. A company

38
Customised Software

should be able to determine costs incurred on a customised


software with a relatively high degree of precision, depending on
the adequacy and effectiveness of its cost accounting system.

4.18 Contract costs would include:

• All direct costs and sub-contracting costs;

• Indirect costs identifiable with or allocable to the


customised software.

4.19 Costs that cannot be attributed to a customised software or


cannot be allocated to it are excluded from the costs of the software.
Such costs include general and administration costs and selling
costs.

Cost Adjustments Arising from Back Charges

4.20 Back charges are billings for work performed or costs incurred
by one party that, in accordance with the contract, should have
been performed or incurred by the party to whom it is billed. Back
charges to others should be recorded as receivables and, to the
extent considered collectible, should be applied to reduce contract
costs. However, if the billed party disputes the charge then it
should be treated as claim and recorded accordingly. Back charges
from others should be recorded as payables and as additional
contract costs to the extent that it is probable that the amounts will
be paid.

Estimated Cost to Complete

4.21 This is another component of total estimated contract costs.


Few points to be taken into consideration while making estimations
are:

• There should be periodic comparison of actual and


estimated costs.

39
Revenue Recognition for Software

• In estimating total contract costs, the quantities and


prices of all significant elements of cost should be
identified.

• The estimating procedures should provide that estimated


cost to complete includes the same elements of cost
that are included in actual accumulated costs; also,
those elements should reflect expected price increases.

• Escalation provisions should be considered particularly


when the contract is for long period.

• Estimates of cost to complete should be reviewed


periodically and revised as appropriate to reflect new
information.

4.22 Repeated estimations may indicate that the estimations are


not accurate and not finalised with the customer, thus reducing the
reliability.

Provisions for Anticipated Losses on Contracts

4.23 When the current estimates of total contract revenue and


contract cost indicate a loss, a provision for the entire loss on the
contract should be made in the period in which they become evident.
The provision for loss should be recognised in the statement of
profit and loss rather than as a reduction of revenue. If the provision
is material it should be shown as a separate line item. In the
Balance Sheet, it should be shown under the head ‘Current
Liabilities and Provisions’.

MEASURING PROGRESS TO
COMPLETION UNDER PROPORTIONATE
COMPLETION METHOD
4.24 Stage of completion of a contract can be determined based
upon either proportion of contract costs incurred to total costs,

40
Customised Software

surveys of work performed or based on completion of a physical


proportion of the contract work.

4.25 For determining the proportion of completion, in a software


industry, two approaches viz., input and output measures may be
followed.

Input Measures

4.26 Input measures are made in terms of efforts devoted to a


contract. They include the methods based on costs and on efforts
expended. A significant drawback of input measures is that the
relationship of the measures to productivity may not hold, as all
the efforts expended may not be productive.

4.27 Labour hours often are chosen as the basis for measuring
progress-to-completion, because they closely approximate the
output of labour-intensive processes and often are established
more easily than output measures. Under labour hours method
extent of progress is measured by the ratio of hours performed to
date to estimated total hours for completion. As software
development involves labour intensive customisation, labour hours
provide good measure of progress-to-completion on elements of
software arrangements that involve the customisation of software.

4.28 If the measurement of progress-to-completion is based


primarily on costs, the contribution to that progress of hardware
and software that were produced specifically for the arrangement
may be measurable and recognisable before delivery to the user’s
site. For example, efforts to install, configure, and customise the
software may occur at the vendor’s site. The costs of such activities
are measurable and recognisable at the time the activities are
performed.

Output Measures

4.29 Output measures are made in terms of results achieved.


They include methods based on units produced, units delivered,

41
Revenue Recognition for Software

contract milestones, and value added. Output is used to measure


results directly and is generally considered the best method of
progress toward completion in circumstances in which a reliable
measure of output can be established. However, output measures
often cannot be established, in such cases input measures are
used.

4.30 As a general rule, when estimates of costs to complete and


extent of progress toward completion of contract are reasonably
dependable and outcome of the contract can be estimated reliably,
the proportionate completion method is followed. When lack of
dependable estimates or inherent hazards cause forecasts to be
doubtful, then revenue should be recognised in the following
manner:

• Revenue should be recognised only to the extent of


contract costs incurred of which recovery is probable;
and

• Contract costs should be recognised as an expense in


the period in which they are incurred.

42
5

Multiple-Element Arrangements

5.1 Many entities offer multiple solutions to their customers’


needs. Those solutions may involve the delivery or performance of
multiple products, services, or rights to use assets, and performance
may occur at different points in time or over different periods of
time. In some cases, the arrangements include initial installation,
initiation, or activation services and involve consideration in the
form of a fixed fee or a fixed fee coupled with a continuing payment
stream. The continuing payment stream generally corresponds to
the continuing performance, and the amount of the payments may
be fixed, variable based on future performance, or a combination
of fixed and variable payment amounts.

5.2 A multiple-element software arrangement is any arrangement


that provides the customer with the right to software along with
any combination of additional software deliverables, services, post-
contract customer support (PCS), and non-software deliverables.
Non-software deliverables may include such things as hardware,
peripherals, services unrelated to software deliverables, or other
deliverables. The question is when to include non-software
deliverables with other elements and when should they be
accounted as separate units of accounting.

DETERMINATION OF MULTIPLE-
ELEMENTS IN A CONTRACT
5.3 A vendor should evaluate all deliverables in an arrangement
Revenue Recognition for Software

to determine whether they represent separate units of accounting.


That evaluation must be performed at the inception of the
arrangement and as each item in the arrangement is delivered.

5.4 In an arrangement with multiple-deliverables, the delivered


item(s) may be considered as a separate unit of accounting if the
following criteria are met:

• The delivered item(s) has value to the customer on a


standalone basis. That item(s) has value on a
standalone basis if it is sold separately by the vendor
or the customer could resell the delivered item(s) on a
standalone basis.

• Reliable fair values of the undelivered item(s) can be


determined.

• If the arrangement includes a general right of return


relative to the delivered item(s), and delivery or
performance of the undelivered item(s) is considered
probable and substantially in the control of the vendor.

5.5 Separate contracts with the same entity or related parties


that are entered into at or near the same time are presumed to
have been negotiated as a package, and, therefore, may be
evaluated as a single arrangement in considering whether there
are one or more units of accounting. That presumption may be
overcome if there is sufficient evidence to the contrary.

Sale of Computer License

Company B sells computer licenses. On March 20, a customer


purchases a computer license from Company B for Rs. 1,000
together with implementation services and training charges for
the license.

On March 31, Company B delivers the license to the customer.


The implementation services are carried out from April 1 to

44
Multiple-Element Arrangements

June 30. Training services are carried out for two months from
July 1 to August 31. Company B also sells training services
separately for Rs 200, but the license and implementation are
always sold together. The arrangement does not include any
general rights of return. Company B is evaluating whether
delivery of the license represents a separate unit of accounting.

Evaluation:

• The separation criterion is not met for the license


alone, as it is always sold together with implementation
services.

• Further fair values of the undelivered implementation


services need to be independently developed and in
the absence of the same the license may not be
considered as a separate element.

• There are no general rights of return.

• In the absence of fair value of implementation services


separately, delivery of license cannot be considered
as a separate element.

5.6 The following aspects of multiple-element arrangements have


been dealt with in this chapter:

(i) General guidelines for revenue recognition for multiple-


element arrangements

(ii) Measurement and allocation of arrangement


consideration

(iii) Fair value determination

(iv) Specified upgrades, enhancements and platform transfer


rights

45
Revenue Recognition for Software

(v) Additional products

(vi) Specified versus unspecified additional software


products

GENERAL GUIDELINES FOR REVENUE


RECOGNITION FOR MULTIPLE-ELEMENT
ARRANGEMENTS
5.7 General guidelines for revenue recognition for multiple-
element arrangements are as follows:

• Revenue arrangements with multiple deliverables should


be divided into separate units of accounting if the
deliverables in the arrangement meet the separate
identification criteria specified in paragraph 5.4.

• Revenue recognition criteria should be applied to


each separately identifiable component of a single
transaction to reflect the transaction’s substance.
However, in applying those criteria, the delivery of an
element is considered not to have occurred if there are
undelivered elements that are essential to the
functionality of the delivered element, because the
customer would not have the full use of the delivered
element. In software industry reliable determination of
fair values for each of the separately identifiable
elements is usually essential to reasonably determine
the price for such elements, which is one of the
conditions for revenue recognition.

• Arrangement consideration should be allocated among


the separate units of accounting based on their relative
fair values or by application of the residual method.

46
Multiple-Element Arrangements

MEASUREMENT AND ALLOCATION OF


ARRANGEMENT CONSIDERATION
5.8 The consideration may be allocated to the elements of the
arrangement based on Relative Fair Value Method or the Residual
Method.

Relative Fair Value Method

5.9 If the fair value can be reliably determined for all units of
accounting, the consideration should be allocated to separate units
of accounting based on relative fair values. Contractually stated
prices for individual products and/or services in an arrangement
with multiple deliverables may not be presumed to be representative
of fair value.

5.10 Fair value evidence often consists of specific objective


evidence (SOE) of fair value obtained from entity’s own sources
(vendor specific) or from market place participants or fair value
can be reliably determined by the entity in some other manner,
e.g., by deriving an estimated selling price that would be expected
to cover the costs of services under the agreement together with a
reasonable profit on those services. Only in the absence of SOE,
other ways of determining fair values should be used by the entity
for allocation of consideration to each separately identifiable
component. For revenue to be recorded for the delivered elements,
the amount allocated to delivered elements may not be subject to
a future adjustment. The portion of the fee that is allocated to an
element should generally be recognised as revenue when all of
the criteria for revenue recognition have been met with respect to
that element. If reliable fair value of each of the element does not
exist, all revenue from the arrangement should be deferred until
the earlier of when:

(i) Such evidence does exist for each element, or

(ii) All elements have been delivered, or

47
Revenue Recognition for Software

(iii) The reliable fair values of the undelivered elements can


be determined.

As stated earlier, fair value of an element can also be determined


in some other manner, e.g., by considering an estimated selling
price which would be expected to cover the costs of services under
the agreement together with a reasonable profit on those services.

5.11 However, the following situations may be considered as


exceptions:

• If the only undelivered element is Postcontract Customer


Support (PCS), the deferred amount may be recognised
ratably over the contract period;

• If the only undelivered element consists of services that


do not involve significant production, modification, or
customisation of software (for example training or
installation), the deferred amount may be recognised
over the period during which the services are expected
to be performed;

• If the arrangement is for additional software products


and provides for a specified price per copy and an
allocation of the fee cannot be made at the outset,
revenue may be recognised as copies are made by the
customer (or furnished to the customer). If the vendor
is duplicating the software, once the vendor has
delivered the product master (or the first copy of all
products covered by the arrangement), any licensing
fees that were not previously recognised should be
recognised.

• If in substance the arrangement is a subscription, the


entire fee may be recognised ratably.

• If it appears that the portion of the fee allocated to an


undelivered element may not be sufficient to cover the
vendor’s costs for delivering that element of the
48
Multiple-Element Arrangements

arrangement, a loss needs to be recognised


immediately.

Specific Objective Evidence

5.12 Specific Objective Evidence may generally be established


with;

• Price charged when the same element is sold separately


by the entity (vendor specific); or

• Price charged by the vendor or any competitor’s largely


inter-changeable products or services in sales to similarly
situated customers (market place participants); or

• Price established by management having the relevant


authority for an element not yet being sold separately;
it must be probable that the price, once determined, will
not change before the separate introduction of the
element into the marketplace.

5.13 If vendor specific evidence is available then the same should


be considered, if not, then evidence from market place participants
should be considered and the last priority should be given to price
determined by management.

5.14 SOE may generally be limited to the above mentioned three


conditions. If SOE of fair value for all elements becomes available
prior to the date when all deliverables are provided under the
contract, the revenue could be recognised for the delivered
elements on the date when the SOE of fair value becomes known.

5.15 It should be noted that separate prices in contracts or list


prices may not be indicative of the SOE of fair value of related
elements. Hence, the fee from a software arrangement with multiple
elements should be allocated to the various elements based on
SOE of fair value of those separate elements, regardless of the
separate prices for each element stated within the contract. When
SOE of the fair value of the elements of a software arrangement is
49
Revenue Recognition for Software

being determined, all of the factors that the vendor used in


determining its pricing should be documented. The vendor may
base its pricing on factors such as the number of products delivered,
number of copies made or to be made, number of users, type of
customer, etc.

5.16 In most instances, SOE of fair value will be an average price


of several recent, actual transactions that are priced within a
reasonable range. There could be more than one fair value for a
given product because of the variety of considerations that impact
the pricing in an arrangement for that element. The considerations
may be, for instance, the fair value differs on type of vendors, type
of customer, channel of distribution or different fair value for same
product in different geographical territories.

5.17 SOE of fair value should be analysed on an annual basis,


unless there is a significant change in a company’s business that
may necessitate a more timely analysis. If SOE of fair value is
established after the balance sheet date but before the issuance
of financial statements, then that SOE should not be considered to
exist as on the balance sheet date.

5.18 Generally, vendors need to have a significant amount of


sales for it to be proved that a class of customers has sufficient
SOE of fair value.

Residual Method

5.19 In case of software arrangements in which the fair values for


the undelivered elements have been reliably determined, but fair
values do not exist for delivered elements, the amount of the
arrangement fee allocated to the delivered elements is measured
based on the difference between the arrangement fee and the fair
value of the undelivered elements. When discounts are offered
then these should be allocated to all elements in transaction.

A vendor provides one user-license covering a single copy of


products A, B, C, and D for a non-refundable fixed fee of

50
Multiple-Element Arrangements

Rs.800, with no stated price per product. Products A, B, and C


are delivered. Product D is not delivered and is not essential to
the functionality of products A, B, or C. Evidence exists that
indicates that the revenue related to products A, B, or C is not
subject to refund, forfeiture, other concessions if product D is
not delivered. The vendor has a history of sales prices for
products A, B, and C of Rs.250 each. The vendor’s pricing
committee has determined a price for product D of Rs.250. It is
probable that the price determined by the pricing committee for
product D will not change before introduction. Therefore, the
vendor is able to derive its specific price for the undelivered
software.

Revenue allocated to each product may be recognised upon


the delivery of that product if all revenue recognition criteria
have been met. The allocation of revenue to each product is
based on the relative fair values of each product. The fair value
of each product should be reliably determined to determine
allocation. In this example, sufficient specific objective evidence
exists to determine that the fair value of each product on a
stand-alone basis is Rs.250. Therefore, the discount should be
allocated evenly to each product, and revenue of Rs.200 per
product should be recognised when each product is delivered.

A vendor offers an arrangement that includes a license for an


accounting program and one year of PCS. The total fee for the
arrangement is Rs.115,000. The vendor does not have SOE of
the fair value of the accounting program, as it is always licensed
with PCS. The vendor always sells renewal PCS for Rs.15,000
and has sufficient evidence to support that price as a fair value.

What amount of revenue would the vendor be able to recognise


upon the delivery of the accounting program?

The vendor knows the SOE of the fair value of the undelivered
element (Rs.15,000) and has a total contract fee of Rs.115,000.
The revenue related to the accounting program (Rs.100,000)
can be derived through the residual method (Rs.115,000 -

51
Revenue Recognition for Software

Rs.15,000 = Rs.100,000) and recorded upon the element’s


delivery, assuming that all other revenue recognition criteria
have been met.

A vendor sells Product A separately, but always sells Product B


with Product C. The vendor enters into a contract to sell Products
A, B and C. Product A will be delivered immediately on 12/1/X2
and Products B and C will be delivered on 2/1/X3. SOE exists
for Product A, but not for Products B and C separately. Fair
values for products B and C have not been reliably determined.
Can any revenue be recognised upon delivery of Product A?

Yes. Although the vendor never sells Product B and C separately


and therefore SOE of fair value does not exist for each product,
the vendor does have SOE of fair value for the combined B and
C offering, as B and C are always sold together. In this case,
the vendor can consider the B and C combination as one
element instead of two. The vendor would allocate the entire
arrangement fee based upon the relative SOE of fair value for
Product A and the Product B and C combination and record the
pro rata amount of revenue related to Product A upon delivery
of Product A.

ACCOUNTING FOR FREE SOFTWARE


5.20 Some hardware and software vendors offer free software on
their Web sites. This free software generally is downloaded from
the vendor’s Web site for use on the vendor’s hardware or in
conjunction with other software being sold by the vendor. This
software may be developed by vendor, or vendor pays others to
develop the software or vendor obtains the software without charge
and offers it without charge.

5.21 The offer of free software by a vendor (specified software)


constitutes an “element” that affects revenue recognition for other
products, when an arrangement entered between a vendor and a
customer specifies that free software products will be provided in

52
Multiple-Element Arrangements

the future even if they will be provided on a when-and-if-available


basis.

5.22 However, if a vendor offers free software to both customers


and non-customers then the free software would not be considered
in evaluating the accounting for a specific arrangement since the
customer would have the right to download the software regardless
of its current arrangement with the vendor.

Vendor V produces hardware consoles that are sold with


software installed and the software is more than incidental to
the product. V posts a software program on its Web site. The
program works on multiple platforms and does not require the
user to be a customer of V to access or use the software.
Finally, there is no requirement to have purchased hardware
from V prior to downloading the software from V’s Web site. In
this example, there would be no impact on revenue recognition
since the software can be accessed and used independent of
V’s hardware console and is available to anyone who accesses
the Web site.

Vendor V produces hardware consoles that are sold with


software installed and the software is more than incidental to
the product. V has been approached by programmer P who
wishes to place a new software product on V’s Web site. P is
giving the software away (i.e., free software) and V has not
paid any amounts to P, nor is V requiring any payments from
those who download the program. In this example there would
be no impact on revenue recognition regardless of whether the
program can be used on platforms other than V’s. P is actually
providing the software and is merely using V’s Web site to
distribute the program.

Vendor V produces hardware consoles that are sold with


software installed and the software is more than incidental to
the product. V distributes programs to current V customers that
are useable only on V’s hardware platform.

53
Revenue Recognition for Software

In this example, it is likely there may be an impact on revenue


recognition since the software cannot be used independent of
V’s hardware console, and is therefore, useable only by V’s
customers. Based on this fact, V has created an expectation in
its customers that additional products will be delivered free of
charge, and therefore, revenue recognition would be affected.

MAXIMUM NUMBER OF COPIES


5.23 There are certain arrangements wherein the customer is
entitled to a maximum number of copies although there is no
delivery at the inception of the arrangement. In this situation revenue
should be allocated to delivered products when the first or master
copy is delivered. A portion of fee should be allocated to
undeliverable products assuming the customer will elect to receive
the maximum number of copies of the undeliverable product. If,
during the term of the arrangement, the customer reproduces or
receives such number of copies of these delivered products so
that revenue allocable to the delivered products exceeds the
revenue previously recognised, such additional revenue should be
recognised as the copies are reproduced or delivered. The revenue
allocated to the undeliverable product(s) is reduced by a
corresponding amount.

5.24 Intent on the part of the vendor not to develop new products
during the term of the arrangement does not relieve the vendor of
the requirement to recognise revenue ratably over the term of the
arrangement or the economic life of product package if no term is
stated, beginning with the delivery of the first product.

RIGHT OF RETURN IN A MULTIPLE-


ELEMENT ARRANGEMENT WHEN FAIR
VALUES CAN BE RELIABLY DETERMINED
5.25 A vendor may enter into a multiple-element arrangement
that involves a right of return or exchange accounted for as a
return. For example, the arrangement may include multiple software
54
Multiple-Element Arrangements

products, one of which is subject to a right of return, and PCS or


other services. The multiple-element arrangement fee should be
allocated to the elements based on fair values. A right of return is
not considered to be a separate element of an arrangement for
purposes of revenue allocation. However, the provisions relating
to right to return would be applied to the revenue allocated to that
element of the arrangement that is subject to the right of return.

ABC Corp. enters into an arrangement with a customer to


deliver Product A and Product B for a non-refundable fee of
Rs. 1,000,000. In addition, the customer is granted the right to
exchange Product B for Product C, which has more than a
minimal difference in functionality. Fair values for Products A
and B are Rs. 900,000 and Rs. 600,000, respectively.
Accordingly, ABC Corp. allocates revenue of Rs. 600,000 to
Product A (Rs. 900,000/Rs. 1,500,000 x Rs. 1,000,000) and
Rs. 400,000 to Product B (Rs. 600,000/Rs. 1,500,000 x Rs.
1,000,000). Product A is delivered immediately, and Product B
is delivered three months later. ABC can reasonably estimate
that 10% of customers will exercise the right to exchange Product
B for Product C.

Assuming all other revenue recognition criteria are met, ABC


Corp. would recognise revenue attributable to Product A (Rs.
600,000) upon delivery of Product A. The revenue attributable
to Product B (Rs. 400,000) would be recognised upon delivery
of Product B, and the related liability for returns (Rs. 40,000)
would be established as a reduction of revenue when Product
B is delivered.

RIGHT OF RETURN IN A MULTIPLE-


ELEMENT ARRANGEMENT WHEN FAIR
VALUES CANNOT BE RELIABLY
DETERMINED
5.26 If a vendor enters into a multiple-element arrangement that
includes multiple software products and an exchange right

55
Revenue Recognition for Software

accounted for as a right of return related to only one of the products,


and if reliable fair value cannot be determined, for the product
subject to the exchange right, a question arises as to when revenue
from the arrangement should be recognised because the vendor
may be able to reasonably estimate the amount of returns and
determine the monetary value attributable to those returns prior to
recognising revenue for the arrangement.

5.27 In order to estimate the amount of returns related to only


one product in a multiple-element arrangement and to quantify the
monetary value of those returns, the vendor should be able to
reasonably determine the amount of the arrangement fee
attributable to the product subject to the right of return.

5.28 If a vendor can not reliably determine fair value for the product
in the arrangement to which the right of return relates, the vendor
will generally be unable to make a reasonable estimate of the
amount of returns (i.e., in monetary terms), and thereby may have
to defer revenue until the right of return lapses.

5.29 If the residual method is applied to the arrangement because


fair value can be reliably determined for all undelivered elements
and the product subject to the right of return is the only delivered
element, then the amount allocated to that product under the
residual method may be used to quantify the monetary value of
the estimated returns.

5.30 However, if the vendor is able to reasonably estimate the


amount of returns and if the arrangement specifies that cash refunds
will be provided for the amount of the return, the amount provided
for estimated returns should reasonably approximate the amount
of cash that will be refunded or forfeited as a result of the return.

ABC Corp. enters into an arrangement with a customer to deliver


Product A and Product B for a non-refundable fee of Rs.
1,000,000. In addition, the customer is granted the right to
exchange Product B for Product C, which has more than a
minimal difference in functionality from the functionality expected

56
Multiple-Element Arrangements

in Product B. ABC Corp., does not sell separately Products A


and B, and, therefore, does not have SOE of fair values to
allocate the arrangement fee to the individual products and is
neither able to reliably determine the fair value for the individual
products. However, the prices stated in the arrangement for
Product A and Product B are Rs. 300,000 and Rs. 700,000,
respectively. Product A is delivered immediately, and Product B
is delivered three months later. Historically, approximately 20% of
the Product B units sold with this exchange right have been
returned.

As ABC Corp. can not reliably determine the fair value to allocate
the arrangement fee to Product A and Product B, the entire
arrangement fee should be deferred until the earlier of: (1) the
date when both Products A and B have been delivered and the
customer exercises the right to exchange Product B for Product
C or the exchange right expires, whichever occurs first, or (2)
fair value, is established for Product B.

SPECIFIED UPGRADES, ENHANCEMENTS


AND PLATFORM TRANSFER RIGHTS
5.31 Upgrade is an improvement to an existing product that is
intended to extend the life or improve significantly the marketability
of the original product through added functionality, enhanced
performance, or both. The terms upgrade and enhancement are
used interchangeably to describe improvements to software
products; however, in different segments of the software industry,
these terms may connote different levels of packaging or
improvements.

5.32 Upgrade right is the right to receive one or more specified


upgrades or enhancements, even if it is offered on a when-and-if-
available basis. If an upgrade right is offered on a when-and-if-
available basis then it is considered as Postcontract Customer
Support (PCS).

5.33 Rights to unspecified upgrades on a when-and-if-available


basis are included within Postcontract Customer Support (PCS).
57
Revenue Recognition for Software

5.34 The upgrade right may be evidenced by a specific agreement,


commitment, or the vendor’s established practice. Specified upgrade
rights should generally be accounted for as separate elements
and, therefore, should be allocated a portion of the fee based on
the fair value of the upgrade. When a vendor is allocating an
arrangement fee based on the fair value of the elements that are
covered by the arrangement, the value that is to be assigned to a
specified upgrade right is usually the price that will be charged to
existing users of the software upon it being upgraded.

5.35 License arrangements may include rights to specified


upgrades or enhancements. Such rights may be evidenced by a
specific agreement, commitment, or the vendor’s established
practice. Allocation of revenue to the specified upgrade or
enhancement is required even if the customer will be entitled to
receive the upgrade or enhancement under PCS, because the
obligation is specified. However, the amount allocated may be
reduced for the percentage of licenses that are not expected to be
upgraded if sufficient evidence exists to support this expectation.
If the vendor does not have sufficient evidence to estimate the
percentage, then it may be presumed that all customers would
exercise the upgrade right. The estimate of the number of
customers who will take advantage of an upgrade needs to be
periodically reviewed.

5.36 If an arrangement includes discounts, such discount


should generally not be allocated to specified upgrade rights in the
software industry.

A vendor offers a software package over the Internet for Rs.35.


The customer is advised that an upgrade of the software
package will be released in 60 days, and, as part of the licensing
arrangement, the customer will receive the right to license the
upgrade for Rs.10. The fair value of the software package is
Rs.35 (without the upgrade). The vendor believes that minimal
effort will be required to develop the upgrade, as the upgrade is
being designed only to allow the program to take advantage of
improved operating systems. The upgrade will be marketed to

58
Multiple-Element Arrangements

existing users for Rs.15, which represents the fair value of the
upgrade. The vendor expects that the customer will exercise
the upgrade right.

What amount of revenue would the vendor be able to recognise


once all of the revenue recognition criteria for the original version
have been met?

In this case, the vendor has determined the fair values of the
original version and of the upgrade - Rs. 35 and Rs.15,
respectively. However, the total fee from the arrangement is
only Rs. 45, so there appears to be a Rs. 5 discount involved in
the transaction. The entire Rs.15 is deferred until the delivery
of the specified upgrade, with the remaining Rs.30 (Rs. 35 –
Rs. 5) being recognised with the delivery of the original software.
This effectively allocates the entire discount to the delivered
element and not to the specified upgrade right.

Vendor A currently is in negotiation with a customer to sell


customer B a license for Version 2.0 of A’s software product.
During the negotiations, the sales representative for A learns
that B is looking for certain functionality in the product. The
sales representative notifies B in writing that while the
functionality currently is not available, it will be included in the
next version of the product, which is expected to be available
within the next three months and that B will be entitled to that
version under its PCS arrangement.

B agrees to purchase Version 2.0 and an annual PCS


agreement. The signed agreement does not discuss explicitly
the additional functionality promised by the sales representative.
However, in the absence of evidence to the contrary, A has
implicitly granted a specified upgrade right to B based on the
correspondence from the sales representative which created a
reasonable expectation that the desired functionality would be
available in the next version of the product. As such, the specified
upgrade right would be treated as a separate element of the
arrangement.

59
Revenue Recognition for Software

Revenue would need to be deferred until such time as A


determines fair value of all undelivered elements or until such
time as all the elements are delivered and all other requirements
for revenue recognition have been met.

SPECIFIED UPGRADES THAT WILL BE


INCLUDED AS PART OF PCS, WITH NO
SEPARATE CHARGE
5.37 The method of recognising revenue for upgrade right on the
basis of its fair value applies when upgrade rights are licensed
separately. Many vendors make major upgrades available to
customers without charging an upgrade fee, as the upgrades are
included as part of PCS (described later). In this situation, no fair
value can be determined for undelivered specified upgrade and
hence no revenue from the arrangement can be recorded until the
upgrade is delivered. It is not appropriate to allocate zero value to
an upgrade right that is specified in the contract but that will be
made available for free to customers paying for PCS. The upgrade
right is specified and therefore cannot be accounted for as PCS.

A vendor licenses its payroll product along with a one-year PCS


contract. The vendor also sells renewal-period PCS contracts.
Under the PCS contracts, the vendor’s business practice is to
provide updates for changes in tax laws and other reporting
requirements that may arise during the period that the payroll
software is under a PCS contract. The vendor also specifically
states in its PCS contracts that, as necessary, it will update the
payroll software for changes in tax laws. The vendor specifically
states it will update software for necessary changes.

Does the PCS contract involve a specified upgrade right?

Specified upgrade rights generally relate to upgrades and


enhancements that are known or expected. In the above
example, the potential updates for changes in tax laws are not
known, because they are outside the control of the vendor.

60
Multiple-Element Arrangements

Additionally, upgrade rights must be stated on a “when-and-if-


available” basis in order to qualify as PCS. Although this is not
explicitly stated in the above example, the upgrade or
enhancement would not be delivered unless there were changes
in tax laws, etc., that would result in the vendor’s providing an
update. Because possible changes in tax laws are outside the
control of the vendor, the upgrade right is implicitly on a when-
and-if-available basis. Further, the need to implement the change
would be required with respect to the vendor’s ongoing product
offering, and it is not likely that the required efforts would be
significant relative to the original development effort; therefore,
the incremental cost should be minimal. Although specific facts
need to be considered in each situation, the right in this example
could be considered an unspecified upgrade right and accounted
for as PCS.

A vendor may license a software product to a customer and, at


no additional charge, promise the customer a specified upgrade
on a when-and-if-available basis as long as the customer is
current on PCS. The vendor has determined the fair values for
the software license and for PCS. If the vendor is offering the
specified upgrade for free to all of its customers that are current
on PCS, can the vendor account for the specified upgrade as
part of PCS?

No. The specified upgrade is a separate element. It is not PCS.


If the vendor can not determine fair value for the specified
upgrade, no revenue should be recognised until one of the
following occurs: (a) the specified upgrade is delivered, (b) fair
value for the specified upgrade can be reliably determined, (c)
or the specified upgrade right expires; and all other requirements
for revenue recognition have been met.

PLATFORM-TRANSFER RIGHTS
5.38 Platform-Transfer Right (PTR) is the right granted by a vendor
to transfer software from one hardware platform or operating system
to one or more other hardware platforms or operating systems. It
61
Revenue Recognition for Software

can be treated as an exchange, a return or additional software


product depending on the circumstances and revenue is recognised
accordingly.

(i) PTR is treated as additional software product in case


where customer is entitled by contract to continue to
use originally delivered software in addition to software
delivered because of PTR.

(ii) PTR is generally to be treated as exchange for a like-


kind product, if

• PTR is for same product,

• Does not increase the copies of product or


concurrent users available under license
arrangement.

• The products involved must also be “marketed as


the same product.”

5.39 If the platform-transfer right does not qualify for like-kind


exchange accounting, the platform-transfer right would be
accounted for as a return.

ABC Corp. enters into an arrangement with a customer to deliver


Software Product X on Platform A (Platform A software) and
grants the customer the right to exchange the Platform A
software for Software Product X on Platform B (Platform B
software) when-and-if-available. The customer may continue to
use the Platform A software if the platform-transfer right is
exercised. The Platform B software has no more than minimal
differences in price, features and functions from the Platform A
software and the two products are marketed as the same
product.

Because the customer is entitled to continue to use the Platform


A software in addition to the Platform B software, the Platform

62
Multiple-Element Arrangements

B software would be accounted for as an additional software


product. Accordingly, the arrangement would be treated as a
multiple-element arrangement, and the license fee would be
allocated to the Platform A software and the Platform B software
based on their relative fair values.

Assume the same facts as in the example given above, except


that the customer contractually is not entitled to continue to use
the Platform A software if the customer exercises the platform-
transfer right. Because the Platform B software would meet the
criteria to be considered the same product as the Platform A
software and the platform- transfer right does not increase the
number of copies or concurrent users of the software, the
platform-transfer right would be accounted for as a like-kind
exchange. Accordingly, assuming all other general revenue
recognition criteria are met, ABC Corp. would recognise revenue
from the arrangement upon delivery of the Platform A software.

Platform-Transfer Right for Unspecified Platform


Software Products

5.40 A software arrangement may provide a user with a platform-


transfer right for an unspecified platform. If the criteria for exchange
accounting (discussed in paragraph 5.38 above) are met, then
PTR should be accounted as per the provisions related to exchange
accounting. If PTR does not satisfy the criteria for exchange
accounting, the entire fee would be recognised ratably over the
term of the arrangement beginning with the delivery of the first
product.

ABC Corp. enters into an arrangement with a customer to deliver


Software Product X on Platform A (Platform A software) and
grants the customer the right to exchange the Platform A
software for Software Product X on a different operating system.
The different operating system is not specified in the
arrangement.

ABC has granted the customer an unspecified platform-transfer

63
Revenue Recognition for Software

right that does not expire, so this arrangement would not qualify
for exchange accounting. Given the unlimited time period, there
is a high likelihood that the product received upon an exchange
would contain more than minimal differences from Platform A
software with respect to price, features, and functionalities.
Accordingly, revenue should be recognised ratably over the
estimated economic life of the products (as no term is specified),
beginning with delivery of the first product assuming the
remaining revenue recognition criteria are met.

Exchange and Platform-Transfer Rights for


Specified Products Currently Available

5.41 If a right that is included in an arrangement meets the criteria


for exchange accounting discussed in paragraph 5.38, recognising
revenue upon the delivery of the initial product is appropriate,
assuming that all other revenue recognition criteria have been met
and the products and/or platforms eligible for exchange are currently
available.

Exchange and Platform-Transfer Rights for


Specified Products not Currently Available

5.42 If the other product(s) is/are not available at the time the
initial product is delivered, there should be evidence that
demonstrates there will be no more than minimal differences in
price, features, or functionality among the products in order for the
right to qualify as a right to exchange. Further, if the vendor expects
to incur a significant amount of development costs related to the
other product, the other product may be considered to have more
than a minimal difference in functionality.

5.43 Exchanges by users of software products for dissimilar


software products or for similar software products with more than
minimal differences in price, functionality, or features should be
accounted for as right to return.

64
Multiple-Element Arrangements

Delivery of Unspecified Software including


Unspecified Platform Transfer Rights

5.44 As part of multiple arrangement if a vendor agrees to deliver


software currently and deliver unspecified software products in
future including unspecified transfer rights, then software elements
do not qualify for exchange accounting and hence should be
accounted for as subscription accounting. In subscription accounting
no allocation of revenue would be made among any of the software
products, and all software product-related revenue from the
arrangement would be recognised ratably over the term of the
arrangement (if term is not stated, then revenue should be
recognised over the economic life of the product) beginning with
delivery of the first product.

On September 30, X1, a vendor enters into a licensing


arrangement with a customer for Product X, which is operating
on Platform A (the platform that is currently being used by the
customer), for Rs. 750,000. Pursuant to the terms of the
arrangement, the vendor delivers Product X. The arrangement
also contains a provision that the customer can exchange its
current version of Product X for another version of Product X
that operates on a different operating system. The different
operating system is not specified in the arrangement.

Would the arrangement qualify for exchange accounting? Can


the vendor recognise the Rs.750,000 on September 30, X1?

The customer has been granted an unspecified platform-transfer


right that does not expire. Due to extended time lines, it may be
difficult for the vendor to establish that the features, functionality
and pricing of the new product will be the same as the original.
This arrangement would not qualify for exchange accounting
and consequently all software-related revenue from the
arrangement would be recognised over the term of the
arrangement beginning with the delivery of the first product. As
the term of the arrangement is not stated, the revenue would
be recognised ratably over the estimated economic life of the

65
Revenue Recognition for Software

products. Intent on the part of the vendor not to develop new


products during the term of the arrangement does not relieve
the vendor of the requirement to recognise revenue ratably.

Vendor X develops and distributes self-study information


technology training courses. X enters into an arrangement with
Customer Y under which Y can request any of the courses in
X’s library during the two-year term of the arrangement. Payment
for the arrangement is due 30 days subsequent to the execution
of the arrangement. How would revenue be recognised in this
situation?

If all other requirements for revenue recognition have been


met, X would recognise revenue, on the arrangement ratably
over the term of the arrangement beginning with the delivery of
the first course (i.e., subscription accounting).

ADDITIONAL PRODUCTS
5.45 In practice, software arrangements often include the right to
obtain specified additional products that are often similar to specified
upgrade rights. A great deal of judgment must be exercised in
evaluating whether an undelivered element represents an upgrade
or a new product, because their accounting is very different. In
case the product is an upgrade no portion of the discount is
allocated to such upgrade rights whereas discounts can be allocated
to additional products.

• If the new features do not enhance the basic functionality


of the software, but rather, can operate independently
from the previously delivered software, this may indicate
that the right relates to a product and not an upgrade.

• An additional software product generally does not


supersede or replace the delivered element, whereas
an upgrade frequently does.

66
Multiple-Element Arrangements

5.46 The following indicative factors may help to determine whether


the undelivered element is specified upgrade or new product:

(a) Pricing: New features and functionality that will


substantially increase the price of the delivered product
may indicate that the right to receive these new features
and functionality relates to an additional software
product. Conversely, if the new features and functionality
would provide the vendor only with the ability to keep
prices at a constant rate, the right to receive these
would be considered an upgrade. The magnitude of
the upgrade fee should also be considered. Upgrade
rights are frequently priced at 10% to 20% of the original
license fee when sold separately to existing users.

(b) Development effort: The more significant the


development effort to create the undelivered element,
the more likely it is that the element will be a product
and not an upgrade.

(c) Marketing: New features and functionality offered in


connection with the delivered product would indicate
that the right to receive the features and functionality is
an upgrade. Alternatively, marketing efforts that are
focused solely or substantially on the new features and
functionality would indicate that the right to receive these
relates to a new product.

(d) Performance domain: If the undelivered element


performs functions in areas outside the domain of the
delivered version of a product, it is likely that the element
provides a solution that the delivered product does not.
This may suggest that the undelivered element is a
product rather than an upgrade.

A vendor enters into an arrangement with a customer to license


software package A for Rs.1,000,000. The arrangement also
specifies that the vendor will provide software package B for no
charge when it becomes available in a couple of months.
67
Revenue Recognition for Software

Software package B will be licensed for Rs. 500,000 when it


becomes available. The customer will install software package
A. Fair value for both software package A (Rs.1,000,000) and
software package B (Rs.500,000) can be reliably determined.

Is software package B considered an additional product or a


specified upgrade?

It would appear that software package B might be an additional


product rather than a specified upgrade, because both packages
will be utilised independent of each other. If it is determined
that software package B is an additional product, the vendor
would recognise 66.66% of the Rs.1,000,000 license fee or
Rs.666,666 upon the delivery of software package A (assuming
that all other revenue recognition criteria have been met). The
remaining Rs.333,334 would be deferred and recognised when
all revenue recognition criteria have been met for software
package B.

5.47 Some fixed fee license arrangements provide customers with


the right to reproduce or obtain copies at a specified price per
copy (rather than price per product) of two or more software
products up to the total amount of the fixed fee. Although the price
per copy is fixed at the inception of the arrangement, an allocation
of the arrangement fee to the individual products generally cannot
be made, because the total revenue allocable to each software
product is unknown.

5.48 Revenue from this kind of arrangement should not be


recognised fully until at least one of the following conditions is met:

• Delivery is complete for all products covered by the


arrangement.

• The aggregate revenue attributable to all copies of the


software products delivered is equal to the fixed fee,
provided that the vendor is not obligated to deliver
additional software products under the arrangement.

68
Multiple-Element Arrangements

Specified Additional Software Products - Various


Delivery Dates

A vendor enters into an arrangement with the customer to license


several of its products for a total fee of Rs.150,000. None of
the products is essential to the functionality of the other products.
The vendor performs duplication (which has a minimal cost),
and once the customer has accepted delivery of a product, the
related fees are not subject to adjustment, nor can the delivered
product be returned or exchanged. The products will be licensed
at stated prices per copy, all of which represent SOE of the fair
value, as follows:

Software Price
Product A Rs.2500 per copy
Product B Rs.4000 per copy
Product C Rs.7500 per copy

The fee is fixed and non-refundable regardless of whether the


customer accepts the delivery of any or all of the products. The
customer has six months to accept the delivery of all of the
products available under the arrangement. The arrangement
commences on July 1, X1 and ends on December 31, X1. On
July 31, the customer accepts a delivery of fifteen copies of
Product A. On September 15, X1, the customer accepts a
delivery of five copies of Product C and five copies of Product
A. On October 20, X1, the customer accepts a delivery of ten
copies of Product B.

How should revenue be recognised under the arrangement?

Revenue should be recognised based on the number of copies


delivered of Product A and Product C until October 20, at
which time all of the remaining fees should be recognised as
follows:

69
Revenue Recognition for Software

Date Copies Price per copy Revenue


Delivered
July 31 15 Rs.2500 Rs.37,500
September 15 5 Rs.7500 Rs.50,000
5 Rs.2500
October 20 10 Rs.4000 Rs.150,000
Rs. 62,500*
(40,000+22,500)

*Since Product B was the only product that was not delivered
before October 20, when Product B is delivered, all of the
remaining fees should be recognised because all of the criteria
for revenue recognition will have been met, including the delivery
criterion (as the fee is fixed and non-refundable regardless of
whether the delivery of any or all of the products is accepted).

SPECIFIED VERSUS UNSPECIFIED


ADDITIONAL SOFTWARE PRODUCTS
5.49 Specified additional software products, including those offered
on a when-and-if-available basis, should be accounted for
separately, so that a portion of the fee is allocated to the additional
software products based on fair value. If fair value can be reliably
determined, revenue allocated to the additional software products
should be recognised when an additional element is delivered and
all of the other criteria for revenue recognition have been met. As
with other elements, if fair value of the additional software products
cannot be reliably determined, all revenue from the arrangement
should be deferred until:

(1) such fair value can be reliably determined or

(2) all elements of the arrangement have been delivered,


whichever occurs earlier.

5.50 Unspecified additional software products are sometimes


included in software arrangements. These arrangements are similar
to PCS arrangements. However, the rights relate to unspecified
70
Multiple-Element Arrangements

products instead of unspecified upgrades or enhancements.

5.51 All software-product-related revenue under this arrangement


should be recognised ratably over the term of the arrangement or
over the economic life of the products if no term is stated, beginning
with the delivery of the first product (assuming that all other revenue
recognition criteria have been met).

71
6

Postcontract Customer Support


(PCS)

6.1 PCS or maintenance as it is usually called, means right to


receive services (other than services separately accounted for) or
unspecified product upgrades/enhancements (these unspecified
arrangements are PCS only if they are offered on ‘when-and-if-
available’ basis) or both offered to customers after the software
license period begins or other time provided for by PCS
arrangement.

6.2 PCS may be a separate element, bundled with other products


and services or implicitly included in an arrangement. Regardless
of whether PCS is separately stated in a contract, every software
arrangement should be evaluated for the potential impact of
PCS and, if it proves to be part of an arrangement, it should
be considered a separate element in determining revenue
recognition.

6.3 PCS does not include the following:

• Installation or other services directly related to the initial


license of the software;

• Specified upgrade rights;

• Rights to additional software products;


Postcontract Customer Support (PCS)

• Bug fixes to maintain compliance with product


specifications. Such costs are generally accounted as
warranty costs and

• Intellectual property infringement indemnifications.

6.4 Typical arrangements of PCS include services, such as


telephone support and unspecified upgrades/enhancements when
and if developed by the vendor during the period in which the PCS
is provided. PCS arrangements include patterns of providing
services or unspecified upgrades/enhancements to users or
resellers, although the arrangements may not be explicitly evidenced
by a written contract signed by the vendor and the customer. In
the case of unspecified upgrades and enhancements, the qualifier
‘when-and-if-available’, serves to emphasise that the upgrade or
enhancement would not have been known or expected to be
delivered at the time the right was granted to the customer.

GENERAL GUIDELINES FOR REVENUE


RECOGNITION OF PCS FOR PERPETUAL
LICENSES
6.5 Fees related to PCS, whether sold separately (e.g., renewal-
period PCS) or as an element of a multiple-element arrangement,
should generally be recognised as revenue ratably (i.e., on straight
line basis), over the term of the PCS arrangement. If the use of
the straight-line basis does not approximate the timing of when the
software vendor actually incurs the costs, then revenue could be
recognised on pro rata basis based on when the amounts are
expected to be charged to expense.

6.6 The PCS obligation is met: (1) By the vendor’s delivery of the
services, upgrades, and enhancements or by its fulfilling other
obligations under the arrangement, or (2) by the mere passage of
time.

73
Revenue Recognition for Software

PCS CONSIDERATIONS FOR TERM


LICENSES
6.7 The guidance given above contemplates to PCS
arrangements involving perpetual licenses. However, term licenses
are becoming common practice in the arrangements. Term licenses
involve a license to use the software for a specific period, generally
one to five years. Generally, PCS for all or part of the license term
will be bundled together with the term license. In this regard, the
following aspects may be considered:

(a) Fair value of PCS in a short-term time-based license


(ordinarily less than one year) and software revenue
recognition.

The duration of the time-based software license is so


short that a renewal rate or fee for the PCS services
does not generally represent the fair value of the bundled
PCS. In arrangements of this kind, the total arrangement
fee should be recognised ratably over the PCS period.

Time-based or perpetual software arrangements


sometimes contain contractually stated annual PCS
renewal rates and a requirement that the licensee be
current with PCS in order to maintain its rights to use
the software. This language essentially transforms a
perpetual or multi-year time-based license into an annual
license. As a result, such a clause dramatically impacts
how revenue is recognised. In this arrangement the
customer is not making the decision to only renew PCS,
but is in fact making a decision to renew both PCS and
the software license. Hence, the renewal is not
considered a PCS renewal (that is, PCS being sold
separately). Accordingly, fair value of PCS is not
established by reference to that renewal rate and hence,
the fee should be recognised ratably over the PCS
period.

74
Postcontract Customer Support (PCS)

(b) Fair value of PCS in a multi-year time-based license


and software revenue recognition.

If the arrangements for multi-year time-based software


licenses include:

• initial (bundled) postcontract customer support


(PCS) services for only a portion of the software
license’s term (for example, a five-year time-based
software license that includes initial PCS services
for one year) and

• a renewal rate for PCS for an additional year(s)


within the time-based license period the renewal
rate may constitutes the fair value of the PCS
provided that the renewal rate is substantive.

6.8 It may be noted that it would not be appropriate to use the


fair value of PCS sold with perpetual licenses as a “surrogate” for
the fair value for PCS in a term license. However, in following type
of indicative situations such values may be considered:

(a) The PCS renewal terms in a perpetual license provide


the fair value of the PCS services element included
(bundled) in the multi-year time-based software
arrangement when the term of the multi-year time-based
software arrangement is substantially the same as the
estimated economic life of the software product and
enhancements during that term.

(b) The fees charged for the perpetual (including fees from
the assumed renewal of PCS for the estimated economic
life of the software) and multi-year time-based licenses
are substantially the same.

6.9 In case PCS is the only undelivered element and the fair
value cannot be reliably determined, the entire fee under the
arrangement is generally recognised ratably over:

75
Revenue Recognition for Software

• The contractual PCS period (for those arrangements


with explicit rights to PCS); or

• The period during which PCS is expected to be provided


(for those arrangements with implicit rights to PCS).

6.10 PCS revenue may be recognised simultaneously with the


initial license fee when software is delivered in the following
indicative situations provided all of the estimated costs of providing
the services, including upgrades and enhancements, must be
accrued at the time when the software is delivered.

• The PCS fee is included with the initial licensing fee.

• The PCS included with the initial license is for one year
or less.

• The estimated cost of providing PCS during the


arrangement is insignificant.

• Unspecified upgrades/enhancements offered during


PCS arrangements historically have been and are
expected to continue to be minimal and infrequent.

Implied PCS and Warranties

6.11 A software vendor may have developed a historical pattern


of regularly providing all customers, or certain classes of customers,
with services or unspecified upgrades and enhancements that are
normally associated with PCS, even though the vendor is under
no written contractual obligation to provide these additional features.

6.12 Any implied PCS is considered an additional element of the


software arrangement, to which a portion of the total fees needs to
be allocated.

6.13 Even though implied PCS may be termed as warranty, it


should be noted that terms of implied PCS go beyond warranty in
the sense that these involve much more than a representation that
76
Postcontract Customer Support (PCS)

the product will perform up to certain specifications or that the


vendor will replace or fix the product if it ceases to work properly.

6.14 An example of an implied PCS arrangement is one in which


a vendor offers a “warranty” period, during which the customer
would have the right to both phone support and to unspecified
upgrades and enhancements that significantly enhance the
functionality of the delivered software. “Bug fixes” that are offered
pursuant to a warranty do not represent an implied PCS
arrangement and can therefore be accounted for as a warranty
cost.

A vendor licenses its software products with a 90-day warranty.


The customer may also purchase an annual PCS arrangement
that commences upon expiration of the warranty period. The
warranty provides for standard limited warranties
(merchantability, performance specification, bug fixes, etc.).
Additionally, the customer will have the right to receive customer
support and unspecified upgrades and enhancements, if any,
during the 90-day period.

Does the right to customer support and unspecified upgrades


and enhancements during the warranty period represent an
implied PCS arrangement?

Yes. The warranty constitutes an implied PCS arrangement.


Fair value of the implied PCS arrangement would be necessary
for the fee to be allocated among the multiple elements. Any
fees allocated to the implied PCS would be recognised ratably
over the warranty period.

DETERMINING FAIR VALUE FOR PCS


ARRANGEMENTS
6.15 The fair value of PCS may generally be determined by
reference to the price the customer will be required to pay when it
is sold separately (that is, the renewal rate). Accordingly, fair value
of PCS is generally based on renewal rates for PCS, which are to
77
Revenue Recognition for Software

be charged once the initial PCS period contained in the original


licensing arrangement expires. However, fair values can be
established otherwise also by the methods described earlier. If a
vendor offers PCS rates that are lower than the fully deployed
PCS renewal rates, a discount is embedded in the transaction.

PCS Arrangements involving a Maximum Charge

6.16 Companies implement “enterprise-wide software wherein


software” is licensed based on the number of users. PCS frequently
is part of such multiple-element arrangements and is also sold
based on the number of users.

6.17 A customary business practice that has evolved due to the


size of the fees involved in these arrangements has come to be
known as “capped maintenance” or “capped PCS”. Customers
have required vendors to limit the amount of additional PCS fees
charged as more users are added, under the theory that each
additional user does not actually add incremental costs to the
vendor’s expenses.

6.18 The following two examples provide guidance on


determination of fair value:

1. Capped PCS arrangement with a maximum number of seats-

A vendor licenses an enterprise-wide software package to a


customer. The arrangement calls for the vendor to install 1,000
seats for a fee of Rs.1,000,000 (or Rs.1,000 per seat). The
arrangement also calls for the vendor to provide PCS services
for a fee of 15% of the per-seat license fee, per year, for two
years. Both the per-seat license fee and the PCS fee stated
above are the established fair values.

Assume that the arrangement also allows the customer to


purchase up to 1,000 additional seats for Rs.1,000 per seat.
The fee for PCS services related to the additional seats remains
at 15% of the per-seat license fee, unless the additional 1,000

78
Postcontract Customer Support (PCS)

seats are licensed by the end of the first year, in which case
the PCS fee for the subsequent year will be fixed at Rs.200,000
for all 2,000 seats.

How should revenue be recognised under the arrangement?

This arrangement has a potential discount of Rs.100,000 (2,000


seats x Rs.150 [15% of Rs.1,000 per- seat price] - Rs.200,000
maximum PCS fee) that needs to be allocated to all elements
of the arrangement (licenses and PCS). The potential discount
related to the licenses would be allocated as follows:

Maximum Fair Percent- Allocation Allocated


Contract Value age of of Fees
Price Total Potential
Fair Discount
Value
Rs. Rs. Rs. Rs.
License fee 2,000,000 2,000,000 87.0% 87,000 1,913,000
PCS 200,000 300,000 13.0% 13,000 287,000
2,200,000 2,300,000 100% 100,000 2,200,000

Assume that the maximum 2,000 seats are licensed. Upon the
delivery of the first 1,000 seats, the vendor would record
Rs.956,500 (Rs.956.50 per seat x 1,000 seats) of license
revenue and defer Rs.43,500 of revenue related to the discount.
For each subsequent seat delivered, the vendor would record
Rs.956.50 of license revenue and defer Rs.43.50 related to the
discount. If at the end of the first year, the customer has not
licensed 2,000 seats, the vendor would record all deferred
revenue as income. If all 2,000 seats are licensed, the deferred
revenue of Rs.287,000 would be recognised over the remaining
12 months of the PCS arrangement.

2. Capped PCS arrangement with no maximum number of seats.

Assume that the arrangement does not provide for a maximum


number of seats, but still contains the clause that allows the
79
Revenue Recognition for Software

PCS fees for the second year to be capped at Rs.200,000, if at


least 2,000 seats are licensed by the end of the first year. How
should revenue be recognised?

The vendor does not know the potential discount because the
number of seats has not been fixed. Therefore, the vendor
would have to defer all revenue under the agreement until the
end of the first year, which is when the number of seats subject
to the second-year PCS coverage would be known. At that
point, the discount could be determined and the appropriate
allocation of license fees and PCS fees made (allocated license
fees would be recognised immediately, whereas the PCS fees
would be recognised over the remaining 12 months of the PCS
arrangement).

However, if the vendor could reliably estimate the maximum


number of seats based on the number of employees the
customer has or the customer’s hardware configuration, the
maximum discount may be calculable and an allocation of license
and PCS fees could be made.

PCS Offered in Arrangements involving Significant


Customisation or Modification

6.19 In an arrangement which involves services involving


significant customisation or modification and PCS, these have to
be considered as separately identifiable component provided the
fair value for PCS can be reliably determined. If the fair value of
the PCS cannot be reliably determined, then the entire arrangement,
including PCS, would have to be accounted for based upon the
principles of proportionate completion method or completed contract
service method.

PCS Renewals based on Users Deployed

6.20 Arrangements may include a perpetual license with a fixed


PCS fee for a specified period, say a three-year unlimited
deployment period but optional PCS for a subsequent period, say
80
Postcontract Customer Support (PCS)

year four and thereafter based on the ultimate number of copies of


software deployed. In this case, it may be difficult to determine fair
values reliably and the entire fee would have to be recognised
ratably over the three-year deployment period.

Fair Value of PCS with Usage-Based Fees

6.21 Usage-based fees are generally fees in excess of any upfront


license fee based on the frequency that the licensee uses the
software. If usage-based fees are not paid timely, the licensee’s
perpetual license to use the software is generally vacated and
there is no continuing obligation to provide PCS.

6.22 In arrangements where fair value for PCS is determinable,


the addition of usage-based fees will not impact the accounting for
the license or the PCS. The usage-based fees would then be
recognised when reliable estimates can be made of the actual
usage. In arrangements where fair value of PCS is not determinable
(or when PCS is included in the usage-based fee), the initial license
fee would be recognised ratably over the period the vendor expects
to provide PCS since there is no contractual PCS period.

6.23 In arrangements where the usage-based fee represents


payment for both the perpetual license and PCS, revenue would
be recognised when reliable estimates can be made of the actual
usage.

81
7

Non-PCS Services

7.1 Services other than PCS-related services generally include


training, installation, and consulting. Consulting services often
include implementation support, data conversion, software design
or development, and customisation of the licensed software. Service
element may be accounted for separately when the following
indicative conditions are satisfied (assuming all other revenue
recognition criteria are met):

• Fair value can be determined reliably for revenue to be


allocated to the various elements;

• The services are not essential to the functionality of


any other element of the transaction; and

• The services are described in the contract such that


the total price of the arrangement would be expected to
vary as a result of the inclusion or exclusion of the
services.

7.2 If the preceding criteria are met, revenue may be allocated


to the various elements based on their fair values. Services need
not be priced separately in order for them to be accounted for
separately. Revenue allocated to the services should be recognised
as the services are performed, or, if no pattern of performance is
discernible, on a straight-line basis over the period during which
the services are performed.
Non-PCS Services

A enters into an arrangement with B to provide both software


and training for Rs.100,000. The arrangement states that the
value of the training is Rs.1,000 and the value of the software
is Rs. 99,000. However, A licenses the software separately for
Rs.90,000 and offers the training separately for Rs.10,000. In
addition, B could purchase the training from another vendor for
Rs.10,000.

Even though the arrangement explicitly states that the price of


the software is Rs.99,000, A would record revenue of Rs.90,000
when the software is delivered (provided all other requirements
for revenue recognition have been met) and Rs.10,000 as the
training is provided.

7.3 If the services do not qualify for separate accounting, then


Proportionate Completion Method of accounting is followed. This
method is also used if software included in the arrangement is not
off-the-shelf software or significant modifications are necessary
for off-the-shelf software.

83
8

Arrangements with Resellers

8.1 Reseller is an entity licensed by a software vendor to market


the vendor’s software to users or other resellers. Licensing
agreements with resellers typically include arrangements to
sublicense, reproduce, or distribute software.

8.2 Resellers may be distributors of software, hardware, or


turnkey systems, or they may be other entities that include software
with the products or services they sell. Entities that commonly act
as intermediary channels (and should therefore be considered
resellers) include distributors, value-added resellers (VARs), original
equipment manufacturers (OEMs) and system integrators.

8.3 Several arrangements may be made with resellers which


may lead to complexities in revenue recognition. The following key
types of arrangements have been addressed in this Technical
Guide:

(a) Form of an Arrangement

(b) Delivery

(c) Fixed or Determinable Fees and Collectability

(d) Rights of Return or Exchange and Price Protection

(e) Unspecified Additional Products in Software


Arrangements
Arrangements with Resellers

(f) Reseller’s PCS Arrangements

(g) Prepaid Royalties

FORM OF AN ARRANGEMENT
8.4 Complexities arise in case the terms and conditions of the
vendor’s contract with the reseller incorporates or attaches to the
arrangement provisions of the contract between the reseller and
the end user. A legal opinion may be required to determine the
vendor’s obligation to the end-user customer.

DELIVERY
8.5 Delivery issues arise from the facts as to whether the reseller
has actually taken responsibility for the product such that the vendor
will not be required to accept returns, provide price protection,
conduct exchanges, or agree to payment terms that are subject to
the reseller’s receiving payment from its customer, which may or
may not be the end-user. Each arrangement would require
evaluation to establish that all the delivery obligations have already
been met by the vendor.

FIXED OR DETERMINABLE FEES


AND COLLECTABILITY
8.6 In arrangements with resellers, in addition to the general
factors that are considered in evaluating whether fixed or
determinable fee and collectability criteria are met, the following
factors may also be considered:

• If the business practices, reseller’s operating history,


competitive pressures, informal communications, or
other factors indicate that payment is substantially
contingent on the reseller’s success in distributing
individual units of the product if contractual
arrangements are such that the reseller is obligated to

85
Revenue Recognition for Software

pay only if sales are made to end-users, such


arrangements should be accounted for as a
consignment.

• If resellers are new, undercapitalised, or in financial


difficulty and may not demonstrate an ability to honour
a commitment to make fixed or determinable payments
until they collect cash from their customers, then fee is
not fixed or determinable and collectability criteria is
not met.

• If there are uncertainties about the potential number of


copies to be sold by the reseller, it may indicate that
the amount of future returns cannot be reasonably
estimated on delivery. Examples of such factors include
the newness of the product or marketing channel,
competitive products, or dependence on the market
potential of another product offered (or anticipated to
be offered) by the reseller.

• If the distribution arrangements with resellers require


the vendor to give rebate for a portion of the original
fee consequent to any reduction in the price of its
product by the vendor and the reseller has rights with
respect to that product (sometimes referred to as price
protection) then the fee may not be fixed or
determinable.

• If a vendor is unable to reasonably estimate future price


changes in the light of competitive conditions, or if
significant uncertainties exist about the vendor’s ability
to maintain its price, the arrangement fee may not be
fixed or determinable. In such circumstances, revenue
from the arrangement may have to be deferred until
the vendor is able to reasonably estimate the effects of
future price changes and the other conditions pertaining
to revenue recognition have been satisfied.

• If the vendor can reasonably estimate the amount of


86
Arrangements with Resellers

the fee that may be subject to rebate or forfeiture only


arising as a result of the vendor reducing its price for a
product, the vendor generally would recognise revenue
for the arrangement after a provision for discount is
created for the estimated amount of the price
concessions that would be granted to resellers as a
result of the price reduction by the vendor, assuming all
other revenue recognition criteria are met.

• If the amount of price concessions to be granted to


resellers is estimated to be unusually large, the vendor
would have to evaluate whether revenue recognition is
appropriate even if the vendor can reasonably estimate
the amount of the price concession because an
unusually large amount of price protection may be
indicative of an arrangement granting the use of software
for evaluation or demonstration purposes rather than
an arrangement involving a valid sale.

• Arrangements with distributors, particularly those at


international locations, that may not require a substantial
portion of the fee to be paid upon the delivery of a
product which may lead to concerns on collectability.

ABC Limited enters into an arrangement to deliver various


software products to a reseller for a non-refundable fee of
Rs.300,000. ABC Ltd. obtains a copy of reseller’s most recent
unaudited financial statements and notes that reseller has
suffered operating losses in the past two years and is thinly
capitalised. Reseller represents to ABC Ltd. that it expects the
addition of ABC Ltd.’s products to its inventory to improve its
operating performance immensely.

Due to the uncertainty about Reseller’s ability to pay ABC Ltd.


and absence of reseller’s success in distributing ABC Ltd.’s
products, ABC Ltd. would not consider the arrangement fee to
be fixed or determinable.

87
Revenue Recognition for Software

A vendor licenses its imaging product strictly through a reseller


channel and has no end-user sales force. The vendor has
licensed its imaging products for three years and has a history
of collecting all amounts due from resellers without granting
concessions, refunds or forfeitures. All licensing arrangements
to date have been through domestic resellers. During the current
year, the vendor begins licensing its products to new international
resellers on a limited basis. The vendor has not been able to
obtain reliable credit information regarding these international
resellers, some of whom operate in troubled economic
environments. Some of these new resellers are granted extended
payment terms.

Should the vendor continue to record revenues from these new


distributors upon the delivery of the product to the reseller (i.e.,
on a sell-in basis)?

The fact that the vendor has never licensed the imaging product
through these new international distributors indicates that it does
not have a history of collections with this type of resellers. This
raises a concern that some of the fees may not be fixed or
determinable and/or collectible. This is exacerbated by the fact
that (1) no credit reviews or financial analysis is available to
substantiate recording revenues upon the delivery of the product,
and (2) some distributors are operating in troubled economic
environments. In many of these cases, the vendor should not
recognise the license revenue from these types of distributors
unless the product is delivered to the end-users, particularly
when extended payment terms are granted.

RIGHTS OF RETURN OR EXCHANGE


AND PRICE PROTECTION
8.7 Software vendors may grant resellers the right to exchange
unsold software for other software (including software that runs on
a different hardware platform or operating system) or the right to
simply return the software altogether.

88
Arrangements with Resellers

8.8 Vendors may induce resellers to license a product by promising


to provide rebates for any future decreases in the pricing of affected
products, which is sometimes referred to as price protection.

8.9 All of above rights, including exchange rights, return rights,


platform-transfer rights and price protection, should be accounted
for as right to return, regardless of whether these rights relate to
software products among which there are no more than minimal
differences in price, functionality, and features. Hence, exchange
rights granted to resellers are generally accounted for as returns
even if the reseller is required to purchase additional software to
exercise the exchange right.

Reseller arrangement involving price protection


clause

Vikas Limited enters into a distribution agreement with a reseller.


The distribution agreement contains a clause that stipulates
that in the event Vikas Limited reduces the price of any product,
it will provide the reseller with a credit equal to the difference
between the original purchase price and the new purchase price
of the product for any units in reseller’s inventory at the time of
the price reduction, as well as any units of the product purchased
by the reseller within 30 days of the price reduction.

On April 1, 20X8, Vikas Limited made its first delivery to reseller.


Vikas Limited delivered 1,000 units of Product A for a non-
refundable fee of Rs.100,000. At the time of delivery, the pricing
committee of Vikas Limited is contemplating a price reduction
for Product A from Rs.100 to Rs.90 per unit within the next 30
days. They can reasonably estimate that the amount of the
credit that will be granted to the reseller as a result of the price
reduction will be Rs.10,000 [(Rs.100-Rs.90) x 1,000].

Accordingly, assuming that all other revenue recognition criteria


have been met, Vikas Limited would recognise Rs.100,000 of
revenue from the arrangement upon delivery of the units of

89
Revenue Recognition for Software

Product A and also establish a provision of Rs.10,000 for the


estimated amount of discount for price protection.

XYZ Limited enters into an arrangement to deliver 100 copies


of Product A to a reseller. XYZ Limited also grants reseller the
right to exchange copies of Product A for an equivalent number
of copies of Product B. Product B has no more than minimal
differences in price, functionality, or features from Product A.

Since reseller is not the end-user, the right to exchange copies


of Product A for copies of Product B would be accounted for as
a right of return. Accordingly, assuming all other revenue
recognition criteria have been met and that XYZ Limited can
reasonably estimate the amount of returns for Product A, XYZ
Limited would recognise revenue from the arrangement upon
delivery of the copies of Product A to Reseller and establish a
provision for the estimated amount of the returns.

UNSPECIFIED ADDITIONAL PRODUCTS


IN SOFTWARE ARRANGEMENTS
8.10 A reseller may be entitled to receive unspecified additional
software products from the vendor. Facts and circumstances of
each arrangement may lead the arrangement to be accounted for
in the following manner:

• Return: Resellers may grant the right of return to end-


users, with respect to delivered products, in the form of
the right to receive unspecified future products; in turn,
the reseller has the right to return such products to the
vendor. In this case, the revenue is recognised when
the right to return granted to the end-user is exercised
or expired.

• Subscription: If the arrangement involves a specified


time period to deliver unspecified additional software
products in the future, then revenue can be recognised

90
Arrangements with Resellers

ratably over the term of the arrangement beginning


with the delivery of first product.

• Consignment: If arrangements include terms whereby


the right to return or exchange a product would expire
only upon the reseller’s having licensed the product to
end-users, then revenue would not be recognised untill
the product is licensed to the end-user.

ABC Ltd. enters into an arrangement with a reseller. Under the


terms of the arrangement, ABC Ltd. grants reseller the right to
duplicate and sublicense in territory XYZ an unlimited number
of copies of Products A and B, which currently are deliverable,
and any other products introduced by ABC Ltd. in the Product
A family over the next two years. The non-refundable
arrangement fee of Rs.3,000,000 is due within 90 days of
delivery of Products A and B.

ABC Ltd. would account for the arrangement with the reseller
as a subscription. Assuming that all other revenue recognition
criteria have been met, ABC Ltd. would recognise the fee of
Rs.3,000,000 ratably over the two-year term of the arrangement
beginning with the delivery of Products A and B (Rs.125,000
per month after Products A and B have been delivered).

RESELLER’S PCS ARRANGEMENTS


8.11 A vendor may sell PCS directly to resellers either separately
or on an implied basis.

8.12 If a vendor sells PCS separately to resellers its fair value


can be determined based on the prices charged in those separate
sales. In those circumstances, it may not be appropriate to use
prices of PCS sold to end-users as a surrogate and disregard the
actual prices charged in separate transactions with resellers.
However, it may be appropriate to use prices for PCS sold to end-
users to establish fair value for PCS in reseller arrangements if
PCS is not sold separately to resellers.
Revenue Recognition for Software

8.13 In some reseller arrangements, the software vendor provides


upgrades/enhancements to the reseller on a when-and-if-available
basis for no additional charge, which are then provided to the
reseller’s customers. This is a situation of implied PCS
arrangement. If fair value does not exist to allocate the fee to the
software and the PCS, revenue from both the licensing arrangement
and the PCS would be recognised ratably over the period during
which PCS is expected to be provided.

PREPAID ROYALTIES
8.14 In certain cases, the reseller licenses the software to its
customers. The agreement between the software vendor and the
reseller may stipulate that the prepayment of the license fee is to
be based on minimum royalties. Additional fees would then be
payable if the minimum royalty fee were exceeded as a result of
the reseller’s sales.

8.15 License fees for software should be evaluated based on the


general revenue recognition criteria, regardless of whether they
are based on minimum royalty amounts. If all of the requirements
for revenue recognition are met, including the determination that
the fees in the arrangement are fixed or determinable, then the
royalty prepayment fee should be recognised upon the delivery of
the software (with deferral of an appropriate portion for PCS, if
applicable).

8.16 The additional fees that will be payable if the minimum is


exceeded are generally based on a price per copy and, therefore,
do not impact the revenue recognition of the minimum fee. The
requirements as regards revenue recognition criteria should be
evaluated at the time that the minimum royalties are exceeded,
based on the facts and circumstances that exist at that time.

A vendor enters into an arrangement to license an unlimited


number of copies of Product X to the reseller on June 28.
Product X was delivered to the reseller on June 28, and the
reseller will reproduce all necessary copies. Under the

92
Arrangements with Resellers

arrangement, the reseller will pay the vendor Rs.100,000, which


is the value of the license fee. No future deliverables are due
under the arrangement. After the reseller licenses 10,000 copies
of Product X to end-users, royalties will be due to the vendor at
a rate of Rs.15 per copy of Product X.

When is it appropriate to recognise revenue for Rs.100,000?

License fees for software should be evaluated based on the


general revenue recognition criteria, regardless of whether they
are based on minimum royalty amounts. Assuming that all other
revenue recognition criteria have been met, Rs.100,000 of
revenue would be recognised upon the delivery of Product X on
June 28. If the reseller has licensed over 10,000 copies of
Product X to end users, the vendor would record the additional
royalty revenues when the reseller notifies it of sales.

93
9

Application Service Providers


(ASPs)

9.1 In connection with the licensing of software products, some


vendors are offering arrangements in which end-users of the
software do not take possession of the software. Rather, the
software application resides on the vendor’s or a third party’s
hardware, and the customer accesses and uses the software on
an as-needed basis over the Internet or via a dedicated line
(“hosting”). Such vendors are referred to as Application Service
Providers (ASPs).

9.2 Structurally, the form of those arrangements may be split


into two elements — (a) The right to use software and (b) The
hosting service. The arrangements may or may not include a license
right to the software and the customer may or may not have an
option to take delivery of the software.

9.3 If an arrangement includes multiple elements, the fee should


be allocated to the various elements based on their fair values and
recognised when certain criteria are met. In addition, if a multiple-
element arrangement includes both software and services, the
portion of the fee allocable to the services is recognised separately
as the services are performed, provided certain criteria are met.

9.4 Software element in a software arrangement is generally


said to be present when
Application Service Providers (ASPs)

• The customer has the contractual right to take


possession of the software at any time during the hosting
period without incurring significant penalty; and

• It is feasible for the customer to either run the software


on its own hardware or contract with another party
unrelated to the vendor to host the software without
incurring significant penalty.

This would allow the vendor the ability to recognise that portion of
the fee attributable to the license on delivery, as transfer of
significant risks and rewards is considered to have taken place,
ordinarily when the delivery has occurred. The portion of the fee
related to the hosting element would be recognised ratably as the
service is provided, assuming all other revenue recognition criteria
have been met.

To satisfy ‘without incurring significant Penalty’, the conditions


mentioned below have to be ordinarily met:

• The user can take delivery of the software without


incurring significant monetary cost; and

• The end-user would be able to use the software


separately without a significant diminution in utility or
value.

9.5 It should be noted that all of the requirements for recognising


revenue, including fair value of the various elements in the contract
and the requirement that the fee allocated to the software element
is not subject to forfeiture, refund, or other concession, should be
met in order to recognise revenue upon delivery for the portion of
the fee allocated to the software element.

9.6 Arrangements that do not give the customer an option to


take delivery of the software are service contracts.

9.7 In hosting arrangements wherein the customer has the option


to take possession of the software, delivery of the software occurs
95
Revenue Recognition for Software

when the customer has the ability to take immediate possession of


the software.

A vendor enters into a contractual arrangement that grants a


perpetual software license to an end-user for an initial non-
refundable payment of Rs.100,000. Although the end-user has
the ability to take delivery of the software without incurring
significant cost and could use it separately without impairing its
utility or value, it initially chooses to have the vendor host the
software. No separate fee is charged for the hosting services
for the first year and the agreement allows for the hosting
arrangement to be renewed for a second year at a rate of Rs.
20,000. The Rs.100,000 fee is considered to be fixed, there is
a contract signed by both parties and collectability is considered
reasonably assured.

How should the vendor recognise revenue for this contract?

The arrangement contains two elements - the perpetual license


and the first year hosting service. Assuming the renewal rate
on the hosting services is substantive (i.e., the fair value is
reliably determinable), Rs. 20,000 of the initial Rs.100,000 fee
would be allocated to the hosting services and the residual
amount (Rs.80,000) could be assigned to the perpetual license.
Thus, the vendor would be able to recognise Rs. 80,000 of
license revenue at the time the customer has the ability to take
immediate possession of the software and would recognise the
remaining Rs. 20,000 as hosting service revenue ratably over
the twelve months for which hosting services are provided.

9.8 If the conditions mentioned above for recognising the hosting


arrangement as a software element are not met then generally the
software in hosting arrangement is not be treated as separate
element and would be considered as a service contract (not within
the scope of this Technical Guide).

96
Application Service Providers (ASPs)

UPFRONT FEES
9.9 Unless the up-front fee is in exchange for products delivered
or services performed that represent the culmination of a separate
earnings process, the deferral of revenue is more appropriate.
The deferred revenue would then be recognised ratably over the
term of the arrangement or the expected period of performance
(the ‘customer relationship period’).

9.10 The following may not normally be considered as a separate


earning process:

• The up-front payments are negotiated in conjunction


with the pricing of the other elements;

• The customer would ascribe a lower value, or no value,


to the up-front activity in the absence of the performance
of the other elements in the arrangement; and

• The vendor often does not sell the initial right or activities
separately.

9.11 Since all of the above points would apply to a hosted software
solution, a separate earnings process is not considered to have
occurred, and therefore the fair value allocated to the up-front fees
would need to be deferred and recognised ratably. Use of a straight-
line method is appropriate for amortising revenues unless evidence
suggests that the revenue is earned or obligations are fulfilled in a
different pattern. The vendor may not assume that the life of the
initial contract is the appropriate period for revenue recognition for
an up-front fee. If the relationship with the customer is expected to
extend beyond the initial term (anticipated renewals) and the
customer continues to benefit from the payment of the up-front
fee, the revenue attributed to that element of the contract should
be recognised over a longer period.

97
Revenue Recognition for Software

Straight-line Revenue Recognition

An end-user enters into a license agreement with a software


vendor for its product. It is not possible for the end-user to take
delivery of the software. The license has a term of five years
and the end-user signs a one-year hosting agreement. It would
have been possible for the end-user to enter into a shorter-term
license at a lower cost. Based on vendor’s established fair
values, the revenue attributable to the license and the hosting
arrangement is Rs. 20,000 and Rs. 6,000, respectively.

How much revenue should the vendor recognise in the first


year of the arrangement?

Although the end-user has only entered into a one-year hosting


contract, it has paid the software vendor for a five-year license.
This would suggest that it has an intention of continuing to use
the software after the expiration of the initial hosting agreement.
Thus, the up-front fee should be recognised ratably over the
license term of five years, resulting in license revenue of Rs.
4,000 (Rs. 20,000 ÷ 5 years) and hosting revenue of Rs. 6,000
for the first year.

Non-straight-line revenue recognition

An ASP providing training solutions enters into a license


agreement with a customer to make its software available for
up to ten separate training sessions in a twelve-month period.
The customer is required to pay an up-front configuration fee of
Rs. 8,000 and a monthly support fee of Rs. 1,000. The training
material will be out-of-date at the end of the twelve-month period
and there will be no benefit of the set-up work in future years.

How should revenue be recognised in this scenario?

The provision of the configuration service and the monthly


management fee do not represent separate earnings events
(i.e., no one would pay for the set-up without receiving the
98
Application Service Providers (ASPs)

ongoing training) and, hence, cannot be bifurcated. The total


revenue to be earned from the contract is Rs.20,000 (Rs.8,000
configuration fee plus twelve monthly support fee payments).
As the software will be used for only ten distinct training sessions,
Rs.2,000 of revenue should be recognised on the date of each
training session. Only at the end of the twelve-month period
would the ASP be able to recognise the balance of the deferred
revenue for any unused training sessions and only then as long
as there is no future obligation to the customer. In this situation,
the vendor may also need to have a history of not providing the
service after the contract’s expiration.

9.12 A hosted software arrangement may, in addition to the up-


front fee and hosting, and/or consulting services. Such services
should be accounted as multiple-element arrangement (discussed
earlier).

CONTINGENT REVENUES
9.13 There are occasions where an ASP will enter into an
arrangement to make software available to a customer for a stated
period of time. The monthly fee that the ASP receives for providing
these services is calculated as a fixed percentage of the value of
the transactions that the customer processes using the software.
Thus, each month’s fee is contingent upon the outcome of events
occurring within that month, and such events are:

• Not within the control of the ASP; and

• Not directly tied to the ASP’s provision of service.

9.14 The contingent revenue is recognised in the financial


statements of the period when the contingency is resolved as per
the terms of the arrangement.

9.15 The implementation/customisation services are not unique


to the ASP and could be performed by other service providers and
the ASP has determined fair value for the ongoing hosting services.

99
Revenue Recognition for Software

Assuming all other revenue recognition criteria are met, the vendor
would recognise the implementation/customisation fee upon
completion and acceptance, if applicable, of the service. The other
aspects relating to hosting arrangements is similar to that of regular
arrangements and hence are not dealt with in this section.

100
Appendix 1
GLOSSARY
Application System

A group of related applications programs designed to perform a


specific function.

Business Application

Business application refers to any application that is important to


running your business. Business applications can range from large
line-of-business systems to specialised tools. Applications that run
on either client computers or servers, including commercial off-
the-shelf products, customised third-party systems, and internally
developed systems represent Business Application Systems.

Business Process

An action taken in the course of conducting business is termed as


business process. Whether manual or automated, all processes
require input and generate output. Depending on the level of viewing
and modeling, a process can be a single task or a complicated
task such as building a product.

Business Continuity Planning

Business Continuity Planning (BCP) is an interdisciplinary concept


used to create and validate a practiced logistical plan for how an
Revenue Recognition for Software

organisation will recover and restore partially or completely


interrupted critical function(s) within a predetermined time after a
disaster or extended disruption. The logistical plan is called a
Business Continuity Plan. In simple language, BCP is working out
how to stay in business in the event of disaster. Incidents include
local incidents like building fires, regional incidents like earthquakes,
or national incidents like pandemic illnesses.

Disaster Recovery

Disaster Recovery (DR) is the process, policies and procedures of


restoring operations critical to the resumption of business, including
regaining access to data (records, hardware, software, etc.),
communications (incoming, outgoing, toll-free, fax, etc.), workspace,
and other business processes after a natural or human-induced
disaster.

Enterprise Service Oriented Architecture

Service Oriented Architecture (SOA) is a computer systems


architectural style for creating and using business processes,
packaged as services, throughout their lifecycle. SOA also defines
and provisions the IT infrastructure to allow different applications
to exchange data and participate in business processes. These
functions are loosely coupled with the operating systems and
programming languages underlying the applications. SOA separates
functions into distinct units (services), which can be distributed
over a network and can be combined and reused to create business
applications. These services communicate with each other by
passing data from one service to another, or by coordinating an
activity between two or more services. SOA concepts are often
seen as built upon, and evolving from older concepts of distributed
computing and modular programming.

Executable Code

Software in a form that can be run in the computer. It typically


refers to machine language, which is comprised of native

102
Appendix 1

instructions the computer carries out in hardware. Executable files


in the DOS/Windows world use .EXE and .COM file extensions,
while executable files in Unix and Mac do not require specific
extensions.

Interface

An interface defines the communication boundary between two


entities, such as a piece of software, a hardware device, or a user.
Software interfaces which exist between separate software
components and provide a programmatic mechanism by which
these components can communicate.

Information Asset

An Information Asset is a definable piece of information, stored in


any manner which is recognised as ‘valuable’ to the organisation.
The information which comprises an Information Asset, may be
little more than a prospect name and address file; or it may be the
plans for the release of the latest range of products to compete
with competitors.

Irrespective of the nature of the information assets themselves,


they all have one or more of the following characteristics:-

• They are recognised to be of value to the organisation.

• They are not easily replaceable without cost, skill, time,


resources or a combination.

• They form a part of the organisation’s corporate identity,


without which, the organisation may be threatened.

• Their Data Classification would normally be Proprietary


or Highly Confidential.

It is the purpose of Information Security to identify the threats


against the risks associated to potential damage to Information
Asset.
103
Revenue Recognition for Software

Level 1 & Level 2 Support

Level 1 - Initial

The characteristic of processes at this level are (typically)


undocumented and in a state of dynamic change, tending to be
driven in an ad hoc, uncontrolled and reactive manner by users or
events. This provides a chaotic or unstable environment for the
processes.

Level 2 - Repeatable

The characteristic of processes at this level include processes that


are repeatable, possibly with consistent results. The processes
may not repeat for all the projects in the organisation. The
organisation may use some basic project management to track
cost and schedule.

Process discipline is unlikely to be rigorous, but where it exists it


may help to ensure that existing practices are retained during
times of stress. When these practices are in place, projects are
performed and managed according to their documented plans.

Multi-module Application

A Module is a self-contained component of a system, which has a


well-defined interface to the other components; something is
modular if it includes or uses modules which can be interchanged
as units without disassembly of the module. Design, manufacture,
repair, etc. of the modules may be complex, but this is not relevant;
once the module exists, it can easily be connected to or
disconnected from the system.

Middleware

Middleware is a computer software that connects software


components or applications. The software consists of a set of

104
Appendix 1

enabling services that allow multiple processes running on one or


more machines to interact across a network. It includes web servers,
application servers, and similar tools that support application
development and delivery. Middleware is especially integral to
modern information technology based on XML, SOAP, Web
services, and service-oriented architecture.

Platforms

A software system that connects different data domains and


analysis applications under one graphical user interface.

System

System is a set of interacting or interdependent entities, real or


abstract, forming an integrated whole. The concept of an ‘integrated
whole’ can also be stated in terms of a system embodying a set of
relationships which are differentiated from relationships of the set
to other elements, and from relationships between an element of
the set and elements not a part of the relational regime.

Software Development Life Cycle

Software Development Life Cycle (SDLC) or sometimes just (SLC)


is a software development process used by a systems analyst to
develop an information system, including requirements, validation,
training, and user ownership through investigation, analysis, design,
implementation, and maintenance. SDLC is also known as
information systems development or application development.

SDLC is a systematic approach to problem solving and is composed


of several phases, each comprised of multiple steps:

105
1. Implemen- 2. Testing 3. Evaluation or
tation
1. Feasibility 2. Analysis 3. Design 4. Development 5. Implementa- 6. M a i n t e n a - or
Study tion nce
1. Feasibility 2. Analysis 3. Design 4. Implementa- 5. Maintenance or
Study tion
1. Feasibility 2. Analysis 3. Design 4. Development 5. Testing 6. Implement- 7. Mainten- or
Study ation ance
Revenue Recognition for Software

1. Analysis 2. Design 3. Development 4. Implementa- 5. Evaluation or


tion

106
1. Feasibility 2. Analysis 3. Design 4. Implementa- 5. Testing 6. Evaluation 7. Mainten-
Study tion ance
Appendix 1

Quality Assurance (QA)

Quality Assurance environment is created for performing interactive


quality assurance testing of User Language request.

User Support

Technical assistance from a hardware manufacturer, software


publisher, internal help desk, educational institution or third-party
support company.

Virtual Private Network (VPN)

A virtual private network (VPN) is a computer network in which


some of the links between nodes are carried by open connections
or virtual circuits in some larger network (e.g., the Internet) instead
of physical wires. The link-layer protocols of the virtual network
are said to be tunneled through the larger network when this is the
case. One common application is to secure communications through
the public Internet, but a VPN need not have explicit security
features, such as authentication or content encryption. VPNs, for
example, can be used to separate the traffic of different user
communities over an underlying network with strong security
features.

107