Wadliwe oprogramowanie: kiedy możesz odmówić odbioru?

Spór o wadliwe oprogramowanie?

Kancelaria Sowa i Partnerzy pomaga zamawiającym z z całej Polski w sporach z dostawcami oprogramowania: od analizy wad i procedury odbiorowej, przez odpowiedź na jednostronny protokół i negocjacje, po zabezpieczenie dowodów i postępowanie sądowe. Współpracujemy z zespołami technicznymi i ekspertami IT, aby przełożyć problemy systemu na wymagania kontraktowe i materiał przydatny w procesie.

Skontaktuj się z naszym ekspertem.

W skrócie

Odmowa odbioru to nie decyzja techniczna, lecz prawna – trzeba wskazać, które wymaganie umowy nie zostało spełnione.
Odmowa jest skuteczna tylko przy wadach istotnych, które czynią system niezdatnym do umówionego użytku.
Klauzula jednostronnego protokołu nie działa automatycznie – nie stosuje się jej, gdy zamawiający uczestniczył i zgłosił merytoryczną odmowę (SN II CSK 476/12).
Bierność zamawiającego działa na jego niekorzyść: milczenie i produkcyjne korzystanie z systemu wspierają tezę o dorozumianym odbiorze.
O wyniku sporu przesądza dokumentacja – dowody trzeba budować jak zapis eksperymentu: wersja, środowisko, data, autor.

Wykonawca oprogramowania twierdzi, że „system działa”, wystawia fakturę i zapowiada jednostronny protokół odbioru w związku z ukończeniem tworzenia lub wdrożenia oprogramowania. Zamawiający widzi błędy, brak kluczowych funkcji i ryzyko dla biznesu. W takim konflikcie nie wystarczy napisać, że oprogramowanie jest wadliwe. Trzeba wykazać, które wymaganie umowy nie zostało spełnione, dlaczego wada jest istotna i jaki materiał techniczny potwierdza odmowę odbioru.

Odmowa odbioru oprogramowania to nie decyzja techniczna – to decyzja prawna

W sporach wdrożeniowych zespoły często mówią różnymi językami. Programiści wskazują, że aplikacja się uruchamia i wykonuje większość operacji. Użytkownicy biznesowi odpowiadają, że system nie realizuje procesu, dla którego został kupiony. Dział finansowy widzi końcową fakturę, a zarząd – ryzyko zatrzymania operacji. Warto jednak przyjąć perspektywę, z którą przy ewentualnym sporze zmierzy się sąd: będzie musiał przełożyć ten konflikt na treść zobowiązania – co dostawca miał wykonać, według jakich kryteriów i na jaki moment.

Pierwszym krokiem nie jest więc liczenie błędów, lecz zbudowanie „mapy kontraktu” – solidnej podstawy umownej pod odbiór końcowy: umowy głównej, specyfikacji, analizy przedwdrożeniowej, backlogu, kryteriów akceptacyjnych, change requestów, protokołów komitetu sterującego i korespondencji. Dopiero na tej podstawie można ustalić, czy problem jest wadą rezultatu, nieuzgodnionym oczekiwaniem zamawiającego, pracą dodatkową czy skutkiem niewykonania obowiązku współdziałania.

Sąd Apelacyjny w Gdańsku w wyroku z 13 maja 2015 r. (sygn. akt I ACa 1054/14), w sprawie dotyczącej wdrożenia istniejącego programu, zwrócił uwagę, że dostawca odpowiada za funkcjonalność objętą kontraktem, a nie za każde subiektywne oczekiwanie biznesowe użytkownika. Zamawiający musi wykazać niezgodność z wymaganiami umownymi. Podobnie SA w Łodzi w wyroku z 24 października 2012 r. (sygn. akt I ACa 745/12) podkreślał znaczenie sprawdzalnego rezultatu i obiektywnych kryteriów oceny jego wad.

