PKWiU 62.01.1 - co obejmuje i kiedy nie pasuje do usług IT?

Kod pkwiu 62.01.1 najczęściej pojawia się wtedy, gdy trzeba odróżnić klasyczny development oprogramowania od doradztwa, hostingu albo zarządzania systemami. W praktyce to nie jest drobiazg formalny: od właściwej klasyfikacji zależy sposób opisu usługi, ryczałt i to, jak bezpiecznie ułożyć umowę z klientem. Poniżej rozkładam temat na konkretne części, żeby łatwo było sprawdzić, gdzie ten kod pasuje, a gdzie zaczyna się już inna usługa.

Co obejmuje to grupowanie i dlaczego warto je czytać dosłownie

Na poziomie klasyfikacji to grupa dla usług związanych z projektowaniem i rozwojem technologii informatycznych. Na tym poziomie mieszczą się dwa ważne podgrupowania: 62.01.11, czyli projektowanie, programowanie i rozwój oprogramowania, oraz 62.01.12, czyli projektowanie i rozwój technologii IT dla sieci i systemów komputerowych. GUS opisuje więc ten obszar bardzo konkretnie, a nie jako ogólnikowe „usługi komputerowe”.

Ja traktuję ten kod jak granicę między pracą, w której realnie tworzysz albo rozwijasz rozwiązanie techniczne, a pracą, w której tylko doradzasz, utrzymujesz środowisko albo obsługujesz infrastrukturę. To właśnie ten szczegół robi różnicę w podatkach i w dokumentach. Jedna współpraca może obejmować kilka rodzajów działań, ale nie każda z nich powinna dostać ten sam opis. Dlatego najpierw patrzę na efekt pracy, a dopiero potem na etykietę.

W praktyce najczęstszy błąd polega na tym, że ktoś bierze nazwę zawodu i robi z niej automatycznie kod usługi. To nie działa. Liczy się nie to, czy ktoś nazywa się programistą, tylko czy faktycznie dostarcza kod, rozwija system albo projektuje techniczne rozwiązanie. Jeśli umiesz to rozróżnić, łatwiej przejdziesz do kolejnego kroku, czyli porównania z sąsiednimi kodami.

Jak odróżnić je od sąsiednich kodów IT

W usługach IT granice między grupowaniami bywają cienkie. Najbezpieczniej analizować je przez pryzmat dominującej czynności: co jest głównym efektem pracy i za co klient naprawdę płaci. Poniżej zestawiam najbliższe kody, bo właśnie one najczęściej mylą przedsiębiorców.

Gdy mam wątpliwość, pytam bardzo prosto: czy klient kupuje ode mnie kod, rozwój funkcji albo techniczne rozwiązanie, czy raczej wiedzę, nadzór, utrzymanie albo dostęp do infrastruktury? Ta jedna różnica zazwyczaj ustawia cały kod. Jeśli odpowiedź nie jest oczywista, nie próbuję na siłę wciskać usługi do pierwszej lepszej szufladki. Lepiej doprecyzować zakres niż później prostować cały kontrakt.

Właśnie dlatego warto patrzeć na usługi mieszane z chłodną głową. Development, konsulting i administracja systemami to nie to samo, nawet jeśli w praktyce wykonuje je ta sama osoba. Rozdzielenie tych elementów zwykle oszczędza więcej czasu niż późniejsze tłumaczenie się z jednego źle przypiętego kodu.

Co ten kod zmienia w podatkach

W podatkach ten kod ma znaczenie przede wszystkim przy ryczałcie. Na podatki.gov.pl usługi związane z oprogramowaniem w tym ujęciu są wskazane jako objęte stawką 12%, ale tylko wtedy, gdy faktycznie chodzi o taki rodzaj świadczenia. To ważne, bo ryczałt liczysz od przychodu, a nie od dochodu, więc koszt sprzętu, subskrypcji czy biura nie obniża samego podatku. Przy usługach IT to często zmienia całą ekonomię współpracy.

