Ryczałt 12% czy 8,5% dla programisty: kiedy można zastosować niższą stawkę

Programista, który „robi IT”, nie ma automatycznie prawa do 8,5% ryczałtu. To najczęstszy błąd. Fiskus nie patrzy na nazwę stanowiska z LinkedIna, wpisane PKD ani opis „usługi informatyczne” na fakturze. Patrzy na to, co faktycznie robisz dla klienta.

Jeżeli piszesz kod, rozwijasz aplikację, poprawiasz błędy, projektujesz logikę systemu albo doradzasz w zakresie oprogramowania, bezpiecznym punktem wyjścia jest 12% ryczałtu. Stawka 8,5% pojawia się dopiero wtedy, gdy usługa nie jest związana z oprogramowaniem w rozumieniu przepisów i interpretacji. Brzmi technicznie, ale w praktyce chodzi o prostą rzecz: czy Twoja praca dotyka tworzenia, modyfikowania, testowania lub doradzania przy software, czy raczej obejmuje czynności poboczne, wsparciowe albo administracyjne.

Różnica jest konkretna. Przy 20 000 zł miesięcznego przychodu 12% ryczałtu to 2 400 zł podatku, a 8,5% to 1 700 zł. Oszczędność wynosi 700 zł miesięcznie, czyli 8 400 zł rocznie. Tyle że źle dobrana stawka może skończyć się dopłatą podatku z odsetkami. Dlatego niższa stawka ma sens tylko wtedy, gdy da się ją obronić dokumentami, opisem usług i rzeczywistym zakresem pracy.

Kiedy programista płaci 12% ryczałtu

Stawka 12% ryczałtu dotyczy przede wszystkim usług związanych z oprogramowaniem. I tu zaczyna się problem, bo wielu specjalistów IT interpretuje to zbyt wąsko. „Nie jestem programistą, tylko konsultantem technicznym”, „nie tworzę aplikacji od zera, tylko poprawiam istniejące moduły”, „nie koduję codziennie, częściej analizuję wymagania” — takie argumenty nie zawsze wystarczą.

W praktyce 12% będzie właściwe zwłaszcza wtedy, gdy wykonujesz czynności takie jak:

• pisanie kodu albo tworzenie nowych funkcjonalności,
• modyfikowanie istniejącego oprogramowania,
• poprawianie błędów w aplikacji,
• przygotowywanie skryptów, integracji, automatyzacji,
• projektowanie architektury lub logiki systemu,
• analiza techniczna prowadząca bezpośrednio do zmian w oprogramowaniu,
• doradztwo w zakresie oprogramowania,
• testowanie automatyczne, jeżeli obejmuje tworzenie lub modyfikowanie skryptów testowych.

Granica bywa cienka. Tester manualny, który tylko wykonuje scenariusze i raportuje błędy, może być w innej sytuacji niż tester automatyzujący, który pisze skrypty w Pythonie, Javie, Cypressie czy Playwright. Ten drugi faktycznie pracuje na kodzie. A to już zbliża usługę do oprogramowania.

Największy błąd? Opisywanie faktur i umów zbyt ogólnie. Hasła typu „usługi IT”, „konsulting informatyczny”, „programowanie” albo „development” nie pomagają przy obronie 8,5%. Jeśli w dokumentach wszystko wygląda jak software development, trudno potem przekonywać, że usługa nie była związana z oprogramowaniem.

Drugi błąd to patrzenie wyłącznie na PKD. PKD służy do określenia rodzaju działalności gospodarczej, ale przy ryczałcie kluczowe jest PKWiU i rzeczywisty zakres usługi. Sam wpis w CEIDG nie „daje” stawki 8,5%. Może co najwyżej pasować albo nie pasować do tego, co faktycznie robisz.

Kiedy można rozważyć stawkę 8,5%

Stawka 8,5% ryczałtu jest możliwa w IT, ale nie dla klasycznego programowania. Najczęściej wchodzi w grę przy usługach, które są informatyczne, lecz nie są bezpośrednio związane z tworzeniem, rozwijaniem lub doradztwem dotyczącym oprogramowania.

W praktyce niższą stawkę można rozważyć przy usługach takich jak:

