CAPEX, OPEX and Data

Public cloud hosting providers has meant using OPEX to pay for services is now the norm, we are no longer paying upfront for servers, data centres or software licences. 
We should take this opportunity to refresh our understanding of the two options available when managing project costs. For this example, we are assuming the purchase of hardware (e.g. database server) or lease of a service (e.g. EC2 instance on AWS). The following table describes various activities that can take place, and what happens if you are managing the costs as either CAPEX or OPEX:

Activity	CAPEX	OPEX
Purchase of Hardware in FY	Large upfront expense	N/A
Lease of Service in FY	N/A	Monthly cost for leasing the service
Depreciation at end of FY	Asset is depreciated against a schedule that reflects the hardware’s expected life	N/A no depreciation occurs
Reporting of Income Tax at end of FY	Reduced by the scheduled depreciation amount	Reduced by all the cash spent that year for the service
Reporting Value of Assets at end of FY	Increased by the value of the purchase	N/A no assets have been purchased

So why can OPEX be good news? Here are some of the advantages:  

• Authorisation to make an OPEX procurement is often much less onerous than a CAPEX procurement, even though the overal cost of ownership can be greater.
• An OPEX purchase does not tie up dollars which could be used to generate income elsewhere.
• If your organisation is using a cloud provider (Google, AWS, AZURE, etc.), they have mitigated their risk or making a large CAPEX purchase only to find that:
• The hardware purchased is too small and not easy to scale.
• The anticipated demand for a project never eventuated and hardware purchased is too large and cannot be repurposed.
• They are encouraged to keep the hardware for longer than is sensible in order to improve the ROI.

Points to Note