„Projektowanie specjalistyczne” (PKWiU 74.10.19) w branży IT: checklist przesłanek, które kontrola będzie próbowała udowodnić dokumentami i praktyką pracy

26.01.2026

W branży IT klasyfikacja świadczonych usług bywa jednym z najsłabszych ogniw rozliczeń – nie dlatego, że jest „tajemna”, lecz dlatego, że organ w trakcie kontroli zwykle nie poprzestaje na nazwach z faktur czy opisach na stronie internetowej. Dla fiskusa kluczowy jest rzeczywisty charakter czynności i to, jak wyglądała praktyka wykonywania pracy w projektach. W efekcie, gdy podatnik wykazuje przychody jako projektowanie specjalistyczne (PKWiU 74.10.19.0) albo – odwrotnie – próbuje „uciec” od tej kwalifikacji, kontrola będzie budowała tezę na podstawie dowodów: umów, korespondencji, ticketów, repozytoriów, makiet, materiałów UX/UI oraz sposobu raportowania pracy.

Tekst koncentruje się na praktycznym ujęciu: jakie przesłanki i jakie dokumenty kontrola będzie próbowała „spiąć” w spójną narrację, aby wykazać, że usługa mieści się (lub nie mieści się) w PKWiU 74.10.19 oraz jakie to ma znaczenie na gruncie ryczałtu od przychodów ewidencjonowanych. Podstawą jest zasada, że organ ma obowiązek możliwie dokładnie wyjaśnić stan faktyczny (tzw. zasada prawdy obiektywnej), a więc będzie dążył do weryfikacji nie tylko papierów, ale też „śladów” pracy w narzędziach projektowych i developerskich.

Co oznacza PKWiU 74.10.19 i dlaczego wzbudza emocje w IT

PKWiU 74.10.19.0 to „usługi w zakresie pozostałego specjalistycznego projektowania”. Opis grupowania wskazuje m.in. na projektowanie wzornictwa różnych wyrobów (harmonizacja estetyki z wymogami technicznymi), projektowanie opakowań, tworzenie modeli 3D oraz usługi projektowania graficznego (np. reklamy, ilustracje, plakaty). Wprost nie jest to klasyfikacja „informatyczna”, ale w praktyce sporów podatkowych bywa przywoływana przy usługach z pogranicza designu cyfrowego (np. UI), gdy przedmiotem jest projekt warstwy wizualnej/komunikacyjnej produktu cyfrowego. 

Z perspektywy ryczałtu kluczowe jest to, że ustawa o zryczałtowanym podatku dochodowym przewiduje 14% dla usług w zakresie specjalistycznego projektowania (PKWiU 74.1) oraz 12% m.in. dla wybranych usług „software’owych” (np. związanych z oprogramowaniem – wskazanych w art. 12 przez odwołania do grupowań PKWiU, w tym „ex”). To sprawia, że spór o „design” vs „software” często jest sporem o stawkę ryczałtu i o ryzyko dopłaty podatku z odsetkami. 

Dodatkowo, linia interpretacyjna pokazuje, że w sprawach „UX/UI” organy potrafią kwalifikować czynności jako specjalistyczne projektowanie i wskazywać stawkę 14% dla przychodów mieszczących się w PKWiU 74.10.19. W interpretacjach podkreśla się, że znaczenie ma kompleksowy charakter usługi (np. projekt interfejsu + dokumentacja + kontrola wizualna), a nie sama deklaracja podatnika na fakturze. 

Jak kontrola „buduje sprawę”- dowody, do których ma realny dostęp

W kontrolach (w tym celno-skarbowych) organ może żądać udostępnienia akt, ewidencji, ksiąg i wszelkiego rodzaju dokumentów związanych z przedmiotem kontroli, sporządzać kopie, a także żądać przekazania danych w postaci elektronicznej – zwłaszcza gdy rozliczenia prowadzone są przy użyciu systemów IT. W praktyce oznacza to, że kontrola może oczekiwać nie tylko umów i faktur, ale również eksportów z narzędzi typu Jira/Asana, historii zmian w Figma, zapisów w repozytoriach czy raportów czasu pracy (o ile istnieją i są wykorzystywane).

