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

12.02.2026

W branży IT spór o właściwą stawkę ryczałtu od przychodów ewidencjonowanych zwykle nie dotyczy „etykiety” stanowiska (programista, analityk, project manager), lecz tego, co w praktyce zostało wykonane i jak to udokumentowano. W postępowaniach kontrolnych organ potrafi odtworzyć rzeczywisty zakres świadczenia z materiałów, które na co dzień powstają „przy okazji” realizacji projektów: e-maili, komunikatorów, ticketów w Jira/YouTrack, historii commitów w Git, opisów merge requestów, dokumentacji technicznej czy raportów ze sprintów. Punkt ciężkości przesuwa się z deklaracji podatnika na rekonstrukcję faktów, a ta bywa mniej korzystna niż założenia przyjęte przy wyborze stawki.

Podstawowa zasada jest prosta: stawkę ryczałtu determinuje rodzaj faktycznie świadczonych usług, a nie sama nazwa na fakturze czy w umowie. Ustawa o ryczałcie przypisuje różne stawki do określonych typów usług, często z odwołaniem do PKWiU. W praktyce IT najczęściej „ścierają się” stawki 8,5% i 12%, a 14% pojawia się w wybranych, bardziej wyspecjalizowanych modelach świadczeń, które bywają częścią projektów technologicznych (np. specjalistyczne projektowanie). {index=0}

1) Skąd biorą się stawki 8,5%, 12% i 14% – i dlaczego w IT to nie jest oczywiste

12% ryczałtu jest w praktyce najczęściej kojarzone z usługami „software’owymi”: usługami związanymi z oprogramowaniem oraz doradztwem w zakresie oprogramowania i informatyki – w zakresie, w jakim ustawa wiąże te czynności z konkretnymi grupowaniami PKWiU. To właśnie ta stawka bywa stosowana (lub narzucana w trakcie kontroli), gdy z materiałów projektowych wynika tworzenie, modyfikowanie, rozwijanie, wdrażanie lub utrzymywanie elementów oprogramowania – także wtedy, gdy podatnik określa się jako „konsultant” czy „inżynier wsparcia”.

8,5% ryczałtu występuje w IT najczęściej tam, gdzie realnie świadczone są usługi o charakterze technicznym lub organizacyjnym, ale nie „wchodzą” one w zakres usług związanych z oprogramowaniem w rozumieniu ustawy (np. część usług zarządzania projektem, koordynacji, niektóre usługi operacyjne i pomocnicze). W interpretacjach indywidualnych często widać, że kluczowe znaczenie ma brak elementu doradztwa oraz brak czynności kwalifikowanych jako usługi związane z oprogramowaniem – nawet jeśli praca odbywa się w środowisku IT i na narzędziach typowych dla wytwarzania software’u.

14% ryczałtu jest przewidziane m.in. dla usług: w zakresie opieki zdrowotnej, architektonicznych i inżynierskich, badań i analiz technicznych oraz specjalistycznego projektowania. W kontekście projektów technologicznych ta stawka może pojawić się wtedy, gdy zakres świadczenia realnie mieści się w tych kategoriach (np. wyspecjalizowane prace projektowe o określonym profilu, a nie wytwarzanie oprogramowania). Z perspektywy ryzyka kontrolnego istotne jest, aby nie „dopasowywać” stawki do oczekiwań finansowych, tylko do obiektywnego charakteru usługi i właściwej klasyfikacji.

2) Jak kontrola „czyta” IT: dowody, które przesądzają o kwalifikacji usługi

W postępowaniu podatkowym obowiązuje otwarty katalog dowodów: jako dowód można dopuścić wszystko, co może przyczynić się do wyjaśnienia sprawy i nie jest sprzeczne z prawem. Oznacza to, że materiały cyfrowe – korespondencja, logi, eksporty z narzędzi – mogą mieć pełne znaczenie dowodowe, jeżeli służą ustaleniu, co faktycznie wykonano.

Równolegle przepisy o kontroli podatkowej nakładają na kontrolowanego obowiązki związane z udostępnianiem dokumentów i wyjaśnień; przepisy przewidują też możliwość przekazania wyciągów z ksiąg i dowodów księgowych w formie elektronicznej (na nośniku lub elektronicznie), w określonych warunkach. W praktyce – jeżeli spór dotyczy stawki ryczałtu – organ będzie dążył do zebrania materiału, który pokaże, czy praca miała charakter „software’owy” (12%), stricte organizacyjny/pozasoftware’owy (często 8,5%), czy odpowiada innym kategoriom usług.

