Firma IT może mieć bardzo dobry system ewidencji czasu pracy programistów, szczegółowe zadania w Jira i repozytorium pełne commitów, a mimo to nie mieć bezpiecznych podstaw do stosowania podwyższonych kosztów. 50% koszty uzyskania przychodu dla programistów nie wynikają bowiem z nazwy stanowiska ani z samego faktu pisania kodu. Trzeba połączyć rezultat twórczy, prawa autorskie, honorarium i dokumentację.
Problem dotyczy przede wszystkim firm zatrudniających programistów i innych specjalistów IT, które chcą prawidłowo skonstruować zasady wynagradzania twórców. Dla pracodawcy ma to znaczenie nie tylko podatkowe, ale też kadrowo-płacowe: sposób zapisania praw w umowie, identyfikowania utworów i naliczania honorarium powinien tworzyć jeden spójny proces.
Stan prawny: 25 sierpnia 2026 r.
50% KUP można stosować do autorskiej części wynagrodzenia programisty tylko wtedy, gdy powstaje chroniony utwór, prawa są odpowiednio uregulowane, honorarium wyodrębnione, a firma potrafi wykazać konkretny rezultat.
Cztery pytania przed wdrożeniem 50% KUP
Dopiero odpowiedź na wszystkie cztery pozwala ocenić, czy model wynagradzania programisty jest spójny podatkowo i prawnoautorsko.
-
1Czy rzeczywiście powstaje utwór?
Nie każda czynność techniczna, poprawka lub godzina pracy nad projektem tworzy rezultat chroniony prawem autorskim.
-
2Komu przysługują prawa do programu?
W przypadku programu pracowniczego działa szczególna reguła z art. 74 ust. 3 prawa autorskiego, dlatego umowę trzeba czytać inaczej niż przy typowym utworze pracowniczym.
-
3Za co wypłacane jest honorarium?
Część autorska wynagrodzenia powinna pozostawać w związku z konkretnym utworem lub utworami określonymi rodzajowo, a nie wyłącznie z nazwą stanowiska.
-
4Czy firma potrafi to udowodnić?
Ewidencja czasu może być pomocna, ale powinna łączyć czas twórczy z rzeczywiście tworzonym lub stworzonym rezultatem.
Kiedy 50% koszty uzyskania przychodu dla programistów mogą być stosowane?
Podwyższone koszty mogą dotyczyć przychodu twórcy z korzystania z praw autorskich lub rozporządzania tymi prawami, jeżeli przychód mieści się w katalogu działalności wskazanym w ustawie o PIT. Katalog obejmuje między innymi działalność twórczą w zakresie programów komputerowych. Samo zatrudnienie na stanowisku developer, software engineer czy tester nie przesądza jednak o prawie do 50% KUP.
50% KUP dla programisty to podatkowy sposób ustalenia kosztów dotyczących kwalifikowanego przychodu autorskiego, a nie ulga przyznawana całemu zawodowi IT. Ministerstwo Finansów wskazuje, że dla honorarium autorskiego potrzebne są przede wszystkim: powstanie utworu, obiektywne dowody jego stworzenia oraz wyraźne wyodrębnienie honorarium od pozostałych składników wynagrodzenia. Interpretacja ogólna Ministra Finansów nr DD3.8201.1.2018 opisuje te warunki szczegółowo.
Z perspektywy pracodawcy nie należy więc zaczynać od pytania „jaki procent pensji objąć 50% KUP?”. Najpierw trzeba ustalić, jakie rezultaty pracy powstają, czy są chronione prawem autorskim, jaki jest mechanizm nabywania praw i jak firma będzie dokumentować honorarium.
Co w pracy programisty może być utworem?
Utworem jest rezultat działalności twórczej o indywidualnym charakterze, ustalony w jakiejkolwiek postaci. Ustawa o prawie autorskim wprost wymienia programy komputerowe, ale ochronie podlega sposób wyrażenia, a nie same idee, procedury, metody czy zasady działania. Oznacza to, że ocena powinna dotyczyć konkretnego rezultatu pracy, a nie ogólnego procesu „tworzenia oprogramowania”.
Nie każda praca wykonana przez programistę jest automatycznie utworem. Rutynowa konfiguracja, odtwórcza zmiana parametru, wykonanie instrukcji technicznej albo powtarzalne czynności utrzymaniowe mogą nie wykazywać twórczego i indywidualnego charakteru. Z kolei nowa funkcjonalność, oryginalna struktura kodu czy twórcze rozwiązanie konkretnego problemu mogą taki charakter mieć, jeżeli spełniają przesłanki prawa autorskiego.
To rozróżnienie jest ważne również wtedy, gdy zespół pracuje w Scrumie i każda aktywność ma osobny ticket. Sam ticket nie jest dowodem, że powstał utwór. Może jednak stać się częścią dokumentacji, jeżeli wskazuje rezultat, autora, okres pracy, powiązanie z repozytorium i sposób akceptacji rezultatu.
Kto ma prawa do programu stworzonego przez pracownika?
W przypadku programu komputerowego stworzonego przez pracownika obowiązuje szczególna zasada. Art. 74 ust. 3 ustawy o prawie autorskim stanowi, że prawa majątkowe do programu stworzonego w wyniku wykonywania obowiązków ze stosunku pracy przysługują pracodawcy, o ile umowa nie stanowi inaczej. Jest to istotna różnica wobec ogólnej reguły dotyczącej utworów pracowniczych.
Zgodnie z interpretacją ogólną MF, gdy działa ustawowa reguła pierwotnego nabycia praw do programu przez pracodawcę, programista nie korzysta z tych praw ani nimi nie rozporządza. W takim modelu nie powstaje honorarium autorskie, do którego można zastosować 50% KUP.
Ta kwestia jest jednym z najważniejszych punktów całego wdrożenia. Minister Finansów wyjaśnił jednocześnie, że art. 74 ust. 3 ma charakter dyspozytywny: pracownik i pracodawca mogą w umowie uregulować prawa inaczej. Jeżeli strony wprowadzą model, w którym prawa najpierw przysługują programiście, a następnie są nabywane przez pracodawcę za odpowiednim wynagrodzeniem, może powstać przychód autorski objęty 50% kosztami po spełnieniu pozostałych warunków.
Nie wystarczy więc dodać do umowy zdania, że „pracownik przenosi wszystkie prawa autorskie”. Postanowienia powinny odpowiadać faktycznemu modelowi powstawania utworów, chwili nabycia praw oraz sposobowi ustalania honorarium. W przypadku firmy, która chce wdrożyć taki system dla większej grupy pracowników, warto analizować razem umowy, regulamin wynagradzania, proces akceptacji utworów i naliczanie list płac.
Jak wyodrębnić honorarium autorskie programisty?
Honorarium autorskie powinno być odróżnione od wynagrodzenia za pozostałe obowiązki pracownicze i powiązane z utworem. Interpretacja ogólna MF dopuszcza zarówno wskazanie konkretnej kwoty honorarium, jak i metodę procentową, ale procent nie może działać w oderwaniu od rzeczywistych rezultatów twórczych.
Największym ryzykiem jest stały zapis typu „70% wynagrodzenia stanowi honorarium autorskie”, jeżeli firma nie potrafi wykazać, jakie utwory w danym okresie powstały lub były tworzone. Sam procent czasu przeznaczonego na „pracę kreatywną” również nie wystarcza. Powinien istnieć związek pomiędzy czasem, konkretnym utworem i sposobem wyliczenia honorarium.
Programista backendowy w jednym miesiącu tworzy nowy moduł autoryzacji, wykonuje rutynowy support oraz uczestniczy w spotkaniach organizacyjnych. Firma nie zakłada z góry, że wszystkie te aktywności są pracą autorską.
Nowy moduł zostaje zidentyfikowany w ewidencji jako konkretny rezultat, powiązany z zadaniem i repozytorium oraz zaakceptowany zgodnie z procedurą firmy. Jeżeli umowa prawidłowo reguluje nabycie praw, a honorarium jest wyliczone na podstawie przyjętej metody odnoszącej się do tego rezultatu, można oceniać zastosowanie 50% KUP do części autorskiej wynagrodzenia.
Praktyczny wniosek: procent wynagrodzenia nie powinien być punktem wyjścia. Najpierw trzeba zidentyfikować rzeczywisty utwór i prawny mechanizm rozporządzenia prawami, a dopiero potem ustalać honorarium.

