Spis treści
- adw. TOMASZ SOWA, LL.M.
- +48 22 243 34 75
- kancelaria@sowaip.pl
W skrócie
- Zgodnie z art. 643 k.c. zamawiający ma obowiązek odebrać dzieło wykonane zgodnie z umową – odbiór nie jest jego swobodną decyzją.
- Brak podpisu pod protokołem nie przekreśla prawa do wynagrodzenia, jeżeli oprogramowanie działa i realizuje umówione funkcje.
- Sądy uznają „odbiór dorozumiany”, gdy klient korzysta z systemu produkcyjnie, akceptuje go mailowo albo rozlicza prace.
- Odmowa odbioru jest skuteczna tylko przy wadach istotnych – takich, które uniemożliwiają korzystanie z systemu zgodnie z przeznaczeniem.
• Najlepszą ochroną jest umowa z procedurą odbioru: terminy testów, forma zgłaszania wad i mechanizm milczącego odbioru.
Projekt został ukończony, wykonawca dostarczył klientowi działające oprogramowanie, wdrożenie zostało przeprowadzone, a system jest już wykorzystywany w działalności zamawiającego. Kiedy jednak przychodzi moment podpisania protokołu odbioru i wystawienia końcowej faktury, klient zaczyna zgłaszać kolejne uwagi, domaga się dodatkowych zmian albo po prostu przestaje odpowiadać. Branża IT zna ten problem zbyt dobrze. Powstaje wówczas pytanie: czy brak podpisu pod protokołem odbioru oznacza, że software house nie wykonał umowy, a tym samym nie może skutecznie dochodzić zapłaty wynagrodzenia?
Odbiór oprogramowania a obowiązek współdziałania klienta
W praktyce sporów dotyczących wdrożeń informatycznych często można spotkać się z błędnym przekonaniem, że klient ma pełną swobodę w decydowaniu o tym, czy podpisze protokół odbioru. Tymczasem zgodnie z art. 643 Kodeksu cywilnego zamawiający jest obowiązany odebrać dzieło, które zostało wykonane zgodnie z umową.
Na tę zasadę zwrócił uwagę Sąd Okręgowy w Warszawie w wyroku z 25 sierpnia 2021 r. (sygn. akt XXII GW 42/20). Sprawa dotyczyła wykonania aplikacji mobilnej, której odbioru zamawiający odmówił pomimo zakończenia prac programistycznych. Klient próbował uzależnić podpisanie protokołu odbioru od przekazania kodu źródłowego, choć taki obowiązek nie wynikał ani z umowy, ani z przepisów prawa. Zamawiający chciał zatem wprowadzić dodatkowe warunki odbioru dzieła, które nie wynikały z zawartej umowy. Sąd jednoznacznie przypomniał, że „zgodnie z treścią art. 643 k.c. zamawiający obowiązany jest odebrać dzieło, które przyjmujący zamówienie wydaje mu zgodnie ze swym zobowiązaniem”.
W uzasadnieniu podkreślono, że wykonawcy zakończyli prace, aplikacja została przetestowana i była gotowa do użytkowania, a zamawiający nie zgłaszał zastrzeżeń dotyczących jej funkcjonalności. Dopiero później próbował uzależnić odbiór od spełnienia dodatkowych warunków, których strony wcześniej nie przewidziały. Zamawiający twierdził przy tym, że w przypadku oprogramowania komputerowego prawa autorskie przechodzą automatycznie z wykonawcy na zamawiającego. Sąd nie podzielił tego stanowiska, uznał takie działanie za bezpodstawne i zasądził wynagrodzenie na rzecz wykonawców pomimo braku podpisanego protokołu odbioru.
Orzeczenie to przypomina, że protokół odbioru nie może być wykorzystywany jako narzędzie wymuszania na wykonawcy dodatkowych świadczeń niewynikających z umowy, o ile dzieło zostało prawidłowo wykonane.
Brak reakcji klienta po dostarczeniu systemu – czy możliwy jest „milczący odbiór”?
Jednym z najczęstszych problemów praktycznych jest sytuacja, w której klient nie podpisuje protokołu odbioru, ale jednocześnie nie przedstawia konkretnych zastrzeżeń do wykonanego systemu. Pojawia się wtedy pytanie, czy milczenie zamawiającego można potraktować jako dorozumianą akceptację rezultatu prac.
Polskie przepisy nie regulują wprost instytucji „milczącego odbioru”, jednak analiza orzecznictwa prowadzi do wniosku, że zachowanie stron może prowadzić do przyjęcia, iż odbiór nastąpił w sposób dorozumiany. Każde zachowanie drugiej strony może bowiem służyć odczytaniu i wykładni jej rzeczywistej woli.
Dobrym przykładem jest wyrok Sądu Rejonowego w Kłodzku z 12 lipca 2013 r. (sygn. akt I C 137/12), dotyczący wykonania strony internetowej. Zamawiająca nie podpisała „papierowego” protokołu odbioru, jednak równocześnie poinformowała wykonawcę drogą mailową, że akceptuje uruchomienie serwisu. Sąd ustalił, że „pozwana jedynie z uwagi na uszkodzoną drukarkę nie podpisała protokołu odbioru w formie papierowej, zaś mailem zaakceptowała odbiór umowy i poprosiła o uruchomienie strony”. Mimo że pozwana później twierdziła, iż do odbioru nie doszło, sąd uznał, że umowa została wykonana, a wykonawcy przysługuje wynagrodzenie.
Podobne stanowisko zajął Sąd Rejonowy w Lubinie w wyroku z 3 lutego 2014 r. (sygn. akt I C 2053/13). Zamawiający próbował twierdzić, że odbiór prac nie nastąpił, jednak jego wcześniejsze zachowanie wskazywało na coś przeciwnego: dokonał rozliczenia wykonanych prac, naliczył karę umowną za opóźnienie i podejmował działania charakterystyczne dla sytuacji, w której dzieło zostało już odebrane. Sąd uznał więc, że późniejsze podważanie odbioru nie mogło odnieść skutku.
Dla software house’ów płynie z tych orzeczeń bardzo ważny wniosek: nawet jeżeli klient nie podpisuje formalnego protokołu, jego zachowanie może świadczyć o faktycznym przyjęciu oprogramowania. Za uznaniem, że odbiór w rzeczywistości nastąpił, często przemawia:
- korzystanie z systemu i uruchomienie go w środowisku produkcyjnym,
- przekazanie systemu własnym klientom lub użytkownikom końcowym,
- zgłaszanie wyłącznie drobnych poprawek zamiast wad istotnych,
- rozliczenie prac, np. zapłata części wynagrodzenia lub naliczenie kary umownej.
Z perspektywy kontraktowej kluczowe jest jednak odpowiednie uregulowanie procedury odbiorowej. Najlepszym rozwiązaniem okazuje się wprowadzenie mechanizmu milczącego odbioru: wykonawca zgłasza gotowość do odbioru, klient otrzymuje określony czas na przeprowadzenie testów akceptacyjnych, a brak zgłoszenia wad w wyznaczonym terminie oznacza automatyczne przyjęcie systemu. Warto rozważyć również sukcesywny odbiór prac w miarę ich postępów, o ile pozwala na to przedmiot umowy.
Klient nie może blokować odbioru w nieskończoność
Wiele sporów nie wynika z rzeczywistych wad oprogramowania, lecz z braku odpowiednio skonstruowanej procedury odbiorowej. Jeżeli umowa nie określa terminów przeprowadzenia testów, sposobu zgłaszania błędów oraz konsekwencji braku reakcji klienta, wykonawca może znaleźć się w sytuacji wielomiesięcznej niepewności co do statusu projektu.
Orzecznictwo wskazuje, że software house powinien być w stanie wykazać nie tylko fakt wykonania prac, ale również moment ich zakończenia i zgłoszenia do odbioru. Dobrze ilustruje to wyrok Sądu Apelacyjnego we Wrocławiu z 28 sierpnia 2013 r. (sygn. akt I ACa 796/13). Wykonawca twierdził, że system został ukończony, a późniejsze działania miały charakter wyłącznie serwisowy. Sąd nie podzielił tej argumentacji, wskazując, że materiał dowodowy nie pozwalał ustalić momentu zakończenia projektu. Jak podkreślono w uzasadnieniu: „nie ma wskazanej daty (ani jednej), że wszystkie trzy moduły współpracowały, że oprogramowanie działało, funkcjonowało zgodnie z jego przeznaczeniem i celem, dla którego miało być wykonane”.
Orzeczenie to pokazuje, jak istotne znaczenie ma dokumentowanie procesu wdrożeniowego. Jeżeli wykonawca nie potrafi wykazać, kiedy dokładnie zakończył prace i kiedy zgłosił system do odbioru, może mieć poważne trudności z dochodzeniem wynagrodzenia. Dlatego dobrze skonstruowana umowa powinna szczegółowo regulować przebieg testów akceptacyjnych: termin na zgłoszenie uwag, ich wymaganą formę oraz konsekwencje braku reakcji klienta.
Zasada „No Critical Bugs” – nie każda wada uzasadnia odmowę odbioru
Kluczowe znaczenie w sporach o odbiór oprogramowania ma rozróżnienie pomiędzy wadami istotnymi i nieistotnymi. To właśnie od tej kwalifikacji zależy odpowiedź na pytanie, czy klient może skutecznie odmówić odbioru systemu.
W wyroku Sądu Apelacyjnego w Katowicach z 5 lipca 2017 r. (sygn. akt V ACa 924/16) wskazano, że „jeśli dzieło ma wady istotne, to zlecający ma prawo odmówić jego odbioru. Jeżeli go jednak odbiera, a tym bardziej przekazuje osobie trzeciej w wykonaniu swojego zobowiązania, należy przyjąć, że przyjął świadczenie dłużnika w takiej formie, w jakiej wykonawca je wydał (…). W takiej sytuacji można bowiem jedynie mówić o niewłaściwym wykonaniu umowy, a nie o jej niewykonaniu”.
Rozstrzygnięcie to oddaje dominujące stanowisko sądów. Jeżeli system realizuje swoje podstawowe funkcje biznesowe, drobne niedoskonałości nie powinny prowadzić do blokowania odbioru. Mogą natomiast stanowić podstawę roszczeń z tytułu rękojmi, gwarancji lub umownego obowiązku usunięcia usterek.
Na definicję wady istotnej zwrócił uwagę również Sąd Okręgowy w Warszawie w wyroku z 3 października 2024 r. (sygn. akt XXII GW 183/24), wskazując – za utrwaloną linią Sądu Najwyższego (por. wyrok SN z 6 października 2006 r., V CSK 198/06) – że „wada istotna to taka, która uniemożliwia normalne korzystanie z rzeczy w zakresie jej podstawowych właściwości funkcjonalnych”.
W analizowanej sprawie przedmiotem umowy był sklep internetowy. Sąd ustalił, że system nie realizował swojej podstawowej funkcji sprzedażowej: występowały poważne błędy integracji z hurtownią, nieprawidłowo działał import produktów, a liczba produktów prezentowanych w sklepie nie odpowiadała rzeczywistej ofercie. W takiej sytuacji odmowa odbioru została uznana za w pełni uzasadnioną.
Orzeczenie to wyznacza jednocześnie granicę między wadą istotną a nieistotną. Trudno uznać za wadę istotną błędny kolor przycisku, niewielkie przesunięcie elementów interfejsu, literówkę czy inne niedoskonałości estetyczne. Tego rodzaju usterki nie uniemożliwiają korzystania z systemu zgodnie z jego przeznaczeniem, a zatem co do zasady nie powinny blokować odbioru.
Kiedy odmowa odbioru jest rzeczywiście skuteczna?
Nie można tracić z pola widzenia sytuacji, w których oprogramowanie rzeczywiście nie odpowiada warunkom umowy. Wówczas klient ma prawo odmówić odbioru, a wykonawca nie może powoływać się na sam fakt dostarczenia kodu źródłowego czy przekazania kolejnej wersji systemu.
Już w wyroku Sądu Najwyższego z 31 stycznia 1983 r. (sygn. akt IV CR 380/82) wskazano, że „dzieło jest dostarczone w całości (…), gdy (…) odpowiada warunkom umowy i jest wykonane należycie”. Sąd podkreślił również, że jeżeli dzieło „w sposób istotny i oczywisty odbiega od treści umowy”, to nawet brak formalnej odmowy nie prowadzi do jego dorozumianego przyjęcia.
Podobny kierunek odnajdziemy w wyroku Sądu Okręgowego w Rzeszowie z 24 listopada 2015 r. (sygn. akt VI GC 102/14), gdzie sąd uznał, że zamawiający nie miał obowiązku odbioru dzieła, ponieważ jego wady uniemożliwiały korzystanie z niego zgodnie z przeznaczeniem. Istotność wad „dyskwalifikowała przydatność” przedmiotu umowy do umówionego użytku, co oznaczało, że dzieło nie zostało skutecznie oddane do odbioru.
Wszystkie te rozstrzygnięcia prowadzą do wspólnego wniosku: odmowa odbioru jest uzasadniona wyłącznie wtedy, gdy wada dotyczy podstawowych funkcjonalności systemu i uniemożliwia realizację celu gospodarczego, dla którego oprogramowanie zostało stworzone.
Wnioski dla software house’ów
Analiza orzecznictwa pokazuje, że spory o odbiór oprogramowania rzadko koncentrują się na samym podpisie pod protokołem. Kluczowe znaczenie ma ustalenie, czy system został wykonany zgodnie z umową oraz czy zgłaszane przez klienta nieprawidłowości rzeczywiście mają charakter istotny.
Sądy konsekwentnie przyjmują, że brak reakcji klienta nie zawsze chroni go przed obowiązkiem zapłaty. Korzystanie z systemu, jego uruchomienie w działalności przedsiębiorstwa czy akceptacja wyrażona w korespondencji mogą przemawiać za uznaniem, że odbiór nastąpił w sposób dorozumiany.
Najlepszą ochroną interesów software house’u pozostaje odpowiednio skonstruowana umowa wdrożeniowa. Powinna ona szczegółowo regulować zasady zgłaszania gotowości do odbioru, przebieg testów akceptacyjnych, klasyfikację błędów oraz skutki braku reakcji klienta.
Najczęściej zadawane pytania (FAQ)
Czy brak podpisu pod protokołem odbioru oznacza, że software house nie może żądać zapłaty?
Nie. Jeżeli oprogramowanie zostało wykonane zgodnie z umową i jest zdatne do użytku, brak podpisu nie przekreśla prawa do wynagrodzenia. Sądy badają rzeczywiste wykonanie dzieła, a nie samą formalność podpisu (art. 643 k.c.; wyrok SO w Warszawie XXII GW 42/20).
Czym jest milczący (dorozumiany) odbiór oprogramowania?
To sytuacja, w której – mimo braku formalnego protokołu – zachowanie klienta wskazuje na przyjęcie systemu: korzystanie z niego produkcyjnie, akceptacja mailowa, rozliczenie prac lub zgłaszanie wyłącznie drobnych poprawek. Instytucja ta nie jest uregulowana wprost, ale wynika z orzecznictwa (np. wyroki SR w Kłodzku I C 137/12 i SR w Lubinie I C 2053/13).
Czy klient może uzależnić odbiór od wydania kodu źródłowego?
Nie, jeżeli taki obowiązek nie wynika z umowy ani z przepisów. Sąd Okręgowy w Warszawie (XXII GW 42/20) uznał żądanie wydania kodu źródłowego jako warunku odbioru za bezpodstawne i zasądził wynagrodzenie mimo braku podpisu.
Jaka wada uzasadnia odmowę odbioru oprogramowania?
Wyłącznie wada istotna – taka, która uniemożliwia normalne korzystanie z systemu w zakresie jego podstawowych funkcji. Błędy kosmetyczne (kolor przycisku, literówka, drobne przesunięcia interfejsu) nie uprawniają do odmowy odbioru.
Jak zabezpieczyć się przed blokowaniem odbioru przez klienta?
Najskuteczniej poprzez umowę wdrożeniową z precyzyjną procedurą odbiorową: terminy testów akceptacyjnych, forma zgłaszania wad, klasyfikacja błędów oraz mechanizm milczącego odbioru, zgodnie z którym brak zgłoszenia wad w terminie oznacza przyjęcie systemu.