Równolegle w postępowaniu podatkowym organ działa w reżimie ustalania stanu faktycznego, a podatnik – chcąc ograniczyć ryzyko – powinien zakładać, że sama „etykieta” PKWiU na fakturze nie wystarczy. Znaczenie mają dowody z dokumentów oraz dowody pośrednie: sposób komunikacji z klientem, zakres odpowiedzialności, realne deliverables i to, czy praca kończy się „projektem” (design), czy „działającą funkcją” (software). 

Checklista: przesłanki, które kontrola będzie próbowała udowodnić przy PKWiU 74.10.19 w IT

Poniższa lista nie jest „jedyną słuszną”, ale odzwierciedla typową logikę kontroli: organ nie pyta, jak podatnik nazywa usługę, tylko jak – na podstawie materiału dowodowego – da się ją zakwalifikować.

A. Przedmiot świadczenia: czy efektem jest projekt (design), czy wytworzenie/rozwój oprogramowania

• Czy rezultat ma formę makiet, wireframe’ów, prototypów, design systemu, komponentów UI, guideline’ów, specyfikacji wizualnej, assetów graficznych lub dokumentacji UI? (Kontrola będzie szukać plików i historii zmian.) 
• Czy podatnik odpowiada za harmonizację estetyki z wymogami technicznymi (typowa cecha usług projektowania) oraz za spójność wizualną? 
• Czy usługa obejmuje implementację (kod, testy, wdrożenie) lub udział w wytwarzaniu oprogramowania w sposób wykraczający poza „wstępne projektowanie” i dokumentację? (To zwykle argument w stronę usług z obszaru PKWiU wskazywanych w art. 12 jako 12%.) 

B. Zakres obowiązków z umowy i praktyki: czy rola jest „designerem”, czy „developerem”

• Jak opisano zakres prac w umowie/SOW: czy dominują sformułowania typu „projektowanie”, „warstwa wizualna”, „identyfikacja UI”, „makiety”, „prototypy”, „asset creation”, „visual QA”, czy raczej „development”, „coding”, „deployment”, „bug fixing”? 
• Czy w praktyce podatnik był rozliczany za deliverables projektowe (np. przekazanie wersji w Figma), czy za „dowiezione funkcje” i story points developerskie? 
• Czy występuje „mieszanie” ról: projektowanie + kodowanie. Jeżeli tak, kontrola będzie badała, czy da się wydzielić przychody według rodzajów działalności (bo ustawa dopuszcza różne stawki przy odpowiedniej ewidencji), czy też była to jedna kompleksowa usługa. 

C. Sposób raportowania pracy: co pokazują narzędzia projektowe i zarządcze

• Jakie typy zadań dominują w Jira/Asana: „UI screens”, „UX flow”, „prototype”, „design review”, „accessibility audit (UI)”, „visual regression review” vs „implement feature”, „fix bug”, „refactor”, „write tests”. 
• Czy istnieją rejestry czasu pracy i co z nich wynika (design vs development). Jeżeli ewidencja jest prowadzona, kontrola będzie ją traktowała jako ważny dowód pomocniczy. 
• Czy w repozytoriach (Git) występuje istotna aktywność podatnika (commity, pull requesty). Brak aktywności nie przesądza sprawy, ale jej obecność bywa argumentem, że rola obejmowała elementy wytwarzania oprogramowania. 

D. Opis na fakturach i korespondencja: czy „marketingowy opis” nie rozmija się z faktami