Ewidencja czasu czy ewidencja utworów – co trzeba naprawdę udokumentować?
Sama ewidencja czasu pracy nie daje bezpiecznej podstawy do 50% KUP, jeżeli pokazuje wyłącznie liczbę godzin oznaczonych jako „twórcze”. Minister Finansów wskazał, że dokumentacja powinna pozwalać ustalić, jaki konkretnie utwór powstał lub powstawał, a czas pracy może służyć do kalkulacji honorarium wtedy, gdy jest z takim utworem powiązany.
Firma nie ma jednego ustawowego formularza „ewidencji utworów”. Dokumentacja może mieć formę elektronicznej bazy, odrębnej ewidencji, zaakceptowanego raportu, oświadczenia albo procesu zbudowanego z kilku istniejących narzędzi. Ważniejsza od nazwy dokumentu jest jego zawartość oraz możliwość odtworzenia związku pomiędzy pracownikiem, utworem, przyjęciem rezultatu i honorarium.
Ewidencja utworów dla 50% KUP powinna identyfikować rezultat, a nie tylko aktywność. Oświadczenie „pracownik wykonywał w tym miesiącu pracę twórczą” jest za słabe, jeżeli nie wskazuje, co powstało. Z kolei wpis zawierający nazwę lub opis utworu, autora, okres pracy, identyfikator zadania lub repozytorium oraz potwierdzenie przyjęcia tworzy znacznie bardziej użyteczny ślad dowodowy.
Jeżeli firma już używa Jira, Azure DevOps, GitLab, GitHub lub podobnego systemu, nie musi automatycznie budować drugiej równoległej ewidencji od zera. Najpierw warto sprawdzić, czy obecny obieg można uzupełnić o identyfikację autora, rezultatu i akceptacji, a następnie połączyć z dokumentacją kadrowo-płacową.

