„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

12.04.2026

„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

„Projektowanie specjalistyczne” (PKWiU 74.10.19) to kategoria statystyczna obejmująca wyspecjalizowane prace projektowe. W praktyce branży IT spór zwykle nie dotyczy samej nazwy usługi na fakturze, lecz tego, czy realnie wykonywane czynności mają charakter projektowy i twórczy, czy też są to powtarzalne prace wykonawcze (np. wdrożenia, utrzymanie, support). Dla firmy to problem podatkowy i dowodowy: ryzyko zakwestionowania klasyfikacji wpływa na rozliczenia, stawki, koszty, a czasem na kwalifikację umów i model współpracy.

W toku kontroli organy będą szukały spójności między: (1) opisem usługi (umowy, faktury), (2) dowodami wykonania (repozytoria, ticketing, protokoły), (3) rzeczywistą praktyką pracy zespołów (kto, co, kiedy, w jakim procesie i na jakich zasadach). Poniżej znajduje się checklist obszarów, które typowo są „udowadniane” dokumentami oraz obserwacją procesu pracy.

Dlaczego klasyfikacja PKWiU 74.10.19 w IT trafia pod lupę

PKWiU jest narzędziem statystycznym, ale bywa wykorzystywane w praktyce podatkowej i sprawozdawczej. Ryzyko kontroli rośnie, gdy:

• opis na fakturze jest ogólny („projektowanie specjalistyczne”), a zakres prac szeroki,
• występują rozliczenia ryczałtowe lub godzinowe bez jasnych rezultatów (deliverables),
• ten sam zespół realizuje jednocześnie projektowanie, development i utrzymanie,
• firma korzysta z preferencji, ulg lub specyficznych zasad rozliczeń, gdzie „rodzaj usługi” ma znaczenie.

Podstawy prawne, które najczęściej pojawiają się w tle oceny dowodów, to ogólne reguły postępowania podatkowego i kontroli, w tym zasada prawdy obiektywnej i ocena dowodów, a także przepisy o kontroli celno-skarbowej i uprawnieniach organów do żądania dokumentów [1], [2].

Checklist: przesłanki „projektowania specjalistycznego”, które organ będzie weryfikował

1) Czy występuje element projektowy, a nie tylko wykonawczy

Organ będzie próbował ustalić, czy prace obejmują tworzenie koncepcji i rozwiązań (design), a nie jedynie implementację cudzych założeń.

• Dowody „na projekt”: dokumentacja architektury, specyfikacje rozwiązań, decision log, ADR (Architecture Decision Records), makiety, prototypy, diagramy, modele domeny.
• Dowody „na wykonawstwo”: głównie taski implementacyjne, bugfixy, prace utrzymaniowe, konfiguracja, administracja, rutynowe zmiany bez warstwy koncepcyjnej.

2) Jaki jest rezultat prac i czy da się go odebrać

W praktyce kontrolnej silnym argumentem jest istnienie jasno określonych rezultatów: projektu, koncepcji, dokumentacji projektowej, prototypu, standardu UI/UX, architektury, wzorca integracji.

• protokoły odbioru (także mailowe), backlog, release notes, raporty z warsztatów, prezentacje dla klienta, materiały przekazane w repozytorium lub narzędziach typu Confluence, SharePoint, Notion,
• „Definition of Done” obejmujące element projektowy, a nie wyłącznie kod.

3) Rola i odpowiedzialność osób wykonujących prace

Organ często bada nie tylko „co” zrobiono, ale „kto” to zrobił i w jakiej roli (np. architekt, projektant, analityk, UX designer). Ryzyko rośnie, gdy fakturowane „projektowanie” wykonują osoby formalnie rozliczane jak developerzy bez przypisanej odpowiedzialności projektowej.

• opisy ról w umowach i SOW, matryca RACI, zakres odpowiedzialności,
• CV kompetencyjne, przypisania w systemach (Jira), uprawnienia do zatwierdzania rozwiązań.

4) Sposób organizacji pracy: warsztaty, discovery, iteracje projektowe

W projektowaniu specjalistycznym typowe są etapy discovery, analiza wymagań, warsztaty, praca na wariantach i kompromisach. Organ będzie sprawdzał, czy proces to odzwierciedla.

• harmonogramy warsztatów, notatki, mapy procesów, user journey, wyniki analiz, backlogi z epikami projektowymi,
• ślady iteracji: wersjonowanie dokumentów, komentarze, zmiany koncepcji wraz z uzasadnieniem.

5) Spójność między umową, fakturą i praktyką (najczęstszy punkt sporny)

Jeżeli faktura wskazuje PKWiU 74.10.19, a umowa opisuje „development i maintenance”, a realnie przeważa utrzymanie, organ będzie miał prostą tezę: klasyfikacja jest etykietą bez pokrycia.

• spójne nazewnictwo usług w: umowie, załącznikach (SOW), ofertach, fakturach, raportach,
• jednoznaczne rozdzielenie strumieni prac: projektowanie vs implementacja vs utrzymanie.

Dokumenty i artefakty, po które organ sięga najczęściej

• umowy, aneksy, zamówienia, opisy usług (SOW), SLA, korespondencja,
• repozytoria (commit history), pull requesty, code review, tagi wydań,
• systemy ticketowe (Jira/Azure DevOps), raporty timesheet, ewidencje czasu,
• dokumentacja projektowa (Confluence), prezentacje, protokoły spotkań,
• polityki wewnętrzne i procedury (np. zarządzanie zmianą, akceptacja architektury).

Trzy wyjątki, które w praktyce często przesądzają o wyniku (do sprawdzenia w każdej firmie)