• wsparcie techniczne IT, jeżeli nie obejmuje doradztwa software’owego,
• administracja wybranymi elementami infrastruktury,
• konfiguracja środowisk bez ingerencji w kod aplikacji,
• monitoring systemów i reagowanie na zgłoszenia,
• helpdesk techniczny,
• testy manualne bez pisania skryptów i bez modyfikowania aplikacji,
• czynności operacyjne, które nie prowadzą do tworzenia ani zmiany oprogramowania.

Nie wystarczy jednak nazwać usługi „supportem”. Jeżeli pod tym supportem kryje się analiza kodu, rekomendowanie zmian w aplikacji, przygotowywanie poprawek albo doradzanie zespołowi developerskiemu, ryzyko 12% wraca natychmiast.

Najprostszy test decyzyjny wygląda tak:

• jeżeli efektem Twojej pracy jest kod, poprawka, funkcjonalność, skrypt albo decyzja techniczna dotycząca software — zakładaj 12%;
• jeżeli efektem jest obsługa, utrzymanie, monitoring, konfiguracja lub pomoc techniczna bez wpływu na kod i projekt oprogramowania — można analizować 8,5%;
• jeżeli robisz jedno i drugie — nie wybieraj jednej stawki „na całość”, tylko rozdziel przychody według rodzaju usług.

To ostatnie jest bardzo ważne. Ryczałt pozwala stosować różne stawki do różnych rodzajów przychodów, ale tylko wtedy, gdy ewidencja przychodów pozwala je rozdzielić. Bez rozdzielenia urząd może potraktować całość według stawki wyższej. Przy usługach mieszanych trzeba więc mieć osobne pozycje na fakturach, jasny opis zakresu prac i ewidencję, która pokazuje, ile przychodu dotyczyło danej usługi.

Przykład praktyczny: specjalista wystawia jedną fakturę za „usługi IT — 20 000 zł”. W miesiącu robił 60% prac developerskich i 40% wsparcia technicznego. Taki dokument jest słaby dowodowo. Znacznie lepiej wygląda faktura z rozbiciem: „rozwój modułu aplikacji” oraz „wsparcie techniczne środowiska”, pod warunkiem że taki podział odpowiada rzeczywistości.

Jak zabezpieczyć niższą stawkę i nie przegrać przy kontroli

Najpierw trzeba ustalić zakres usług, dopiero potem stawkę. Nie odwrotnie. Szukanie argumentów pod gotowe 8,5% to proszenie się o problem, szczególnie gdy umowa z klientem mówi o developmentcie, repozytorium pokazuje commity, a faktury opisują „programowanie”.

Priorytet numer jeden: opis usług w umowie i na fakturach. Powinien być konkretny, ale nie sztucznie podkręcony pod niższą stawkę. Jeżeli wykonujesz support, napisz, czego dotyczy: obsługi zgłoszeń, monitoringu, konfiguracji, utrzymania środowiska, pomocy użytkownikom. Jeżeli piszesz kod, nie udawaj, że to tylko „konsultacje techniczne”.

Priorytet numer dwa: PKWiU. W razie wątpliwości warto zlecić klasyfikację lub przynajmniej dobrze przeanalizować, czy wskazane grupowanie pasuje do faktycznej usługi. Kody typu 62.01.11.0, 62.01.12.0 czy 62.02 często pojawiają się przy usługach związanych z oprogramowaniem lub doradztwem, więc automatyczne przypisanie ich do 8,5% jest ryzykowne. Z kolei niektóre usługi pomocy technicznej mogą być oceniane inaczej, ale tylko wtedy, gdy faktycznie nie zahaczają o doradztwo i software development.

Priorytet numer trzy: interpretacja indywidualna. Kosztuje 40 zł za każdy opisany stan faktyczny lub zdarzenie przyszłe, więc przy rocznej różnicy podatku liczonej w tysiącach złotych to często najtańsze ubezpieczenie. Trzeba jednak opisać rzeczywistość bardzo precyzyjnie. Nie wystarczy napisać: „świadczę usługi IT niezwiązane z oprogramowaniem”. Trzeba pokazać:

• co dokładnie robisz,
• czego nie robisz,
• czy piszesz kod,
• czy modyfikujesz aplikacje,
• czy doradzasz w zakresie oprogramowania,
• jakie są efekty Twojej pracy,
• jak wygląda umowa z klientem,
• jak klasyfikujesz usługę według PKWiU.