Macierz kwalifikacji pracy programisty do 50% KUP
Poniższa macierz nie rozstrzyga automatycznie, że dana czynność jest albo nie jest utworem. Pokazuje, jakie pytania należy zadać przy typowych zadaniach w zespole IT. Ostateczna ocena zależy od rzeczywistego rezultatu, stopnia twórczości, indywidualnego charakteru, zasad nabycia praw i dokumentacji.
| Rodzaj pracy | Co może być rezultatem? | Co sprawdzić? | Przydatny dowód | Główne ryzyko |
|---|---|---|---|---|
| Nowa funkcjonalność lub moduł | Kod i struktura rozwiązania o indywidualnym charakterze | Czy rezultat jest twórczy i możliwy do wyodrębnienia | Ticket, merge request, repozytorium, akceptacja | Automatyczne uznanie całego czasu projektu za twórczy |
| Implementacja algorytmu | Oryginalny sposób wyrażenia rozwiązania w kodzie | Czy wykonawca miał realną swobodę twórczą | Opis rozwiązania, kod, wersja, akceptacja | Mylenie chronionego sposobu wyrażenia z samą ideą lub metodą |
| Refaktoryzacja | Nowa, indywidualna struktura fragmentu programu | Zakres zmian i stopień kreacyjności | Porównanie wersji, pull request, opis celu | Traktowanie każdej refaktoryzacji jako utworu |
| Poprawa błędu | Nowy fragment kodu, jeżeli ma twórczy charakter | Czy zmiana była odtwórcza, czy wymagała twórczego rozwiązania | Bug ticket, commit, opis rozwiązania | Uznawanie każdej drobnej poprawki za utwór |
| Testy automatyczne | Kod testów spełniający samodzielnie cechy utworu | Czy rezultat ma indywidualny charakter, a nie jest szablonem | Kod testów, zadanie, akceptacja | Utożsamienie samego testowania z działalnością autorską |
| Dokumentacja techniczna | Oryginalny materiał tekstowy lub graficzny | Czy dokument ma twórczy i indywidualny charakter | Wersja dokumentu, autor, data przyjęcia | Traktowanie formularzy i szablonów jako utworów |
| Code review | Ewentualny odrębny twórczy materiał powstały podczas review | Czy powstał samodzielny chroniony rezultat | Komentarze, propozycje zmian, odrębny rezultat | Rozliczanie samej czynności kontrolnej jako utworu |
| Konfiguracja, deployment, support | Tylko rezultat, który sam spełnia cechy utworu | Czy praca nie jest wyłącznie techniczna lub rutynowa | Opis rezultatu, jeżeli rzeczywiście powstał | Włączanie czynności utrzymaniowych do stałego procentu twórczego |
| Analiza i spotkania projektowe | Ewentualny odrębny materiał twórczy, nie sama idea | Czy ustalono rezultat w chronionej formie | Dokument analityczny, specyfikacja, diagram | Przypisywanie ochrony prawnoautorskiej samym pomysłom i dyskusjom |
Jak połączyć utwór, honorarium i listę płac?
Bezpieczniejszy proces nie zaczyna się w dziale płac, lecz wcześniej – w dokumentacji zatrudnienia i w obiegu pracy zespołu IT. Lista płac jest końcowym etapem, na którym firma wykorzystuje informacje o honorarium, ale nie powinna być miejscem, w którym dopiero „tworzy się” uzasadnienie dla kosztów autorskich.
Określ rodzaje prac, które mogą prowadzić do powstania utworów. Oddziel je od zadań rutynowych, administracyjnych i utrzymaniowych.
Sprawdź umowy o pracę pod kątem art. 74 ust. 3 prawa autorskiego i faktycznego mechanizmu nabywania praw do programów.
Powiąż utwory z pracownikiem, okresem, zadaniem, repozytorium lub innym śladem oraz momentem przyjęcia przez pracodawcę.
Wybierz metodę zgodną z umową i rzeczywistym przebiegiem pracy. Jeżeli korzystasz z czasu pracy, musi on pozostawać w związku z konkretnymi utworami.
Dopiero na tej podstawie nalicz odpowiednie koszty w liście płac i kontroluj limit roczny oraz spójność danych z dokumentacją.
Przy większym zespole warto ustalić odpowiedzialność za każdy etap. Manager techniczny może potwierdzać rezultat, HR przechowywać dokumentację umowną, a dział płac naliczać koszty na podstawie zatwierdzonych danych. Taki podział ogranicza sytuacje, w których księgowość otrzymuje wyłącznie procent bez informacji, z jakiego utworu on wynika. W tym obszarze pomocne jest połączenie procesu podatkowego z bieżącą obsługą kadr i płac.
Jaki jest limit 50% KUP w 2026 roku?
W 2026 r. łączne 50% koszty uzyskania przychodów z tytułów objętych ustawowym limitem nie mogą przekroczyć 120 000 zł w roku podatkowym. Limit dotyczy kwoty kosztów, a nie samego przychodu autorskiego. Oficjalne informacje Ministerstwa Finansów potwierdzają tę wartość dla dochodów z pracy i praw autorskich. Zasady rozliczania dochodów z pracy na podatki.gov.pl.
50% koszty oblicza się od kwalifikowanego przychodu pomniejszonego o potrącone przez płatnika składki na ubezpieczenia społeczne, których podstawę wymiaru stanowi ten przychód. Jeżeli pracownik korzysta z ulgi dla młodych, ulgi na powrót, ulgi dla rodzin 4+ albo ulgi dla pracujących seniorów, należy dodatkowo pilnować ustawowego wspólnego limitu 120 000 zł dla wskazanych przychodów zwolnionych i 50% kosztów.
W praktyce oznacza to, że dział płac powinien kontrolować limit narastająco. Firma nie powinna zakładać, że raz skonfigurowane 50% KUP będzie naliczane identycznie przez wszystkie miesiące roku bez kontroli kwot i zmian w sytuacji pracownika.
50% KUP, IP Box i koszty firmy IT to trzy różne mechanizmy
50% KUP nie należy utożsamiać z IP Box ani ze zwykłymi kosztami podatkowymi przedsiębiorcy. Podwyższone koszty autorskie odnoszą się do kwalifikowanego przychodu twórcy, natomiast IP Box dotyczy dochodu z kwalifikowanych praw własności intelektualnej przy spełnieniu odrębnych warunków. Z kolei klasyczne koszty działalności firmy IT dotyczą wydatków ponoszonych w celu osiągania, zachowania lub zabezpieczenia przychodów.
Programista rozliczający działalność B2B nie powinien przenosić na swoje przychody firmowe modelu z listy płac pracownika. W takim przypadku trzeba analizować zasady właściwe dla działalności gospodarczej, a przy spełnieniu warunków również IP Box dla programisty. Odrębnie należy kwalifikować koszty firmowe w branży IT, takie jak sprzęt, oprogramowanie czy usługi związane z działalnością.
Gdzie najczęściej rozpada się model 50% KUP?
Najczęstszy problem nie polega na braku jednego dokumentu, ale na niespójności kilku elementów. Umowa może mówić o honorarium, ewidencja rejestrować tylko czas, a lista płac stosować stały procent niezależnie od tego, co faktycznie powstało. Każdy z tych dokumentów wygląda poprawnie osobno, ale razem nie pokazują logicznego łańcucha od utworu do przychodu autorskiego.
Sygnały wymagające ponownego sprawdzenia
Jeżeli któryś z poniższych punktów występuje w firmie, model 50% KUP warto przeanalizować przed kolejną listą płac.
-
✓
Umowa nie uwzględnia szczególnej reguły praw do programu komputerowego z art. 74 ust. 3.
-
✓
Stały procent honorarium jest naliczany bez wskazania konkretnych utworów lub ich kategorii.
-
✓
Ewidencja pokazuje wyłącznie godziny pracy twórczej, ale nie identyfikuje rezultatów.
-
✓
Do czasu twórczego automatycznie zaliczane są support, spotkania, wdrożenia lub rutynowe poprawki.
-
✓
Dział płac nie otrzymuje informacji pozwalających zweryfikować kwotę honorarium i limit 120 000 zł.
-
✓
Dokumentacja kadrowa, projektowa i techniczna opisuje różne zasady przyjęcia rezultatu lub nabycia praw.
Usunięcie tych niespójności ma praktyczną korzyść dla obu stron stosunku pracy. Pracownik otrzymuje czytelne zasady ustalania części autorskiej wynagrodzenia, a pracodawca dysponuje dokumentacją, która pozwala wyjaśnić sposób naliczenia PIT. Nie daje to automatycznej gwarancji braku sporu, ale istotnie porządkuje podstawy rozliczenia.
Co firma powinna sprawdzić przed pierwszym naliczeniem 50% KUP?
Przed wdrożeniem nie należy zaczynać od ustawienia parametru w programie kadrowo-płacowym. Najpierw trzeba sprawdzić umowy i zakres obowiązków, następnie rodzaje rezultatów twórczych, sposób ich identyfikacji, mechanizm praw autorskich oraz metodę ustalania honorarium. Dopiero spójny model powinien trafić do naliczania wynagrodzeń.
W większych organizacjach dobrze działa krótki pilotaż na jednej grupie stanowisk. Pozwala sprawdzić, czy managerowie potrafią rzeczywiście identyfikować rezultaty, czy ewidencja nie staje się dodatkowym formularzem bez wartości dowodowej oraz czy dane trafiają do płac w odpowiednim terminie. Dla stanowisk granicznych można rozważyć odrębną ocenę prawno-podatkową zamiast mechanicznego obejmowania całego działu jednym modelem.
Jeżeli firma dopiero projektuje system, warto też ustalić procedurę okresowego przeglądu. Zmieniają się role w zespole, typy projektów i zakres obowiązków, dlatego model odpowiedni dla developera tworzącego nowe moduły nie musi pasować do osoby, której praca po kilku miesiącach koncentruje się na utrzymaniu, wdrożeniach albo wsparciu użytkowników.
Art. 22 ust. 9, 9a i 9b ustawy o podatku dochodowym od osób fizycznych określa zasady 50% kosztów, limit oraz katalog działalności obejmujący programy komputerowe. Aktualny tekst jednolity ustawy o PIT w ELI.
Art. 1 oraz art. 74 ustawy o prawie autorskim i prawach pokrewnych regulują pojęcie utworu, ochronę programów komputerowych oraz szczególną zasadę dotyczącą praw do programu pracowniczego. Tekst ustawy o prawie autorskim w ELI.
Interpretacja ogólna Ministra Finansów z 15 września 2020 r., nr DD3.8201.1.2018, wyjaśnia warunki stosowania 50% KUP do honorarium autorskiego, dokumentowanie utworów oraz szczególną sytuację programistów. Wykaz interpretacji ogólnych Ministerstwa Finansów.
Podsumowanie – 50% KUP w firmie IT trzeba zbudować jako cały proces
50% koszty uzyskania przychodu dla programistów mogą być wartościowym elementem systemu wynagradzania, ale ich stosowanie nie powinno opierać się na nazwie stanowiska, stałym procencie ani samej ewidencji czasu. Punktem wyjścia jest rzeczywisty utwór, a następnie prawidłowo uregulowane prawa, honorarium i dokumentacja.
W branży IT szczególnej uwagi wymaga art. 74 ust. 3 prawa autorskiego. Domyślne nabycie praw do programu przez pracodawcę działa inaczej niż przy typowym utworze pracowniczym, a Minister Finansów wprost odniósł tę różnicę do możliwości stosowania kosztów autorskich. To właśnie ten element powinien zostać przeanalizowany przed skonfigurowaniem rozliczenia w płacach.
mdoFinanse może pomóc uporządkować księgowo-kadrową stronę procesu: sprawdzić, jakie dane powinny trafiać do listy płac, jak kontrolować limit oraz jak połączyć dokumentację pracowniczą z bieżącym rozliczeniem PIT. Przy modelach obejmujących prawa autorskie warto równolegle zadbać o prawidłową konstrukcję prawną umów.
Sprawdź, jak mdoFinanse wspiera firmy technologiczne w bieżącej księgowości i rozliczeniach związanych z zespołem.




