Servicing platform and data/analytics systems: internally developed software vs SaaS configuration and customisation costs

A servicing business runs on its loan administration, collections workflow, payment matching and analytics systems, and implementing them is often its largest non-staff spend; some of that spend creates software the entity controls and can capitalise, but much of it relates to cloud services where the vendor controls the software, so configuration and customisation are usually expenses or prepayments rather than intangible assets, and getting this wrong overstates assets and understates operating costs.

Does the entity control the software (it holds the code or a licence to run it on its own or third-party infrastructure) or does it only have a right to access the vendor's application over the contract term? For development work, can the entity demonstrate technical feasibility, intention and ability to complete and use the software, how it will generate future benefits, adequate resources and reliable cost tracking? Who performs configuration and customisation: the SaaS vendor (and is that work distinct from access) or a third-party integrator? Which costs are data migration, cleansing, training or process redesign that never qualify?

1. Classify each system: software the entity controls (internally developed or licensed to run independently) versus a cloud service contract giving only access to the vendor's software.
2. For internally developed software, expense the research or preliminary phase (feasibility, vendor selection, requirements exploration).
3. Capitalise development costs only from the point all the development criteria are demonstrated, including technical feasibility and how the asset will generate future economic benefits; capitalisation is required, not optional, once they are met.
4. For a cloud service contract with no software asset, recognise configuration and customisation costs as an expense when the service is received; where the SaaS vendor itself performs customisation that is not distinct from access, recognise the payment as a prepayment and expense it over the contract term.
5. Capitalise separately only components that create a resource the entity controls, such as interface code or a data platform it owns and can use independently.
6. Expense data migration, data cleansing, training and process redesign as incurred; start amortising capitalised software when it is available for use.

Measure capitalised software at directly attributable cost: staff costs of developers, contractor fees for development, testing and directly attributable overheads, excluding general administration, training and inefficiencies. Amortise over the expected useful life, typically shorter for platforms subject to rapid change, using a straight-line method unless another pattern better reflects consumption; review useful life, amortisation method and impairment indicators each year. Measure SaaS prepayments at the amount paid and expense them over the period of access.

Disclose: (1) the policy for software development costs and cloud computing arrangements, including how configuration and customisation costs are treated; (2) the carrying amount of internally developed software and its movement, amortisation methods and useful lives; (3) development costs expensed in the period; (4) significant judgements on control of software and on the distinctness of vendor customisation; (5) prepayments relating to cloud services.

• Capitalising configuration of a SaaS platform the entity does not control as an intangible asset
• capitalising feasibility, vendor selection, data migration or training costs
• starting capitalisation before the development criteria are evidenced
• continuing to capitalise after the system is available for use
• failing to assess whether customisation performed by the SaaS vendor is distinct, and therefore whether it is expensed when performed or over the contract term
• ignoring impairment when a platform is replaced or a mandate it supports is lost.