W drugim odcinku Podcastu z cyklu “jak pomogliśmy naszym klientom odzyskać podatek z ulgi na działalność B+R”, w rozmowie z Mateuszem Latkowskim, doradcą podatkowym, partnerem w Gardens Tax & Legal, tym razem opowiemy o pracy dla klienta z branży software house.
W nagraniu Mateusz opowiada między innymi o:
Kluczowych aspektach kwalifikacji działań do B+R:
- Jak odróżnić prace B+R od standardowych działań IT?
- Dlaczego to takie trudne w wirtualnym świecie IT i jak oceniać ryzyko projektów?
Kosztach pracowników zaangażowanych w prace rozwojowe:
- Kto jest brany pod uwagę i jak dokładnie ewidencjonować ich czas pracy?
- Jakie są problemy z różnorodnymi podejściami organów podatkowych do obliczania kosztów?
Materiałach, surowcach oraz środkach trwałych i WNiP-y:
- Co można uwzględnić do ulgi B+R w branży IT?
- Jakie wydatki są zazwyczaj zerowe, a kiedy można uwzględnić zakup sprzętu lub licencji?
Dokumentacji niezbędnej do wykazania działalności B+R:
- Jakie etapy tworzenia oprogramowania trzeba zidentyfikować i opisać?
- Dlaczego warto mieć ewidencję prac B+R i jak to ułatwia przyszłe rozliczenia?
Przygotowaniu do kontroli i czynności sprawdzających:
- Jakie dokumenty przekazywać urzędowi skarbowemu?
- Jakie są najlepsze praktyki w przygotowaniu do kontroli?
Korzyściach płynących z ulgi B+R:
- Jak ulga B+R może pomóc firmie w cięciu kosztów, zatrudnieniu specjalistów i budowaniu poduszki finansowej na przyszłość?
Jeśli chcesz sprawdzić czy Twojej firmie przysługuje ulga podatkowa na działalność B+R, wypełnij krótki formularz kontaktowy, klikając przycisk poniżej.
Transkrypcja
Michał Wilk: Dzień dobry, Mateuszu.
Mateusz Latkowski: Cześć, Michał.
Witam Cię ponownie po niedługiej przerwie. Niedawno widzieliśmy się w kontekście ulgi B+R, w kontekście której widzimy się ponownie dzisiaj po to, żeby opowiedzieć o przykładowym projekcie doradczym, projekcie wdrożeniowym, który przeprowadziliśmy dla firmy z branży produkcyjnej. A dzisiaj, tak jak zapowiadaliśmy, wedle bardzo podobnego schematu, chciałbym, żebyśmy przeszli przez kluczowe punkty, kluczowe elementy takiego procesu doradczego, ale dla firmy z branży IT. A konkretnie, precyzyjnie rzecz ujmując dla firmy wytwarzającej oprogramowanie dla software house’u. Wedle tego schematu powiedziałem – tzn. powiemy sobie o kwalifikacji działalności do działalności badawczo-rozwojowej, o kosztach, pracownikach, materiałach, surowcach, środkach trwałych, o kwestiach dokumentacyjnych i wreszcie o kontroli podatkowej. Więc zacznijmy może od jakiejś krótkiej charakterystyki, z czym ten nasz przykładowy klient do nas przyszedł i jak wyglądało szukanie działalności badawczo-rozwojowej właśnie w tej branży?
Od razu przechodząc do rzeczy – klient ten zajmował się programowaniem. To był typowy software house, to jest typowy software house. Zajmuje się tworzeniem aplikacji webowych, sieciowych. Ale gdyby tworzył aplikacje mobilne, to również byłby w naszej sferze zainteresowania. Wydaje mi się, że on wpisuje się w taki typowy software house, czyli w związku z tą sferą swojej aktywności zatrudniał cały zespół osób specjalistów IT różnego rodzaju. Jakich? No to sobie przejdziemy. Właściwie niemalże 100% działalności tego podmiotu to było tworzenie i rozwój takiego produktu wirtualnego.
Tak jak sobie mówiliśmy przy produkcji, to od czego zaczęliśmy, to rozmowa, taki look na to, co ten klient robi i jak on to robi, jak jest zorganizowane, to właściwie tutaj mamy to samo na wstępie, bo my wiemy o kliencie tyle, ile on nam powiedział. Wiemy tyle, ile wyczytaliśmy na stronie i zwykle te strony będą, bo akurat ta branża, trudno sobie wyobrazić firmę IT bez strony. Tyle wiemy. Weszliśmy do tego klienta, zaczęliśmy rozmawiać, poznaliśmy cały proces, który rządzi powstaniem tego oprogramowania. Poznaliśmy etapy, w jakich to się dzieje i zidentyfikowaliśmy, kto przy tym pracuje. Dokonaliśmy oceny, które z tych elementów mają walor prac badawczo-rozwojowych, a które są zbyt ryzykowne.
Może warto od razu powiedzieć, że inaczej niż w wypadku produkcji, ten biznes, o którym mówimy dzisiaj, to jest biznes, którego nie da się dotknąć. Nie widać go. Maszynę możesz sobie przyjść, zobaczyć. Ona istnieje. Możesz zrobić jej zdjęcie. Program to co to jest? To są te przysłowiowe zera i jedynki, które gdzieś tam sobie wiszą w tym wirtualu. Z tym wiąże się szereg wyzwań w tego typu projektach. Pokusiłbym się o stwierdzenie, że one też mogą być przez to mniej zrozumiałe, mniej uchwytne dla urzędnika.
Tym większa waga jest tego naszego raportu, który przygotowujemy przed wystąpieniem.
Dokładnie, za tym stoją konkretne wyzwania, które z tym są związane. Teraz, kiedy my już zidentyfikowaliśmy te obszary prac badawczo-rozwojowych, to musieliśmy przejść do kosztów. Tak jak przy produkcji powiedzieliśmy sobie o tych poszczególnych grupach kosztów. Tutaj oczywiście pracujemy na tym samym przepisie, bo to żadnej różnicy nie ma. Przepis nie różnicuje jak jesteś IT, to masz koszty takie, jak produkcja to koszty takie. Więc to jest tak naprawdę nasze zadanie, żeby sobie te koszty wyłuskać.
Zaczęlibyśmy pewnie od kosztów osobowych, tak jak i poprzednio, bo właściwie te są zdecydowanie w IT kosztami największymi, najpoważniejszymi. Dlaczego? Pracujemy na wiedzy, informacji. Wiedza i informacje to są ludzie i tak naprawdę bez tych ludzi tego oprogramowania nie będzie. Więc w typowym takim software housie chyba się nie pomylę, jeśli powiem, że niemalże całe koszty to będą koszty osobowe, to będą koszty ludzi. To od razu uwaga. Wiemy, że w różnych modelach działają software house’y na rynku. Jeśli będziemy mieć software house, który pracuje w oparciu o filozofię B2B, że ci programiści, developerzy, testerzy itd. są na B2B, nie na umowie o pracę, to możemy mieć świetne, piękne działanie badawczo-rozwojowe jako obszar i zero kosztów kwalifikowanych i tamtej ulgi nie rozpoznamy.
U naszego klienta zespół był mieszany i to jest zresztą częsty przypadek, że będzie część zespołu na B2B, część na umowie o pracę i tam warto się zawsze pochylić nad tą ulgą, bo wiemy, jak zarabia się w IT. Zarabia się dobrze, nawet mimo jakiegoś tąpnięcia, które gdzieś było na rynku, w związku z czym też ten poziom kosztów kwalifikowanych jest wysoki. A pamiętajmy, znowu mówiliśmy o tym, ale warto wspomnieć, że mamy 200% tych kosztów kwalifikowanych od 2022 roku. Wchodząc już bardziej na poziom szczegółów, trzeba rozdzielić sobie ten proces badawczo-rozwojowy na etapy i zobaczyć, kto przy tym pracuje u tego klienta i generalnie w software house’ach to będzie cały szereg różnych różnych stanowisk. Będą programiści, bardziej developerzy, czyli osoby, które piszą kod i one właściwie wykonują jedną z istotniejszych prac, żeby to działało.
Będą testerzy, będą backendowcy, frontendowcy, mogą być project managerowie, scrum masterzy. Tak naprawdę to wszystko zależy od organizacji, ale niezależnie od firmy, to w wielu firmach generalnie to się powtarza. Filozofia pracy jest podobna i również etapowanie tych prac jest podobne, więc trzeba sobie zidentyfikować czy ten dany człowiek, programista, developer – instynktownie czujemy, że on będzie wykonywał multum tej pracy twórczej. Tutaj będziemy łapać ten jego czas, jego zaangażowanie i jego koszt. Testerzy pewnie też. No bo nie wypuścimy tego na rynek czy do klienta, jeśli to nie działa, jeśli powoduje jakieś bugi itd. Frontendowcy, backendowcy – trzeba się zastanowić na ile ten wkład jest ich twórczy i czy to można uwzględnić. Tak jak w produkcji, nie zawsze będziemy mieć specyficzną ewidencję czasu pracy, tak jednak w IT jest pewnym standardem, że te ewidencje są. Wiele firm pracuje na zasadzie time and materials i oni ten czas ewidencjonują. To nie jest tylko ewidencja na zasadzie od 8 do 16 jestem w pracy tylko od 8 do 11 robiłem to, od 11 do 12:15 itd.
To ułatwia. Ale inną sprawą jest to, że nie wszędzie jest ten proces zunifikowany i czasem mogą być to ewidencje, ale jeden developer wpisze tę samą czynność tak, drugi wpisze inaczej. To może być wyzwanie, żeby to zidentyfikować. Gdyby to było proste do zrobienia, to pewnie byśmy o tym nie rozmawiali. Zadanie nasze polega na tym, żeby zidentyfikować te czynności, zaproponować pewne ujednolicenia na przyszłość, bo to porządkuje wiele rzeczy. Więc w tej sferze osobowej można powiedzieć tak to wygląda. Tych kosztów szukamy, te koszty łapiemy.
Drugi punkt, o którym rozmawialiśmy poprzednio, to były materiały i surowce, takie absolutnie oczywiste dla branży produkcyjnej. Przy software house’ach. to niespecjalnie ich tutaj będziemy szukać.
Niespecjalnie będziemy szukać. Czy kojarzymy jakiś software house, który miałby magazyn? Raczej nie. To jest jednak biznes oparty o wiedzę i bardziej taki wirtualny, a nie pracujący na towarach, produktach. Ale można wyszukać gdzieś tam np. komputery. Powiedzmy taki nisko cenny sprzęt, który nie będzie środkiem trwały, może w pewnych przypadkach być traktowany jako materiały, surowce. Trochę więcej może tego być, jeśli byśmy rozmawiali np. o takim przemysłowym IT. Ktoś pracuje w takiej automatyce, robotyce. To nie jest czysto IT, nie jest do końca czysta produkcja. To coś pomiędzy. Tam rzeczywiście te materiały i surowce mogą być, ale zostawmy to.
Trzeci punkt, wydawałoby się też mało istotny może być, ale musimy go poszerzyć. Bo przypomnę trzeci punkt to były środki trwałe. O nich mówiliśmy przy okazji produkcji, te maszyny itd. No ale przecież tutaj mówimy o środkach trwałych, które też zakładam, że znajdziemy w IT, ale też wartości niematerialne i prawne. I tutaj już troszkę więcej.
No dokładnie, jeśli chodzi o środki trwałe, to mogą być jakieś serwery, wysoko cenne elementy, ale raczej rzadko kiedy się to zdarza. Mogą być natomiast licencje. Możemy pracować na licencjach i jeśli te licencje będziemy mieć na wartościach niematerialnych i prawnych, bo nie zawsze tak jest, to powiemy, że są różne modele udostępniania programów. Jeśli kupujemy co roku dostęp to nam nie wejdzie na te WNiP-y przysłowiowe, nie będziemy mieć tych odpisów amortyzacyjnych, to nas nie będzie interesować, ale takie, które mamy amortyzowane jak najbardziej. One mogą stanowić nasz koszt kwalifikowany. Tu oczywiście możemy znowu stanąć przed wyzwaniem, czy ten program to jest w całości wykorzystywany do procesu badawczo-rozwojowego? A jak nie, to jak złapać tę część kosztu, która jest związana z procesem badawczo-rozwojowym? Trochę jak przy środkach trwałych w produkcji. Musimy szukać jakiegoś modelu alokacji. To da się zrobić. A czasem, jeśli nie jesteśmy w stanie tego rozpoznać, to trzeba z tego zrezygnować. Praktyka jednak pokazuje, że to nie są jakieś koszty, które robią istotną różnicę, więc czasem łatwiej je pogrzebać i zostawić.
Tutaj ten akcent chyba będzie głównie przesunięty na ten element osobowy, na tych developerów, nie tylko pracowników.
Dokładnie tak. Tak samo nie będziemy mówić o kosztach jakichś jednostek naukowych, aparatury specjalistycznej, bo to nie jest ten biznes. Mówimy o tym biznesie nieuchwytnym. I tu bardzo ważna jest dokumentacja.
Dokumentacja, dlatego że o wadze tej dokumentacji dość szczegółowo już mówiłeś w poprzednim odcinku. Natomiast już tu zaznaczyłeś, że ta mniejsza uchwytność efektów tego biznesu polegającego na wytworzeniu oprogramowania i być może trudniejsze zrozumienie tych procesów na zewnątrz dla osoby, która kontrolowała by taką ulgę sprawia, że ten raport, czy w ogóle szerzej ta dokumentacja jest ważniejsza.
Tak, tu stajemy przed tak naprawdę wieloma wyzwaniami. Łatwo się mówi: firma tworzy oprogramowanie. Tylko że najczęściej to jest tak, że np. mamy jedno stworzone oprogramowanie wiele lat temu i tak naprawdę zespół pracuje, dodaje funkcjonalności. Nad tym pracują różne zespoły, pracują niezależnie od siebie, dodają mniejsze, większe klocki. Nie zawsze to da się ładnie wyodrębnić na pierwszy rzut oka, więc też to jest wyzwanie, żeby to odpowiednio opisać, przedstawić, ale także ocenić. Bo przecież to, co my dodajemy do istniejącego programu, wcale niekoniecznie musi być taką czystą pracą rozwojową. To może być jakaś rutynowa, okresowa zmiana, jakaś przysłowiowa łatka, coś się wysypie, to się naprawia. To nie jest praca rozwojowa, ale już dodanie jakiejś nowej funkcjonalności, jakiegoś modułu wirtualnej obsługi klienta, zgłaszania problemu itd. To trzeba odsiać, oddzielić ziarno od plew, że tak powiem i odpowiednio to opisać w dokumentacji. To jest jedno wyzwanie.
Drugie wyzwanie: rzeczywiście to jest tak, że ten świat IT jest dosyć specyficzny. To jest specyficzny język, specyficzna filozofia pracy. Istnieje pewna dokumentacja, ale to trzeba bardzo mocno przełożyć na ten język. Chyba bardziej nawet niż w produkcji. Trzeba gdzieś to przełożyć na ten ludzki język po to, żeby ten urzędnik miał szansę trochę sobie to wyobrazić, no bo tego nie dotknie, to już ustaliliśmy. Ale żeby mógł sobie wyobrazić jak to zostało zrobione.
Ma być łatwiej, nie trudniej. Na tym nam zależy.
Dokładnie tak. Kolejny problem: firmy IT bardzo mocno chronią swoje know-how, swoją tajemnicę przedsiębiorstwa. Nic dziwnego, one z tego żyją. Żyją z tej wiedzy, która jest nieuchwytna. Umówmy się: łatwiej wynieść wiedzę, niż wynieść półtonową maszynę, która jest na magazynie. W związku z tym to też w praktyce widać pewien opór przed udostępnieniem tego nawet nam ekspertom. Oczywiście, przecież jeśli by doszło do twardej kontroli urzędu skarbowego, nawet nie związanej z ulgą na działalność badawczo-rozwojową, to przecież ta firma nie powie: nie przekażę ci, urzędzie skarbowy, dokumentu, bo boję się o wyciek tajemnicy przedsiębiorstwa. No to urzędnik powie: mamy tajemnicę skarbową, dawajcie co macie albo będzie kara porządkowa, albo KKS wam zrobimy.
Jest taka bariera mentalna i tym też trzeba jakoś zarządzić. Tym też trzeba jakoś zarządzić i odpowiednio rozmawiać z klientem, odpowiednio też ostrożnie konstruować dokumentację na potrzeby ewentualnej przyszłej kontroli czy czynności sprawdzających. W tej dokumentacji też musimy odseparować ten proces badawczo-rozwojowy od nie badawczo-rozwojowego, np. mamy całą sferę maintenance produktu, którą trzeba wyłączyć, opisać, dlaczego to wyłączyliśmy. W tej dokumentacji oczywiście istotną jej częścią będzie ta ewidencja czasu pracy. U klienta bardzo często funkcjonuje ewidencja czasu pracy. Trzeba ją też skroić pod potrzeby dokumentacyjne ulgi na działalność badawczo-rozwojową.
Tutaj, podobnie jak w produkcji, bo procedury są jednolite, nie ma tutaj żadnej różnicy. Występujemy o ulgę, czy to w postaci złożenia zeznania podatkowego, to mówimy o uldze na przyszłość, czy na bieżąco, bądź też korekty zeznania podatkowego. Tu mówimy o odzyskiwaniu nadpłaconego, jak się okazuje, podatku wstecz. No i spodziewamy się czynności sprawdzających, jakiejś formy weryfikacji tej ulgi. Bo tak jak już mówiłeś w poprzednim odcinku dotyczącym produkcji, z zeznania podatkowego wynikają nagie liczby. Urzędnik musi poznać, co stoi za tą ulgą, za tymi liczbami. Temu służy cała ta dokumentacja, raporty, które tworzymy itd. Powiedz może, jak mogą wyglądać takie czynności sprawdzające właśnie w odniesieniu do software house’ów? Jak to wyglądało u tego naszego modelowego klienta?
Początek tych czynności właściwie niczym się nie różni, bo urząd dysponuje rozeznaniem. Tak jak powiedziałeś ma kwoty. Więc o co zapyta? Podatniku, co robiłeś w ramach prac badawczo-rozwojowych i jakie koszty poniosłeś? Tak naprawdę również na wstępie ten nasz sposób działania jest bardzo podobny. Na etapie czynności sprawdzających my jesteśmy w sytuacji, w której mamy już ten projekt badawczo-rozwojowy przeprocesowany po naszej stronie, mamy do niego przygotowaną dokumentację i ta dokumentacja tak naprawdę jest tym najistotniejszym elementem i tym, co my przedkładamy do urzędu.
Zwykle nie dajemy od razu wszystkiego. Dlaczego? Po pierwsze dlatego, żeby nie zarzucić tego urzędnika nadmiarem wiedzy, a po drugie dlatego, że w ramach czynności sprawdzających często wystarczy przedstawienie, nie chcę powiedzieć ogólnych opisów, bo jednak dosyć szczegółowo staramy się opisywać te projekty, ale pokazanie co ja robiłem. Przełożenie tego na język ludzki w tym raporcie czy nawet kartach projektów wraz z wyliczeniem tak naprawdę tych kosztów. A te koszty, uprośćmy, mówimy o kosztach osobowych, bo bardzo często innych nie będzie akurat w tej sferze, to będzie dokumentacja płacowa przełożona tak naprawdę na jakiś tam współczynnik wynikający z godzin pracy B+R. To są dane, które są dla urzędnika oczywiste. Tutaj nie ma jakieś większej filozofii. Wystarczy zrobić matematykę i to wyjdzie. Bardzo często na tym te czynności sprawdzające się kończą.
Tak jak i w produkcji, my zawsze musimy liczyć się z tym, że to zostanie później sprawdzone w ramach kontroli podatkowej, celno-skarbowej czy postępowania podatkowego. Dokumentacja, również ta, która już była wykorzystana w czynnościach sprawdzających, ona musi być na poziomie tej firmy, musi czekać. Ta dokumentacja jest też o tyle ważna, że przecież nam zespół będzie rotować. To może być tak, że ktoś pracował 3 lata temu, dzisiaj już nie pracuje. A jak my nie mamy spisanego tego co on robił w jakiś taki ludzki sposób, to możemy już do tego po czasie nie dotrzeć.
No dobrze, to chyba zamyka nam temat. Bardzo dziękuję Ci za to dzisiejsze spotkanie.
Dziękuję.
Na pewno jeszcze do tematu ulgi badawczo-rozwojowej wrócimy. Do zobaczenia.
Do zobaczenia!
Jeśli zajmujesz się zawodowo podatkami – w szczególności prowadzisz biuro rachunkowe, jesteś doradcą podatkowym lub radcą prawnym bądź adwokatem – dołącz do Klubu Dzień Dobry Podatki.
Klub to abonament na comiesięczne szkolenia „Dzień Dobry Podatki” oraz forum dyskusyjne, na którym codziennie wspieramy się w pracy z podatkami.
Sprawdź więcej szczegółów TUTAJ.