Protokół odbioru bez zastrzeżeń – tracisz kary umowne i rękojmię?

Masz problem z odbiorem systemu IT?

Kancelaria Sowa i Partnerzy wspiera zamawiających w analizie umów wdrożeniowych, procedur odbiorowych, kar umownych, rękojmi, gwarancji oraz odpowiedzialności odszkodowawczej. Prowadzimy także spory z software house’ami dotyczące systemów ERP, aplikacji dedykowanych i innych projektów technologicznych. Pomoc prawna jest dostępna dla podmiotów z całej Polski.

Skontaktuj się z naszym ekspertem.

W skrócie

Jedno zdanie w protokole odbioru może przenieść na zamawiającego ryzyko warte setki tysięcy złotych.
Podpis „bez zastrzeżeń” zwykle uruchamia fakturę końcową i bywa mocnym dowodem prawidłowego wykonania – ale nie jest niepodważalny.
Kara umowna to odrębne roszczenie; sam odbiór nie unicestwia jej automatycznie (art. 483–484 k.c.).
Rękojmia nie wygasa mechanicznie z podpisem – liczy się, które wady były znane przy odbiorze (art. 557, 563 k.c.).
Najbezpieczniejsze rozwiązanie to odbiór z wyraźnymi zastrzeżeniami, a nie fikcja „bezusterkowości”.

Jedno zdanie w protokole odbioru oprogramowania może przesunąć na zamawiającego ryzyko warte setki tysięcy, a nawet miliony złotych. Podpis „bez zastrzeżeń” często uruchamia fakturę końcową, zamyka okres naliczania kar za opóźnienie i tworzy silny dowód dla wykonawcy, że oprogramowanie wykonano zgodnie z umową. Nie oznacza to jednak, że każde roszczenie automatycznie wygasa. Kluczowe jest to, co dokładnie znalazło się w umowie i w protokole odbioru, jakie wady były znane w momencie odbioru, a nawet jak zachowywały się same strony.

Protokół odbioru oprogramowania: dokument techniczny czy prawna bramka?

W wielu projektach, również poza branżą IT, protokół odbioru traktowany jest jak formalność pozostawiona na koniec realizacji. Z perspektywy prawnej jest jednak odwrotnie: protokół bywa punktem, w którym umowa wiąże powstanie obowiązku zapłaty, rozpoczęcie gwarancji, przejście do utrzymania, zwrot zabezpieczenia albo zakończenie naliczania kar umownych za opóźnienie.

Dlatego analiza skutków podpisu nie może kończyć się na pytaniu, czy system „w zasadzie działa”. Trzeba zestawić co najmniej cztery warstwy: treść umowy wraz z założeniami projektu, kryteria akceptacyjne (które powinny zostać wcześniej zastrzeżone w umowie), rzeczywisty stan systemu oraz dokładne brzmienie protokołu. W ewentualnym sporze liczy się również to, czy zamawiający zaczął realnie korzystać z systemu, odebrał dokumentację, opłacił wynagrodzenie albo bez zastrzeżeń komunikował zakończenie projektu.

Warto pamiętać, że polskie prawo nie zawiera jednej regulacji dotyczącej stworzenia lub wdrożenia oprogramowania. Umowa wdrożeniowa może być kwalifikowana jako umowa o dzieło, umowa o świadczenie usług, umowa mieszana albo zespół kilku umów. Sąd Apelacyjny w Łodzi w wyroku z 24 października 2012 r. (sygn. akt I ACa 745/12), analizując kontrakt wdrożeniowy, akcentował znaczenie oznaczonego, sprawdzalnego rezultatu i możliwości oceny jego wad. Nie oznacza to jednak, że każde wdrożenie IT jest automatycznie dziełem – o kwalifikacji decyduje treść konkretnego zobowiązania.

Protokół najczęściej uruchamia fakturę końcową

Jeżeli kontrakt ma charakter umowy o dzieło, punktem wyjścia są art. 642 § 1 i art. 643 Kodeksu cywilnego. W braku odmiennego postanowienia wynagrodzenie staje się należne przy oddaniu dzieła, a zamawiający powinien odebrać dzieło wydane zgodnie z zobowiązaniem. W praktyce kontrakty IT zwykle modyfikują ten model i wiążą płatność nie z samym oddaniem oprogramowania, lecz z podpisaniem protokołu albo upływem procedury akceptacyjnej. Po podpisaniu dokumentu dostawca uzyskuje podstawę do wystawienia faktury, a zamawiający powinien zapłacić. Jeżeli nie zapłaci może bronić się zarzutami dotyczącymi wad, nienależytego wykonania albo potrąceniem własnych wierzytelności, ale pozycje procesowe stron się zmieniają: to już nie software house tłumaczy, dlaczego system należy uznać za wykonany – to zamawiający musi podważyć znaczenie własnego podpisu.

