„Współpraca z programistami” jako argument KAS: jak wykazać, że uzgodnienia techniczne nie są doradztwem ani wytwarzaniem oprogramowania

22.04.2026

„Współpraca z programistami” jako argument KAS: jak wykazać, że uzgodnienia techniczne nie są doradztwem ani wytwarzaniem oprogramowania

Definicja: na potrzeby praktyki kontroli należy przyjąć, że „uzgodnienia techniczne” to działania polegające na doprecyzowaniu sposobu integracji, parametrów, formatów danych, bezpieczeństwa, testów i utrzymania systemów IT, bez przejmowania odpowiedzialności za dobór rozwiązania biznesowego, bez tworzenia autorskiego kodu oraz bez przenoszenia praw do wytworzonego oprogramowania.

W realiach kontroli prowadzonych przez Krajową Administrację Skarbową spór często nie dotyczy tego, czy firma korzystała z usług programistów, lecz jak zakwalifikować taki model współpracy na gruncie prawa podatkowego i celno-skarbowego. KAS bywa skłonna traktować „współpracę z programistami” jako argument, że podatnik w istocie kupował doradztwo (np. w zakresie wyboru rozwiązań IT), licencje lub wręcz wytwarzanie oprogramowania, co może mieć wpływ m.in. na stawkę VAT, miejsce świadczenia, obowiązki dokumentacyjne, WHT (podatek u źródła) czy rozliczenie kosztów. Ryzyko rośnie, gdy dokumentacja jest skrótowa, a faktyczny zakres prac nie został precyzyjnie opisany.

Dlaczego KAS bada „uzgodnienia techniczne” w kontroli celno-skarbowej

Organ kontrolujący zwykle zestawia: (1) zapisy umów i zamówień, (2) korespondencję projektową, (3) faktyczny efekt prac oraz (4) sposób rozliczeń. Jeżeli z materiału wynika, że wykonawca „rekomendował” rozwiązanie, przygotowywał koncepcję architektury, prowadził warsztaty decyzyjne lub projektował „to-be”, KAS może próbować zakwalifikować część świadczeń jako doradztwo. Jeżeli natomiast pojawia się kod źródłowy, repozytoria, przeniesienie praw autorskich lub licencje, może paść teza o wytwarzaniu oprogramowania.

Z perspektywy biznesu oznacza to ryzyko korekt rozliczeń za lata wstecz, odsetek, sankcji administracyjnych, a w skrajnych przypadkach także ryzyk karnych skarbowych. W praktyce część spraw rozpoczyna się jako kontrola celno-skarbowa, a następnie może przenieść się na etap postępowania podatkowego lub czynności sprawdzających, w zależności od ustaleń.

Klucz: rozdzielenie „techniki” od „doradztwa” i „wytwarzania oprogramowania”

W sporach z KAS najczęściej wygrywa nie ogólna narracja, lecz spójny materiał dowodowy pokazujący, że prace miały charakter wykonawczy lub koordynacyjny (techniczny), a nie doradczy ani wytwórczy. Warto oprzeć podejście na trzech filarach:

1. Zakres – co dokładnie było przedmiotem świadczenia (deliverables, odpowiedzialności, kryteria odbioru).
2. Proces – jak przebiegała praca (kto decydował, kto zatwierdzał, jakie były role i uprawnienia).
3. Rezultat – jaki jest finalny efekt (dokumentacja techniczna, konfiguracje, testy) i czego brakuje (brak kodu, brak praw autorskich do programu, brak licencji jako głównego świadczenia).

Trzy wyjątki, które zwykle „przesuwają” kwalifikację na niekorzyść firmy

Poniższe sytuacje w praktyce kontrolnej bywają traktowane przez KAS jako sygnał, że nie chodziło wyłącznie o uzgodnienia techniczne. Dla celów tego materiału należy je traktować jako trzy wyjątki wymagające podwyższonej ostrożności dowodowej i kontraktowej:

• Wyjątek 1: rekomendacje i „warsztaty decyzyjne” – gdy wykonawca formalnie lub faktycznie wskazuje, jakie rozwiązanie wybrać (np. „najlepszy dostawca”, „optymalna architektura”), przygotowuje analizy porównawcze, uzasadnienia i bierze odpowiedzialność za wybór.
• Wyjątek 2: powstaje kod źródłowy lub modyfikacje oprogramowania – gdy w ramach współpracy tworzony jest kod, skrypty, wtyczki, mikroserwisy lub modyfikacje systemów, a nie tylko konfiguracja i parametryzacja. Samo użycie narzędzi low-code nie zawsze rozwiązuje problem, jeśli efekt ma cechy utworu i jest przenoszony.
• Wyjątek 3: rozliczenie i prawa typowe dla licencji lub przeniesienia praw – gdy umowa przewiduje przeniesienie autorskich praw majątkowych, licencję jako główny element świadczenia, wynagrodzenie „od użytkownika”, „od stanowiska” albo opłaty okresowe właściwe dla licencji.

Fakt wystąpienia wyjątku nie przesądza automatycznie o błędzie w rozliczeniach, ale zwykle oznacza konieczność rozdzielenia świadczeń (odrębne pozycje, opis, dowody) oraz urealnienia kwalifikacji podatkowej.

Jakie dowody realnie działają w kontroli

W praktyce KAS większą wagę przywiązuje do dokumentów operacyjnych niż do ogólnych oświadczeń w umowie. Skuteczna obrona polega na pokazaniu, że wykonawca nie pełnił roli doradcy biznesowego ani producenta oprogramowania, lecz realizował uzgodnienia techniczne. Pomocne są w szczególności:

• Opis przedmiotu zamówienia z listą konkretnych rezultatów (np. specyfikacja integracji API, mapa danych, plan testów, instrukcje wdrożeniowe) oraz wyłączeniami (brak prac programistycznych, brak rekomendacji wyboru dostawcy).
• Matryca ról (RACI) lub regulamin projektu, wskazujące kto decyduje o doborze rozwiązania, a kto wyłącznie je wdraża/konfiguruje.
• Protokoły odbioru powiązane z mierzalnymi kryteriami (np. testy przejścia, checklisty bezpieczeństwa).
• Ślad audytowy z narzędzi (Jira/Confluence) pokazujący typ zadań: konfiguracje, testy, parametry, a nie development.
• Korespondencja projektowa potwierdzająca, że decyzje były po stronie zamawiającego, a wykonawca przedstawiał warianty techniczne bez rekomendacji biznesowej.

Jak pisać umowy i zamówienia, żeby ograniczyć ryzyko kwalifikacji jako doradztwo lub wytwarzanie

W umowach B2B z programistami oraz firmami IT liczy się precyzja. Postanowienia powinny wzmacniać to, co wynika z praktyki projektu, a nie ją przykrywać. Warto rozważyć:

1. Język „techniczny” zamiast „strategicznego” – unikać sformułowań typu „doradztwo”, „konsulting”, „rekomendacje”, „optymalizacja biznesowa”, jeśli nie są rzeczywistym celem.
2. Wyłączenie przeniesienia praw tam, gdzie nie powstaje utwór lub kod, oraz wskazanie, że przedmiotem są dokumenty techniczne, konfiguracje lub wsparcie wdrożenia.
3. Rozdzielenie świadczeń – jeżeli w praktyce występuje komponent doradczy lub development, bezpieczniej ująć go jako osobny zakres z odrębną wyceną i fakturowaniem.
4. Odpowiedzialność i decyzyjność – jasno wskazać, że wybór rozwiązania i decyzje biznesowe należą do zamawiającego (zarządu, IT governance), a wykonawca realizuje uzgodnienia techniczne.

Konsekwencje błędnej kwalifikacji: podatki, sankcje, odpowiedzialność zarządu

Fakty: w razie zakwestionowania rozliczeń możliwe są zaległości podatkowe, odsetki, dodatkowe zobowiązania (sankcje VAT w przypadkach ustawowych) oraz ryzyko odpowiedzialności karnoskarbowej przy spełnieniu przesłanek z Kodeksu karnego skarbowego. W spółkach istotne jest także ryzyko odpowiedzialności osób zarządzających na gruncie Ordynacji podatkowej, jeżeli dojdzie do bezskuteczności egzekucji wobec spółki i spełnione zostaną ustawowe przesłanki odpowiedzialności.

Opinia (zależna od stanu faktycznego): najczęstsze problemy wynikają nie z samej współpracy z IT, lecz z braku rozdzielenia ról, zbyt ogólnych umów oraz dokumentacji projektowej, która „z automatu” używa języka konsultingowego. W wielu przypadkach korekta dokumentacji procesowej i kontraktowej zmniejsza ryzyko sporu jeszcze przed wejściem organu.

