Chapter 069: Software, Intangibles and Goodwill

Section 14: Tax and Other Corporate Accounting · Chapter 069 of 100

This chapter explains software, intangibles and goodwill from the reporting bank's perspective. Examples are fictional; accounting follows IFRS unless another framework is expressly identified.

1. Chapter opening

Software, other intangibles and goodwill differ in recognition, amortisation, impairment and prudential treatment. A large project budget or expected strategic value does not itself create an asset. Control of a qualifying resource, documented costs and recoverability are essential.

2. Learning objectives

Apply all IAS 38 development recognition criteria.
Distinguish controlled software from SaaS access and implementation services.
Test goodwill at its allocated cash-generating unit.
Separate accounting impairment from the capital deduction bridge.

3. Business context

Banks invest in core systems, data platforms and customer applications. Project governance needs phase, cost eligibility, delivery and abandonment evidence. Finance can recognise qualifying development costs prospectively from the criteria date; previously expensed research is not retrospectively recreated as an asset.

4. Finance and accounting view

4.1 Development and software

For internally developed intangible assets, IAS 38 requires demonstration of six development criteria: technical feasibility; intention to complete/use or sell; ability to use or sell; probable future economic benefits; adequate technical, financial and other resources; and reliable measurement of attributable expenditure. Research is expensed. Training, general administration and inefficient/abnormal costs are not automatically development assets. Directly attributable eligible costs need evidence, including time records where relevant.

Finite-life assets are amortised when available for use over their assessed useful life; review life, method and residual value as required. Indefinite-life intangibles and assets not yet available for use require annual impairment testing, as does goodwill. A project pause or cancellation can indicate impairment but the loss is carrying amount less supported recoverable amount, not necessarily the entire historic spend.

4.2 Cloud arrangements

SaaS access ordinarily provides a service rather than ownership/control of the supplier's software. Assess configuration/customisation output: separately controlled qualifying code may be an intangible, while services may be expensed when received or recognised as a prepayment for future services as the facts require. Do not capitalise every implementation invoice merely because access spans several years. The April 2021 IFRS Interpretations Committee agenda decision explains this distinction.

4.3 Goodwill and impairment

Allocate goodwill to the cash-generating units (CGUs) or groups benefiting from the acquisition under IAS 36. Compare the whole tested unit's carrying amount, including allocated goodwill, with recoverable amount, the higher of value in use and fair value less costs of disposal. Goodwill has no independent cash flows; compare neither its standalone balance nor acquisition price alone with CGU value.

Assume a CGU has other net assets 700 and goodwill 300: carrying amount 1,000. Recoverable amount is 960, giving a loss of 40, allocated first to goodwill, leaving goodwill 260. Do not infer the same 40 loss by comparing goodwill of 300 with an unrelated standalone value of 260.

Value-in-use budgets normally cover at most five years unless a longer period is justified, not a mandatory minimum of five years. Use consistent cash flows and discounting, excluding uncommitted future restructuring and asset enhancement as required. Goodwill impairment is not reversed. Other asset reversals have criteria and a ceiling based on the carrying amount without prior impairment.

5. Product and customer impact

Capitalising software does not prove the system is operational, safe or useful to customers. Conversely, expense recognition does not make a cloud service economically worthless. Evaluate delivery and service resilience separately from balance-sheet treatment.

6. Regulatory and supervisory view

IAS 38, IAS 36 and the IFRIC cloud-cost agenda decision provide the IFRS basis. Basel capital definitions address goodwill/intangible deductions; local software exceptions and transitional treatments differ. An impairment of an already fully deducted intangible may release a deduction as equity falls, so its CET1 impact need not equal the accounting loss.

7. Systems and data view

Maintain project phase/recognition dates, approved business case, resource funding, eligible cost records, useful lives and CGU assignments. Review cancelled features, obsolete systems and duplicated platforms. Lock model versions and challenge forecasts independently of project sponsors.

8. End to end process

Identify controlled resource versus service.
Determine the date all recognition criteria are demonstrated.
Capitalise eligible subsequent expenditure only.
Begin amortisation when available for use.
Test indicators/annual requirements and measure impairment.
Reconcile tax and prudential effects separately.

9. Controls and risks

Risk	Evidence/control
Missing development criterion	Six-criterion sign-off and dated evidence
SaaS fees capitalised as software	Contract/control and service assessment
Sponsor optimism drives impairment value	Independent challenge and sensitivities
Goodwill tested standalone	Complete CGU carrying-value bridge
Asset impairment equated with CET1 loss	Deduction release calculation

10. Practical examples

A cancelled project has a carrying value of 120 and supported recoverable amount of 15: impairment is 105, leaving 15. For a separate project carrying 70 with reusable modules valued at 30, impairment is 40, not 70. Future pivot spend of 25 is assessed when incurred under recognition criteria; it is not automatically today's asset or a credit against the impairment.

11. Diagrams

Figure 1. Intangible recognition. Figure 2. Software and goodwill. Figure 3. Impairment example.

12. Tables

CGU impairment proof	Amount
Other net assets	700
Goodwill	300
Total carrying amount	1,000
Recoverable amount	960
Loss, allocated first to goodwill	40
Remaining goodwill	260

13. Fictional banking case study

A fictional bank capitalised research and SaaS configuration costs without assessing control or development criteria. Review separated service/prepayment costs from qualifying code, corrected the accounts under the relevant error/estimate assessment and tested remaining assets for impairment. Finance introduced a dated recognition gate rather than approving spend solely against the project budget.

14. BA, developer, tester and operations guidance

Operating costs and fixed assets have different recognition criteria. Tax may arise from carrying-value/tax-base differences. Capital reporting reconciles recognised intangibles to eligible deductions rather than undoing the accounting entries.

15. Common mistakes

Applying only four of the six development criteria.
Capitalising research retrospectively.
Treating all SaaS implementation as controlled software.
Comparing goodwill alone with CGU recoverable amount.
Reversing goodwill impairment when trading improves.

16. Key takeaways

Recognise the resource only when criteria are demonstrated, track its use and test recovery at the correct level. Keep accounting, tax and capital adjustments distinct.

17. References and verification notes

Basel CAP30 regulatory adjustments: current international deduction framework, including goodwill/intangibles and DTA rules; domestic implementation determines a bank's enforceable requirements.
IAS 38: intangible recognition/amortisation.
IAS 36: CGU impairment and reversals.
April 2021 cloud-cost agenda decision: SaaS configuration/customisation.
Basel capital definitions: deductions subject to domestic treatment.
Projects and amounts are fictional.