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...

Pozostałe 70% treści dostępne jest tylko dla Prenumeratorów

Co zyskasz, kupując prenumeratę?
  • 6 papierowych oraz cyfrowych wydań magazynu
  • Dostęp online do aktualnych i archiwalnych wydań czasopisma oraz dostęp do dodatkowych materiałów
  • Nielimitowane konsultacje
  • ...i wiele więcej!

Jeśli jesteś Prenumeratorem, zaloguj się, aby przeczytać artykuł w całości.

Przypisy