IPBoxCyprus
Cyprus IP Box guides

Marketplace commissions and the Cyprus IP Box

Assess a marketplace’s software contribution separately from transaction value, commissions, payment services and other commercial functions.

IPBox Cyprus editorial team · Ebrovia Ltd
Updated:

Marketplace commission is not automatically qualifying IP income. Identify the company’s qualifying software and how it contributes to the service, then support any embedded-income attribution and relevant costs. Gross merchandise value is not the same as the marketplace’s revenue or qualifying profit.

Keep transaction value, revenue and profit separate

A marketplace may process a large value of transactions while earning only a commission or service fee. The total value paid by buyers is often described as gross merchandise value. It should not be inserted into an IP Box profit calculation as though it were all income earned by the platform.

The company’s revenue recognition depends on the actual arrangement and applicable accounting treatment, including whether it acts as principal or agent. Establish that position before the tax bridge. Funds collected for sellers and amounts retained by the platform need to be distinguished.

Net income requires a further step: relevant costs must be taken into account. Even if part of the marketplace’s own revenue is attributable to qualifying software, the deduction is not applied directly to gross transaction value or receipts.

Identify what earns the marketplace fee

A marketplace may provide matching technology, payment handling, customer acquisition, dispute resolution, logistics or human account management. Its commission can reward several functions together. The existence of a proprietary website or app does not establish that all profit is attributable to qualifying software.

The Cyprus regulations include embedded income from products and services directly related to qualifying IP. A marketplace therefore needs a fact-specific attribution analysis where relevant. It should not assume either universal eligibility or universal exclusion solely because the invoice calls the fee a commission.

Map the technology and the commercial functions. Identify the software asset and rights, how customers use it and what other activities contribute to the fee. Where related entities perform functions, consider the separate pricing and profit-allocation questions.

A simple reconciliation exposes the key questions

Suppose buyers transact €5 million through a platform and the company retains €500,000 in recognised fees under the assumed arrangement. The IP Box analysis starts with the company’s income, not the €5 million transaction total.

Assume the company also earns €100,000 from separately contracted manual advisory work. That additional activity needs its own classification. The company should not combine all €600,000 and assume it is software income simply because the customers were introduced through the platform.

The example intentionally leaves the qualifying allocation unresolved. A credible assessment must establish it from the facts, then account for relevant costs and apply the supported nexus fraction. An invented percentage would conceal the main question rather than answer it.

Shared operating costs can materially change the result

Marketing, payment processing, customer support and infrastructure may support the marketplace as a whole. Identify how costs relate to the income components and document reasonable allocations where needed. Do not leave all shared costs against non-IP activity while assigning most income to software.

Keep R&D expenditure separate from ordinary operating costs. Developing a matching capability may present different facts from running advertising campaigns or handling disputes. Technical complexity alone does not convert every operational expense into QE.

Use consistent asset identifiers and reconcile both the income schedules and expenditure history to the accounts. The nexus fraction should reflect the relevant asset’s development and acquisition history, not the marketplace’s current transaction volume.

Build a marketplace-specific evidence pack

The pack should explain how money moves and why the company earns its fee. This helps prevent confusion between customer funds, recognised revenue and qualifying profit.

  • Buyer, seller and platform terms.
  • Principal-or-agent and revenue-recognition analysis.
  • Reconciliation of transaction value, collected funds and retained revenue.
  • Description of software and non-software functions.
  • Ownership and development history of the relevant asset.
  • Supported income and shared-cost allocations.
  • Separate nexus and any relevant transfer-pricing analysis.

Review new revenue streams separately

A marketplace can add subscriptions, promoted listings, payment services or managed fulfilment over time. Each new stream can change the income mix. Do not carry forward a single qualifying percentage without reviewing what the business now supplies.

Promoted listings may particularly involve advertising and marketing value as well as software functionality. That calls for analysis, not a blanket statement that advertising revenue always qualifies or never can. The relevant asset and income connection remain central.

Model the company’s actual expected profit mix before making tax-saving claims to investors or partners. A supported partial claim can be more reliable than presenting the full-nexus headline rate as the tax rate on every transaction.

Common questions

Is gross merchandise value qualifying income?

It is not automatically the company’s revenue at all. Establish recognised platform income and then the relevant net IP income.

Do marketplace commissions always qualify?

No universal answer applies. Examine the qualifying software contribution, other functions and a supported attribution of income and costs.

Sources and scope

General information, with illustrative examples. Eligibility and tax treatment depend on the facts and applicable law; this article is not an individual tax opinion.