Najczęściej analizowane źródła „rekonstrukcji” usługi w IT

Korespondencja (e-mail, komunikatory): ustalenie, czy podatnik rekomenduje rozwiązania (doradztwo), projektuje architekturę oprogramowania, definiuje wymagania funkcjonalne, czy jedynie koordynuje wykonanie.
Repozytoria kodu (Git): historia commitów, opisy PR/MR, code review, nazwy branchy – wskazują na realny udział w wytwarzaniu lub modyfikacji oprogramowania.
Narzędzia PM (Jira, Azure DevOps, Asana): typ ticketów („feature”, „bug”, „refactor”), przypisane zadania, komentarze, estymacje, time tracking – pozwalają zobaczyć, czy wykonywano prace developerskie, analityczne czy stricte koordynacyjne.
Dokumentacja projektowa: specyfikacje, diagramy, ADR-y (architecture decision records), protokoły ze sprintów – pokazują, czy powstawały elementy charakterystyczne dla tworzenia oprogramowania lub doradztwa w tym zakresie.
Faktury i umowy: spójność opisu świadczenia z realnymi deliverables; rozdzielenie zakresów (np. osobno zarządzanie projektem, osobno rozwój systemu).

Kluczowe jest to, że organ nie musi poprzestać na deklaracjach. Jeżeli z zestawienia dowodów wynika, że dominującym elementem było tworzenie/rozwijanie oprogramowania, wówczas ryzyko „przekwalifikowania” przychodu na stawkę 12% rośnie – nawet wtedy, gdy podatnik próbował argumentować, że świadczył „usługi wsparcia”, „koordynacji” lub „consultingu” bez kodowania. Z perspektywy praktyki interpretacyjnej i sporów w IT jest to obszar szczególnie wrażliwy.

3) Typowe scenariusze sporne: gdzie w IT najczęściej „pęka” linia obrony

Scenariusz A: „Project Manager”, ale w ticketach widać decyzje architektoniczne.
Jeśli narzędzia PM pokazują, że osoba nie tylko koordynowała pracę, lecz także definiowała rozwiązania techniczne, zatwierdzała sposób implementacji, rozpisywała funkcje systemu lub prowadziła analizy wprost pod development, organ może uznać, że usługa miała związek z oprogramowaniem (w kierunku 12%) albo miała komponent doradczy.

Scenariusz B: „konsulting”, ale repozytorium pokazuje regularne commity.
W praktyce to jeden z najprostszych przypadków: commit history i opisy PR/MR potrafią jednoznacznie wykazać udział w wytwarzaniu oprogramowania. Wtedy opis na fakturze staje się drugorzędny, a rozstrzygające jest to, co faktycznie powstało jako rezultat pracy.

Scenariusz C: rozdzielone role, ale brak rozdzielenia przychodów.
Nawet przy rzeczywistym wykonywaniu kilku rodzajów usług (np. część zadań stricte organizacyjnych, część software’owych) problemem bywa brak takiej ewidencji i dokumentacji, która pozwala precyzyjnie przypisać przychody do właściwych czynności. Wtedy kontrola może przyjąć mniej korzystną kwalifikację dla całości lub większej części przychodów, jeśli nie da się wiarygodnie wydzielić usług.

4) Jak ograniczyć ryzyko: praktyczne działania „compliance” dla IT na ryczałcie

Skuteczna obrona stawki ryczałtu w IT zwykle nie zaczyna się w trakcie kontroli, tylko na etapie projektowania współpracy z klientem i prowadzenia dokumentacji. W praktyce rekomenduje się wdrożenie kilku prostych, ale konsekwentnych standardów:

Mapa usług: spis czynności, które faktycznie są wykonywane, z przypisaniem do PKWiU i argumentacją, dlaczego dana stawka ma zastosowanie.
Spójność umowy, faktury i dowodów operacyjnych: jeżeli umowa mówi o koordynacji, a Jira i e-maile o projektowaniu rozwiązań i wdrożeniach – ryzyko sporu rośnie.
Rozdzielenie zakresów: przy usługach mieszanych warto rozważyć osobne zamówienia/etapy/pozycje fakturowe oraz ewidencję umożliwiającą wydzielenie przychodów według rodzaju usług.
Higiena komunikacji: unikanie pojęć typu „doradztwo w zakresie oprogramowania”, „projekt architektury systemu”, „wdrożenie funkcjonalności” w sytuacji, gdy intencją jest świadczenie usług stricte organizacyjnych – język w korespondencji bywa kluczowy.
Pakiet dowodowy: regularne archiwizowanie ustaleń zakresu (SOW), protokołów odbioru, raportów i innych deliverables, które pokazują, co było przedmiotem świadczenia.

Warto podkreślić, że organy coraz częściej kwestionują stosowanie niższej stawki w sytuacjach, w których z materiału sprawy wynika realny związek świadczenia z oprogramowaniem. Z tego powodu działania prewencyjne (uporządkowanie dokumentów i języka projektu) mają bezpośredni wymiar finansowy i procesowy.

5) Kiedy warto wejść z pełnomocnikiem – i co daje profesjonalna strategia dowodowa

W sporach o stawkę ryczałtu w IT nie chodzi wyłącznie o „przekonanie” organu, ale o zbudowanie spójnej narracji o charakterze usługi, popartej materiałem dowodowym dopuszczalnym w postępowaniu. Ponieważ organy mogą opierać się na szerokim katalogu dowodów, profesjonalna strategia obejmuje zwykle: analizę ryzyk w treści umów i faktur, przygotowanie wyjaśnień do korespondencji i zapisów w narzędziach, a także uporządkowanie materiału tak, aby fakty przemawiały na rzecz właściwej kwalifikacji.

W praktyce wsparcie kancelarii jest szczególnie przydatne, gdy kontrola już trwa albo gdy podatnik planuje uporządkowanie modelu współpracy z klientami przed spodziewaną weryfikacją. W takich sprawach Kopeć & Zaborowski Adwokaci i Radcowie Prawni może pomóc w analizie stanu faktycznego, ocenie klasyfikacji usług pod kątem ryczałtu, przygotowaniu bezpiecznych zapisów umownych oraz w prowadzeniu korespondencji i argumentacji na etapie czynności sprawdzających, kontroli i postępowania podatkowego – tak, aby obrona opierała się na faktach, a nie deklaracjach.

Podsumowanie

Różnica między 8,5%, 12% i 14% w środowisku IT nie sprowadza się do tego, „kto kim jest”, lecz do tego, co faktycznie zrobił i jakie ślady tej pracy pozostały w narzędziach oraz dokumentach. Kontrola potrafi zrekonstruować charakter usługi z e-maili, repozytoriów i narzędzi PM, a otwarty katalog dowodów w postępowaniu podatkowym sprzyja takiej analizie. Najbezpieczniejszą strategią jest spójność: zakres w umowie, opis na fakturze oraz rzeczywiste deliverables muszą opowiadać tę samą historię.

Bibliografia

Ustawa z dnia 20 listopada 1998 r. o zryczałtowanym podatku dochodowym od niektórych przychodów osiąganych przez osoby fizyczne (w szczególności art. 12) – tekst jednolity Dz.U. 2025 poz. 843.
Ustawa z dnia 29 sierpnia 1997 r. – Ordynacja podatkowa (w szczególności art. 180 i art. 287).
Ustawa z dnia 16 listopada 2016 r. o Krajowej Administracji Skarbowej – przepisy o kontroli celno-skarbowej (rozdział dot. kontroli).
Interpretacja indywidualna Dyrektora KIS z 26 marca 2025 r. (dot. usług PKWiU 62.01.12.0 i stawki 12% – związek z oprogramowaniem).
Interpretacja indywidualna Dyrektora KIS z 21 maja 2025 r. (dot. stawek ryczałtu dla usług informatycznych i zarządzania projektami – klasyfikacja i stawki).
Interpretacja indywidualna Dyrektora KIS z 16 lipca 2025 r. (przykład kwalifikacji usług technicznych do 8,5%).
Prawo.pl, „Ryczałt 8,5 proc. w IT ciągle możliwy, ale ryzykowny” (materiał omawiający praktykę kwestionowania stawki 8,5% w branży IT).
Biznes.gov.pl, „Ryczałt od przychodów ewidencjonowanych” (informacje publiczne dot. zasad i stawek ryczałtu).