Sąd Najwyższy w wyroku z 29 stycznia 2021 r. (sygn. akt V CSKP 10/21) wskazał, że zamawiający może odmówić odbioru i zapłaty przede wszystkim wtedy, gdy rezultat ma wady istotne: uniemożliwia korzystanie zgodnie z przeznaczeniem albo w oczywisty sposób sprzeciwia się umowie. Wady nieistotne co do zasady nie pozwalają traktować świadczenia tak, jakby w ogóle nie zostało wykonane. Po odbiorze zamawiający może nadal korzystać z roszczeń związanych z nienależytym wykonaniem, ale nie zawsze może zatrzymać całe wynagrodzenie.

Polecane: Wadliwe oprogramowanie: kiedy możesz odmówić odbioru i jak bronić się przed jednostronnym protokołem software house’u?

Co to oznacza dla projektów IT? System może zawierać błędy, a mimo to nadawać się do odbioru. Jeżeli błędy nie blokują podstawowych procesów i nie naruszają twardych kryteriów akceptacyjnych, sąd może uznać, że zamawiający powinien odebrać rezultat, zapłacić, a następnie dochodzić usunięcia wad lub innych roszczeń. Właśnie dlatego protokół powinien precyzyjnie opisywać wszystkie stwierdzone niezgodności.

Siła dowodowa protokołu

Protokół nie jest niepodważalnym orzeczeniem o jakości systemu. Sąd Najwyższy w wyroku z 1 grudnia 2006 r. (sygn. akt I CSK 276/06), który odnosi się do robót budowlanych, określił podpisany protokół odbioru jako rodzaj pokwitowania, które stwarza domniemanie faktyczne prawidłowego wykonania umowy (chyba, że w protokole zastrzeżono wady). Możemy przenieść to rozumowanie Sądu Najwyższego na sprawy dotyczące oprogramowania i powiedzieć, że podpisanie przez zamawiającego protokołu odbioru stanowi swego rodzaju pokwitowanie spełnienia świadczenia ze strony wykonawcy, co uzasadnia domniemanie faktyczne, że oddane oprogramowanie wykonano zgodnie z umową, ale jest to domniemanie, które można obalić przez wykazanie, że umowa nie została wykonana lub wykonana nienależycie. W tej sprawie Sąd Najwyższy uchylił wyrok sądu apelacyjnego, który nadał protokołowi zbyt daleko idące znaczenie i potraktował go niemal jako automatyczne potwierdzenie pełnego, niewadliwego wykonania (tę samą linię SN podtrzymał w wyroku z 30 września 2009 r., sygn. akt V CSK 89/09).

Protokół stanowi zatem istotny dowód, ale zamawiający może wykazywać, że rzeczywisty zakres lub jakość prac odbiegały od umowy. W praktyce wymaga to jednak mocnego materiału technicznego: historii testów, logów, korespondencji, dokumentacji zmian, nagrań i – w sporze wymagającym wiadomości specjalnych – opinii biegłego sądowego.

Czy odbiór bez zastrzeżeń zamyka drogę do kar umownych za opóźnienie?

Nigdy automatycznie. Kara umowna jest odrębnym roszczeniem wynikającym z kontraktu. Zgodnie z art. 483 i 484 Kodeksu cywilnego może zabezpieczać niewykonanie albo nienależyte wykonanie zobowiązania niepieniężnego, a wierzyciel może jej żądać w zastrzeżonej wysokości niezależnie od wykazania szkody. Dłużnik może jednak domagać się miarkowania kary – m.in. gdy zobowiązanie zostało w znacznej części wykonane albo kara jest rażąco wygórowana.

Dobrym ostrzeżeniem przed zbyt kategoryczną tezą jest wyrok SN z 26 września 2012 r. (sygn. akt II CSK 84/12). W sprawie podpisano końcowy protokół odbioru, a mimo to zamawiający potrącił karę umowną naliczoną za wcześniejsze opóźnienie. Sąd Najwyższy oddalił skargę kasacyjną wykonawcy – sam odbiór nie unicestwił naliczonej wierzytelności. O wyniku przesądziły postanowienia kontraktu, przebieg opóźnienia i sposób rozliczenia.

