Koszty wdrożenia KSeF w uldze badawczo--rozwojowej – 3 pułapki, które mogą zniweczyć Twoje odliczenia

AKTUALNOŚCI

Wdrożenie KSeF to dla wielu firm konieczność, ale też powód do uporządkowania procesów finansowo-księgowych i automatyzacji. Zasadne zdaje się pytanie: Czy przynajmniej część kosztów da się rozliczyć w uldze B+R? Odpowiedź, jak to u prawników, brzmi – co do zasady tak. I właśnie „nie zawsze” jest tu słowem kluczem. Poniżej trzy najczęstsze pułapki, które widzę w praktyce i które potrafią przekreślić prawo do odliczenia albo je okroić do symbolicznych kwot.

Mylenie wdrożenia compliance z działalnością B+R

KSeF to ramy prawno-techniczne, które należy spełnić. Samo „postawienie” integratora, zakup licencji, konfiguracja, szkolenia użytkowników czy przeniesienie schematów do ERP to standardowe prace wdrożeniowe, ale to w żadnym wypadku nie B+R. Działalność badawczo-rozwojowa zaczyna się tam, gdzie powstaje nowe lub istotnie ulepszone rozwiązanie: autorska warstwa integracyjna, algorytmy walidujące, moduły klasyfikacji dokumentów, mechanizmy odporności na błędne komunikaty, prototypy, iteracje, testy hipotez. Jeśli zespół rozwiązuje realną niepewność techniczną, tworząc wiedzę i artefakty, wtedy możemy mówić o B+R. Jeżeli „odtwarzamy” znane praktyki rynkowe, to wciąż wdrożenie.

Jak zrobić to dobrze i w zgodzie z przepisami?

  • Opisz projekt językiem problemu i ryzyka technicznego („nie wiemy, czy…”, „sprawdzimy hipotezę…”), a nie tylko harmonogramu.
  • Oddziel „wdrożenie” od „rozwoju” – w szczególności budżetowo i organizacyjnie.
  • Zdefiniuj rezultaty B+R (np. repozytorium modułów, prototyp, raport z testów), a nie tylko „uruchomienie KSeF”.

 

Słaba ewidencja i alokacja kosztów

Ulga B+R jest bezwzględna. Brak wyodrębnienia kosztów kwalifikowanych, mieszanie zadań utrzymaniowych z rozwojowymi, rozliczanie całych etatów „z marszu”, a do tego brak dzienników czasu pracy – to prosta droga do utraty odliczeń. Uważaj też na dublowanie preferencji (np. IP Box, ulga na robotyzację) i finansowanie z dotacji – podwójne korzyści (i znowu ten slang prawniczy) co do zasady są zakazane.

Na co warto uważać w praktyce?

  • Wynagrodzenia. Kwalifikuj tylko godziny faktycznie poświęcone na B+R (developerzy, analitycy, architekci, testerzy). Utrzymanie produkcji, helpdesk i szkolenia użytkowników z reguły odpadają.
  • Zakupy i usługi. Materiały do prototypów, narzędzia testowe – tak; „pudełkowe” licencje, typowe usługi wdrożeniowe – co do zasady nie.
  • Amortyzacja i CAPEX. Jeżeli tworzysz własne oprogramowanie, pamiętaj o zasadach dla WNiP i o tym, że do kosztów kwalifikowanych „wpada” część odpowiadająca aktywności B+R.
  • Konflikty preferencji. Nie kumuluj ulg w sposób, który „podwójnie premiuje” ten sam wydatek. Sprawdź, czy dane godziny/koszty nie zostały już wykorzystane w innej preferencji podatkowej.

 

Nieprawidłowy moment i zakres odliczenia

Nawet gdy projekt spełnia definicję B+R, błędy techniczne potrafią sprowadzić odliczenie do zera. Najczęstsze? Zły moment ujęcia kosztu (zwłaszcza przy projektach trwających dłużej niż rok), nieuwzględnienie „nieodliczalne...

TA CZĘŚĆ SERWISU DOSTĘPNA JEST TYLKO DLA PRENUMERATORÓW.

Zaloguj się, aby uzyskać dostęp do materiałów
Zaloguj się

Przypisy