Cyprus IP Box: umowa rozwoju oprogramowania i praktyczna lista

Umowa powinna opisywać rzeczywistą współpracę przy rozwoju

Umowa dotycząca rozwoju oprogramowania jest użytecznym dowodem, bo wyjaśnia, kto zamówił i wykonał prace, jaki produkt skorzystał oraz jakie prawa powstały. Nie stanowi zatwierdzenia ulgi IP Box. Kwalifikowany składnik, przychód, koszty i faktyczne działanie nadal wymagają odrębnego sprawdzenia według obowiązujących zasad.

Ustal właściwe strony prawne i ich powiązania. Pracownik, niezależny freelancer, zewnętrzne studio i badawcza spółka grupy mają różne role. Sprawdź zarejestrowaną firmę, odbiorcę płatności, kraj, łańcuch podwykonawców i relację kapitałową. Nazwa handlowa na fakturze może ukrywać prawdziwą stronę umowy i zmieniać klasyfikację nexus.

Opisz zlecenie na poziomie możliwym do porównania z pracami. Specyfikacja powinna wskazywać produkt, moduł, wyniki, etapy, odbiór i ważne zmiany. Nie twierdź, że każda godzina techniczna jest kwalifikowanym badaniem. Wsparcie, wdrożenie klienta i marketing mogą towarzyszyć rozwojowi, lecz potrzebują oddzielnego opisu i ujęcia kosztów.

Połącz w umowie prawa i dokumentację finansową. Kontrakt, zapis projektu, faktura i ewidencja składnika powinny mówić to samo. Jeśli umowa obejmuje platformę, a wniosek IP Box dotyczy jednego komponentu, określ komponent i zasadę przypisania prac. Ogólne zdanie o „kwalifikowanej IP” nie rozwiązuje problemu.

Ustal praktyczny sposób potwierdzania pracy. Nie każdy dostawca musi prowadzić ewidencję co do minuty. Kod projektu, zadanie, wersja oprogramowania lub odbiór etapu mogą lepiej dokumentować cenę ryczałtową. Ważne, by dało się połączyć płatność z pracą, wykonawcą, datą i aktywem.

Oddziel nowy kod, wcześniejszą technologię i późniejsze ulepszenia

Kod napisany dla klienta, technologia dostawcy istniejąca przed zleceniem i późniejsze ulepszenia to różne kategorie. Umowa powinna podawać, jakie prawa są przenoszone, licencjonowane lub pozostają u wykonawcy albo osób trzecich. Ogólne przeniesienie „całej IP” może obiecywać prawa do narzędzi, których dostawca sam nie może przenieść.

Sprawdź prawa potrzebne dla modelu biznesowego: używanie, kopiowanie, modyfikację, utrzymanie, sublicencjonowanie, dystrybucję, przeniesienie i ochronę. Dyrektywa 2009/24/WE chroni formę wyrażenia oryginalnego programu, nie idee leżące u podstaw, oraz reguluje niektóre programy pracownicze. Nie przenosi automatycznie praw każdego freelancera lub zagranicznego dostawcy na zamawiającego.

Zapytaj o biblioteki wielokrotnego użytku, elementy open source, zewnętrzne interfejsy i kod podwykonawców. Umowa może nakazywać ujawnienie i przestrzeganie licencji, ale dokumentacja praw powinna wykazać, że dostawca uzyskał prawa, które obiecuje przekazać. Zapewnienie spółki grupy nie usuwa braku w łańcuchu podwykonawcy.

Ureguluj prace pochodne, ulepszenia i wersje po odbiorze. Gdy spółka powiązana ulepsza wspólną platformę, wyjaśnij, czy spółka cypryjska dostaje własność, licencję wyłączną lub niewyłączną albo inne uprawnienie. Późniejsze ulepszenie może potrzebować osobnej analizy księgowej, cenowej i nexus; nie zawsze należy do pierwotnego przeniesienia.

Pamiętaj o wydaniu kodu źródłowego, dokumentacji, dostępów i materiałów do budowania programu. Takie obowiązki handlowe same nie tworzą ulgi podatkowej. Mogą jednak pokazać, czy spółka może rzeczywiście korzystać z deklarowanych praw i utrzymywać program po zakończeniu współpracy.

