Kontrakt B2B w software house i gamedev: które zapisy umowy najczęściej „podbijają” stawkę ryczałtu w ocenie KAS (zakres, nadzór autorski, konsultacje)

09.02.2026

Współpraca w modelu B2B jest w branży IT standardem – zarówno w software house, jak i w gamedev. Jednocześnie jest to obszar, w którym organy podatkowe coraz częściej weryfikują, czy deklarowana stawka ryczałtu od przychodów ewidencjonowanych odpowiada faktycznie wykonywanym usługom. W praktyce „podbicie” stawki nie wynika z abstrakcyjnego sporu o nazewnictwo, lecz z tego, jak opisano zakres obowiązków w umowie i jak ten opis „czyta się” w świetle klasyfikacji PKWiU oraz art. 12 ustawy o ryczałcie.

W realiach kontroli najwięcej ryzyk generują trzy grupy zapisów: zbyt szeroko ujęty zakres usług, postanowienia o nadzorze autorskim (szczególnie w roli lead/architect) oraz nieprecyzyjne konsultacje i „doradztwo” dodane do developmentu. Poniżej omówiono, dlaczego te klauzule są tak istotne i jak je konstruować, aby ograniczać spory interpretacyjne – bez wchodzenia w rozwiązania pozorne.

1) Dlaczego KAS patrzy na umowę: stawka ryczałtu zależy od treści świadczenia, nie od nazwy stanowiska

Ustawa o zryczałtowanym podatku dochodowym wiąże stawki z rodzajem świadczonych usług – w praktyce z ich przyporządkowaniem do odpowiednich grupowań PKWiU oraz z oceną, czy usługa mieści się w katalogu czynności „uprzywilejowanych” niższą stawką, czy w katalogu usług, dla których ustawodawca przewidział stawki wyższe.

W branży IT kluczowe znaczenie ma to, że ustawodawca wprost wskazuje stawkę 12% m.in. dla usług związanych z oprogramowaniem (PKWiU ex 62.01.1) oraz dla usług związanych z doradztwem w zakresie oprogramowania (PKWiU ex 62.02) i innych usług powiązanych (m.in. instalowanie oprogramowania czy zarządzanie siecią i systemami informatycznymi). W gamedev dodatkowo pojawia się w art. 12 wątek usług związanych z wydawaniem m.in. pakietów gier komputerowych (określone grupowania PKWiU), co – zależnie od modelu biznesowego – potrafi komplikować kwalifikację przychodów.

Równolegle w art. 12 przewidziano stawkę 15% dla określonych usług, w tym m.in. usług doradztwa związanego z zarządzaniem (PKWiU ex dział 70) – co ma znaczenie wtedy, gdy kontrakt B2B opisuje obowiązki typowe dla „zarządzania projektem”, „koordynacji zespołów” czy „konsultingu strategicznego”.

Wniosek praktyczny jest prosty: im więcej w umowie sformułowań o doradztwie, zarządzaniu, „kierowaniu” lub „nadzorze” rozumianym jako podejmowanie decyzji i prowadzenie innych osób, tym częściej organ uzna, że świadczenie wykracza poza „czysty development” i należy je opodatkować stawką właściwą dla usług z katalogu 12% albo 15%.

2) „Zakres usług” – najczęstszy zapalnik sporu o stawkę

Najbardziej typowy błąd kontraktowy to opis zakresu jako „świadczenie usług programistycznych i okołoprojektowych”, a następnie dopisanie szeregu czynności, które w praktyce przypominają doradztwo IT albo zarządzanie. W sporach o stawkę ryczałtu organ zwykle analizuje nie tylko nagłówek („Developer”), ale konkretne obowiązki, np.:

Analiza wymagań i rekomendowanie rozwiązań (zwłaszcza sformułowane jako „dobór technologii”, „ocena ryzyk”, „przygotowanie koncepcji architektury”, „opracowanie rekomendacji dla klienta”);

Projektowanie architektury i standardów oraz „zatwierdzanie” decyzji technicznych innych osób;

Utrzymanie, „optymalizacja”, „zarządzanie środowiskami” i odpowiedzialność za ciągłość działania (gdy zakres zbliża się do usług zarządzania systemami/sieciami);

Koordynacja prac, prowadzenie backlogu, planowanie sprintów, raportowanie postępu, współpraca z interesariuszami po stronie klienta w formule konsultingowej.

