Ryczałt 8,5% vs 12% vs 14% w IT: jak kontrola rekonstruuje faktyczny charakter usługi z korespondencji, repozytoriów i narzędzi PM

18.04.2026

Ryczałt 8,5% vs 12% vs 14% w IT: jak kontrola rekonstruuje faktyczny charakter usługi z korespondencji, repozytoriów i narzędzi PM

Ryczałt od przychodów ewidencjonowanych to forma opodatkowania, w której stawka podatku zależy od faktycznego rodzaju świadczonych usług, a nie od nazwy wpisanej w umowie czy na fakturze. W branży IT spór najczęściej dotyczy tego, czy podatnik realnie wykonuje usługi „programistyczne” (zwykle wyższe stawki), czy też usługi wsparcia, analizy, zarządzania, konsultingu lub inne czynności kwalifikowane odmiennie. W praktyce organ może weryfikować to poprzez rekonstrukcję przebiegu pracy na podstawie śladów cyfrowych: korespondencji, repozytoriów kodu i narzędzi do zarządzania projektami.

Dlaczego stawka 8,5% vs 12% vs 14% w IT jest tak często kwestionowana

Stawka ryczałtu wynika z ustawy o zryczałtowanym podatku dochodowym od niektórych przychodów osiąganych przez osoby fizyczne (dalej: „ustawa o ryczałcie”) [1]. Ustawa przypisuje stawki do kategorii usług, często przez odwołanie do klasyfikacji PKWiU. W IT problemem jest mieszany charakter świadczeń: jedna osoba w ramach jednego kontraktu potrafi analizować wymagania, pisać specyfikacje, konfigurować system, testować, nadzorować wdrożenie i tylko częściowo wytwarzać kod.

Ryzyko biznesowe ma kilka wymiarów:

• Finansowe – doszacowanie podatku, odsetki, potencjalne sankcje.
• Operacyjne – konieczność odtworzenia dokumentacji, praca zespołów (compliance, finanse, HR) podczas kontroli.
• Odpowiedzialność osób zarządzających – przy określonych stanach faktycznych ryzyka mogą dotyczyć również odpowiedzialności karnoskarbowej za rozliczenia [2].
• Reputacyjne – spór z organem w obszarze „optymalizacji” często wywołuje dodatkowe pytania kontrahentów lub instytucji finansujących.

Jak organ „rekonstruuje” faktyczny charakter usługi

W praktyce kontrolnej liczy się to, co podatnik faktycznie robił. Organ nie poprzestaje na opisie na fakturze typu „usługi IT” lub „programowanie”. Zamiast tego może budować obraz pracy z danych, które zwykle istnieją niezależnie od woli podatnika, bo są artefaktem procesu wytwarzania oprogramowania.

Korespondencja i komunikatory: co wynika z maili, Slacka, Teams

Korespondencja pokazuje rolę w projekcie. Przykładowo, jeśli dominują wątki: „ustalenie zakresu”, „negocjacje wymagań”, „priorytetyzacja backlogu”, „akceptacje”, „koordynacja interesariuszy”, to organ może argumentować, że jest to praca analityczno-zarządcza, a nie stricte wytwarzanie kodu. Z kolei rozmowy o refaktorze, implementacji, review, merge, dependency management częściej wspierają tezę o usługach programistycznych.

Repozytoria i narzędzia developerskie: commit, pull request, code review

Repozytorium jest jednym z najsilniejszych dowodów, bo pozwala wykazać ilość i rodzaj wkładu w kod. Organ może pytać o:

• historię commitów i opisy zmian,
• pull requesty i komentarze w code review,
• zakres modyfikowanych modułów (np. core vs konfiguracja),
• powiązanie commitów z ticketami (Jira/Azure DevOps).

Istotne jest również to, że brak aktywności w repozytorium nie przesądza automatycznie o braku prac programistycznych (np. praca na repo klienta bez dostępu, pair programming, prace koncepcyjne). Jednak w sporze dowodowym ciężar wyjaśnienia zwykle spada na podatnika.