• Czy opisy faktur odzwierciedlają rzeczywisty zakres (np. „usługi projektowania interfejsu”, „projektowanie graficzne UI”), czy są ogólnikowe („usługi IT”), co otwiera pole do tezy organu. 
• Czy e-maile/Slack/Teams wskazują, że klient oczekiwał „projektu” (design), czy „wdrożenia” (software). Kontrola lubi cytować konkretne fragmenty korespondencji jako dowód intencji stron. 

E. Klasyfikacja PKWiU: czy podatnik ma uzasadnienie i spójność

• Czy podatnik posiada wewnętrzną notę klasyfikacyjną (dlaczego 74.10.19, jakie deliverables, jak odróżniono od usług software’owych). Taka nota nie jest „tarczą absolutną”, ale porządkuje argumentację. 
• Czy podatnik korzystał z informacji o standardach klasyfikacyjnych (GUS). W praktyce, w razie wątpliwości, warto rozważyć pozyskanie formalnego stanowiska/statystycznej informacji (w granicach dostępnych trybów). 
• Czy stanowisko podatnika nie stoi w sprzeczności z aktualną praktyką interpretacyjną w podobnych stanach faktycznych (np. UI/UX kwalifikowane jako specjalistyczne projektowanie ze stawką 14%). 

Najczęstsze „punkty zapalne” w kontrolach dotyczących designu cyfrowego

Z doświadczeń rynkowych i analizy sporów wynika, że kontrola najczęściej atakuje trzy obszary: (1) kompleksowość usługi (czy da się rozbić na design i software), (2) implementacja (czy podatnik jednak „dotykał kodu”), (3) niespójność dokumentów (co innego w umowie, co innego w fakturach, a co innego w praktyce projektowej). W interpretacjach dotyczących UI/UX organ potrafi wprost stwierdzać, że skoro podatnik świadczy jedną kompleksową usługę projektowania wizualnego interfejsów produktów cyfrowych, to przychody z PKWiU 74.10.19 mieszczą się w usługach specjalistycznego projektowania i podlegają 14%. 

Ważny detal: ustawa posługuje się również oznaczeniem „ex” przy niektórych grupowaniach (np. przy usługach związanych z oprogramowaniem). W praktyce oznacza to, że dana stawka dotyczy części danego grupowania – a więc organ może próbować wykazać, że konkretna czynność mieści się w tej „wydzielonej” części. To kolejny powód, dla którego opis czynności i dowody z praktyki pracy mają znaczenie większe niż sama etykieta. 

Jak ograniczyć ryzyko: dokumentacja i organizacja współpracy „pod kontrolę”

Podejście zorientowane na rozwiązania zaczyna się zanim kontrola się pojawi. Dobre przygotowanie polega na tym, aby dokumenty i praktyka pracy mówiły jednym głosem.

• Precyzyjny opis w umowie/SOW: zdefiniowanie deliverables (makiety, prototypy, design system, specyfikacja wizualna, assety), z wyłączeniem implementacji, jeżeli faktycznie nie występuje. 
• Spójne faktury: opisy świadczeń zgodne z rzeczywistą treścią usług; unikanie „worka” typu „usługi IT”, gdy faktycznie chodzi o projektowanie. 
• Ślady pracy: uporządkowane repozytorium plików projektowych, wersjonowanie (np. w Figma), zrozumiałe nazwy i logika folderów; eksporty/raporty na koniec sprintu.
• Rozdzielenie strumieni usług: jeżeli obok designu pojawia się software, warto rozważyć rozdzielenie zakresów (i przychodów) oraz ewidencję pozwalającą ustalić przychody z każdego rodzaju działalności – inaczej organ będzie skłonny uznać wszystko za jedną usługę. 
• Uzasadnienie klasyfikacji PKWiU: krótka nota (co jest projektowaniem, co nie jest; jakie są deliverables; dlaczego nie są to usługi wymienione w art. 12 jako 12%). 

Gdy kontrola już trwa: jak myśleć o strategii dowodowej?

