Cyprus IP Box: Softwareentwicklungsvertrag und praktische Prüfliste

Der Vertrag muss die tatsächliche Entwicklungsbeziehung beschreiben

Ein Softwareentwicklungsvertrag ist ein nützlicher Beleg, weil er erklärt, wer die Arbeit beauftragt und ausgeführt hat, welchem Produkt sie zugutekommt und welche Rechte entstehen. Er ist keine IP-Box-Genehmigung. Die Voraussetzungen für Wirtschaftsgut, Einkommen, Ausgaben und tatsächliches Verhalten müssen weiterhin gesondert geprüft werden.

Benennen Sie die richtigen Rechtsträger und ihr Verhältnis zueinander. Angestellte, selbstständige Entwickler, unabhängige Studios und verbundene Forschungsunternehmen erfüllen unterschiedliche Rollen. Prüfen Sie eingetragene Firma, Zahlungsempfänger, Land, Subunternehmerkette und Konzernzugehörigkeit. Ein Handelsname auf der Rechnung kann den tatsächlichen Vertragspartner verbergen und die Nexus-Einordnung verändern.

Definieren Sie das Projekt so, dass die Angaben mit den Arbeiten abgeglichen werden können. Eine Leistungsbeschreibung sollte Produkt, Modul, Ergebnisse, Meilensteine, Abnahme und wichtige Änderungen nennen. Behaupten Sie nicht, jede technische Stunde sei qualifizierende Forschung. Support, Implementierung beim Kunden oder Marketing können neben Entwicklung stehen, müssen aber getrennt beschrieben und zugeordnet werden.

Verknüpfen Sie mit dem Vertrag Rechte und Buchführung. Vertrag, Projektdaten, Rechnung und Verzeichnis des immateriellen Guts sollten dieselbe Geschichte erzählen. Wenn ein Rahmenvertrag eine breite Plattform umfasst, der Anspruch aber nur ein Modul betrifft, benennen Sie das Modul und die Grundlage der Arbeitszuordnung. Eine pauschale Behauptung über „qualifizierende IP“ beantwortet die Frage nicht.

Vereinbaren Sie eine praktikable Dokumentation. Nicht jeder Dienstleister braucht minutengenaue Zeiterfassung. Projektkennzeichen, Entwicklungsaufgaben, Versionshistorie oder Abnahme von Meilensteinen können bei einem Festpreis verlässlicher sein. Entscheidend ist, dass sich Vergütung und konkrete Arbeit, ausführende Person, Zeitpunkt und begünstigtes Gut nachvollziehen lassen.

Neuen Code, vorhandene Technik und spätere Verbesserungen trennen

Neu für den Auftraggeber geschriebener Code, Technik aus der Zeit vor dem Auftrag und spätere Verbesserungen sind verschiedene Kategorien. Der Vertrag sollte sagen, welche Rechte übertragen, lizenziert oder beim Entwickler beziehungsweise Dritten belassen werden. Eine pauschale Übertragung „sämtlicher IP“ kann irreführen, wenn der Anbieter verwendete Werkzeuge selbst nicht übertragen darf.

Prüfen Sie die für das Geschäftsmodell erforderlichen Rechte: Nutzung, Vervielfältigung, Änderung, Wartung, Unterlizenzierung, Vertrieb, Weiterübertragung und Durchsetzung. Richtlinie 2009/24/EG schützt die Ausdrucksform eines originellen Computerprogramms, nicht zugrunde liegende Ideen; sie regelt auch bestimmte Arbeitnehmerprogramme. Daraus folgt keine automatische Rechteübertragung jedes freien oder ausländischen Entwicklers an den Auftraggeber.

Fragen Sie nach wiederverwendbaren Bibliotheken, Open-Source-Bausteinen, Schnittstellen und Code von Subunternehmern. Der Vertrag kann Offenlegung und Beachtung fremder Lizenzen verlangen. Die Rechteakte muss aber zeigen, dass der Anbieter die versprochenen Rechte tatsächlich erworben hat. Eine Zusage einer Konzerngesellschaft beseitigt keine Lücke in der Rechtekette des Subunternehmers.

Regeln Sie Verbesserungen, Bearbeitungen und spätere Versionen nach Abnahme. Entwickelt ein verbundenes Unternehmen eine gemeinsame Plattform weiter, muss klar sein, ob die zyprische Gesellschaft Eigentum, ausschließliche oder einfache Lizenz oder ein anderes Recht erhält. Eine spätere Verbesserung kann eine eigene Buchungs-, Preis- oder Nexus-Prüfung brauchen und fällt nicht automatisch unter die ursprüngliche Übertragung.

Denken Sie an Herausgabe von Quellcode, Dokumentation, Zugängen und Build-Materialien. Solche geschäftlichen Pflichten begründen allein keinen Steuervorteil. Sie können aber zeigen, ob die Gesellschaft beanspruchte Rechte praktisch ausüben und die Software bei Vertragsende weiter betreiben oder warten kann.