Narzędzia PM i ticketing: Jira, Asana, Azure DevOps, ServiceNow

Tickety opisują „co” było robione. Jeżeli dominują zadania typu „analiza”, „warsztaty”, „koordynacja”, „zarządzanie ryzykiem”, „UAT”, „przygotowanie dokumentacji”, to organ może kwalifikować usługę jako inną niż programistyczna. Z drugiej strony, zadania „implementacja”, „bugfix”, „feature”, „deployment scripts”, „unit tests” wspierają tezę o wytwarzaniu i rozwoju oprogramowania.

Trzy typowe punkty sporne w IT (i jak ograniczać ryzyko)

Poniżej trzy powtarzalne sytuacje, w których dochodzi do rozjazdu między opisem usługi a materiałem dowodowym. Są to wyjątki w tym sensie, że nawet przy podobnej fakturze organ może dojść do różnych wniosków po analizie artefaktów pracy.

Wyjątek 1: „Programowanie” w umowie, ale w praktyce rola analityka lub PM

Fakt: organ porównuje umowę z rzeczywistymi zadaniami. Jeżeli materiały (Jira, maile) pokazują, że podatnik prowadził refinement, uzgodnienia i raportowanie, a kodu jest niewiele, ryzyko zakwestionowania stawki rośnie.

Opinia (zależna od stanu faktycznego): warto rozdzielać zakresy prac w umowie i w fakturowaniu, a w razie roli mieszanej prowadzić ewidencję, która pokaże proporcje i charakter działań.

Wyjątek 2: Realne prace techniczne, ale brak „śladu” w repozytorium

Fakt: w wielu projektach dostęp do repozytorium jest ograniczony lub praca odbywa się na środowiskach klienta. Organ może wtedy opierać się na ticketach i korespondencji, co bywa mniej korzystne, jeśli opisy są ogólne.

Opinia (zależna od stanu faktycznego): warto zabezpieczać dowody zastępcze, np. potwierdzenia scope’u technicznego, opisy zadań, raporty z wdrożeń, logi CI/CD, protokoły odbioru.

Wyjątek 3: Jedna usługa w ujęciu biznesowym, kilka usług w ujęciu podatkowym

Fakt: jeden kontrakt „IT” może zawierać elementy o różnej kwalifikacji (np. development + szkolenia + wsparcie). Ustawa o ryczałcie wiąże stawkę z rodzajem przychodu [1].

Opinia (zależna od stanu faktycznego): czasem bezpieczniej jest kontraktowo i fakturowo rozdzielić świadczenia, aby ograniczyć spór o „dominujący” charakter usługi.

Co sprawdzić przed kontrolą: minimum compliance dla ryczałtu w IT

W praktyce przygotowanie polega na tym, aby firma była w stanie szybko i spójnie odpowiedzieć na pytanie: „co dokładnie było dostarczane”. Przydatne działania:

1. Mapowanie usług do PKWiU i weryfikacja, czy przyjęta stawka ma oparcie w przepisach i praktyce interpretacyjnej.
2. Spójność dokumentów – umowa, załączniki (SOW), opisy na fakturach, tickety, protokoły odbioru.
3. Higiena opisów zadań w narzędziach PM (konkret: „implementacja endpointu”, „napisanie testów”, a nie „prace IT”).
4. Retencja danych – zasady przechowywania korespondencji i logów projektowych (z uwzględnieniem RODO i tajemnic kontraktowych).
5. Procedura na wypadek kontroli – kto odpowiada, kto zbiera dowody, jak wygląda obieg informacji i zatwierdzeń.

Kontrola i konsekwencje: czego realnie oczekiwać

