Cyprus IP Box for multiple software products

Start with an asset map, not the sales catalogue

A company may sell three subscription plans built on one codebase, or one subscription containing several separately developed software systems. Commercial product names therefore do not always correspond to the assets that need to be tracked for IP Box purposes.

Map the technology before constructing the calculation. Identify the codebases, major modules, development histories, ownership and ways income is earned. Explain whether each item is a separate asset, a version of an existing asset or shared infrastructure. The conclusion should follow the facts rather than the tax result it produces.

Regulation 5 requires accounting books and records of income and expenditure by intangible asset. Regulation 4 also addresses allocation of certain expenditure that cannot be directly assigned. Together these provisions make traceability and justified allocation more useful than an arbitrary company-wide percentage.

Why pooling can distort the result

Assume Product A has €400,000 net IP income and full nexus, while Product B has €100,000 net IP income and a 50% nexus fraction. Treating the assets separately produces qualifying profit of €450,000 and an 80% deduction of €360,000. The remaining €140,000 gives €21,000 corporation tax at 15%, before other adjustments.

A simple average of the two fractions is 75%. Applying that average to total net IP income of €500,000 would produce only €375,000 qualifying profit. The result differs because the assets generate different profits. A different pooling method could overstate relief instead.

The lesson is not to select whichever average gives the lowest tax. It is to preserve the correct relationship between each asset’s expenditure and income. If a proposed grouping is necessary because the technology and costs are inseparable, establish why that grouping is appropriate rather than substituting a spreadsheet convenience for analysis.

Allocate shared development consistently

Authentication, billing, data-processing and developer tooling may serve several products. First ask whether the expenditure can be directly assigned using project evidence. Where it cannot, document a reasonable allocation supported by how the work benefits the assets and by the applicable rules.

Do not allocate a shared development cost in full to every product. The sum of the allocations must reconcile to the actual expenditure. Equally, allocating all shared cost to the most profitable product without evidence can disconnect the numerator from the development that produced it.

Use different allocation drivers only where there is a factual reason. Engineering effort, documented project use and technical dependency can help explain a cost relationship. Revenue may be relevant in some contexts but should not be selected automatically for every development cost merely because it is easy to obtain.

• List the shared work and the products or assets benefiting from it.
• Explain why direct assignment is unavailable.
• Record the allocation driver and supporting evidence.
• Reconcile allocated amounts to the source total.
• Review the method when the architecture or use changes.

Income allocation needs its own evidence

Cost allocation does not itself establish how income should be divided. A bundled subscription may include access to multiple assets and non-IP services. Review contracts, pricing and the commercial contribution of each component before deriving net income for the relevant calculation.

Maintain a bridge from recognised revenue to the asset-level schedules. Include refunds, credits and other adjustments consistently. Costs of earning income must also be allocated so the combined results reconcile to the business accounts, subject to identifiable tax adjustments.

If one asset is acquired and another developed internally, keep their acquisition and R&D histories distinct. Moving revenue between product labels should not make the acquisition cost vanish from the asset to which it relates.

Treat product changes as review events

Product mergers, shared-platform migrations and major rewrites can change the factual map. Preserve the history before changing identifiers and document whether the work improves an existing asset or creates a separate one. A marketing relaunch alone does not answer that question.

An annual review should be able to explain the asset list, changes during the year, income attribution, shared-cost allocations and resulting fractions. Where the appropriate treatment remains uncertain, obtain specific advice or clarification on those facts rather than applying a universal product-family rule.