Nie traktowałbym jednak tego kodu jak automatycznej przepustki do jednej stawki dla całej działalności. Słowo ex oznacza zawężenie grupowania, więc nie każda usługa z szerokiego obszaru 62.01.1 wpada do tego samego worka podatkowego. Jeśli obok developmentu świadczysz doradztwo, utrzymanie albo hosting, trzeba rozdzielić przychody i pilnować, która część odpowiada któremu rodzajowi usługi. W VAT z kolei patrzy się na rzeczywisty charakter świadczenia, więc sam kod nigdy nie zastępuje analizy tego, co faktycznie sprzedajesz.

To jest miejsce, w którym najwięcej osób traci kontrolę nad rozliczeniem. Wystawia jedną ogólną fakturę za „usługi IT”, a w środku ma kodowanie, konsultację architektoniczną, wsparcie i monitoring. Dla księgowości to nie jest detal, tylko problem do rozwiązania. Im lepiej rozbijesz ofertę na czytelne składniki, tym mniej ryzyka po swojej stronie.

Jakie usługi zwykle mieszczą się w tej klasyfikacji

Najłatwiej myśleć o tym kodzie przez pryzmat efektu pracy. Jeśli rezultatem jest działający fragment oprogramowania, nowa funkcja, moduł albo techniczne rozszerzenie systemu, zwykle jesteś blisko tej klasyfikacji. Poniżej pokazuję przykłady, które w praktyce najczęściej mieszczą się w tym obszarze.

• Tworzenie dedykowanej aplikacji na zamówienie, bo tutaj centralnym produktem jest kod i działająca funkcjonalność.
• Rozwój istniejącego systemu o nowe moduły, bo klient płaci za techniczne rozszerzenie produktu, a nie za samą poradę.
• Budowa API i integracji między systemami, bo to klasyczna praca rozwojowa na styku kilku aplikacji.
• Projektowanie warstwy technicznej dla produktu SaaS, jeśli zakres obejmuje realne rozwiązania programistyczne, a nie tylko konsultacje.
• Refaktoryzacja i prace rozwojowe przy kodzie źródłowym, o ile są elementem usługi tworzenia lub rozwoju oprogramowania, a nie osobną usługą wsparcia.

Przy tych przykładach najważniejsze jest jedno: nie nazwa usługi, tylko jej treść. Dwie faktury mogą wyglądać podobnie, a jedna będzie dotyczyła rozwoju software’u, a druga doradztwa technologicznego. To dlatego w umowie i w opisie prac warto pisać konkretnie: co zostało zbudowane, co rozwinięto, jaki był rezultat. Zbyt ogólny opis typu „obsługa IT” niczego nie wyjaśnia i tylko utrudnia klasyfikację.

Jeżeli usługa kończy się na rekomendacjach, audycie albo szkoleniu zespołu, zwykle zaczyna się już inny obszar. To nie znaczy, że taka usługa jest gorsza albo mniej wartościowa. Po prostu jej kod i sposób rozliczania mogą być inne. I dobrze to sobie uporządkować zanim pojawi się pierwsza większa współpraca.

Jak ustalić właściwy kod dla swojej usługi

W praktyce klasyfikacja nie jest jednorazowym strzałem, tylko krótkim procesem analizy. Ja robię to zawsze od tej samej strony: najpierw opisuję usługę prostym językiem, potem rozbijam ją na elementy, a dopiero na końcu porównuję z kodami. To prostsze niż zgadywanie z pamięci i daje dużo lepszy efekt.

1. Opisz, co faktycznie robisz, bez marketingowych skrótów i bez technicznego żargonu.
2. Oddziel development od doradztwa, bo konsultacja i programowanie to dwa różne świadczenia.
3. Sprawdź, czy nie dominuje utrzymanie, monitoring albo administracja systemem.
4. Oceń, czy usługa dotyczy samego oprogramowania, czy raczej sieci, infrastruktury lub całego środowiska IT.
5. Jeśli masz kilka rodzajów pracy w jednym kontrakcie, rozdziel je w umowie, fakturze i ewidencji przychodów.
6. Przy nieoczywistym zakresie poproś o pisemne potwierdzenie klasyfikacji albo zabezpiecz się interpretacją, zanim kwestionują ją pieniądze.

