Cloud hosting costs under the Cyprus IP Box

Classify the activity before the supplier

AWS, Azure or another provider can supply resources for research, production, customer support and sales demonstrations on the same invoice. The provider name therefore tells you little about the tax classification. The question is what work the resource supported and how it relates to the qualifying asset.

The Cyprus regulations include costs directly connected with developing, improving or creating qualifying intangible assets, subject to exclusions. They do not provide a general rule that every cloud bill is qualifying R&D, nor a blanket exclusion for cloud services. A practical analysis starts with the development activity and then identifies the expenditure that supports it.

Keep two decisions separate. First, determine how expenditure is treated in calculating net income from the IP. Second, decide whether the expenditure meets the qualifying-expenditure definition for nexus. Recording a production expense in the first calculation does not justify inserting it into the second.

Use a resource-by-purpose classification

This matrix is a review tool, not an official tax schedule. Each entry still depends on the actual activity, the connection with the asset and the applicable tax treatment.

An allocation example without inventing eligibility

Suppose a monthly invoice is €12,000. Resource tags identify €7,000 for production, €3,000 for a development project and €2,000 for shared resources. The €3,000 is a candidate for R&D review, not an automatically approved nexus input. The project’s work must satisfy the relevant criteria and be connected to the qualifying asset.

For the shared €2,000, the finance team obtains usage records showing which environments consumed the resources. It applies a documented allocation driver and asks engineering to confirm that the driver reflects actual use. There is no reason to allocate the whole amount to R&D simply because the company develops software.

Assume, for illustration, that the review supports €3,500 as directly connected qualifying development expenditure after allocation. That figure enters the nexus schedule on the relevant basis. The treatment of the rest in the annual profit calculation remains a separate question; it is not necessarily non-deductible merely because it is outside QE.

Make the cloud account explainable to finance

Create a shared vocabulary between engineering and accounting. Each relevant project needs a stable asset identifier. Environment labels should distinguish production, development, testing and commercial use where that reflects the system. Keep the mapping when projects are renamed or accounts are migrated.

Export usage records alongside invoices. A high-level invoice showing only a service name and a total may be insufficient to explain several products’ costs. Retain the time period, resource identifiers, allocation calculation and an explanation of the underlying activity. Do not rewrite historical labels as though they were contemporaneous evidence.

Changing tagging practice prospectively can improve future records without proving past eligibility. Where historical records are incomplete, use genuine supporting material and mark estimates and unresolved amounts transparently. Missing documentation should not be converted into a confident qualifying percentage.

• Link each claimed amount to a project and qualifying asset.
• Explain why the work was development rather than ordinary operation.
• Reconcile allocated amounts to the invoice total.
• Separate acquisition, related-party and other cost categories where relevant.
• Record who approved the allocation and why.

Revisit the classification when a project goes live

The same environment can change purpose over time. Compute used in an experimental project may later become the production service customers pay for. An allocation that was reasonable during development can become misleading after launch. Review purpose at material releases and when workloads move.

AI products make this especially important. Training, evaluation, inference and ordinary customer use are not interchangeable labels. Do not treat all GPU expenditure as R&D simply because the infrastructure is expensive or technically complex. Establish the relevant asset, development activity and cost relationship first.