Jede Zahlung mit Arbeit und immateriellem Gut verbinden

Die zyprischen Vorschriften verlangen Aufzeichnungen über Erträge und Ausgaben je immateriellem Gut. Rechnungsbeschreibung und Projektkennzeichen sind daher sachlich wichtig. Legen Sie fest, wie der Anbieter Ergebnisse beschreibt, auf Leistungsbeschreibungen verweist und wesentliche Kategorien trennt. Die Finanzabteilung sollte eine Belastung mit der Arbeit, dem Datum und dem Verzeichnis des Guts verbinden können.

Gemischte Leistungen brauchen eine gestützte Aufteilung. Eine monatliche Rechnung kann einen neuen Algorithmus, Kundeneinführung und routinemäßigen Support umfassen. Umfang, Meilensteine, Zeiten oder andere vertretbare Maßstäbe können eine Aufteilung begründen; der gesamte Betrag wird dadurch nicht zu Forschung. Die Teilbeträge müssen mit der Originalrechnung übereinstimmen und dürfen nicht mehrfach auf Güter verteilt werden.

Unterscheiden Sie Entwicklung neuen Codes vom Erwerb einer fertigen Codebasis sowie unabhängige von verbundenen Anbietern. Das modifizierte Nexus-System behandelt diese Kategorien verschieden. Eine Überschrift „F&E-Dienstleistungen“ verwandelt den Kauf bestehender Software nicht in aktuelle Forschung und verändert nicht das gesellschaftsrechtliche Verhältnis der Beteiligten.

Trennen Sie Verrechnungspreise und Nexus. Ein verbundener Entwickler kann ein fremdübliches Entgelt erhalten; die Zahlung bleibt trotzdem Auslagerung an ein verbundenes Unternehmen für die Ausgabenkategorie. Ebenso braucht eine Ausgabe für unabhängige Entwicklung Belege für die Arbeit und den Gutbezug. Unabhängigkeit allein macht nicht jede Rechnung qualifizierend.

Bewahren Sie bei Festpreisen und Teilzahlungen Meilensteinplan, Abnahmen und Änderungen auf. Der Zahlungstag zeigt nicht immer, wann Arbeit und Aufwand entstanden. Nach den zyprischen Regeln wird qualifizierender Aufwand beim Entstehen berücksichtigt, unabhängig von seiner bilanziellen oder steuerlichen Behandlung; die Historie muss deshalb rekonstruierbar bleiben.

Tatsächliche Steuerung, Risiken und Zuständigkeiten festhalten

Erfassen Sie, wer technische Ziele setzt, Budget genehmigt, den Umfang ändert, Ergebnisse abnimmt und über Fortsetzung oder Abbruch entscheidet. Das sind praktische Fragen des Projektmanagements, die innerhalb einer Gruppe auch DEMPE und Verrechnungspreise betreffen können. Weisen Sie einer zyprischen Gesellschaft nicht nur im Vertrag Kontrolle zu, wenn ein ausländisches Team wirklich entscheidet.

Beschreiben Sie fehlgeschlagene Entwicklung, Nacharbeit, Verzögerungen und Mehrkosten. Ein Vertrag kann Risiken zuordnen; eine Gesellschaft, die deren Kontrolle beansprucht, braucht aber Fähigkeit und wirkliche Entscheidungen zur Steuerung. Protokolle und Änderungsfreigaben sind überzeugender, wenn sie während der Arbeit entstehen und nicht erst für eine spätere Steuerprüfung.

Bei grenzüberschreitenden Teams müssen anwendbares Recht, Arbeitnehmer- und Auftragnehmerregeln, Urheberstellung und Durchsetzbarkeit mit Fachleuten der betroffenen Länder geprüft werden. Artikel 2 der EU-Softwarerichtlinie behandelt Arbeitnehmerprogramme unter bestimmten Voraussetzungen und vorbehaltlich vertraglicher Regelung; er ist keine allgemeine Abtretung sämtlicher Freelancerrechte.

Machen Sie Subunternehmer sichtbar. Vereinbaren Sie, ob sie eingesetzt werden dürfen, wer zustimmt, wie Rechte und Sicherheitsanforderungen weitergegeben werden und ob der erste Anbieter verantwortlich bleibt. Für die Nexus-Klassifikation können tatsächlicher Leistungserbringer und dessen Beziehung zur Gesellschaft wichtig sein. Die Kette sollte nicht hinter einem allgemeinen Lieferantennamen verschwinden.

Klausel- und Belegcheckliste für ein reales Projekt

Nutzen Sie die folgenden Fragen bei der Besprechung mit Rechtsberatern oder bei der Prüfung eines vorhandenen Vertrags. Jede Antwort sollte auf ein Dokument, eine verantwortliche Person oder eine Entscheidung verweisen und nicht nur auf eine Standardklausel. Die Liste ist ein Prüfungsplan, keine unterschriftsreife Vertragsvorlage.