W tym procesie bardzo pomaga pojęcie świadczenia złożonego, czyli jednej usługi zbudowanej z kilku elementów. To częsty przypadek w IT: klient kupuje nie tylko kod, ale też analizę, wdrożenie i późniejsze wsparcie. Jeśli wszystko wrzucisz do jednego worka, ryzykujesz błędną stawkę albo zły opis na fakturze. Jeśli rozbijesz świadczenie uczciwie i logicznie, rozliczenie staje się dużo czytelniejsze.

Właśnie dlatego nie zaczynam od pytania „jaki kod pasuje do mojego profilu”, tylko „co dokładnie sprzedaję”. Taka kolejność zwykle oszczędza najwięcej czasu. A gdy usługa jest naprawdę mieszana, lepiej to od razu przyznać niż udawać, że wszystko jest jednym rodzajem pracy. To rzadko kończy się dobrze.

Najczęstsze błędy, które widzę przy usługach programistycznych

Przy tej klasie usług błędy powtarzają się zaskakująco regularnie. Najczęściej nie wynikają ze złej woli, tylko z uproszczeń. Problem w tym, że uproszczenia w podatkach potrafią kosztować więcej niż porządne doprecyzowanie opisu usługi.

• Przypinanie kodu do zawodu zamiast do usługi. To, że ktoś jest programistą, nie znaczy jeszcze, że każda jego czynność ma ten sam kod.
• Wrzućenie doradztwa, developmentu i supportu do jednej pozycji. To najprostsza droga do nieczytelnego rozliczenia.
• Opisy typu „usługi IT” bez wskazania rezultatu. Taki zapis nic nie mówi o faktycznym świadczeniu.
• Kopiowanie kodu z umowy innej firmy. W IT podobieństwo branży nie oznacza podobieństwa usługi.
• Brak rozdzielenia przychodów w ewidencji, mimo że różne rodzaje pracy mają różne stawki lub różne konsekwencje podatkowe.
• Zakładanie, że hosting, utrzymanie i rozwój oprogramowania to jedna kategoria. To właśnie tam najczęściej pojawiają się spory.

Najbardziej ryzykowny błąd widzę wtedy, gdy ktoś myśli: „skoro robię coś w technologii, to ten kod będzie bezpieczny”. Nie będzie. Technologia jest za szeroka, żeby opierać na niej rozliczenie. Potrzebny jest konkret: czy tworzysz kod, czy rozwijasz system, czy tylko nim zarządzasz, czy może sprzedajesz dostęp do infrastruktury. Bez tego łatwo o zbyt odważne założenia.

Jeśli mam wskazać jedną rzecz, która najczęściej ratuje sytuację, to jest nią precyzyjny opis prac. Dobrze napisany zakres usług jest często ważniejszy niż sam kod wpisany w dokument. To on pozwala obronić klasyfikację, gdy ktoś po drugiej stronie zaczyna zadawać szczegółowe pytania.

Co sprawdzam przed wpisaniem kodu do umowy i faktury

Na końcu zostawiam prostą checklistę, którą sam uznaję za najbardziej praktyczną. Nie chodzi o to, by komplikować życie, tylko by uniknąć sytuacji, w której jedna ogólna etykieta ukrywa kilka różnych świadczeń. W IT to naprawdę częste.

• Czy opis usługi pokazuje efekt pracy, a nie tylko nazwę branży.
• Czy umowa rozróżnia development, konsulting, utrzymanie i hosting.
• Czy przychody da się rozdzielić w ewidencji bez zgadywania.
• Czy faktura odzwierciedla rzeczywisty zakres wykonanych prac.
• Czy wątpliwe przypadki mam opisane wcześniej, a nie dopiero po wystąpieniu problemu.

Jeżeli miałbym zostawić jedną praktyczną myśl, to tę: kod trzeba przypinać do konkretnego świadczenia, nie do zawodu ani do nazwy firmy. Przy usługach mieszanych rozdzielam development, doradztwo i utrzymanie, bo właśnie tam najczęściej powstają niepotrzebne błędy podatkowe. To prosta dyscyplina dokumentacyjna, ale w usługach IT bardzo często oszczędza najwięcej czasu wtedy, gdy pojawia się pytanie z urzędu albo zmienia się sposób rozliczania kontraktu.