Podpis bez zastrzeżeń może jednak poważnie osłabić albo faktycznie zamknąć roszczenie o karę w kilku typowych sytuacjach:

protokół potwierdza terminowość wykonania,
umowa wprost uzależnia zachowanie kary od zastrzeżenia jej w protokole,
protokół zawiera klauzulę pełnego rozliczenia lub braku wzajemnych roszczeń,
data odbioru kończy okres naliczania kary,
zamawiający nie składa wymaganego oświadczenia o naliczeniu lub potrąceniu kary.

Odbiór bez zastrzeżeń a rękojmia w projektach IT

W umowach o dzieło art. 638 § 1 Kodeksu cywilnego odsyła odpowiednio do przepisów o rękojmi przy sprzedaży. Zastosowanie tej konstrukcji do projektu IT wymaga jednak wcześniejszego ustalenia, czy przedmiot umowy jest dziełem i w jakim zakresie przepisy o rzeczach można odpowiednio przenieść na oprogramowanie. W umowach usługowych, SaaS albo silnie mieszanych reżim może wyglądać inaczej, a sama umowa często ogranicza, rozszerza lub wyłącza rękojmię na podstawie art. 558 Kodeksu cywilnego.

Zgodnie z art. 557 § 1 k.c. sprzedawca jest zwolniony z odpowiedzialności z tytułu rękojmi, jeżeli kupujący wiedział o wadzie w chwili zawarcia umowy. Reguła ta zakłada jednak, że rzecz istnieje już w momencie kontraktowania. Przy rzeczach oznaczonych tylko co do gatunku oraz rzeczach mających powstać w przyszłości art. 557 § 2 k.c. przesuwa moment miarodajny dla oceny tej wiedzy – z chwili zawarcia umowy na chwilę wydania rzeczy. Oprogramowanie tworzone na zamówienie bywa do tej drugiej kategorii zaliczane, choć nie jest to oczywiste: do wad dzieła przepisy o rękojmi przy sprzedaży stosuje się jedynie „odpowiednio” (art. 638 § 1 k.c.), a oprogramowanie nie jest klasyczną „rzeczą”, więc przenoszenie tej konstrukcji wymaga ostrożności. Dlaczego ma to znaczenie przy odbiorze? Ponieważ momentem wydania jest tu zwykle właśnie odbiór systemu. Podpisanie protokołu „bez zastrzeżeń” bywa więc odczytywane jako potwierdzenie, że w chwili wydania zamawiający znał wady jawne rezultatu – a co do takich wad jego uprawnienia z rękojmi mogą zostać osłabione lub wyłączone. Mechanizm ten nie obejmuje jednak wad ukrytych, których w chwili odbioru nie można było stwierdzić.

Odrębną – i często myloną – podstawą utraty rękojmi jest art. 563 k.c. Nie chodzi w nim o wiedzę o wadzie, lecz o akty staranności kupującego-przedsiębiorcy. W relacjach B2B zamawiający może utracić uprawnienia z rękojmi, jeżeli nie zbada rezultatu w czasie i w sposób przyjęty przy rzeczach danego rodzaju oraz nie zawiadomi sprzedawcy niezwłocznie o wadzie (a w przypadku wady ujawnionej później – niezwłocznie po jej stwierdzeniu). Oba przepisy działają więc niezależnie: art. 557 § 2 k.c. odpowiada na pytanie, co zamawiający wiedział przy odbiorze, a art. 563 k.c. – czy dochował staranności w zbadaniu systemu i zgłoszeniu wad. Prowadzą jednak do tego samego praktycznego wniosku: protokół odbioru warto sporządzać z wyraźnymi zastrzeżeniami, a wykryte wady zgłaszać niezwłocznie i na piśmie.

Cytowany już wyrok Sądu Najwyższego z 1 grudnia 2006 r. (sygn. akt I CSK 276/06) pokazuje, dlaczego nie wolno przyjmować uproszczonego automatu „podpisano protokół, więc rękojmia wygasła”. Sąd Najwyższy zakwestionował takie podejście, ponieważ sąd niższej instancji nie ustalił dostatecznie, które wady były widoczne i znane przy odbiorze. Co więcej, wskazał, że nawet utrata uprawnień z rękojmi nie musi wyłączać odpowiedzialności odszkodowawczej z art. 471 Kodeksu cywilnego za nienależyte wykonanie zobowiązania.

