PKWiU a ryczałt dla programisty: jak ustalić stawkę, gdy projekty się zmieniają
W praktyce PKWiU a ryczałt dla programisty trzeba oceniać nie na podstawie samej nazwy stanowiska, ale przez pryzmat rzeczywiście wykonywanych usług. To, że klient określa współpracownika jako „programistę” albo „IT Consultanta”, nie przesądza jeszcze o właściwej stawce podatku.
Dostajesz ofertę współpracy z dużą firmą. Formalnie nie będzie to etat, tylko kontrakt B2B. Zakładasz jednoosobową działalność gospodarczą, wybierasz ryczałt i chcesz przede wszystkim spokojnie pracować, wystawiać faktury oraz nie martwić się później o podatki.
Problem pojawia się wtedy, gdy pytasz: jaki kod wybrać i jaką stawkę ryczałtu zastosować?
W umowie często jest tylko ogólny opis: współpraca przy projektach IT, rozwój systemów, wsparcie zespołu, analiza wymagań, integracje, testowanie lub utrzymanie aplikacji. Tymczasem każdy projekt może wyglądać trochę inaczej, a realny zakres obowiązków może zmieniać się kilka razy w roku.
To normalna sytuacja. Nie trzeba znać całej przyszłości firmy w dniu rejestracji JDG. Trzeba jednak od początku wiedzieć, co ma znaczenie dla podatków i jak nie zbudować sobie problemu, który wróci po kilku latach.
PKD i PKWiU to nie to samo
Pierwsze źródło nieporozumień jest bardzo proste: przedsiębiorcy często używają zamiennie pojęć PKD i PKWiU. W praktyce pełnią one jednak inne funkcje.
PKD wybierasz przy zakładaniu działalności gospodarczej. To kod opisujący obszary działalności firmy wpisane do CEIDG. Powinien obejmować to, co faktycznie planujesz robić, ale nie jest podatkową deklaracją jednej konkretnej stawki ryczałtu.
PKWiU opisuje konkretną usługę lub czynność. To właśnie charakter rzeczywiście wykonywanych prac ma kluczowe znaczenie przy ustalaniu stawki ryczałtu.
Dlatego wpisanie przy zakładaniu firmy kodu PKD związanego z działalnością informatyczną nie oznacza automatycznie, że każda faktura wystawiona przez taką firmę ma być opodatkowana według jednej, z góry przyjętej stawki.
W przypadku ryczałtu nie liczy się bowiem przede wszystkim to, co przedsiębiorca wpisał kiedyś do CEIDG. Liczy się to, co realnie zrobił dla klienta i za co otrzymał wynagrodzenie.
Jaki PKD wybrać przy zakładaniu JDG w IT?
Jeżeli dopiero zaczynasz współpracę i nie znasz jeszcze dokładnie wszystkich przyszłych projektów, rozsądne podejście jest proste: wybierz PKD wystarczająco szerokie, aby obejmowało przewidywany profil działalności.
Nie ma potrzeby próbować przewidzieć każdego zadania, które może pojawić się za dwa lata. W branży IT projekty zmieniają się szybko. Dziś możesz rozwijać aplikację, za pół roku prowadzić analizę wymagań, a później pomagać przy wdrożeniu lub integracji systemów.
Kod PKD można później zmienić albo rozszerzyć. To techniczna aktualizacja danych przedsiębiorcy, a nie wyrok podatkowy na całą przyszłość firmy.
Najważniejsze jest jednak, aby nie traktować PKD jako odpowiedzi na pytanie o stawkę ryczałtu. Ta odpowiedź pojawia się dopiero wtedy, gdy znamy rzeczywisty zakres prac wykonywanych dla klienta.
Czy programista zawsze płaci 12% ryczałtu?
Nie. I właśnie tutaj zaczyna się najwięcej ryzyka.
Wiele osób słyszało prostą zasadę: „IT to 12% ryczałtu”. W praktyce taka odpowiedź bywa zbyt uproszczona.
Przepisy przewidują 12% ryczałtu dla określonych usług związanych między innymi z oprogramowaniem, doradztwem w zakresie oprogramowania, instalowaniem oprogramowania czy zarządzaniem sieciami i systemami informatycznymi. Nie oznacza to jednak, że każde świadczenie wykonywane przez osobę pracującą w projekcie IT automatycznie mieści się w tej kategorii.
W praktyce liczy się między innymi:
- co dokładnie robi przedsiębiorca,
- jaki jest rezultat jego pracy,
- czy tworzy lub rozwija oprogramowanie,
- czy analizuje procesy biznesowe,
- czy doradza klientowi,
- czy testuje,
- czy zarządza projektem lub zespołem,
- czy wykonuje działania administracyjne, wdrożeniowe albo operacyjne,
- jak opisane są obowiązki w umowie, zamówieniu, backlogu lub dokumentacji projektu.
Stanowisko wpisane przez klienta w systemie HR, podpis w stopce e-mail albo ogólna nazwa „IT Consultant” nie przesądzają jeszcze o prawidłowej stawce ryczałtu.
Jeden freelancer, kilka projektów i kilka stawek ryczałtu
PKWiU a ryczałt dla programisty mogą wyglądać inaczej w zależności od projektu. W jednej współpracy freelancer może rozwijać oprogramowanie, a w drugiej wykonywać analizę, testy, wdrożenie lub inne czynności o odmiennym charakterze.
To, że prowadzisz jedną JDG, nie oznacza, że wszystkie Twoje przychody muszą mieć tę samą stawkę ryczałtu.
Możesz równolegle pracować przy dwóch projektach dla jednego klienta albo dla różnych klientów. W jednym projekcie możesz wykonywać prace związane z tworzeniem lub rozwojem oprogramowania. W drugim możesz zajmować się analizą procesów, wsparciem wdrożenia, szkoleniami lub zadaniami o zupełnie innym charakterze.
Jeżeli różne rodzaje usług podlegają różnym stawkom ryczałtu, przychody trzeba rozliczać zgodnie z właściwą stawką dla danego rodzaju działalności. Warunek jest jeden: ewidencja musi pozwolić ustalić, jaka część przychodu dotyczyła konkretnych usług.
To oznacza, że nie warto czekać do końca roku i dopiero wtedy próbować odtworzyć, co właściwie było robione od stycznia do grudnia.
Najbezpieczniej jest od początku zadbać o prostą logikę dokumentów:
- umowa lub zamówienie opisuje zakres współpracy;
- projekt ma nazwę, zakres albo choćby opis w systemie klienta;
- faktura, raport czasu lub zestawienie prac pozwala przypisać wynagrodzenie do określonego rodzaju czynności;
- księgowość wie, jak dany przychód ująć w ewidencji.
Nie zawsze oznacza to konieczność wystawiania wielu faktur. Czasem wystarczy odpowiednio opisać pozycje na jednej fakturze albo przygotować wewnętrzne zestawienie, które pokazuje, czego dotyczyło wynagrodzenie. Ważne, aby podział wynikał z rzeczywistego sposobu pracy i był możliwy do obrony po czasie.
Problem nie zaczyna się wtedy, gdy projekt się zmienia
Zmiana projektu sama w sobie nie jest problemem. W IT jest wręcz standardem.
Problem zaczyna się wtedy, gdy zakres obowiązków zmienia się, ale nikt tego nie zauważa z perspektywy podatkowej.
Przykład: przez pierwsze miesiące współpracownik tworzy funkcjonalności aplikacji. Później klient przesuwa go do analizy procesów, prowadzenia warsztatów z biznesem lub koordynacji wdrożenia. Wynagrodzenie dalej wpływa na podstawie tej samej umowy i co miesiąc wystawiana jest podobna faktura z ogólnym opisem „usługi IT”.
Po trzech latach nikt już nie pamięta, kiedy dokładnie zmienił się zakres prac. Po pięciu latach może nie być części osób, które pracowały przy projekcie. Mogą zniknąć dostęp do narzędzi klienta, stare raporty czasu albo dokumentacja projektowa.
A wtedy sprawa przestaje być prostym pytaniem: „jaką stawkę chcieliśmy stosować?”. Pojawia się pytanie: czy potrafimy pokazać, że rzeczywiście wykonywaliśmy usługi odpowiadające tej stawce?
Dlaczego optymistyczna interpretacja własnej pracy bywa ryzykowna
Właściciel firmy naturalnie patrzy na swoją działalność z perspektywy codziennej pracy. Wie, że projekt był technologiczny, że pracował w zespole IT i że bez jego udziału system by nie powstał albo nie działał.
Urząd skarbowy może patrzeć na tę samą sytuację inaczej. Nie będzie oceniał ogólnego wrażenia, że „to było IT”. Będzie analizował dokumenty, zakres obowiązków, opis usług, faktury, umowy i rzeczywisty charakter czynności.
To nie oznacza, że każda kontrola kończy się sporem. Oznacza jednak, że przy ryczałcie nie warto opierać się wyłącznie na przekonaniu: „przecież to oczywiste”.
Największe ryzyko pojawia się właśnie wtedy, gdy przedsiębiorca sam ocenia swoją sytuację bardzo optymistycznie. Szuka najniższej możliwej stawki, patrzy na pojedyncze słowa z umowy albo porównuje się z kolegą wykonującym podobną pracę dla innej firmy.
Tymczasem dwa pozornie podobne kontrakty mogą być podatkowo różne, ponieważ różni się realny zakres obowiązków, model współpracy, rezultat pracy i dokumentacja.
Kontrola po kilku latach: dlaczego dokumenty są ważniejsze niż pamięć
Zobowiązanie podatkowe co do zasady przedawnia się po pięciu latach, liczonych od końca roku kalendarzowego, w którym upłynął termin zapłaty podatku. W określonych sytuacjach bieg tego terminu może być jednak zawieszony albo przerwany.
To oznacza, że nawet po kilku latach warto mieć możliwość pokazania:
- co było przedmiotem współpracy,
- jaki był zakres prac na danym projekcie,
- które czynności wykonywano w konkretnym okresie,
- jak przypisano przychód do odpowiedniej stawki,
- dlaczego przyjęte rozliczenie było rozsądne na podstawie dostępnych dokumentów.
Jeżeli stawka została przyjęta błędnie, konsekwencją może być zaległość podatkowa i odsetki. W zależności od okoliczności może też pojawić się odpowiedzialność karna skarbowa. Dlatego nie chodzi o budowanie sztucznej dokumentacji „na wszelki wypadek”, ale o uporządkowanie dowodów wtedy, gdy praca faktycznie jest wykonywana.
Po latach nikt nie powinien próbować rekonstruować całej historii firmy z pamięci, archiwalnych wiadomości na Slacku i pojedynczych faktur opisanych jako „usługi informatyczne”.
Jak ograniczyć ryzyko przy ryczałcie w IT
Dobra organizacja nie musi być skomplikowana. W większości przypadków wystarczy kilka prostych zasad.
1. Nie ustalaj stawki wyłącznie na podstawie nazwy stanowiska
„Programista”, „IT Consultant”, „Business Analyst” czy „Solution Architect” to określenia wygodne w rozmowie, ale za mało precyzyjne dla podatków.
Najpierw trzeba ustalić, co dana osoba rzeczywiście robi.
2. Opisuj zakres prac językiem efektów i czynności
W umowie, zamówieniu, protokole, raporcie czasu czy opisie faktury warto wskazać konkretny charakter usługi.
Zamiast ogólnego „usługi IT” lepiej użyć opisu odpowiadającego realnej pracy, na przykład:
- rozwój i modyfikacja funkcjonalności systemu,
- przygotowanie integracji między systemami,
- konfiguracja i wdrożenie rozwiązania,
- analiza wymagań biznesowych,
- testowanie oprogramowania,
- wsparcie utrzymania systemu,
- konsultacje dotyczące wdrożenia rozwiązania.
Nie chodzi o pisanie długich esejów na fakturze. Chodzi o to, aby po czasie było jasne, czego dotyczyło wynagrodzenie.
3. Reaguj na zmianę projektu, a nie dopiero na zmianę roku
Nowy projekt, nowy zakres obowiązków albo przejście do innego zespołu powinny uruchamiać krótką analizę podatkową.
Czasem okaże się, że nic się nie zmieniło. Czasem trzeba będzie inaczej opisać usługę, zmienić sposób ewidencjonowania przychodów albo rozdzielić wynagrodzenie dotyczące różnych rodzajów czynności.
Najgorszym momentem na analizę jest dzień przed złożeniem PIT-28.
4. Oddzielaj przychody, gdy wykonujesz różne usługi
Jeżeli równolegle wykonujesz czynności o różnym charakterze, warto od początku mieć możliwość pokazania, która część wynagrodzenia dotyczy danego zakresu prac.
Nie należy tworzyć podziału wyłącznie „dla podatków”. Powinien on wynikać z rzeczywistej organizacji pracy, zakresu zlecenia, czasu pracy, etapów projektu albo ustalonego wynagrodzenia za konkretne zadania.
5. Rób okresowy przegląd, zanim zrobi go urząd
W praktyce dobrym rozwiązaniem jest coroczny przegląd zakresu usług i stosowanych stawek, a dodatkowo szybka konsultacja przy większej zmianie projektu.
Taki audyt nie musi oznaczać skomplikowanej analizy prawnej całej firmy. Często wystarczy spokojnie przejrzeć umowy, faktury, opisy projektów i rzeczywiste obowiązki, a następnie ustalić, czy obecne rozliczenie nadal pasuje do sytuacji.
Jeżeli klasyfikacja konkretnej usługi rzeczywiście jest niejasna, można rozważyć wystąpienie do Ośrodka Klasyfikacji i Nomenklatur GUS o informację klasyfikacyjną. Wniosek powinien dotyczyć jednej usługi i zawierać jej precyzyjny opis.
Księgowość to dziś nie tylko faktury i deklaracje
Wystawienie faktury, pilnowanie terminów czy przygotowanie podstawowych rozliczeń coraz łatwiej automatyzować. Robią to programy księgowe, integracje bankowe i narzędzia wykorzystujące AI.
Nie oznacza to jednak, że mała firma nie potrzebuje dobrego wsparcia księgowego.
W dużej organizacji dział finansowy, księgowi, doradcy podatkowi i prawnicy analizują ryzyka, przygotowują dokumentację i prowadzą spory z organami. Freelancer albo mała firma zwykle nie ma własnego zespołu, który po pięciu latach będzie w stanie odtworzyć każdy projekt i bronić każdej decyzji podatkowej.
Dlatego dobra księgowość dla JDG nie powinna kończyć się na zaksięgowaniu faktury. Powinna pomagać właścicielowi firmy:
- zauważyć zmianę ryzyka,
- zadać właściwe pytania przed podjęciem decyzji,
- uporządkować dokumenty,
- zachować spójność między umową, fakturą, projektem i ewidencją,
- ograniczyć ryzyko dopłat i sporów w przyszłości.
Im mniejsza firma, tym większe znaczenie ma każda taka decyzja. Dla dużej korporacji potencjalny spór podatkowy jest jednym z wielu tematów w dziale prawnym. Dla freelancera może oznaczać problem finansowy, stres i wiele miesięcy tłumaczenia decyzji, która kilka lat wcześniej wydawała się oczywista.
Podsumowanie: PKD wybierasz na start, PKWiU oceniasz w trakcie pracy
Jeżeli zakładasz JDG jako programista lub freelancer IT:
- wybierz PKD szeroko, ale zgodnie z planowanym profilem działalności;
- pamiętaj, że PKD nie ustala stawki ryczałtu;
- stawkę określa się na podstawie faktycznie wykonywanych usług i ich klasyfikacji PKWiU;
- nie zakładaj automatycznie, że każda usługa w IT podlega tej samej stawce;
- gdy zakres prac się zmienia, sprawdź konsekwencje podatkowe od razu;
- dokumentuj pracę tak, aby po kilku latach można było wykazać, co rzeczywiście robiłeś;
- traktuj księgowość jako element zarządzania ryzykiem, a nie wyłącznie narzędzie do wystawiania faktur.
Dobrze uporządkowane PKWiU a ryczałt dla programisty dają nie tylko prawidłowe rozliczenie bieżących faktur, ale przede wszystkim większy spokój, gdy po kilku latach urząd zapyta o charakter wykonanych usług.
Ryczałt może być prostą i wygodną formą opodatkowania. Prostota nie polega jednak na tym, żeby raz wpisać kod i przez kolejne lata nie patrzeć na nic więcej. Polega na tym, żeby od początku mieć jasny, możliwy do obrony sposób działania
