Specjaliści z branży IT coraz częściej współpracują ze swoimi kontrahentami na podstawie umów cywilnoprawnych. Popularna umowa o dzieło z programistą od lat znajduje się pod lupą ZUS jako potencjalne narzędzie optymalizacji kosztów. Aktualne przepisy dają organom możliwość zakwestionowania ważności kontraktu i przekwalifikowania go na zlecenie. Sprawdźmy, w jakich sytuacjach może dojść do takiej kontroli i jak bezpiecznie sformułować umowę, aby uniknąć negatywnych konsekwencji.
Jak poprawnie przygotować dokument, jakim jest umowa o dzieło z programistą?
Najczęstszym błędem popełnianym przez strony umowy o dzieło jest opisywanie przedmiotu umowy jako zbioru czynności, a nie jako unikalnego, namacalnego wytworu. Zgodnie z art. 627 Kodeksu cywilnego przyjmujący zamówienie zobowiązuje się do wykonania oznaczonego dzieła, co oznacza, że świadczenie musi mieć charakter autonomiczny. W przypadku programisty oznacza to, że przedmiotem umowy nie powinno być pisanie kodu w określonych godzinach, lecz dostarczenie konkretnego modułu oprogramowania, mającego zdefiniowane funkcjonalności, przetestowanego pod kątem błędów i spełniającego kryteria odbioru zawarte w dokumentacji technicznej.
Sąd Najwyższy wielokrotnie podkreślał w swoim orzecznictwie, że cechą charakterystyczną dzieła jest możliwość poddania go sprawdzianowi na istnienie wad fizycznych, co w świecie IT przekłada się na testy jednostkowe, dokumentację API czy konkretny schemat tworzonej aplikacji. Jeśli umowa nie przewiduje procedury odbioru, nie definiuje kryteriów akceptacji technicznej i nie określa, co konkretnie ma powstać w procesie tworzenia, organ kontrolny może zakwestionować charakter umowy i wydać decyzję stwierdzającą podleganie ubezpieczeniom społecznym, która następnie podlega kontroli sądowej.
„Dla właściwej kwalifikacji przyjmuje się, że dziełem jest z góry określony samoistny, materialny lub niematerialny, znajdujący ucieleśnienie w rzeczy [...] rezultat pracy fizycznej lub umysłowej i umiejętności przyjmującego zamówienie, których charakter nie wyklucza możliwości zastosowania przepisów o rękojmi za wady, a zespół tych cech musi występować łącznie”.
Przykład 1.
Pan Jan jest przedsiębiorcą, który zatrudnił programistę na podstawie umowy o dzieło, określając jej przedmiot jako stworzenie modułu obsługi szybkich płatności. W umowie zabrakło jednak doprecyzowania, jakie konkretnie metody płatności mają zostać zaimplementowane, jakie standardy bezpieczeństwa (np. zgodność z PCI DSS) muszą zostać spełnione oraz w jakim środowisku testowym ma zostać dostarczony wynik prac. Programista przez 2 miesiące zajmował się poprawianiem błędów w już istniejącym kodzie, co ZUS uznał za typowe czynności starannego działania, a nie realizację zamkniętego dzieła. Jak w tym przypadku obronić kwalifikację umowy jako o dzieło, unikając zarzutu pozorności? Kluczem jest wykazanie zindywidualizowania rezultatu. W przypadku sporu należy wskazać na załącznik do umowy będący specyfikacją techniczną (np. dokumentem wymagań funkcjonalnych), w którym jasno określono pożądany stan końcowy, odróżnialny od bieżącej konserwacji kodu. Jeśli natomiast umowa faktycznie ograniczała się do bieżącego wsparcia i poprawiania błędów, to z punktu widzenia prawa cywilnego mamy do czynienia z umową o świadczenie usług, do której stosuje się przepisy o zleceniu. Aby zabezpieczyć się na przyszłość, pan Jan w zawieranych przez siebie umowach o dzieło powinien zawsze stosować zapis o przekazaniu autorskich praw majątkowych do konkretnego, wyodrębnionego kodu, który musi zostać fizycznie odebrany przez zamawiającego za pomocą protokołu odbioru, co potwierdzi zakończenie procesu tworzenia.
Ryzyko przekwalifikowania umowy o dzieło z programistą na zlecenie przez ZUS
W relacjach z programistami, często pracującymi w sposób zdalny i rozproszony, łatwo o przekroczenie granicy między nadzorem autorskim a podporządkowaniem pracowniczym. Zgodnie z art. 22 kp cechą stosunku pracy jest wykonywanie pracy pod kierownictwem oraz w miejscu i czasie wyznaczonym przez pracodawcę. Jeśli jako zamawiający narzucamy programiście godziny pracy, wymagamy dostępności na komunikatorach w określonych ramach czasowych czy egzekwujemy obecność na codziennych spotkaniach w sposób identyczny, jak wobec pracowników etatowych, narażamy się na ryzyko uznania, że naruszamy zasady swobody zawierania umów. Co więcej, próba wymuszania narzuconych sztywnych ram pracy na osobach na kontraktach cywilnoprawnych może prowadzić do oskarżeń o dyskryminację, jeśli osoby na umowach o pracę korzystają z szerszego pakietu przywilejów socjalnych, a wykonawcy dzieła są wykluczeni z tego rodzaju benefitów, będąc jednocześnie traktowanymi jak podwładni.
Nakładanie na wykonawcę dzieła kar porządkowych charakterystycznych dla stosunku pracy nie znajduje podstaw w przepisach prawa cywilnego i może zostać potraktowane jako argument przemawiający za istnieniem stosunku pracy.
Przykład 2.
Firma technologiczna narzuciła wszystkim współpracownikom, w tym programistom na umowach o dzieło, obowiązek pracy w określonym systemie monitorowania czasu, w którym musieli raportować każdą godzinę pracy z podziałem na wykonane zadania. W przypadku niespełnienia tego wymogu zamawiający wstrzymywał wypłatę wynagrodzenia, twierdząc, że dzieło nie zostało dostarczone zgodnie z instrukcjami. Czy takie monitorowanie wykonawcy dzieła jest dopuszczalne w świetle prawa cywilnego i czy nie kreuje to stosunku pracy? W umowie o dzieło zamawiający ma prawo kontrolować prawidłowość wykonywania dzieła, ale nie sposób jego pracy w czasie rzeczywistym, chyba że jest to niezbędne dla zabezpieczenia interesów technicznych. Wprowadzenie rygorystycznego systemu monitorowania czasu dla programisty, który powinien rozliczać się za gotowy produkt, a nie za czas pracy, jest bezpośrednim dowodem na stosowanie mechanizmów kontrolnych właściwych dla stosunku pracy. Programista powinien być rozliczany za poszczególne etapy wdrożenia projektu, a nie za godziny spędzone przed monitorem. Wymuszanie ewidencji czasu pracy w umowie o dzieło jest najszybszą drogą do przegranej w sporze z organami ubezpieczeniowymi.
Przykład 3.
Programista realizował dzieło polegające na stworzeniu aplikacji mobilnej. W połowie procesu, z powodu zmiany strategii biznesowej firmy, zamawiający wypowiedział umowę, powołując się na art. 644 kc, który daje zamawiającemu prawo do odstąpienia od umowy w dowolnym czasie, pod warunkiem zapłaty wynagrodzenia. Programista zażądał jednak pełnego wynagrodzenia, twierdząc, że był w pełni dyspozycyjny i odrzucił inne oferty, licząc na dokończenie projektu. Czy programista może skutecznie żądać odszkodowania wykraczającego poza zapisy kodeksowe, jeśli umowa nie została zrealizowana? Zgodnie z treścią art. 644 kc zamawiający może w każdej chwili od umowy odstąpić, płacąc umówione wynagrodzenie, jednakże może odliczyć to, co przyjmujący zamówienie oszczędził z powodu niewykonania dzieła. Problem pojawia się, gdy programista wykaże, że ze względu na specyfikę projektu był zablokowany czasowo dla innych potencjalnych klientów. Warto w takich sytuacjach mieć w umowie precyzyjny harmonogram etapów, który pozwala na częściowy odbiór dzieła. Pozwala to uniknąć sporów i wyceniać pracę etapami. W kontekście prawnym zabezpieczenie interesów obu stron wymaga wprowadzenia klauzul przewidujących wynagrodzenie za odebrane etapy dzieła w konkretnych okresach, przy jednoczesnym utrzymaniu wymogu dostarczenia konkretnego rezultatu w każdym z tych okresów, co minimalizuje ryzyko przekwalifikowania umowy przez ZUS.
Jakie są konsekwencje, gdy umowa o dzieło z programistą zostanie zakwestionowana przez organ kontrolny?
Proces przekwalifikowania umowy o dzieło na umowę zlecenie przez ZUS stanowi jedną z największych obaw przedsiębiorców działających w sektorze IT. Organ rentowy, działając w ramach swoich uprawnień kontrolnych wynikających z Ustawy z dnia 13 października 1998 roku o systemie ubezpieczeń społecznych, w pierwszej kolejności analizuje rzeczywisty sposób wykonywania zobowiązań, nie ograniczając się jedynie do literalnego brzmienia kontraktu.
Jeżeli w toku postępowania wyjaśniającego wyjdzie na jaw, że zamiast unikalnego rezultatu programista świadczył powtarzalne czynności, podlegał bieżącemu kierownictwu, raportował czas pracy lub był włączony w struktury organizacyjne firmy na zasadach analogicznych do pracowników, ZUS ocenia rzeczywisty sposób wykonywania zobowiązania, kierując się utrwalonym orzecznictwem, zgodnie z którym o charakterze umowy decyduje jej treść i sposób realizacji, a nie nazwa nadana przez strony. W konsekwencji dochodzi do stwierdzenia podlegania obowiązkowym ubezpieczeniom społecznym, co skutkuje decyzją o konieczności odprowadzenia zaległych składek wraz z odsetkami za zwłokę oraz ewentualnymi karami z tytułu nieprawidłowości w zgłoszeniach. Taka decyzja, mająca charakter aktu administracyjnego, jest dla przedsiębiorcy niezwykle trudna do podważenia, gdyż ciężar dowodu w sporze sądowym spoczywa wówczas na płatniku, który musi udowodnić przed sądem pracy i ubezpieczeń społecznych, że proces twórczy faktycznie był ukierunkowany na autonomiczny rezultat podlegający rękojmi, a nie na ciągłe świadczenie usług.
Podsumowanie
Bezpieczeństwo umowy o dzieło z programistą wymaga radykalnego przejścia od rozliczania czasu pracy w stronę wynagradzania za konkretne, unikalne i weryfikowalne rezultaty. Aby skutecznie zabezpieczyć się przed ryzykiem przekwalifikowania umowy na zlecenie przez ZUS, przedsiębiorca musi oprzeć współpracę na trzech fundamentach, którymi są precyzyjne definiowanie przedmiotu dzieła jako przetestowanego modułu o określonych funkcjonalnościach, rygorystyczne stosowanie protokołów odbioru potwierdzających wykonanie prac oraz zachowanie pełnej autonomii wykonawcy poprzez eliminację elementów podporządkowania pracowniczego, takich jak nadzorowanie godzin czy ewidencja czasu pracy. W praktyce oznacza to rezygnację z płacenia za gotowość do pracy na rzecz finansowania gotowych produktów, co stanowi jedyną skuteczną barierę przed zarzutem pozorności stosunku pracy.
