Employee-created software: rights and Cyprus IP Box records

Begin with the employment relationship and scope of work

Software created by an employee is not analysed in exactly the same way as a freelancer’s deliverable. Article 2(3) of Directive 2009/24/EC addresses economic rights in programs created in the execution of employment duties or employer instructions, subject to contrary contractual provision.

That makes the facts important. Identify the employer, the relevant duties and the circumstances of creation. A person working for a group subsidiary is not automatically an employee of the company that intends to exploit the IP. A founder who helps the business informally may also have a different legal position from a documented employee.

Review the applicable national law and contract, especially for staff working across borders. This guide explains the questions to investigate; it does not assume a single contract clause has the same effect in every country.

Distinguish employment work from earlier and outside projects

An employee may bring pre-existing code, libraries or a personal project into the business. That material needs to be identified separately from software created as part of the job. The company should establish what rights it receives and whether third-party restrictions remain.

Similarly, an employee’s repository can contain both company work and unrelated personal work. Account ownership or use of a company laptop does not by itself provide a complete legal conclusion. Keep the contract, scope of duties and project evidence aligned.

Create a process for declaring approved background technology and external components. This helps avoid conflicting assumptions: the employee may believe a library remains personal property while the company describes the whole product as exclusively owned.

Check which group company holds the relevant rights

In a group structure, one company may employ developers while another sells the product. Establish how the exploitation rights reach the revenue-earning company and what the intercompany development arrangement provides. Do not assume common shareholders make the distinction irrelevant.

The same arrangement also affects nexus classification. Development services from a related company are not transformed into the IP owner’s own salary expenditure merely because the service provider’s invoice is based on payroll. Ownership, transfer pricing and the expenditure formula each need their own analysis.

If employees move between entities, document the change and the treatment of existing and future work. The new arrangement should not silently rewrite the history of who created, funded or owned earlier software.

Build a practical employee software file

The file should connect the person’s role with the software and the company’s rights. It need not reproduce every development artefact, but it should allow a reviewer to understand the material contributions and any exceptions.

Keep records proportionate to the purpose. Project descriptions, approved scope, repository history and employment terms can complement one another. Avoid unnecessary personal information where the work can be evidenced through project references and role records.

• Correct employing entity and relevant employment dates.
• Duties or instructions covering the development work.
• Contractual provisions affecting software rights.
• Declared background code and third-party licences.
• Project and asset identifiers linked to material contributions.
• Intercompany rights arrangements where another entity exploits the software.
• Documented changes on transfers or departure.

Rights and salary allocation are separate checks

Even when the company’s economic rights are clear, not all employee time is necessarily qualifying R&D. A developer may also provide support, demonstrations or routine operation. Review the work and supported allocation of salary costs before including them in QE.

Conversely, records showing development expenditure do not replace the rights analysis. A payroll schedule says who was paid; it does not resolve background-code restrictions or the rights of a different employing entity. Keep the two evidence chains connected without treating either as conclusive on its own.

At year end, reconcile the relevant payroll allocation to the asset’s expenditure schedule. Explain shared work and avoid counting the same effort in several products. A defensible nexus calculation follows the actual work and expenditure.

Use departures and restructurings as review points

When a developer leaves, preserve company access to source materials and project records through normal authorised handover procedures. Confirm the status of unresolved background components and ensure future maintenance does not depend on a personal account.

An acquisition or restructuring is another reason to review the file. Buyers and investors often need to understand the chain of rights as well as the tax calculation. A clear employment record can make that review easier without promising that every ownership or eligibility question has been eliminated.