W sporze pytanie nie brzmi „czy system jest dobry?”, lecz „czy oznaczona wersja systemu spełnia konkretne wymagania, które strony włączyły do zobowiązania?”. Im mniej mierzalne są kryteria akceptacyjne, tym większe znaczenie zyskują dokumenty przedwdrożeniowe, komunikacja projektowa i sposób korzystania z systemu.

Wada istotna a wada nieistotna – granica prawa do odmowy

Kodeks cywilny nie zawiera technicznej definicji „wady istotnej oprogramowania”. Pojęcie rozwinięto w orzecznictwie dotyczącym umowy o dzieło i robót budowlanych; rozważania te wykorzystuje się również w sprawach IT, bo wspólnym problemem jest oddanie złożonego rezultatu, jego odbiór oraz rozliczenie wad.

Sąd Najwyższy w wyroku z 29 stycznia 2021 r. (sygn. akt V CSKP 10/21) przyjął, że odmowa odbioru może być uzasadniona wadami istotnymi, które czynią rezultat niezdatnym do umówionego użytku albo wyraźnie sprzeciwiają się umowie. Wady nieistotne co do zasady nie pozwalają twierdzić, że świadczenie w ogóle nie zostało wykonane – zamawiający powinien odebrać rezultat i korzystać z roszczeń z tytułu nienależytego wykonania.

Podobne rozróżnienie zastosował SA w Szczecinie w wyroku z 29 czerwca 2017 r. (sygn. akt I ACa 174/17) oraz SA w Warszawie w wyroku z 12 września 2018 r. (sygn. akt VII AGa 947/18). Wynika z nich praktyczna zasada: nie każda wada daje prawo do zatrzymania całego wynagrodzenia i odmowy podpisania protokołu. Odpowiedź zależy od wpływu wady na funkcję rezultatu oraz od treści umowy.

Ocena powinna być zawsze obiektywna i odniesiona do umowy. Sąd nie musi podzielić stanowiska zamawiającego tylko dlatego, że użytkownicy są niezadowoleni. Z drugiej strony fakt, że dostawca pokazuje działający ekran logowania albo pojedynczą ścieżkę demonstracyjną, nie dowodzi realizacji całości zobowiązania. Liczy się zdolność systemu do wykonywania uzgodnionych procesów w określonej skali, konfiguracji i środowisku.

Czy zamawiający ma obowiązek odebrania systemu z wadami?

Jeżeli wady są nieistotne, odmowa całego odbioru jest ryzykowna. Wykonawca może twierdzić, że zamawiający narusza obowiązek współdziałania, sztucznie przedłuża procedurę i blokuje wymagalność faktury. Bezpieczniejszy bywa wtedy odbiór z zastrzeżeniami: system zostaje odebrany do używania, ale protokół zawiera listę wad, terminy napraw i pełne zastrzeżenie roszczeń.

Jeżeli wada jest istotna, odbioru nie należy podpisywać dla zachowania pozorów. Zamawiający powinien odmówić w sposób zgodny z umową i jednocześnie wykazać gotowość do kontynuowania testów po usunięciu konkretnych przeszkód. Odmowa ma dotyczyć oznaczonej wersji i oznaczonego etapu – nie powinna brzmieć jak wypowiedzenie całej współpracy, chyba że zamawiający rzeczywiście zamierza skorzystać z odrębnego uprawnienia do odstąpienia lub rozwiązania umowy.

Warto pamiętać: odmowa odbioru, żądanie usunięcia wad, odstąpienie od umowy, naliczenie kary i potrącenie wierzytelności to różne czynności prawne. Pismo zatytułowane „odmowa odbioru” nie powinno przypadkowo zawierać oświadczenia o rozwiązaniu kontraktu albo zrzeczeniu się dalszego wykonania.

Jednostronny protokół odbioru IT – kiedy klauzula może zadziałać?

W umowach dostawców często pojawia się mechanizm: jeżeli zamawiający nie przystąpi do testów, nie podpisze protokołu albo nie zgłosi wad w terminie, dostawca może sporządzić protokół jednostronny, a etap uznaje się za odebrany. Sama klauzula nie jest jeszcze dowodem, że wszystkie przesłanki rzeczywiście wystąpiły. Trzeba zbadać dokładne brzmienie, sposób wezwania do odbioru, gotowość systemu do testów, bieg terminów i treść odpowiedzi zamawiającego.