Najbezpieczniejsze wyjście: odbiór z zastrzeżeniami, a nie fikcja „bezusterkowości”

W praktyce określenie „odbiór warunkowy” bywa używane w dwóch znaczeniach. Czasem oznacza pełny odbiór, który uruchamia płatność, ale zawiera listę wad do usunięcia. Innym razem oznacza etap przejściowy, po którym dopiero ponowne testy prowadzą do odbioru końcowego. Nie jest to pojęcie ustawowe – jego skutki muszą wynikać z umowy albo z jednoznacznego, podpisanego przez obie strony porozumienia.

Jeżeli wady są nieistotne, najbezpieczniejszy bywa odbiór z wyraźnymi zastrzeżeniami. Protokół powinien identyfikować wersję systemu, środowisko, wykonane testy, pełną listę wad, terminy napraw, zasady retestu oraz konsekwencje niedotrzymania terminów. Powinien również oddzielać potwierdzenie możliwości używania systemu od potwierdzenia terminowości i bezusterkowości.

Uwaga: jeżeli umowa stanowi, że każdy podpisany protokół uruchamia całą płatność albo uznaje etap za zakończony, jednostronne dopisanie słowa „warunkowy” może nie wystarczyć. Zastrzeżenia powinny zostać zaakceptowane przez osoby umocowane po obu stronach. Gdy dostawca odmawia podpisu, zamawiający powinien niezwłocznie doręczyć odrębne, szczegółowe oświadczenie i zachować dowód doręczenia.

Przykład: wartość wdrożenia wynosi 5 000 000 zł, a umowa przewiduje karę 0,2% wynagrodzenia za każdy dzień opóźnienia. Za 30 dni potencjalna kara to 300 000 zł. Jeżeli protokół zawiera jedynie datę odbioru i listę drobnych wad, roszczenie za wcześniejsze opóźnienie może nadal istnieć. Jeżeli jednak zamawiający podpisze, że system „został wykonany prawidłowo i terminowo, a strony nie mają wzajemnych roszczeń”, dostawca zyskuje argument znacznie silniejszy niż samo techniczne potwierdzenie uruchomienia. W ewentualnym sporze sądowym sąd zbada cały kontrakt, kompetencje podpisujących, korespondencję, rzeczywistą datę gotowości systemu, przyczyny opóźnień oraz to, czy strony zamierzały definitywnie zamknąć rozliczenia. Nie warto budować strategii na nadziei, że później uda się wyjaśnić niefortunny podpis – bezpieczniej wpisać zastrzeżenia przed podpisaniem dokumentu.

Najczęściej zadawane pytania (FAQ)

Czy podpisanie protokołu odbioru „bez zastrzeżeń” pozbawia mnie kar umownych?

Nie koniecznie. Kara umowna to odrębne roszczenie (art. 483–484 k.c.). Sam odbiór jej nie unicestwia – SN w wyroku II CSK 84/12 dopuścił potrącenie kary mimo podpisanego protokołu. Ryzyko rośnie jednak, gdy protokół potwierdza terminowość lub zawiera klauzulę braku wzajemnych roszczeń.

Czy odbiór bez zastrzeżeń oznacza utratę rękojmi?

Nie koniecznie. Zgodnie z wyrokiem SN I CSK 276/06 nie można przyjmować, że sam podpis wygasza rękojmię. Znaczenie ma, które wady były znane przy odbiorze (art. 557 k.c.) oraz czy przedsiębiorca zbadał rezultat i zawiadomił o wadzie w terminie (art. 563 k.c.). Nawet utrata rękojmi nie wyłącza odszkodowania z art. 471 k.c.

Jaką moc dowodową ma protokół odbioru?

Tworzy domniemanie faktyczne prawidłowego wykonania (rodzaj pokwitowania), ale jest ono wzruszalne. Zamawiający może wykazać rozbieżność z umową za pomocą logów, historii testów, korespondencji i opinii biegłego.

Czym jest odbiór z zastrzeżeniami i dlaczego jest bezpieczniejszy?

To odbiór, który uruchamia płatność, ale zawiera listę wad, terminy napraw i pełne zastrzeżenie roszczeń. Chroni zamawiającego lepiej niż fikcja „bezusterkowości”, bo oddziela potwierdzenie używalności systemu od potwierdzenia terminowości i jakości.