W trakcie kontroli kluczowe jest uporządkowanie materiału dowodowego i konsekwentne trzymanie się tezy o rzeczywistym charakterze czynności. Organ ma szerokie narzędzia żądania dokumentów, dlatego brak przygotowania często kończy się dostarczaniem chaotycznych plików, które łatwo zinterpretować na niekorzyść podatnika. Dobrym standardem jest przygotowanie „mapy dowodowej”: (1) dokumenty kontraktowe, (2) faktury i opisy usług, (3) przykładowe deliverables projektowe, (4) eksporty z narzędzi zarządczych, (5) spójny opis procesu pracy.

Jeżeli spór dotyczy granicy między 74.10.19 a usługami „software’owymi”, szczególnie ważne jest wskazanie, czy praca obejmowała programowanie/instalowanie/zarządzanie systemami (art. 12 – 12%), czy pozostawała w obszarze specjalistycznego projektowania (art. 12 – 14%). W podobnych stanach faktycznych organy potrafiły przyjąć, że dominujące zadania projektowe (np. wizualne interfejsy) mieszczą się w 74.10.19 i skutkują 14%.

Wsparcie prawne: kiedy warto włączyć kancelarię?

W sprawach o klasyfikację PKWiU i stawkę ryczałtu „przegrywa” się często nie na przepisach, ale na dowodach: niespójnych umowach, zbyt ogólnych fakturach, braku materiałów potwierdzających projektowy charakter pracy lub przeciwnie – śladach wdrożeniowych, których nie da się sensownie wyjaśnić. Dlatego w praktyce warto rozważyć wsparcie prawne na etapie audytu dokumentów jeszcze przed kontrolą albo natychmiast po jej wszczęciu, gdy organ zaczyna formułować tezy. 

W takich sytuacjach pomoc może obejmować m.in. uporządkowanie strategii dowodowej, ocenę ryzyk w zakresie klasyfikacji PKWiU, przygotowanie odpowiedzi na wezwania oraz zaplanowanie działań minimalizujących skutki ewentualnej zmiany kwalifikacji. W celu omówienia konkretnej sytuacji i doboru optymalnej strategii warto skorzystać z oferty kancelarii prawnej Kopeć Zaborowski Adwokaci i Radcowie Prawni, która wspiera przedsiębiorców w sporach podatkowych i w przygotowaniu do kontroli, ze szczególnym uwzględnieniem realiów branży IT.

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 jedn. ogłoszony w 2025 r.; art. 12 – stawki m.in. 14% dla PKWiU 74.1 oraz 12% dla wskazanych usług IT). 
2. 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). 
3. Opis grupowania PKWiU 74.10.19.0 – „Usługi w zakresie pozostałego specjalistycznego projektowania” (zakres obejmuje m.in. projektowanie wzornictwa, opakowań, modele 3D oraz projektowanie graficzne). 
4. Ustawa z dnia 16 listopada 2016 r. o Krajowej Administracji Skarbowej – uprawnienia w ramach kontroli celno-skarbowej (żądanie dokumentów, danych elektronicznych). 
5. Ordynacja podatkowa – art. 122 (zasada prawdy obiektywnej w postępowaniu podatkowym). 
6. Interpretacja indywidualna Dyrektora KIS z dnia 21 maja 2025 r., sygn. 0115-KDST2-2.4011.142.2025.3.KK (kwalifikacja usług UI/UX i wskazanie stawki 14% dla usług specjalistycznego projektowania). 
7. Interpretacja indywidualna Dyrektora KIS z dnia 7 kwietnia 2025 r., sygn. 0115-KDST2-2.4011.80.2025.3.KK (wątek usług UX/UI i stawki właściwej dla PKWiU 74.1). 
8. Komunikat Prezesa Głównego Urzędu Statystycznego z dnia 18 grudnia 2023 r. w sprawie trybu udzielania informacji dotyczących standardów klasyfikacyjnych (akt obowiązujący od 18.12.2023; wskazuje zmiany od 1.01.2024 względem wcześniejszego komunikatu).