Weryfikacja może odbywać się w ramach czynności sprawdzających, kontroli podatkowej lub kontroli celno-skarbowej w rozumieniu przepisów o KAS [3]. Organ może żądać dokumentów, wyjaśnień, a także analizować cyfrowe artefakty pracy. Jeżeli zakwestionuje stawkę, typowym skutkiem jest określenie zaległości podatkowej i naliczenie odsetek. W zależności od okoliczności mogą pojawić się również wątki karnoskarbowe (fakt) – podstawą jest Kodeks karny skarbowy [2] – jednak ocena ryzyka zawsze zależy od konkretnego stanu faktycznego (opinia).

W sprawach, w których spór dotyczy rekonstrukcji pracy z korespondencji, repozytoriów i narzędzi PM, praktyczne wsparcie obejmuje zwykle porządkowanie materiału dowodowego, ograniczenie ryzyk w komunikacji z organem oraz przygotowanie argumentacji co do kwalifikacji usług i stawek ryczałtu, a w razie wszczęcia działań przez kontrolę celno-skarbową warto rozważyć szybkie zabezpieczenie dowodów i wewnętrzny audyt dokumentów; w takich sytuacjach Kopeć & Zaborowski może pomóc w ocenie ryzyk i strategii działania, dlatego w razie potrzeby najlepiej Skontaktuj się z nami.

FAQ: Ryczałt 8,5% vs 12% vs 14% w IT

Czy nazwa usługi na fakturze przesądza o stawce ryczałtu w IT?

Nie. Decyduje faktyczny charakter czynności. Opis na fakturze jest istotny, ale organ może go skonfrontować z dowodami z projektu (np. repozytorium, Jira, korespondencja).

Jakie dowody są najważniejsze, gdy organ kwestionuje „programowanie”?

Najczęściej: historia zmian w repozytorium (commity, PR, code review), opisy ticketów oraz dokumenty odbiorowe. Korespondencja bywa dowodem uzupełniającym, ale potrafi przesądzać o roli w projekcie.

Czy brak commitów oznacza, że nie było prac programistycznych?

Nie musi oznaczać. Jednak zwiększa ryzyko dowodowe. Wtedy kluczowe są inne artefakty: szczegółowe tickety, potwierdzenia technicznego zakresu prac, logi wdrożeniowe, dokumenty odbioru.

Czy jedna umowa może obejmować usługi o różnych stawkach ryczałtu?

Tak, w praktyce często tak jest. Spór dotyczy wtedy tego, czy i jak rozdzielić przychody na różne kategorie usług oraz czy dokumentacja pozwala wykazać taki podział.

Na czym polega ryzyko dla zarządu lub osób decyzyjnych w spółce?

Ryzyko obejmuje koszty finansowe (doszacowanie, odsetki), zakłócenia operacyjne oraz potencjalne wątki karnoskarbowe przy określonych okolicznościach. Zakres odpowiedzialności zależy od roli, procesów wewnętrznych i konkretnych działań lub zaniechań.

Czy da się przygotować firmę IT do kontroli bez „przepalania” czasu zespołów?

Tak, jeżeli wdrożone są minimalne standardy: spójne SOW i fakturowanie, dobre opisy w ticketach, retencja danych oraz procedura szybkiego zebrania materiału dowodowego.

Bibliography

[1] Ustawa z dnia 20 listopada 1998 r. o zryczałtowanym podatku dochodowym od niektórych przychodów osiąganych przez osoby fizyczne (t.j. Dz.U. 2024 poz. 776 z późn. zm.).

[2] Ustawa z dnia 10 września 1999 r. Kodeks karny skarbowy (t.j. Dz.U. 2024 poz. 628 z późn. zm.).

[3] Ustawa z dnia 16 listopada 2016 r. o Krajowej Administracji Skarbowej (t.j. Dz.U. 2024 poz. 863 z późn. zm.).

[4] Rozporządzenie Rady Ministrów z dnia 4 września 2015 r. w sprawie Polskiej Klasyfikacji Wyrobów i Usług (PKWiU) (Dz.U. 2015 poz. 1676 z późn. zm.).

Materiał ma charakter informacyjny i nie stanowi porady prawnej; w razie planowanej lub trwającej weryfikacji rozliczeń najlepiej Skontaktuj się z nami.