Cloud setup costs: identify the asset a customer controls
Paying to implement cloud software does not necessarily create software the customer controls. Some expenditure can produce an identifiable code asset; other expenditure purchases services already received or services delivered with future access. The invoice title “implementation” cannot decide between those outcomes.
The research deliverable is a cost-by-output worksheet. It should identify who controls each output, who is contractually responsible for services, when those services are received and what balance remains. Separate this customer-side question from a software developer capitalizing its own development work.
Locate the final decision and the reporting framework
Use the final April 2021 addendum titled Configuration or Customisation Costs in a Cloud Computing Arrangement in the March 2021 IFRIC Update. The page also contains earlier discussion; the finalized addendum, not a tentative proposal, is the relevant explanation.
For this teaching example, assume an Australian for-profit customer reporting for January–December 2024. The December 2022 AASB 138 compilation applies to periods beginning from January 1, 2023 before July 1, 2026. Its IFRS-aligned recognition and expense provisions provide the accompanying historical framework.
The specified SaaS access gives the customer a service rather than control of the provider’s underlying application. That starting assumption does not decide whether separate additional code is controlled by the customer. Evaluate the actual output instead of treating every cost connected to SaaS identically.
Main example: ninety of three different outputs
Fictional customer Beech pays ninety thousand at the beginning of a three-year access arrangement. This implementation payment excludes the ordinary SaaS subscription fee, which requires its own accounting.
Thirty pays for additional identifiable code that Beech controls and that meets the relevant intangible-asset recognition conditions. Thirty-six pays the application supplier for configuration not distinct from access. Twenty-four pays an independently contracted third-party implementer for services completed at the beginning of the period.
Assume the code is immediately available for use, has a three-year finite life and zero residual value, with straight-line consumption. Assume access and the non-distinct supplier service are provided evenly over three years. Ignore tax, impairment and other costs for the main calculation.
| Implementation category, thousand | Paid | Initial treatment | First-year expense |
|---|---|---|---|
| Qualifying customer-controlled code | 30 | Intangible asset | 10 amortization |
| Non-distinct supplier configuration | 36 | Prepayment for future access-related service | 12 |
| Completed directly contracted third-party service | 24 | Expense when received | 24 |
| Total | 90 | Two different remaining assets | 46 |
At the end of year one, the code asset is twenty and the supplier-service prepayment is twenty-four. Total remaining assets are forty-four. Cash paid of ninety less modeled expense of forty-six equals forty-four under the stated assumptions.
This arithmetic does not mean both remaining balances are software assets. Their nature and subsequent treatment differ. Calling all forty-four capitalized software would erase the prepaid service and misdescribe what Beech controls.
Test the code output, not the size of the project
The final decision’s section on asset recognition directs attention to the customer’s control and the nature of the configuration output. The customer often does not control the supplier’s software merely because it paid to configure it.
For the thirty-unit code asset, investigate rights to benefits, restrictions on others’ access, identification and the relevant recognition conditions. Access to source code, a configuration file or an escrow arrangement is not alone a complete control assessment.
Portability and dependency are useful evidence questions rather than universal pass/fail labels. Code might depend on a platform while still requiring a separate assessment; an easily copied document might not confer enforceable control. Preserve the legal and technical facts separately.
The main case explicitly assumes recognition conditions are satisfied. It does not authorize an analyst to capitalize thirty because the contract calls it custom development. If the output remains controlled by the SaaS supplier and no separate qualifying asset exists, move to the service analysis rather than inventing a code asset.
Identify the contractual service provider
The final addendum’s expense discussion distinguishes the software supplier’s services from a customer’s direct contract with a third party. A supplier subcontracting implementation does not automatically turn the customer’s arrangement into a direct third-party contract.
In Beech’s main case, the twenty-four service is directly contracted and completed. Its expense follows when the implementation service is received, not the entire three-year period during which Beech hopes to benefit from the operational system.
For the thirty-six supplier service, the main case assumes it is not separately identifiable from access. The expense follows access over the contract term under those facts. A cash payment at the beginning creates a prepayment; it does not establish that a separate software asset was acquired.
Record which party owes the service to the customer. The bank payee or consultant’s name on a status report can be misleading if the contractual obligation remains with the application supplier.
Boundary one: the supplier service is distinct
Change the thirty-six service so that it is distinct and completed at the start, with no qualifying intangible asset created. Under the final decision’s specified analysis, it is expensed when the supplier configures or customizes the application.
In that separate scenario, first-year expense becomes seventy: code amortization ten, supplier service thirty-six and third-party service twenty-four. Closing implementation-related assets are twenty, comprising only the code. Cash remains ninety.
This change does not follow from a shorter expected benefit period. It follows from identifying a different service and when it is performed. The same three-year SaaS access period does not automatically spread every implementation expense over three years.
Boundary two: a supplier uses a subcontractor
Suppose the application supplier engages the same consulting firm to deliver the non-distinct configuration, while Beech’s service contract remains with the application supplier. The consultant’s physical involvement does not alone change the thirty-six to the direct-contract twenty-four branch.
Examine the obligation and distinctness before assigning timing. Otherwise identical work can be classified from an invoice logo rather than the contractual service received. The final decision explicitly includes supplier subcontracting in its supplier-service discussion.
If Beech prepays a direct third party before work starts, a prepayment may exist until the service is received. That is another timing fact, not evidence that all third-party implementation is immediately expensed on the cash payment date.
Reconcile milestones and remaining balances
Paragraphs 68–70 and 69A of AASB 138 provide relevant expense and prepayment concepts. Keep service performance, customer system go-live and payment dates separate. They may coincide in the main case only because the assumptions say so.
A delayed go-live can affect the code’s available-for-use assessment or change the evidence about services, but it does not automatically postpone expense for a distinct service already performed. Conversely, an invoice before performance does not prove the service has been received.
At each period-end, reconcile opening code and prepayments, new eligible costs, amortization, service expense, impairments where relevant and closing balances. Do not roll the entire remaining forty-four through one amortization percentage when one component is a service prepayment.
Use an evidence table that separates public and private inputs
| Input | Public evidence to seek | Decisive detail often missing |
|---|---|---|
| Output identity | Software and cloud accounting policy | Exact code or configured functionality |
| Control | Rights and dependency description | Contractual access restrictions |
| Recognition | Intangible-asset policy and additions | Eligibility evidence for each cost |
| Contracting party | Supplier arrangement explanation | Direct contract versus subcontract |
| Distinctness | Description of implementation services | Relationship to access |
| Timing | Milestone and prepayment note | Service performance and ready-for-use dates |
| Cost allocation | Expense and asset movements | Reliable split of the combined invoice |
Detailed implementation agreements usually are private. If the public note provides only total cloud spending, do not assign ninety to the three categories based on an industry average. The teaching split is explicit; a real issuer may need an unresolved category.
Reopen the worksheet after scope changes, contract termination, a new code-rights agreement or a revised go-live assessment. Preserve the nature of every remaining asset rather than assuming a balance called deferred implementation must be capitalized software.
The final memo should report controlled code, prepaid service, expense received and cash separately. That makes the implementation economics inspectable while preventing future operational benefits from becoming automatic evidence of an intangible asset.
Keep invoice allocation evidence attached
For Beech, preserve the source of the thirty, thirty-six and twenty-four split beside the output description. A combined implementation invoice does not itself establish those categories, even if its ninety total matches the bank payment.
When the next period arrives, roll the twenty code asset and twenty-four service prepayment separately. A later payment settling an existing payable is not another implementation expense. Likewise, a balance being useful for several future years does not change its nature from prepaid service to customer-controlled software.
FAQ
Does a three-year SaaS contract justify amortizing all setup costs over three years?
No. First identify any controlled asset and the services received. Distinctness and contractual performance can produce different expense periods.
Does use of a consultant always mean a direct third-party service?
No. Determine whether the customer contracts directly or the application supplier subcontracts its own obligation.