Powiąż każdą płatność z pracą i aktywem

Cypryjskie przepisy wymagają ewidencji przychodów i wydatków dla każdego składnika niematerialnego. Opis faktury i kod projektu są więc istotne. Ustal, jak dostawca opisuje wyniki, odwołuje się do specyfikacji i oddziela ważne kategorie. Finanse powinny umieć połączyć koszt z pracą, datą i rejestrem aktywa.

Zlecenia mieszane wymagają uzasadnionego podziału. Jedna miesięczna faktura może obejmować nowy algorytm, wdrożenie klienta i rutynowe wsparcie. Zakres, etapy, czas lub inny obronny klucz mogą uzasadnić podział; cała kwota nie staje się badaniem. Części muszą sumować się do oryginalnej faktury bez podwójnego przypisania.

Oddziel rozwój nowego kodu od zakupu istniejącej bazy kodu oraz niezależnego dostawcę od powiązanego. Zmodyfikowany nexus traktuje te kategorie inaczej. Nagłówek „usługi B+R” nie zmienia kupna gotowego programu w bieżące badanie ani nie zmienia powiązań stron.

Rozdziel ceny transferowe od nexus. Powiązany deweloper może otrzymać rynkową zapłatę, ale wydatek nadal stanowi zlecenie podmiotowi powiązanemu dla klasyfikacji. Podobnie koszt niezależnego wykonawcy wymaga dowodów pracy i związku z aktywem; niezależność sama nie kwalifikuje każdej faktury.

Przy ryczałcie lub płatności etapowej zachowaj harmonogram, odbiory i zmiany. Data zapłaty nie zawsze wskazuje, kiedy wykonano pracę i poniesiono wydatek. Cypryjskie zasady uwzględniają kwalifikowany koszt w momencie poniesienia bez względu na jego ujęcie rachunkowe lub podatkowe; historię trzeba móc odtworzyć.

Zapisz rzeczywiste zarządzanie, ryzyka i obowiązki

Wskaż, kto ustala priorytety techniczne, zatwierdza budżet, zmienia zakres, odbiera wyniki i decyduje o kontynuacji albo zakończeniu projektu. Są to sprawy zarządcze, które w grupie mogą mieć znaczenie również dla DEMPE i cen transferowych. Nie przypisuj kontroli spółce cypryjskiej wyłącznie w dokumencie, gdy zagraniczny zespół naprawdę decyduje.

Opisz nieudane prace, poprawki, opóźnienia i przekroczenie kosztów. Umowa może rozdzielać ryzyko, ale podmiot deklarujący kontrolę nad istotnym ryzykiem potrzebuje zdolności i rzeczywistych decyzji zarządczych. Protokoły i zgody na zmiany są bardziej przekonujące, gdy powstają podczas pracy, a nie później na potrzeby kontroli.

W projektach transgranicznych sprawdź prawo właściwe, lokalne zasady zatrudnienia i zleceń, autorstwo i wykonalność z prawnikami odpowiednich krajów. Artykuł 2 dyrektywy o programach dotyczy określonych utworów pracowniczych z uwzględnieniem umowy; nie stanowi powszechnego przeniesienia praw wszystkich freelancerów.

Uwidocznij podwykonawców. Określ, czy są dozwoleni, kto ich zatwierdza, jak przepływają prawa i obowiązki bezpieczeństwa oraz czy główny dostawca pozostaje odpowiedzialny. Tożsamość i powiązanie faktycznego wykonawcy mogą mieć znaczenie dla nexus. Nie chowaj łańcucha za ogólną nazwą dostawcy.

Lista klauzul i dowodów dla prawdziwego projektu

Użyj poniższych pytań w rozmowie z prawnikiem lub przy przeglądzie istniejącej umowy. Każda odpowiedź powinna wskazywać dokument, odpowiedzialną osobę albo faktyczną decyzję, nie tylko standardową klauzulę. To plan weryfikacji, a nie gotowy wzór prawny do podpisu.