W praktyce podatkowej widać, że organy kwalifikują szeroko rozumiane usługi doradcze w IT jako podlegające 12% – przykładowo w interpretacjach indywidualnych Dyrektor KIS konsekwentnie wskazuje, że usługi sklasyfikowane w PKWiU 62.02 (doradztwo w zakresie informatyki) są objęte stawką 12%, a nie 8,5%. Analogicznie, usługi uznane za „związane z oprogramowaniem” (PKWiU ex 62.01.1) również prowadzą do 12%.

Z perspektywy konstruowania umowy w software house i gamedev znaczenie ma więc to, czy zakres jest opisany jako wytwarzanie/rozwój oprogramowania (konkretne rezultaty, moduły, funkcjonalności), czy jako „kompleksowe wsparcie projektu” obejmujące elementy doradcze, organizacyjne i decyzyjne. To właśnie „kompleksowość” bywa w kontroli interpretowana jako mieszanka usług, a mieszanka usług oznacza konieczność porządkowania przychodów do stawek (i prowadzenia ewidencji w sposób pozwalający je rozdzielić).

3) „Nadzór autorski” – kiedy postanowienie o jakości przeradza się w usługę nadzorczą

W kontraktach B2B w IT często pojawia się klauzula o nadzorze autorskim – szczególnie, gdy wykonawca tworzy istotne elementy systemu lub odpowiada za spójność rozwiązań w projekcie. Sama obecność w umowie przeniesienia praw autorskich albo licencji nie jest automatycznie „podatkowym problemem” dla ryczałtu. Ryzyko zaczyna się wtedy, gdy „nadzór autorski” zostaje opisany w sposób typowy dla roli architekta/lead’a, tj. jako:

obowiązek stałego zatwierdzania prac innych osób, „przeglądu i akceptacji” rozwiązań, wprowadzania standardów i ich egzekwowania;

odpowiedzialność za decyzje techniczne całego zespołu, w tym wskazywanie kierunku rozwoju produktu;

stała dyspozycyjność w zakresie konsultowania zmian, priorytetów, ryzyk i „kierowania wdrożeniem”.

Taki opis świadczenia łatwo „oddala” umowę od modelu: „wykonawca tworzy określone elementy oprogramowania”, a przybliża ją do modelu: „wykonawca świadczy usługi doradcze i nadzorcze w projekcie”, co w ocenie organów częściej kończy się zastosowaniem stawki 12% (a w skrajnych konfiguracjach – gdy dochodzi wątek zarządzania – również 15%).

Rozwiązaniem nie jest rezygnacja z dbałości o jakość, lecz takie opisanie mechanizmów jakościowych, aby były one naturalnym elementem wytwarzania (np. kontrola zgodności własnych deliverables ze specyfikacją), a nie trwałą usługą „kierowania” pracą innych podmiotów. W praktyce istotne jest też, czy wynagrodzenie obejmuje „gotowość do nadzoru” oraz czy przewidziano rozliczanie dodatkowych aktywności (np. review innych osób) jako odrębnych usług.

4) „Konsultacje” i „doradztwo” – słowa, które najczęściej robią różnicę

Trzecia grupa zapisów, która najczęściej „podnosi” stawkę, to niedookreślone konsultacje. W umowach spotyka się postanowienia typu: „wykonawca świadczy konsultacje w zakresie rozwoju produktu”, „wykonawca zapewnia wsparcie doradcze”, „wykonawca bierze udział w spotkaniach z klientem i rekomenduje rozwiązania”. Z perspektywy dowodowej organ dostaje wtedy prosty argument: umowa nie dotyczy wyłącznie prac developerskich, lecz obejmuje doradztwo IT (a to – w interpretacjach – jest wiązane ze stawką 12%).

W software house i gamedev konsultacje bywają niezbędne (warsztaty, refinement, uzgodnienia techniczne, review koncepcji). Problem polega na tym, że bez rozdzielenia tych aktywności w umowie i w rozliczeniach, powstaje „świadczenie mieszane”, a organ może uznać, że dominującym elementem jest doradztwo albo usługa związana z oprogramowaniem kwalifikowana do 12%.

Jeżeli konsultacje mają charakter stricte organizacyjny lub zarządczy (np. „doradztwo strategiczne”, „zarządzanie projektem”, „prowadzenie zespołu”, „optymalizacja procesów”), ryzyko przesuwa się dodatkowo w stronę stawki właściwej dla usług doradztwa związanego z zarządzaniem.

5) Jak ograniczać ryzyko sporu: rekomendacje kontraktowe i dowodowe

Po pierwsze, zakres świadczenia powinien być opisany przez pryzmat rezultatów (deliverables) i czynności jednoznacznie developerskich. W praktyce lepiej sprawdza się opis: „wytworzenie/rozwój określonych funkcjonalności” niż „kompleksowe wsparcie projektu” obejmujące analizę, konsulting i nadzór.