Szczególnie istotny jest wyrok Sądu Najwyższego z 7 marca 2013 r. (sygn. akt II CSK 476/12). Umowa przewidywała jednostronny odbiór na wypadek niestawiennictwa zamawiającego. Zamawiający uczestniczył jednak w czynnościach i odmówił odbioru, wskazując wady. Sąd Najwyższy uznał, że mechanizmu przewidzianego dla nieobecności nie można automatycznie zastosować do sytuacji, w której zamawiający stawił się i przedstawił merytoryczną odmowę. Jednocześnie podkreślił, że odmowa jest uzasadniona tylko przy wadach istotnych. Wyrok sądu apelacyjnego został uchylony, a sprawa wróciła do ponownego rozpoznania – nie był to więc definitywny wyrok co do całego sporu, lecz wiążąca wskazówka interpretacyjna.

Wniosek jest bardzo konkretny: zamawiający nie może pozostać bierny. Trzeba przystąpić do uzgodnionej procedury, wykonać możliwe testy, zgłosić konkretne wady w terminie i wyjaśnić, dlaczego uniemożliwiają odbiór. Wtedy dostawcy trudniej wykazać, że wystąpił przypadek „braku współdziałania” uruchamiający jednostronny protokół.

Jednostronny protokół pozostaje dokumentem sporządzonym przez jedną stronę – nie tworzy niepodważalnej prawdy o stanie systemu. Z drugiej strony, jeżeli zamawiający milczy, ignoruje wezwania, nie prowadzi testów albo korzysta produkcyjnie z systemu bez zastrzeżeń, dostawca może zbudować spójny materiał dowodowy faktycznego odbioru. Wyroki SN z 1 grudnia 2006 r. (I CSK 276/06), z 30 września 2009 r. (V CSK 89/09) oraz z 29 stycznia 2021 r. (V CSKP 10/21) tworzą ugruntowaną linię, że protokół i zachowanie stron ocenia się łącznie, a ich znaczenie można podważać dowodami przeciwnymi.

„Odbiór przedmiotu umowy pełni funkcję probacyjną – zamawiający, który odbiera dzieło, kwituje drugą stronę ze spełnienia niepieniężnego świadczenia wzajemnego. (…) W przypadku uzasadnionej odmowy przyjęcia dzieła mamy do czynienia ze stanem niewykonania zobowiązania, co wiąże się z brakiem wymagalności roszczenia o wynagrodzenie. W przypadku przyjęcia dzieła zamawiający dysponuje roszczeniami związanymi z nienależytym wykonaniem zobowiązania, nie może natomiast odmówić wypłaty wynagrodzenia, twierdząc, że dzieło nie zostało wykonane (…). Zamawiający może odmówić odbioru dzieła i zapłaty wynagrodzenia, gdy w chwili oddania ma ono wady istotne, które uniemożliwiają korzystanie z niego zgodnie z przeznaczeniem lub sprzeciwiają się wyraźnie umowie” (wyrok SN z 29 stycznia 2021 r., V CSKP 10/21).

Jak dokumentować błędy, aby nie przegrać sporu sądowego?

W sporze o oprogramowanie stan systemu zmienia się z każdym wdrożeniem. Zrzut ekranu bez numeru wersji, log bez informacji o środowisku albo nagranie bez daty mogą być prawdziwe, ale trudne do przypisania do etapu, którego dotyczy faktura. Materiał dowodowy trzeba więc budować jak zapis eksperymentu — tak, aby inna osoba mogła odtworzyć test i dojść do tego samego wyniku. Zabezpieczone dowody najprawdopodobniej posłużą później biegłemu do sporządzenia opinii.

Zanim jednak przejdziemy do tego, co utrwalić, trzeba odpowiedzieć na drugie pytanie: do czego zamawiający w ogóle ma dostęp. Znaczna część materiału w projekcie IT znajduje się bowiem pod kontrolą wykonawcy, a nie zamawiającego. To przesądza o kolejności działań.