Zacznij od stron, pracy i praw. Potwierdź powiązania i prawo właściwe; zidentyfikuj program i specyfikację; oddziel nowy kod, stare narzędzia, komponenty trzecie i ulepszenia; ustal prawa przenoszone lub licencjonowane. Sprawdź łańcuch praw przez pracowników, freelancerów i podwykonawców, jeśli uczestniczą.

Następnie sprawdź zarządzanie i dowody kosztów. Kto kieruje pracą i ją odbiera? Jak zatwierdza się zmiany? Jakie wyniki, etapy, opisy faktur, podziały i ewidencje według aktywów są przechowywane? Zespół techniczny i finansowy powinny używać tych samych kodów projektu, aby późniejszy kontrolujący odtworzył alokację.

Na koniec osobno oceń kwestie podatkowe: czy dostawca jest powiązany dla nexus, czy płatność dotyczy rozwoju czy nabycia, które transakcje kontrolowane wymagają analizy cen i jakie przychody oraz wydatki zapisano dla aktywa. Nie wpisuj wniosku podatkowego do umowy przed ustaleniem faktów.

Przykład: nowy kod, wcześniejsze narzędzia i ulepszenie

Załóżmy, że CyprusCo zamawia u niezależnego Studia A nowy moduł analityczny do istniejącej aplikacji. Studio A używa własnej starszej biblioteki, pisze nowy kod i później tworzy odrębne ulepszenie. Dobra umowa opisuje te trzy kategorie, zamiast niejasno przenosić „wszystko”.

Nowy kod może zostać przeniesiony na CyprusCo, jeśli Studio A ma potrzebne prawa, a przeniesienie jest skuteczne według prawa właściwego. Wcześniejsza biblioteka może pozostać własnością Studia A, natomiast CyprusCo uzyskuje właściwą licencję do używania jej z modułem. Późniejsze ulepszenie wymaga własnego zakresu, praw i historii wydatków.

Pierwsza faktura przykładowo wynosi 90 000 €: 60 000 € za oryginalny rozwój modułu, 20 000 € za zakup istniejącego kodu lub praw i 10 000 € za wdrożenie u klienta. Liczby pokazują podział, a nie automatyczną klasyfikację podatkową. Odpowiednie badania zależą od faktycznej pracy i praw; zakup i wdrożenie bada się osobno.

Jeśli Studio A okazuje się spółką grupy, a nie podmiotem niezależnym, te same 60 000 € nie stają się własnym kwalifikowanym kosztem CyprusCo tylko z powodu zlecenia lub rynkowej ceny. Powiązanie wpływa na nexus, a ceny transferowe badają wynagrodzenie. Zmiana nazwy na „zwrot wynagrodzeń” nie zmienia faktów.

Jeśli ulepszenie napisał podwykonawca, od którego Studio A nie uzyskało praw, CyprusCo może zapłacić i otrzymać kod, lecz mieć niepełny łańcuch praw. Trzeba zbadać umowy i uzyskać skuteczne prawa. Późniejszy opis faktury lub ogólne memorandum podatkowe nie zastąpi brakującego ogniwa.

Aktualizuj umowę i ewidencję

Przeglądaj umowę, gdy istotnie zmieniają się strony, zakres, architektura produktu, prawa lub metoda rozliczeń. Zachowuj wcześniejsze podpisane wersje, aby historyczne wydatki rozumieć według ówczesnych zasad i działań. Zmiana z datą wsteczną nie powinna sugerować, że nowy model istniał zawsze.

Corocznie porównaj próbkę faktycznych prac i faktur z uzgodnionym zakresem. Sprawdź historię kodu i wersji, odbiór etapów, opisy płatności i ewidencję aktywów. Zapytaj, czy ta sama spółka nadal kieruje pracą, czy pojawili się nowi podwykonawcy i czy łańcuch praw pozostał pełny.

Jeśli umowa i zachowanie różnią się, opisz rozbieżność i okres przed zmianą tekstu. Czy brakuje aneksu, faktura jest błędna, transakcja kontrolowana jest inna czy występuje rzeczywista luka w prawach? Korekta prawna i podatkowa mogą być odmienne.