Stuart Totterdell
Technical Director
When your business buys a machine, it goes on the balance sheet. It is an asset. It depreciates over its useful life. The cost is spread across years, not absorbed in one quarter. It delivers value for as long as it runs.
When your business builds a custom automation system, the same accounting treatment applies. It is a capitalisable asset. It goes on the balance sheet. It depreciates over its useful life - typically three to five years. The cost is spread, not concentrated.
And yet almost nobody thinks about automation this way. Because SaaS has spent two decades training the market to think about technology as a monthly subscription - an operating expense that disappears the moment you stop paying.
This distinction matters more than most finance directors realise.
The accounting difference
When your business pays for a SaaS subscription, the entire cost hits the P&L as an operating expense in the period it is incurred. Every month, the subscription reduces your operating profit. Every year, the total appears as a cost with nothing to show for it on the balance sheet.
When your business invests in custom development and build of an automation system, the development cost is capitalised - treated as an intangible asset under IAS 38 or FRS 102 (depending on your reporting framework). The cost appears on the balance sheet, not as a single-period expense on the P&L. It is then amortised over its useful life - typically three to five years - meaning the P&L impact is spread evenly across those years.
The practical effect: a £60,000 automation project does not hit your P&L as a £60,000 cost in year one. It appears as a £12,000 amortisation charge per year over five years. Your operating profit in the year of the build is £48,000 higher than if you had expensed the entire amount.
Meanwhile, a SaaS platform costing £1,200 per month hits your P&L as £14,400 per year, every year, forever. No asset. No balance sheet entry. Just a recurring cost that never produces equity.
Why this changes the conversation
Most automation projects are evaluated as costs. The business looks at the project price, compares it to the current operational cost, and asks whether the saving justifies the spend.
But when automation is treated as an asset, the conversation changes fundamentally.
It is no longer "can we afford this cost?" It is "should we invest in this asset?" The language shifts from expense to investment. The evaluation shifts from short-term P&L impact to long-term value creation. The comparison shifts from "how much does it cost this quarter?" to "what does this asset deliver over its useful life?"
This is not a semantic trick. It is a legitimate accounting treatment that most mid-market businesses are entitled to use - and almost none of them do, because nobody has framed the automation project as an asset acquisition rather than a technology expense.
What qualifies for capitalisation
Not all automation spend can be capitalised. The rules are specific - and worth understanding.
Under IAS 38 and FRS 102, an internally developed intangible asset can be capitalised if the business can demonstrate that it is technically feasible, the business intends to complete it and use it, the asset will generate future economic benefits, the business has the resources to complete the development, and the development cost can be reliably measured.
Custom-built business automation systems typically meet all five criteria. The development is scoped, planned, and delivered to a specification. The system is built to be used in production. The economic benefit - time saved, errors reduced, capacity returned - is measurable and ongoing. The cost is contracted and documented.
What cannot be capitalised is research-phase activity (exploring whether automation is feasible), ongoing maintenance and support costs, and SaaS subscription fees (these are always opex, by definition).
The distinction is clear: the build is capex, the run is opex. And the build is usually the largest portion of the total cost.
The tax angle
Capitalised automation assets are eligible for capital allowances - tax relief on the cost of the asset, applied over its useful life or (under certain schemes) accelerated.
Under the UK's Annual Investment Allowance, businesses can claim 100% tax relief on qualifying capital expenditure up to £1 million per year. For most mid-market automation projects, this means the entire build cost can be deducted from taxable profit in the year it is incurred - while the asset still sits on the balance sheet and amortises over multiple years.
The effect is a tax benefit in year one and a reduced P&L charge spread over subsequent years. It is, in straightforward terms, a better financial outcome than expensing a SaaS subscription - which provides no capital allowance and no balance sheet value.
R&D tax credits may also apply if the automation involves a technical advance - solving a problem that is not straightforward using existing tools and methods. Many custom projects qualify, particularly those involving data and systems integration, process orchestration, or the application of AI to operational data.
Why SaaS trained everyone to ignore this
SaaS vendors have spent twenty years normalising the subscription model. The pitch is simple: no upfront cost, no capital commitment, pay as you go, cancel any time.
This feels like low risk. It is not. It is a commitment to paying forever, with no asset accumulation, no equity, and no exit without losing everything you have built on the platform.
But the monthly number is small and the approval process is easy. Nobody needs to build a business case for a £500/month subscription. The CFO does not need to evaluate it as a capital investment. It slips through as operational expenditure - easy to approve, easy to forget, easy to accumulate.
The result is a technology estate built entirely on rented platforms, producing no balance sheet value, consuming operating profit every month, and growing in cost with every price increase, every new user, and every add-on module.
The alternative - building automation that you own, capitalise, and depreciate - requires a larger upfront decision. But it produces a better financial outcome by almost every measure that a finance director should care about.
The question
When was the last time your finance team evaluated an automation project as a capital investment rather than an operating cost?
If the answer is "never," the business has been making financial decisions about technology using the wrong framework. The SaaS model is not the only model. And for core operational automation, it is frequently not the best one.
Automation is not a cost. It is an asset. And your accounts should reflect that.