Interpretacja chroni tylko w granicach opisanego stanu faktycznego. Jeżeli napiszesz, że nie tworzysz oprogramowania, a później w praktyce regularnie rozwijasz aplikację klienta, ochrona może nie zadziałać. To nie jest magiczna pieczątka na 8,5%. To ochrona dla konkretnego, uczciwie opisanego modelu pracy.

Trzeba też pamiętać o ogólnych warunkach ryczałtu. Przychodu nie pomniejsza się o koszty, więc przy wysokich wydatkach — sprzęt, podwykonawcy, licencje, szkolenia, podróże — ryczałt nie zawsze wygra z podatkiem liniowym. Dochodzą też terminy: wybór ryczałtu zgłasza się zasadniczo do 20. dnia miesiąca po miesiącu uzyskania pierwszego przychodu w roku, a ryczałt wpłaca się miesięcznie albo kwartalnie, jeżeli podatnik spełnia warunki do rozliczeń kwartalnych.

Najbezpieczniejsza kolejność działania jest taka:

1. Spisz realny zakres prac z ostatnich 2–3 miesięcy.
2. Oddziel czynności związane z oprogramowaniem od czynności wsparciowych.
3. Sprawdź, czy faktury i umowa opisują to samo, co faktycznie robisz.
4. Dopasuj PKWiU do konkretnych usług, nie do nazwy stanowiska.
5. Przy 8,5% przygotuj argumentację i rozważ interpretację indywidualną.
6. Przy usługach mieszanych rozdziel przychody w ewidencji i na fakturach.

Jeżeli po tej analizie nadal nie da się jasno powiedzieć, że usługa nie jest związana z oprogramowaniem, rozsądniej przyjąć 12% albo wystąpić o interpretację. Niższa stawka jest atrakcyjna, ale najdroższa bywa wtedy, gdy została zastosowana „bo znajomy programista też tak robi”.

FAQ: ryczałt 12% czy 8,5% dla programisty

Czy programista może płacić 8,5% ryczałtu?
Może tylko w wyjątkowej sytuacji, gdy jego konkretne usługi nie są związane z oprogramowaniem. Przy pisaniu kodu, rozwijaniu aplikacji, poprawianiu błędów i doradztwie software’owym właściwym punktem wyjścia jest 12%.

Czy PKD decyduje o stawce ryczałtu?
Nie. PKD nie przesądza o stawce. Liczy się faktyczny zakres usług i właściwe PKWiU. Sam wpis w CEIDG nie zabezpiecza prawa do 8,5%.

Czy tester może stosować 8,5%?
Tester manualny, który nie pisze skryptów i nie modyfikuje oprogramowania, może mieć argumenty za 8,5%. Tester automatyzujący, który tworzy skrypty testowe lub pracuje na kodzie, ma znacznie większe ryzyko stawki 12%.

Czy można stosować dwie stawki ryczałtu jednocześnie?
Tak, ale trzeba rozdzielić przychody według rodzaju usług. Ewidencja i faktury muszą pokazywać, jaka część przychodu dotyczy 12%, a jaka 8,5%.

Ile kosztuje interpretacja indywidualna w sprawie stawki ryczałtu?
Opłata wynosi 40 zł za każdy odrębny stan faktyczny albo zdarzenie przyszłe. Przy dużej różnicy między 12% a 8,5% zwykle nie warto na tym oszczędzać.

Co sprawdzić jako pierwsze przed przejściem na 8,5%?
Najpierw sprawdź umowę, faktury i rzeczywisty zakres pracy. Jeżeli w dokumentach lub codziennych zadaniach pojawia się kod, rozwój aplikacji, automatyzacja, analiza software albo doradztwo w zakresie oprogramowania, 8,5% robi się ryzykowne.

Jaki błąd trzeba usunąć najpierw?
Najpierw usuń ogólny opis usług. Faktura z jedną pozycją „usługi IT” nie pomaga w obronie niższej stawki. Opis powinien pokazywać konkretną usługę, ale musi być zgodny z tym, co naprawdę zostało wykonane.

Więcej: usługi księgowe Wrocław.