Zacznij od tego, co masz u siebie i zrób to natychmiast. Zanim spór się zaostrzy, dostawca może odciąć dostęp, dlatego własne materiały należy zabezpieczyć od razu. Po swojej stronie zamawiający zwykle dysponuje zrzutami i nagraniami z własnych kont, eksportami z panelu administracyjnego (o ile ma takie uprawnienia), własną korespondencją i protokołami komitetu sterującego, raportami z przeprowadzonych testów oraz zgłoszeniami z systemu, do którego ma dostęp. Każdy taki dowód utrwalaj według stałych zasad:

Zrzuty ekranu: pełny ekran, adres lub nazwa modułu, użytkownik, data i godzina, numer wersji oraz widoczny komunikat. Zachowaj plik źródłowy, nie tylko obraz w prezentacji.
Nagrania wideo: ciągły zapis od logowania przez kroki testu do błędu; krótkie objaśnienie głosowe; zapis wersji i środowiska na początku.
Raporty testów: scenariusz, dane wejściowe, oczekiwany rezultat, wynik, osoba testująca, data oraz powiązanie z konkretnym kryterium akceptacyjnym.
Korespondencja i spotkania: e-maile, protokoły komitetu sterującego, notatki potwierdzone przez strony, wezwania do współdziałania, a także nagrania spotkań — za zgodą uczestników.

Pamiętaj o materiale, którego sam nie zabezpieczysz. Logi serwerowe, repozytorium kodu, historia CI/CD, system zgłoszeń hostowany przez wykonawcę, wnętrze środowiska produkcyjnego i backupy pozostają zwykle w rękach dostawcy. Tu pojawia się istotne ostrzeżenie: samodzielne „wykonanie kopii środowiska”, snapshotu czy eksportu repozytorium bywa nie tylko technicznie niewykonalne, ale i ryzykowne prawnie – może naruszać zakres licencji, granice autoryzowanego dostępu do systemu, przepisy o ochronie danych osobowych (logi i bazy zwykle zawierają dane osobowe) oraz tajemnicę przedsiębiorstwa i dane osób trzecich. Dowód pozyskany z przekroczeniem uprawnień przeciwnik może skutecznie podważyć.

Gdy dowód jest poza zasięgiem albo stan systemu może się zmienić sięgnij po narzędzia prawne:

Wezwanie dostawcy do zabezpieczenia i wydania materiału (odpowiednik „litigation hold”): żądanie zachowania logów, wersji i repozytorium oraz udostępnienia dowodów, doręczone za potwierdzeniem. Sama odmowa jest wartościowa – dokumentuje brak współdziałania po drugiej stronie i wzmacnia dalsze wnioski dowodowe.
Sądowe zabezpieczenie dowodu (art. 310 k.p.c.): przed wszczęciem lub w toku sprawy, gdy zachodzi obawa, że przeprowadzenie dowodu stanie się niewykonalne lub zbyt utrudnione, albo gdy zachodzi potrzeba stwierdzenia istniejącego stanu rzeczy. Może objąć oględziny systemu i dowód z opinii biegłego zanim kolejne wdrożenie zmieni stan faktyczny.
Instrumenty z postępowania w sprawach własności intelektualnej: ponieważ oprogramowanie jest utworem, w grę wchodzą zabezpieczenie środka dowodowego, wyjawienie lub wydanie środka dowodowego oraz wezwanie do udzielenia informacji. To realna droga dotarcia do kodu, repozytorium i logów pozostających u wykonawcy.
Wiarygodność i integralność utrwalenia: przy eksporcie logów i danych technicznych zachowaj format pierwotny, opis źródła, zakres czasu i osobę wykonującą eksport, a integralność potwierdź sumami kontrolnymi i kwalifikowanym znacznikiem czasu. Przy poważnym sporze rozważ notarialne poświadczenie otwarcia nośnika albo udział niezależnego rzeczoznawcy zamiast wyłącznie własnego działu IT — osoba niezależna jest wiarygodniejszym świadkiem. Pełną historię zgłoszeń zabezpiecz jako kompletny eksport ticketów z komentarzami, zmianami statusu i załącznikami, a nie jako aktualny widok ekranu.