Checklist: przygotowanie firmy przed kontrolą

• Przegląd umów IT pod kątem słów kluczowych sugerujących doradztwo lub licencje.
• Weryfikacja, czy istnieją dowody braku kodu i braku przeniesienia praw (jeżeli to prawda).
• Spójność faktur i opisów pozycji z realnym zakresem prac.
• Centralizacja dokumentacji projektu (protokoły odbioru, RACI, decyzje komitetu sterującego).
• Procedura udostępniania dokumentów organom i komunikacji z pracownikami w toku kontroli.

Materiał ma charakter informacyjny i nie stanowi porady prawnej; w sprawach wymagających oceny konkretnych umów i dowodów w toku czynności KAS warto zlecić analizę, a w razie wszczęcia postępowania skorzystać ze wsparcia Kopeć & Zaborowski (KKZ), dlatego w celu omówienia ryzyk i przygotowania stanowiska najlepiej Skontaktuj się z nami.

FAQ: „Współpraca z programistami” jako argument KAS

1) Czy samo konsultowanie integracji systemów może zostać uznane za doradztwo?

Może, jeśli wykonawca faktycznie rekomenduje wybór rozwiązania lub przejmuje odpowiedzialność za decyzję. Jeżeli ogranicza się do doprecyzowania parametrów technicznych wdrożenia w ramach decyzji podjętych przez zamawiającego, argument za „uzgodnieniami technicznymi” jest zwykle silniejszy.

2) Czy dokumentacja w Jira/Confluence ma znaczenie dowodowe?

Tak. Z perspektywy kontroli pokazuje realny charakter prac. Zadania typu konfiguracja, testy, mapowanie danych wspierają tezę o uzgodnieniach technicznych; commity i zadania developerskie mogą wskazywać na wytwarzanie oprogramowania.

3) Czy przeniesienie praw autorskich zawsze oznacza „wytwarzanie oprogramowania”?

Nie zawsze, ale jest silnym wskaźnikiem, że powstaje utwór. Jeżeli przeniesienie praw jest „na wszelki wypadek”, a faktycznie nie powstaje kod ani utwór, warto rozważyć zmianę wzorca umownego, aby nie tworzyć sprzeczności dowodowej.

4) Jak rozdzielać świadczenia, gdy w projekcie są i uzgodnienia, i development?

Najbezpieczniej rozdzielić je kontraktowo i fakturowo: osobny zakres, osobne wynagrodzenie, odrębne kryteria odbioru. Ułatwia to obronę i ogranicza ryzyko, że KAS zakwestionuje całość jako jedno świadczenie o innym charakterze.

5) Czy w trakcie kontroli wolno „dopisywać” brakujące protokoły odbioru?

Uzupełnianie dokumentacji bywa oceniane krytycznie, zwłaszcza jeśli wygląda na tworzenie dowodów post factum. Dopuszczalne jest porządkowanie archiwum i zebranie istniejących materiałów, natomiast treści wytwarzane wyłącznie na potrzeby sporu mogą podważać wiarygodność.

6) Jakie akty prawne są najczęściej tłem takich sporów?

Zwykle są to przepisy o kontroli celno-skarbowej, zobowiązaniach podatkowych, VAT oraz ewentualnie KKS, w zależności od tego, jakie rozliczenia KAS bada w danej sprawie.

Bibliography

[1] Ustawa z dnia 16 listopada 2016 r. o Krajowej Administracji Skarbowej (t.j. Dz.U. z 2024 r. poz. 1373 ze zm.).

[2] Ustawa z dnia 29 sierpnia 1997 r. – Ordynacja podatkowa (t.j. Dz.U. z 2025 r. poz. 111 ze zm.).

[3] Ustawa z dnia 11 marca 2004 r. o podatku od towarów i usług (t.j. Dz.U. z 2024 r. poz. 361 ze zm.).

[4] Ustawa z dnia 10 września 1999 r. – Kodeks karny skarbowy (t.j. Dz.U. z 2024 r. poz. 628 ze zm.).

[5] Ustawa z dnia 4 lutego 1994 r. o prawie autorskim i prawach pokrewnych (t.j. Dz.U. z 2025 r. poz. 24 ze zm.).