Po drugie, jeżeli obok developmentu rzeczywiście wykonywane są konsultacje lub aktywności nadzorcze, zasadne bywa ich wyodrębnienie: osobny załącznik do umowy, osobne pozycje na fakturze, a w razie potrzeby – nawet osobna umowa. Ma to znaczenie również dlatego, że przy różnych stawkach ustawodawca wymaga prowadzenia ewidencji przychodów w sposób pozwalający ustalić przychody z każdego rodzaju działalności; w przeciwnym razie pojawiają się dodatkowe konsekwencje dowodowe i rozliczeniowe.

Po trzecie, przy rolach typu lead/architect warto rozróżnić „kontrolę jakości własnego świadczenia” od „stałego nadzoru” nad cudzymi pracami. Im bardziej umowa sugeruje odpowiedzialność za decyzje i działania innych osób, tym bardziej rośnie ryzyko kwalifikacji do usług doradczych lub zarządczych.

Po czwarte, w razie wątpliwości co do stawki praktycznym narzędziem ochronnym jest interpretacja indywidualna wydawana przez Dyrektora Krajowej Informacji Skarbowej. Wniosek powinien opisywać realnie wykonywane czynności, a nie „optymistyczną wersję” – bo ochrona działa tylko przy zgodności z opisanym stanem faktycznym.

6) Wsparcie kancelarii w audycie umowy i przygotowaniu strategii podatkowo-kontraktowej

W projektach IT nie ma jednego „magicznego” brzmienia umowy, które zawsze zabezpiecza stawkę ryczałtu. Kluczowe jest dopasowanie zapisów do faktycznego modelu pracy i sposobu rozliczeń, a następnie spójne udokumentowanie świadczenia (zakres, rezultaty, protokoły odbioru, opis na fakturze). W takich sprawach praktycznym wsparciem jest przegląd i uporządkowanie dokumentacji oraz przygotowanie wariantów rozwiązań (np. rozdzielenie świadczeń, doprecyzowanie „konsultacji”, urealnienie nadzoru autorskiego). W tym obszarze Kancelaria Kopeć Zaborowski Adwokaci i Radcowie Prawni prowadzi analizę kontraktów B2B w software house i gamedev, wskazując ryzyka oraz rekomendacje zmian, które są zgodne z aktualną linią interpretacyjną i realiami kontroli.

Podsumowanie

W ocenie KAS „podbijanie” stawki ryczałtu w IT najczęściej nie wynika z samego faktu pracy w branży, lecz z tego, że umowa i praktyka wykonywania usług sugerują: doradztwo, zarządzanie albo „świadczenie kompleksowe”, a nie jednoznacznie wyodrębnione prace developerskie. W software house i gamedev szczególną ostrożność wymagają postanowienia o szerokim zakresie, nadzorze autorskim oraz otwartych „konsultacjach”. Im lepiej dopasowany i dowodowo spójny kontrakt, tym mniejsze ryzyko sporu o stawkę – i tym większa przewidywalność rozliczeń.

Bibliografia

1) Ustawa z dnia 20 listopada 1998 r. o zryczałtowanym podatku dochodowym od niektórych przychodów osiąganych przez osoby fizyczne – tekst jednolity: Dz.U. 2025 poz. 843 (w szczególności art. 12).
2) Wybrane interpretacje indywidualne Dyrektora Krajowej Informacji Skarbowej dotyczące stawek ryczałtu dla usług IT (m.in. sygn. 0115-KDST2-2.4011.222.2025.3.MS z 18.06.2025; sygn. 0113-KDIPT2-1.4011.551.2025.4.KD z 19.12.2025).
3) Materiały informacyjne dotyczące interpretacji indywidualnych (procedura ORD-IN) – serwis gov.pl / podatki.gov.pl.
4) Omówienia orzecznictwa NSA dotyczące kwalifikacji usług IT do stawki 12% ryczałtu – publikacje specjalistyczne (w tym serwisy prawa i podatków).

Źródła kluczowych podstaw prawnych i przykładowej linii interpretacyjnej: ([Dziennik Ustaw][1]) [1]: https://dziennikustaw.gov.pl/DU/2025/843/D2025000084301.pdf „Obwieszczenie Marszałka Sejmu Rzeczypospolitej Polskiej z dnia 13 czerwca 2025 r. w sprawie ogłoszenia jednolitego tekstu ustawy o zryczałtowanym podatku dochodowym od niektórych przychodów osiąganych przez osoby fizyczne”