Autor: Onur Arslan, adwokat w Arslan Advocaten. Aktualizacja: 28 września 2026 r. Informacje ogólne; ocena sprawy wymaga analizy dokumentów.
Nieudany projekt IT nie daje automatycznie prawa do zwrotu wszystkich faktur. Najpierw trzeba ustalić, co dostawca miał dostarczyć, które elementy są niezgodne oraz czy konieczna jest odpowiednia możliwość naprawy. Zabezpiecz techniczne dowody i zadbaj o ciągłość działania firmy, zanim rozwiążesz umowę lub pozwolisz nowemu dostawcy wszystko nadpisać.
W firmach z sektora MŚP problem z oprogramowaniem często uderza w codzienne funkcjonowanie. Zamówienia czekają, dane są wprowadzane podwójnie albo nowy system nie może zostać uruchomiony. Jednocześnie dostawca może twierdzić, że zmieniono specyfikacje, informacje dostarczono z opóźnieniem lub nie zapłacono za dodatkowe prace.
Przydatne podejście łączy więc analizę prawną i techniczną. Ten artykuł dotyczy biznesowego tworzenia oprogramowania, wdrożeń i usług IT. W przypadku standardowego oprogramowania, SaaS, sprzętu, hostingu lub danych osobowych mogą obowiązywać dodatkowe umowy i zasady.
W skrócie
- Nieudany projekt IT nie daje automatycznie prawa do zwrotu wszystkich faktur, bo najpierw trzeba ustalić uzgodnione świadczenie, niezgodne elementy i potrzebę umożliwienia naprawy.
- Opisz każdy problem technicznie, z oczekiwanym wynikiem, rzeczywistym działaniem i krokami odtworzenia, odróżniając błędy od funkcji, których nigdy nie uzgodniono.
- Zabezpiecz dokumentację, zgłoszenia, wyniki testów i konfigurację, zanim nowy dostawca nadpisze istniejące środowisko.
- Wstrzymanie płatności lub rozwiązanie umowy wymaga oceny wagi naruszenia i często wcześniejszego wezwania z rozsądnym terminem, a bezzasadne zakończenie może rodzić Twoją odpowiedzialność.
- Sama płatność nie oznacza automatycznie przeniesienia praw do kodu źródłowego, dlatego sprawdź licencję, ustalenia o przeniesieniu i ewentualny escrow.
Zacznij od uzgodnionego świadczenia
Zbierz ofertę, umowę, specyfikacje funkcjonalne, harmonogram projektu, ogólne warunki oraz późniejsze zmiany. Co system miał potrafić, kiedy miał zostać dostarczony i jakich działań po stronie Twojej organizacji wymagano?
Umowa może zawierać zarówno obowiązki starannego działania, jak i osiągnięcia rezultatu. Dostawca może na przykład mieć obowiązek dostarczenia konkretnej integracji, podczas gdy szersza poprawa biznesowa nie jest gwarantowanym wynikiem. Etykieta „obowiązek starannego działania” nie zwalnia dostawcy z powinności pracy z należytą starannością.
Sprawdź też postanowienia o hierarchii dokumentów. Broszura może budzić oczekiwania, ale ostateczna umowa może zawierać ograniczenia lub inne specyfikacje. I odwrotnie: standardowa klauzula nie zawsze w pełni odpowiada wyraźnie wynegocjowanym zapewnieniom.
Opisz dokładnie problem techniczny
Skarga, że „system nie działa”, jest zbyt ogólna dla skutecznego procesu naprawy. Dla każdego problemu zapisz, jaką czynność wykonujesz, jaki jest oczekiwany wynik, co dzieje się w rzeczywistości i jak problem można odtworzyć. Dodaj wersje, znaczniki czasu i istotne zrzuty ekranu.
Rozróżnij błędy, brakujące funkcje, wydajność, problemy bezpieczeństwa i nowe potrzeby. Funkcja, której nigdy nie uzgodniono, nie jest automatycznie wadą. Z kolei brak istotnej uzgodnionej funkcji nie może bez wyjaśnienia zostać przedstawiony jako płatna rozbudowa.
Określ wpływ problemu na działalność. Czy problem blokuje całe uruchomienie, istnieje tymczasowe obejście, czy dotyczy jedynie ograniczonej części? Taki podział pomaga przy terminach naprawy, priorytetach oraz ewentualnej ocenie wstrzymania płatności lub rozwiązania umowy.
Zabezpiecz dowody, zanim zlecisz zmiany
Zadbaj o zgodną z prawem kopię istotnej dokumentacji projektowej, zgłoszeń (ticketów), wyników testów, korespondencji i danych konfiguracyjnych. Zachowaj, gdzie to możliwe, wersje i pliki dzienników wraz z kontekstem. Pojedynczy zrzut ekranu bez daty lub wersji systemu ma mniejszą wartość.
Nie pozwalaj nowemu dostawcy bez przygotowania zastąpić istniejącego środowiska, jeśli przez to utracisz kluczowe dowody. Najpierw uzgodnij zasady utrwalenia, dostępu i badania. Przy rozległym sporze niezależny biegły może pomóc opisać stan.
Pamiętaj o danych osobowych, tajemnicach przedsiębiorstwa i dostępie osób trzecich. Nie przekazuj biegłemu więcej danych, niż to konieczne, i zadbaj o odpowiednie ustalenia. Zabezpieczenie dowodów nie oznacza, że możesz bez ograniczeń wchodzić na konta lub do systemów drugiej strony.
Akceptacja i uruchomienie
Wiele umów IT zawiera procedurę akceptacji z terminami testów, kategoriami błędów i skutkami uruchomienia. Sprawdź, czy ta procedura faktycznie została zastosowana. Formalne pismo akceptacyjne może być ważnym dowodem, ale jego zakres zależy od ustaleń i ewentualnych zastrzeżeń.
Uruchomienie nie oznacza automatycznie zaakceptowania każdej później wykrytej wady. Jednocześnie długotrwałe używanie bez wyraźnych skarg może wpłynąć na Twoją pozycję. Dlatego odnotuj, dlaczego tymczasowo używasz systemu i jakie braki pozostają otwarte.
Przy etapowym dostarczaniu akceptacja jednego elementu może mieć inne skutki niż akceptacja całego projektu. Przygotuj zestawienie dla każdego modułu lub etapu projektu. Nieudana końcowa integracja nie oznacza automatycznie, że wszystkie wcześniejsze świadczenia były bezwartościowe, ale może wpłynąć na użyteczność całości.
Agile i zmieniające się potrzeby
W projektach agile szczegóły są często doprecyzowywane podczas sprintów. Nie oznacza to braku ustaleń. Lista zadań i funkcji (product backlog), plany sprintów, prezentacje wykonanych prac, priorytety i ustalenia budżetowe łącznie mogą określać, czego strony mogły oczekiwać.
Ustal, kto mógł zatwierdzać zmiany oraz jak omawiano skutki kosztowe i harmonogramowe. Ustne żądanie pracownika nie jest automatycznie nieograniczonym zleceniem na prace dodatkowe. Z drugiej strony ciąg zatwierdzonych i wykazanych zmian może wpłynąć na pierwotny termin dostawy.
Przygotuj zestawienie różnic między zakresem początkowym a obecnym stanem. Zapisz dla każdej zmiany wniosek, akceptację, cenę i wpływ na plan. W przypadku odrębnego sporu cenowego zobacz też niezapłacone prace dodatkowe i dowody ich zlecenia.
Twoja własna współpraca może mieć znaczenie
Wdrożenie często wymaga danych, dostępu, decyzji i testów po stronie zamawiającego. Sprawdź, jakie obowiązki miała Twoja organizacja i czy wykonano je na czas. Dostawcy nie można pociągać do odpowiedzialności za każde opóźnienie spowodowane brakującymi danymi wejściowymi.
To nie zwalnia dostawcy ze wszystkich obowiązków. Profesjonalny usługodawca może na przykład mieć obowiązek ostrzec przed nieużytecznymi danymi, nierealistycznym planem lub niewystarczającą współpracą. Decydujący jest podział zadań w umowie i faktyczna komunikacja.
Przygotuj wspólną oś czasu z zależnościami. Dzięki temu będzie widać, które opóźnienie przypisać do której przyczyny. Akta zawierające wyłącznie błędy drugiej strony nie dadzą wiarygodnej podstawy do strategii procesowej.
Zgłaszaj wady na czas i daj szansę naprawy tam, gdzie to konieczne
Obowiązek reklamacyjny może mieć znaczenie przy wadliwych świadczeniach. Zgłaszaj konkretne problemy, gdy tylko je zauważysz lub powinieneś zauważyć, biorąc pod uwagę okoliczności. Zachowaj potwierdzenia otrzymania i dalsze działania po zgłoszeniach.
Dla odszkodowania lub rozwiązania umowy z powodu jeszcze możliwej do naprawienia nienależytej realizacji może być wymagany stan zwłoki. Wezwanie do usunięcia naruszeń musi wtedy dostatecznie jasno określać, jakiego świadczenia żądasz i w jakim rozsądnym terminie. Ogólny e‑mail z frustracją nie zawsze wystarczy.
Rozsądny termin naprawy zależy od problemu, wcześniejszych prób i potrzebnych prac. Dwa dni mogą być za krótkie dla złożonej integracji; miesiące czekania przy krytycznej awarii mogą być zbyt długie. Uzasadnij termin technicznie i prawnie.
Przykład ukierunkowanego pisma naprawczego
Temat: naprawa nieprawidłowości w projekcie [nazwa]
Zgodnie z naszą umową z dnia [data] i specyfikacją [wersja] system ma umożliwiać [konkretna funkcja]. Podczas testów w dniach [daty] stwierdzono, że [faktyczna niezgodność]. Kroki odtworzenia problemu, wyniki i istotne pliki są w załączeniu.
Wzywamy do usunięcia tej nieprawidłowości najpóźniej do [rozsądna data], tak aby spełnione było [mierzalne kryterium akceptacji]. Zapewniamy niezbędny dostęp i współpracę w [sposób i terminy]. Prosimy o przekazanie najpóźniej do [data] konkretnego planu naprawy.
Pozostałe otwarte punkty ujęto w załączniku [numer], z priorytetem i oczekiwanym rezultatem. Zastrzegamy sobie prawa do wykonania umowy oraz, jeśli spełnione są warunki, dalszych środków prawnych. To pismo nie stanowi zgody na dodatkowe płatne prace bez odrębnego uzgodnienia.
Sprawdź, czy Twoja umowa przewiduje konkretną procedurę eskalacji lub zawiadomień. Pismo musi pasować do tych ustaleń i do realnej możliwości naprawy. Ogólną strukturę znajdziesz w poradniku o wezwaniu do wykonania umowy.
Czy możesz tymczasowo nie płacić faktur
Wstrzymanie świadczenia może być możliwe pod pewnymi warunkami, ale jego zakres musi odpowiadać wadzie i umowie. Awaria w jednym module nie uzasadnia automatycznie wstrzymania wszystkich faktur za hosting i utrzymanie. Fundamentalnie nieużyteczna całość może być oceniona inaczej.
Sprawdź, czy uzgodniono zakaz potrącania lub wstrzymania i czy takie postanowienie utrzyma się w konkretnej relacji. Udokumentuj na piśmie kwestionowaną kwotę i podstawę. Bezzasadne wstrzymanie płatności może dać dostawcy własne roszczenie.
Rozważ także praktyczne ryzyko zablokowania dostępu przez dostawcę. Nie umniejsza to Twoich praw, ale wymaga przygotowania ciągłości działania i dostępności danych. Zobacz poradnik o wstrzymaniu prac lub płatności w zakresie odrębnych warunków.
Kiedy możesz rozwiązać umowę
Art. 6:265 BW co do zasady daje możliwość rozwiązania umowy w razie nienależytego wykonania, chyba że z uwagi na szczególny charakter lub niewielkie znaczenie naruszenia rozwiązanie z jego skutkami nie jest uzasadnione. Gdy świadczenie nie jest trwale lub czasowo niemożliwe, istotną rolę odgrywa stan zwłoki.
Oceń, czy właściwe jest rozwiązanie w całości czy w części. Użyteczny, samodzielny moduł można potraktować inaczej niż projekt, który jako całość nie realizuje celu. Należy też zbadać rozliczenie finansowe i wartość już wykonanych świadczeń.
Pismo o rozwiązaniu to nie zwykłe wypowiedzenie. Nieuzasadnione zakończenie może narazić Cię na roszczenia dostawcy, w tym o zapłatę lub odszkodowanie. Dlatego zanim ostatecznie oświadczysz, że umowa została rozwiązana, oceń podstawę, wcześniejsze próby naprawy i żądane skutki.
Czy odzyskasz wszystkie zapłacone kwoty
Po rozwiązaniu mogą powstać obowiązki zwrotne, ale w usługach i świadczeniach programistycznych zwrot nie zawsze jest dosłownie możliwy. Wtedy znaczenie może mieć wartość wykonanych świadczeń i właściwe przepisy. Odpowiedź nie brzmi automatycznie, że każda zapłacona kwota podlega pełnemu zwrotowi.
Rozróżnij licencje, rozwój, wdrożenie, utrzymanie i sprzęt. Część elementów może pozostać użyteczna lub mieć samodzielną wartość. Inne mogą być bezwartościowe, bo brakuje uzgodnionej spójności.
Uzasadnij, dlaczego żądasz określonego zwrotu lub odszkodowania. Kwota łączna bez podziału utrudnia dyskusję. Dopasuj korekty podatkowe i ewentualne faktury korygujące do wybranego modelu rozliczenia prawnego.
Szkoda i ograniczenia odpowiedzialności
Potencjalne pozycje szkody to rozsądne koszty naprawy, usługi zastępcze, dodatkowe koszty wewnętrzne lub utracony zysk. Nie każda pozycja jest automatycznie możliwa do dochodzenia. Należy ocenić nienależyte wykonanie, przypisanie, związek przyczynowy, przewidywalność i ograniczenie szkody.
Umowy IT często zawierają limity odpowiedzialności i wyłączenia określonych szkód. Zbadaj ich zastosowanie, znaczenie i skuteczność. Słowo „szkoda pośrednia” bez definicji umownej nie ma w każdej umowie tego samego znaczenia.
Gwarancja, zobowiązanie do ochrony przed określonymi roszczeniami osób trzecich (vrijwaring) lub kara umowna mogą dalej wpływać na podział ryzyka. Zobacz też ograniczenie odpowiedzialności w umowie biznesowej. Nie przedstawiaj limitu jako automatycznie nieważnego tylko dlatego, że szkoda jest wyższa.
Dane, kod źródłowy i zmiana dostawcy
Koniec współpracy nie daje automatycznie własności całego kodu źródłowego. Sprawdź licencje, prawa autorskie, ustalenia dotyczące prac dedykowanych oraz ewentualny escrow. Dostęp do danych i możliwość ich eksportu wymagają analizy umowy oraz obowiązujących przepisów. Przy usługach przetwarzania danych objętych unijnym Data Act, w tym określonych usługach chmurowych i SaaS, znaczenie mają przepisy o zmianie dostawcy stosowane od 12 września 2025 r. Nie oznacza to automatycznego prawa do kodu źródłowego ani identycznych obowiązków przy każdej indywidualnej usłudze programistycznej. Zobacz także zakończenie abonamentu firmowego i umowy SaaS.
Przygotuj listę przekazania obejmującą pliki danych, dokumentację, konfiguracje, konta, domeny i zależności. Określ, które dane Twoje przedsiębiorstwo może zgodnie z prawem zabrać oraz jakie istnieją prawa osób trzecich. Działający eksport często wymaga czegoś więcej niż archiwum zip z surowymi tabelami.
Ustal tymczasowe wsparcie, zabezpieczenia oraz zasady zwrotu lub usunięcia danych. Przy zakończeniu usług przetwarzania danych osobowych art. 28 ust. 3 lit. g RODO przewiduje, według wyboru administratora, usunięcie albo zwrot danych oraz usunięcie kopii, z zastrzeżeniem ustawowego obowiązku przechowywania. Przy danych osobowych obowiązki podmiotu przetwarzającego i ustawowe wymogi mogą trwać nadal. Spór o płatność nie jest powodem, by ignorować konieczne zabezpieczenia lub staranne zakończenie współpracy.
Przykład hipotetyczny: nieudane wdrożenie
Hurtownia wdraża system magazynowo‑zamówieniowy. Integracja stanu magazynu nie działa wiarygodnie, a dostawca twierdzi, że klient dostarczył niekompletne dane produktowe. Klient chce zwrotu wszystkich faktur i rozważa natychmiastowe rozpoczęcie prac przez innego dostawcę.
Najpierw zabezpiecza się specyfikacje, wyniki testów i dostarczone dane. Badanie techniczne rozróżnia błędy w integracji i problemy w danych źródłowych. Następnie powstaje plan naprawy z jasnymi odpowiedzialnościami i kryteriami akceptacji.
Jeśli naprawa nie nastąpi, można ocenić, które środki prawne pasują. Być może wystarczy wymiana jednego elementu; być może problem dotyka całego projektu. Przykład pokazuje, dlaczego roszczenie prawne jest silniejsze dzięki konkretnej diagnozie technicznej.
Ugoda czy postępowanie sądowe?
Ustalenia mogą obejmować naprawę pod nadzorem, korektę ceny, przekazanie do nowego dostawcy lub zakończenie ze stosownym rozliczeniem finansowym. Ustal mierzalne kryteria odbioru i skutki niepowodzenia. Nowa ogólna obietnica, że „wkrótce będzie dobrze”, to za mało.
W nagłych przypadkach może być potrzebne zabezpieczenie tymczasowe, np. dotyczące dostępu do danych lub ciągłości. Dla ostatecznej oceny szkody może być konieczna opinia biegłego. Sprawdź klauzulę rozstrzygania sporów: niektóre umowy IT odsyłają do arbitrażu lub konkretnej instytucji.
W ramach pomocy w sprawach gospodarczych możesz zlecić ocenę swojej pozycji prawnej. Zabierz dokumentację techniczną i wskaż, które systemy są krytyczne dla firmy. Dzięki temu najpierw można ustalić, co zabezpieczyć, a potem, jakie rozwiązanie jest realne.
Sprawdź kompletność przekazania technicznego
Ustal przed zmianą dostawcy, czego nowy wykonawca potrzebuje, by odpowiedzialnie zacząć. To zwykle więcej niż sam kod źródłowy: dokumentacja, zależności, konfiguracja, opisy baz danych, licencje i dostęp do środowisk budowy lub hostingu. Zapisz, których elementów brakuje i kto ma je dostarczyć.
W miarę możliwości wykonaj test na kopii w odseparowanym środowisku. Dzięki temu sprawdzisz, czy eksport jest kompletny i użyteczny, bez natychmiastowych zmian w środowisku produkcyjnym. Pamiętaj o bezpieczeństwie i danych osobowych; pełna kopia nie zawsze jest konieczna lub dozwolona.
Przygotuj protokół przekazania z datą, plikami, wersjami i wynikiem weryfikacji. Oświadczenie, że „wszystko przekazano”, może być zbyt szerokie, jeśli nowy dostawca nie mógł jeszcze przetestować dostępu. Użyj konkretnych kryteriów akceptacji i wskaż ewentualne punkty otwarte.
Sprawdź ubezpieczenie i ochronę danych osobowych
Przy incydencie znaczenie może mieć ubezpieczenie OC zawodowej, cyber lub ochrony prawnej. Zgłoś sprawę zgodnie z OWU i w razie potrzeby uzgadniaj uznania lub porozumienia. Zgłoszenie do ubezpieczyciela nie zastępuje reklamacji ani wezwania do usunięcia naruszeń skierowanego do dostawcy.
Jeśli naruszono dane osobowe, mogą dodatkowo istnieć odrębne obowiązki dotyczące zabezpieczeń, badań i ewentualnych zgłoszeń. To inna ocena niż pytanie, kto ma zapłacić za fakturę za wdrożenie. Nie odkładaj pilnego problemu z danymi do czasu rozstrzygnięcia sporu umownego.
Zachowaj oddzielne zestawienia działań technicznych naprawczych, korespondencji prawnej i ewentualnych działań związanych z obsługą incydentu. Dzięki temu będzie jasne, które koszty wynikają z którego problemu i jakie informacje udostępniono której stronie. Ta struktura pomaga zarówno przy rozliczeniu, jak i przy późniejszym wyliczeniu szkody.
Jak przygotować budżet i plan działania?
Oddziel koszty pilnego utrzymania działalności od kosztów sporu. W budżecie uwzględnij analizę umowy, zabezpieczenie dowodów, ekspertyzę, korespondencję, postępowanie oraz migrację. Nie każdy konieczny wydatek zostanie ostatecznie zwrócony przez dostawcę. Czas naprawy lub procesu zależy od skali wad, materiału dowodowego i współpracy stron; bez diagnozy nie da się go wiarygodnie obiecać.
| Etap | Co ustalić |
|---|---|
| Zabezpieczenie | Kopie dowodów, ciągłość działania, dostęp do danych. |
| Diagnoza | Uzgodniona funkcja, rzeczywisty błąd i jego przyczyna. |
| Wezwanie | Adresat, rozsądny termin, kryteria naprawy i dowód odbioru. |
| Decyzja | Naprawa, ugoda, wstrzymanie świadczenia lub rozwiązanie umowy. |
| Rozliczenie | Wartość wykonanych prac, możliwa szkoda i koszt dalszych działań. |
Najczęstsze pytania
Czy mogę od razu przerwać, jeśli oprogramowanie nie działa?
Nie bez oceny. Ważne są ustalenia, waga naruszenia oraz ewentualne wymogi naprawy i zwłoki. Bezzasadne zakończenie może samo prowadzić do odpowiedzialności. Najpierw zabezpiecz dowody i ciągłość działania.
Czy uruchomienie oznacza, że akceptuję wszystkie błędy?
Nie automatycznie. Znaczenie określają umowa, procedura akceptacji i ewentualne zastrzeżenia. Zgłaszaj jasno otwarte wady i odnotuj, dlaczego tymczasowo używasz systemu. Długotrwałe używanie bez skarg może wpłynąć na Twoją pozycję.
Czy dostawca zawsze musi dotrzymać stałej daty zakończenia?
To zależy od ustaleń i okoliczności. Twardy obowiązek dostawy to co innego niż plan orientacyjny. Znaczenie mogą mieć też uzgodnione zmiany i niezbędna współpraca zamawiającego.
Czy po rozwiązaniu umowy odzyskam wszystkie zapłacone kwoty?
To nie jest oczywiste. Należy ocenić obowiązki zwrotne, wartość wykonanych świadczeń i spójność elementów. Rozlicz oddzielnie prace programistyczne, licencje, utrzymanie i inne pozycje, aby można było sprawdzić żądane kwoty.
Czy jestem właścicielem kodu źródłowego, za który zapłaciłem?
Sama płatność nie oznacza automatycznie przeniesienia praw autorskich ani nieograniczonego prawa używania. Sprawdź licencję, ustalenia o przeniesieniu i ewentualny escrow. Znaczenie mogą mieć też prawa do użytego oprogramowania stron trzecich.
Czy mogę pozwolić nowemu dostawcy od razu wszystko poprawiać?
To może wpłynąć na dowody i możliwości naprawy. Najpierw dokładnie utrwal obecny stan i oceń prawa umowne oraz uprawnienia dostępu. Przy pilnych działaniach dla ciągłości trzeba udokumentować, dlaczego zwłoka była nieodpowiedzialna.
Źródła i podstawa prawna
- Burgerlijk Wetboek Boek 6: między innymi artykuły 74, 81–89, 98, 101, 248 i 265–272.
- Gerechtshof Amsterdam, 23 kwietnia 2024 r., ECLI:NL:GHAMS:2024:1070 — spór dotyczący tworzenia oprogramowania: przykład sporu o obowiązki dostawcy pracującego metodą agile i potrzebę oceny technicznej; orzeczenie nie przesądza wyniku innych spraw.
- Auteurswet: prawa do oprogramowania i wymogi przeniesienia.
- Komisja Europejska: wyjaśnienie Data Act.
- Autoriteit Persoonsgegevens: umowa powierzenia przetwarzania.
