Splitting development costs between internal-use software and customer-facing product features

SaaS engineering teams routinely split their time between building generic platform capability (an IAS 38 intangible asset if criteria are met) and delivering features to fulfil a specific customer contract (evaluated under IFRS 15's costs-to-fulfil guidance or expensed); because both categories can look identical on a sprint board, misallocating hours overstates the wrong asset, understates the wrong cost line, and can result in the same effort being capitalized twice under two different standards.

Does the engineering output relate to generic platform capability usable by all customers (a potential IAS 38 asset), or to fulfilling one specific existing contract (a potential IFRS 15 contract cost)? Is time-tracking granular enough at the ticket or initiative level to support a defensible split between the two categories? Does each category independently meet the recognition criteria of its relevant standard, rather than being capitalized by default because the other portion qualifies?

1. For each significant development initiative, determine whether the output is a generic platform capability intended for use by, or sale to, customers beyond a single specific contract, or work performed to satisfy the specific requirements of one existing customer contract.
2. For generic platform capability, apply the full IAS 38 six-criteria test (technical feasibility, intention, ability to use/sell, probable future economic benefit, resource availability, reliable measurement) before capitalizing any related cost.
3. For work tied to fulfilling a specific existing contract, do not apply IAS 38; instead assess it under the IFRS 15 costs-to-fulfil criteria (the costs relate directly to an identifiable contract, generate or enhance resources used in satisfying performance obligations, and are expected to be recovered) or expense it if those criteria are not met.
4. Where a single sprint mixes both types of work, allocate costs based on actual time-tracking or sprint-allocation records at the task or ticket level, not a blanket percentage applied without evidentiary support.
5. Confirm no double-counting: hours capitalized as an IAS 38 intangible must not simultaneously be capitalized as an IFRS 15 contract cost asset or expensed twice.
6. Reassess the classification if a feature built for one customer is later generalized into the core platform, ceasing capitalization under the original basis and starting fresh evaluation under the new one from that point.

Measure capitalized IAS 38 costs at directly attributable expenditure (developer payroll and directly attributable overhead) incurred from the date all six criteria are first met, based on actual hours recorded against the generic-platform initiative. Measure IFRS 15 contract cost assets at the incremental cost directly attributable to fulfilling the specific contract. Use a consistent, auditable time-tracking methodology (sprint or ticket-level tagging) applied the same way period to period, and reconcile total capitalized hours plus expensed hours to total engineering payroll to catch any double-counting or gaps.

Disclose: accounting policy distinguishing internal-use/generic platform capitalized development from contract-related fulfilment costs; the basis (time-tracking methodology) used to split payroll and overhead between the two categories; amounts capitalized as IAS 38 intangibles versus IFRS 15 contract cost assets during the period; confirmation of controls preventing double-counting of the same hours; any reclassification between categories when a contract-specific feature is generalized into the core platform.

• Capitalizing all engineering payroll as IAS 38 intangible assets regardless of whether the work relates to a specific customer contract or generic platform capability
• double-counting the same hours as both a capitalized IFRS 15 contract cost and an IAS 38 intangible asset
• relying on team or department labels ('
• platform team'
• versus '
• delivery team'
• ) rather than actual task content to classify costs, when engineers frequently move between both types of work
• applying a fixed historical percentage split without periodically validating it against actual time-tracking data
• failing to stop capitalizing under the original basis and reassess when a bespoke, contract-specific feature is later rolled out generically to all customers.