Beginnen Sie mit Parteien, Arbeit und Rechten. Bestätigen Sie Konzernbeziehung und anwendbares Recht; benennen Sie Software und Leistungsbeschreibung; trennen Sie neuen Code, alte Werkzeuge, Drittkomponenten und Verbesserungen; bestimmen Sie übertragene oder lizenzierte Rechte. Prüfen Sie die Rechtekette über Mitarbeiter, freie Entwickler und Subunternehmer, soweit diese beteiligt sind.

Danach prüfen Sie Betrieb und Kostennachweise. Wer leitet und nimmt Arbeit ab? Wie werden Änderungen genehmigt? Welche Ergebnisse, Meilensteine, Rechnungsangaben, Aufteilungsmethoden und gutbezogenen Aufzeichnungen bleiben erhalten? Technik und Finanzbuchhaltung sollten dieselben Projektkennzeichen verwenden, damit eine spätere Prüfung die Zuordnung nachrechnen kann.

Zum Schluss beurteilen Sie Steuerfragen separat: Ist der Anbieter für Nexus verbunden? Betrifft die Zahlung Entwicklung oder Erwerb? Welche kontrollierten Vorgänge erfordern Preisbelege? Welche Ertrags- und Ausgabendaten gibt es je geeignetem Wirtschaftsgut? Schreiben Sie kein steuerliches Ergebnis in den Vertrag, bevor die Tatsachen festgestellt sind.

Beispiel: Neuer Code, vorhandene Werkzeuge und Verbesserung

Angenommen, CyprusCo beauftragt das unabhängige Studio A mit einem neuen Analysemodul für eine bestehende Anwendung. Studio A verwendet eine eigene ältere Bibliothek, schreibt neuen Modulcode und entwickelt später eine gesonderte Verbesserung. Ein tragfähiger Vertrag beschreibt alle drei Kategorien, statt undefiniert „alles“ zu übertragen.

Der neue Code kann CyprusCo übertragen werden, wenn Studio A die dafür nötigen Rechte besitzt und die Übertragung nach anwendbarem Recht wirksam ist. Die ältere Bibliothek kann Eigentum von Studio A bleiben, während CyprusCo eine für das Modul geeignete Nutzungslizenz erhält. Die spätere Verbesserung benötigt eigenen Umfang, Rechte und Kostennachweis.

Die erste Rechnung betrage 90.000 €: 60.000 € für ursprüngliche Modulentwicklung, 20.000 € für vorhandenen Code beziehungsweise Rechte und 10.000 € für Kundenimplementierung. Das veranschaulicht eine Aufteilung, aber keine automatische steuerliche Einordnung. Welche Leistung tatsächlich qualifizierende Forschung ist, hängt von Arbeit und Rechtslage ab; Erwerb und Implementierung sind getrennt zu prüfen.

Ist Studio A tatsächlich eine Konzerngesellschaft statt unabhängig, werden die 60.000 € für Entwicklung nicht allein durch die Beauftragung oder einen fremdüblichen Preis zu eigener qualifizierender Ausgabe von CyprusCo. Die Beziehung beeinflusst Nexus; die Preisprüfung behandelt das Entgelt. Eine Umbenennung in „Personalkostenerstattung“ ändert die Tatsachen nicht.

Stammt die Verbesserung von einem Subunternehmer, dessen Rechte Studio A nicht erworben hat, kann CyprusCo den Code bezahlt und erhalten haben, aber dennoch eine unvollständige Rechtekette besitzen. Prüfen Sie die Verträge und erwerben Sie wirksame Rechte. Eine spätere Rechnungsbeschreibung oder ein allgemeines Steuermemo ersetzt die fehlende Verbindung nicht.

Vertrag und Unterlagen aktuell halten

Überprüfen Sie die Vereinbarung bei wesentlichen Änderungen von Parteien, Umfang, Produktarchitektur, Rechten oder Abrechnung. Bewahren Sie unterschriebene frühere Fassungen auf, damit historische Ausgaben anhand der damals geltenden Bedingungen und tatsächlichen Abläufe verstanden werden. Eine rückdatierte Änderung sollte nicht vorspiegeln, ein neuer Betrieb habe schon immer bestanden.

Vergleichen Sie jährlich eine Stichprobe tatsächlicher Arbeiten und Rechnungen mit dem vereinbarten Umfang. Prüfen Sie Code- und Versionshistorie, Abnahme von Meilensteinen, Zahlungsbeschreibungen und Gutverzeichnis. Stellen Sie fest, ob noch dieselbe Gesellschaft die Arbeit steuert, ob neue Subunternehmer aufgetreten sind und ob die Rechtekette vollständig bleibt.

Weichen Vertrag und Verhalten voneinander ab, dokumentieren Sie den Zeitraum und die Abweichung, bevor der Text umgeschrieben wird. Handelt es sich um einen fehlenden Nachtrag, eine falsche Rechnung, einen anders zu beurteilenden kontrollierten Vorgang oder eine echte Rechtslücke? Rechtliche und steuerliche Berichtigungen können sich unterscheiden.