Zabezpiecz też dwie rzeczy, które nie są „formą” dowodu, lecz jego istotą. Po pierwsze, dowód, którą wersję systemu i kiedy wydano, powiązany z konkretnym etapem i fakturą. Po drugie, dowód własnego współdziałania, czyli że zamawiający przystąpił do testów i zgłaszał wady w terminie. To bezpośrednia odpowiedź na najczęstsze argumenty wykonawcy: zarzut „braku współdziałania” oraz jednostronny protokół odbioru.

Krótko: część materiału zabezpieczasz sam i od zaraz, część musisz wymusić od dostawcy albo uzyskać przez sąd – a wszystko z dbałością o integralność i legalność pozyskania, bo dowód zebrany wadliwie potrafi stracić wartość dokładnie wtedy, gdy jest najbardziej potrzebny.

Co zrobić po otrzymaniu jednostronnego protokołu odbioru?

Nie pozostawiaj dokumentu bez odpowiedzi. Złóż formalny sprzeciw i wskaż, dlaczego przesłanki jednostronnego odbioru nie zostały spełnione.
Zabezpiecz aktualny stan systemu. Zanotuj wersję, zachowaj logi, raporty, nagrania, testy i korespondencję przed kolejnym wdrożeniem.
Sprawdź termin i sposób doręczenia. Ustal, kiedy rozpoczął się termin akceptacji i czy wezwanie dostawcy spełniało wymogi kontraktu.
Oddziel wady istotne od nieistotnych. Nie opieraj całej odmowy na błędach kosmetycznych – zbuduj argument wokół funkcji kluczowych.
Przeanalizuj fakturę i potrącenie. Nie pomniejszaj płatności automatycznie bez oceny wymagalności, kar, zasad potrącenia i ryzyka odsetek.
Ustal strategię dalszego wykonania. Wskaż, czy żądasz naprawy i retestu, czy rozważasz odstąpienie, wykonanie zastępcze, mediację albo proces.
Zaangażuj prawnika i eksperta technicznego wspólnie. Sama argumentacja prawna bez dowodów IT oraz sama diagnoza techniczna bez odniesienia do umowy są niewystarczające.

Najczęściej zadawane pytania (FAQ)

Kiedy mogę skutecznie odmówić odbioru oprogramowania?

Gdy system ma wady istotne – uniemożliwiające korzystanie z niego zgodnie z przeznaczeniem lub wyraźnie sprzeczne z umową (wyrok SN V CSKP 10/21). Wady nieistotne nie uprawniają do odmowy całego odbioru; wtedy właściwszy jest odbiór z zastrzeżeniami.

Czy jednostronny protokół odbioru jest wiążący?

Niekoniecznie. To dokument jednej strony; jego skuteczność zależy od spełnienia przesłanek z umowy. SN w wyroku II CSK 476/12 uznał, że mechanizmu dla „niestawiennictwa” nie stosuje się, gdy zamawiający uczestniczył w czynnościach i zgłosił merytoryczną, uzasadnioną odmowę.

Co zrobić od razu po otrzymaniu jednostronnego protokołu?

Złożyć formalny sprzeciw ze wskazaniem, dlaczego przesłanki jednostronnego odbioru nie wystąpiły, zabezpieczyć aktualny stan systemu i dowody, sprawdzić terminy i sposób doręczenia oraz oddzielić wady istotne od nieistotnych – najlepiej z udziałem prawnika i eksperta IT.

Jak dokumentować błędy oprogramowania na potrzeby sporu?

Jak zapis eksperymentu: każdy dowód (zrzut, nagranie, log, raport testu) powinien zawierać numer wersji, środowisko, datę, autora i powiązanie z kryterium akceptacyjnym. Należy zachować pliki źródłowe i pełne eksporty, nie zrzuty w prezentacji.