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ć.
Napisane przez Onur Arslan, adwokat w Arslan & Arslan Advocaten. Wpisany do rejestru dziedzin prawa Niderlandzkiej Izby Adwokackiej w zakresie prawa pracy i szkody na osobie. Onur Arslan przez lata był adwokatem prawa spółek i kuratorem oraz ma wieloletnie doświadczenie w sporach finansowoprawnych. Ostatnia aktualizacja: 17 september 2026.
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.
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.
Uczyń problem technicznie konkretnym
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.
Sklasyfikuj wpływ. 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żdej modułowej części lub kamienia milowego. 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ń. Product backlog, planowanie sprintów, dema, priorytety i uzgodnienia 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ż meerwerk niet betaald.
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 i, o ile wymagane, wnosimy o usunięcie 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 zakelijke ingebrekestelling.
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 werkzaamheden of betaling opschorten 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. Błędne zakończenie może prowadzić do roszczenia zwrotnego. 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 euro wraca.
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, wykładnię i trwałość. Słowo „szkoda pośrednia” bez definicji umownej nie ma w każdej umowie tego samego znaczenia.
Gwarancja, zwolnienie z odpowiedzialności (vrijwaring) lub kara umowna mogą dalej wpływać na podział ryzyka. Zobacz też aansprakelijkheid beperken in een zakelijk contract. 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 również muszą być konkretnie uregulowane.
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 i usunięcie danych. 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.
Fikcyjny przykład nieudanego wdrożenia
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.
Wybrać ugodę czy postępowanie
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.
Przez bedrijfsrecht voor ondernemers możesz ocenić swoją pozycję prawną. 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.
Uczyń przekazanie techniczne weryfikowalnym
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.
Zwróć uwagę na zbieżność z ubezpieczeniem i prywatnością
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ń incydentowych. 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.
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 faktury?
To nie jest oczywiste. Należy ocenić obowiązki zwrotne, wartość wykonanych świadczeń i spójność elementów. Podziel rozwój, licencje, utrzymanie i inne pozycje dla weryfikowalnego rozliczenia.
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. Rolę 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 16 april 2024 over een softwaregeschil: przykład oceny umowy, akceptacji i wykonania; brak ogólnej gwarancji wyniku.
- Auteurswet: prawa do oprogramowania i wymogi przeniesienia.