Wyjątek 1: „Nazwa na fakturze nie wystarczy” – nawet poprawne PKWiU na fakturze nie obroni się, jeśli z dokumentów i praktyki wynika przewaga prac utrzymaniowych lub czysto implementacyjnych. To fakt wynikający z zasad oceny dowodów w postępowaniach podatkowych [1].

Wyjątek 2: „Jedna umowa, wiele usług” – jeżeli w jednym kontrakcie mieszają się projektowanie, development i support, konieczne jest rozdzielenie zakresów i rezultatów (oraz często również sposobu rozliczeń). W przeciwnym razie organ może przyjąć dominujący charakter świadczenia. To ocena zależna od stanu faktycznego i konstrukcji umowy.

Wyjątek 3: „Praktyka pracy może przeczyć dokumentom” – nawet dobre SOW nie pomoże, jeśli narzędzia pracy (Jira, repozytorium, timesheet) pokazują brak faz projektowych, brak iteracji koncepcyjnych i brak deliverables projektowych. To fakt praktyczny: organy opierają ustalenia na całokształcie materiału dowodowego [1], [2].

Jak przygotować firmę: działania compliance, które ograniczają ryzyko

1. Mapa usług i artefaktów: przypisanie do każdej usługi minimalnego zestawu dowodów (np. dla projektowania: ADR, diagramy, prototyp, protokół odbioru).
2. Rozdzielenie strumieni pracy: osobne backlogi lub etykiety dla projektowania vs implementacji vs utrzymania.
3. Standard opisu na fakturze: opis usługi + wskazanie rezultatu (np. „opracowanie architektury integracji X wraz z dokumentacją i decyzjami architektonicznymi”).
4. Kontrola jakości timesheet: opisy czasu pracy powinny wskazywać czynności projektowe, nie tylko „dev”.
5. Przegląd umów: doprecyzowanie ról, odpowiedzialności, procedur odbioru oraz statusu dokumentacji projektowej jako rezultatu.

W przypadku wszczęcia czynności sprawdzających lub sporu o kwalifikację usług, praktycznie kluczowe jest szybkie zabezpieczenie i uporządkowanie materiału dowodowego, zanim dojdzie do eskalacji w tryb postępowania. Informacje o realiach postępowań i ryzykach, jakie niesie kontrola celno-skarbowa, warto uwzględniać w procedurach compliance już na etapie ofertowania i fakturowania.

Materiał ma charakter informacyjny i nie stanowi porady prawnej; ocena klasyfikacji oraz ryzyk zależy od konkretnych umów, sposobu realizacji prac i dokumentów.

W sprawach spornych dotyczących PKWiU 74.10.19 i przygotowania na działania organów, Kopeć & Zaborowski może przeprowadzić przegląd dowodów i procesu pracy, dlatego w razie potrzeby warto Skontaktuj się z nami.

FAQ: „Projektowanie specjalistyczne” (PKWiU 74.10.19) w branży IT

Czy PKWiU na fakturze przesądza o kwalifikacji usługi jako „projektowanie specjalistyczne”?

Nie. Organ ocenia rzeczywisty charakter czynności na podstawie całokształtu dowodów. Oznaczenie na fakturze jest jednym z elementów, ale nie rozstrzygającym [1].

Jakie dowody są najsilniejsze przy obronie „projektowania” w IT?

Najczęściej: dokumentacja architektoniczna i projektowa (wraz z historią zmian), decyzje projektowe (ADR), prototypy/makiety, protokoły odbioru rezultatów oraz ślady faz discovery i warsztatów.

Czy prace UX/UI w IT mogą mieścić się w „projektowaniu specjalistycznym”?

Mogą, jeśli rzeczywiście mają charakter projektowy i dają mierzalny rezultat (np. makiety, design system, prototypy) oraz są rozpoznawalne w dokumentach i procesie. Ostateczna kwalifikacja jest zależna od stanu faktycznego.

Co najbardziej osłabia stanowisko firmy w trakcie kontroli?

Brak spójności między umową, fakturą i narzędziami pracy (Jira, repozytorium, timesheet), a także brak rezultatów projektowych możliwych do odebrania.

Czy jeden kontrakt może obejmować projektowanie i utrzymanie bez zwiększania ryzyka?

Tak, ale wymaga to rozdzielenia zakresów, rezultatów i sposobu raportowania prac. W przeciwnym razie organ może uznać, że dominuje utrzymanie, a „projektowanie” jest jedynie etykietą.

Jak przygotować zarząd na ryzyka związane z kwalifikacją usług?

Z perspektywy governance kluczowe są: audyt umów i fakturowania, standard dowodowy (jakie artefakty muszą powstać), oraz mechanizm szybkiego zabezpieczenia danych na wypadek kontroli [2].

Bibliography

1. Ustawa z dnia 29 sierpnia 1997 r. – Ordynacja podatkowa (t.j. Dz.U. z 2025 r. poz. 111 i n.).
2. Ustawa z dnia 16 listopada 2016 r. o Krajowej Administracji Skarbowej (t.j. Dz.U. z 2025 r. poz. 422 i n.).
3. Rozporządzenie Rady Ministrów z dnia 4 września 2015 r. w sprawie Polskiej Klasyfikacji Wyrobów i Usług (PKWiU) (Dz.U. z 2015 r. poz. 1676, z późn. zm.).

Jeżeli firma potrzebuje weryfikacji, czy praktyka pracy i dokumenty obronią PKWiU 74.10.19 podczas kontroli, najbezpieczniej zlecić przegląd przed eskalacją sprawy i Skontaktuj się z nami.