Rozwiązania chmurowe (SaaS – Software as a Service, PaaS – Platform as a Service, IaaS – Infrastructure as a Service) stały się domyślnym wyborem przy budowie i modernizacji środowisk IT. Wraz z ich popularyzacją pojawiają się wątpliwości dotyczące ujmowania wydatków na abonamenty, konfiguracje, migracje danych, integracje i customizacje. Naturalne pytanie biznesu brzmi: czy te koszty możemy aktywować jako wartość niematerialną zgodnie z MSR38, zamiast ujmować je w kosztach okresu? W tym artykule odpowiadamy czy kapitalizacja projektów cloud-based w ujęciu MSR38 jest możliwa.
Dlaczego temat kapitalizacji projektów IT budzi tyle wątpliwości?
W klasycznym modelu „on‑premise” firma nabywa licencję lub wytwarza oprogramowanie, ma pełną kontrolę nad kodem i może wykazać identyfikowalny, kontrolowany zasób generujący przyszłe korzyści ekonomiczne. W chmurze często płacimy za prawo do korzystania z usługi (SaaS), dostęp do platformy (PaaS) albo mocy obliczeniowej (IaaS), a nie za samo oprogramowanie czy kod źródłowy, który staje się własnością jednostki gospodarczej.
W efekcie pojawia się rozbieżność między intencją (projekt rozwojowy IT) a zdolnością do spełnienia kryteriów MSR 38: identyfikowalność, kontrola i przyszłe korzyści. Dodatkowo, koszty chmurowe są rozproszone w budżetach różnych departamentów (IT, operacje, marketing), a ich naturę (badanie vs. rozwój, CAPEX vs. OPEX) trudno jednoznacznie okleić, jeśli nie ma dobrej dokumentacji projektowej.
Co dokładnie mówi MSR38 o wartości niematerialnej?
MSR38 do uznania aktywa za niematerialne i prawne wymaga, aby było ono:
- możliwe do zidentyfikowania (można je odróżnić od innych składników; wynika z umowy lub jest możliwe do oddzielenia),
- kontrolowane przez jednostkę (firma ma możliwość uzyskiwania korzyści i ograniczania dostępu innych),
- generujące przyszłe korzyści ekonomiczne (np. wzrost przychodów, oszczędności kosztowe).
Ponadto, po spełnieniu kryteriów definicji składnika wartości niematerialnych należy także zaspokoić kryteria ujęcia, czyli prawdopodobieństwo korzyści oraz wiarygodny pomiar kosztu wytworzenia/nabycia. W przypadku projektów rozwojowych, standard dopuszcza kapitalizację kosztów po spełnieniu m.in. następujących warunków: możliwość ukończenia, intencja i zdolność do używania/sprzedaży, sposób generowania korzyści, dostęp do zasobów oraz wiarygodny pomiar kosztów. Natomiast koszty etapu badania muszą być ujmowane w kosztach okresu. To rozróżnienie ma kluczowe znaczenie dla projektów IT. Czy zatem kapitalizacja projektów cloud-based w ujęciu MSR38 jest możliwa?
Cloud: SaaS, PaaS, IaaS – co faktycznie kontrolujesz?
SaaS: w tym przypadku płaci się abonament za dostęp do aplikacji dostawcy. Zazwyczaj nie ma tu kontroli kodu ani środowiska, a prawo do korzystania jest nietrwałe (zależne od płatności). W większości przypadków opłaty SaaS są kosztem okresu, a nie aktywem.
PaaS: w tym przypadku korzysta się z platformy do budowy własnych rozwiązań. Jeśli tworzysz własny, identyfikowalny komponent oprogramowania (np. moduł, integrację, algorytm), do którego masz prawa i który można oddzielić od platformy, wtedy może on spełniać kryteria MSR38. Sama opłata za platformę jest zwykle kosztem okresu.
IaaS: w tym przypadku płacimy za najem mocy obliczeniowej i zasobów. To usługa – brak trwałego, odrębnego aktywa niematerialnego po stronie klienta. Koszty są zazwyczaj ujmowane w bieżącym okresie.
Ekspert radzi: Kluczem nie jest to, czy projekt dzieje się ‘w chmurze’, lecz czy firma tworzy własne, identyfikowalne oprogramowanie, nad którym sprawuje kontrolę i które będzie generować mierzalne korzyści.
Jak rozróżnić koszty: badanie vs. rozwój w projektach cloud-based?
Etap badania (research) obejmuje: analizę potrzeb, proof‑of‑concept, porównanie dostawców, testy wykonalności, pilotaże bez trwałych wytworów – ujmuj je w kosztach bieżącego okresu. Etap rozwoju (development) zaczyna się, gdy: zdefiniowano docelowe rozwiązanie, potwierdzono wykonalność, zaprojektowano architekturę i powstaje trwały kod/konfiguracja należąca do firmy. Wtedy część kosztów można kapitalizować, o ile wytwarzany element spełnia wymienione wyżej kryteria.
Projektami spełniającymi warunki kapitalizacji są np. tworzenie własnego oprogramowania (kod) działającego na PaaS, budowa autorskiego modelu scoringowego, rozwój własnego modułu integracyjnego mającego wartość poza konkretną instancją SaaS.
Projekty niespełniające kryteriów MSR38 to m.in. abonamenty SaaS (np. MS Office 365), standardowe konfiguracje narzędzia dostawcy, opłaty za utrzymanie i wsparcie, szkolenia użytkowników, migracje danych o charakterze operacyjnym (bez wytworzenia odrębnego aktywa).
Kontrola i identyfikowalność w chmurze – jak je udowodnić?
Podczas audytu finansowego biegły rewident będzie weryfikował zasadność ujęcia projektu w aktywach niematerialnych. Aby to udowodnić należy gromadzić:
- umowy licencyjne i własności intelektualnej – zapisy o prawach do kodu/rozszerzeń tworzonych przez integratora, nie mogą one zawierać żadnych zapisów ograniczających lub wykluczających separację aktywa, zmianę dostawcy bądź nakładających istotne kary umowne za zmianę dostawcy,
- repozytoria kodu i dokumentację techniczną – nazwy modułów, metadane, wersjonowanie, opis funkcjonalny,
- matrycę przepływu korzyści – jak aktywo generuje przychody/oszczędności (np. skrócenie cyklu obsługi, zmniejszenie kosztów jednostkowych),
- budżet i ewidencję kosztów – rozdział research vs. development, ścieżka kosztów do konkretnych zadań w JIRA/DevOps,
- dowody możliwości oddzielenia – np. test przeniesienia: czy komponent może działać poza konkretną instancją SaaS/PaaS? Czy da się go zreplikować?
Najczęstsze błędy (i jak ich uniknąć?)
Najczęściej spotykanymi w praktyce sprawozdawczej błędami związanymi z projektami chmurowymi są kapitalizacja abonamentów SaaS, mieszanie etapów research z development, brak zapisów umownych gwarantujących prawo do powstałego kodu, tworzenie dokumentacji projektowej post‑factum, a także zbyt długi okres amortyzacji, nieadekwatny do cyklu technologii.
Aby uniknąć powyższych błędów eksperci DBA Finanse pomogą Ci:
- zdefiniować politykę rachunkowości dla obszaru wartości niematerialnych i prawnych,
- stworzyć procedurę opiniowania i ujmowania projektów inwestycyjnych obejmującą: zasady, niezbędną checklistę decyzji o kapitalizacji, roadmapę procesu od biznesu (inicjatora projektu/zmiany) do księgowości (ujęcie, akceptacja wydatków),
- zrozumieć zawiłe i niejednoznaczne wymogi standardu na bazie praktycznych przykładów.
Kapitalizacja kosztów projektów IT to nie tylko kwestia księgowa. To decyzja, która wpływa na obraz firmy w oczach inwestorów i banków – przeszacowane aktywa mogą skończyć się bolesną korektą wyniku w trakcie audytu.
Podsumowanie: podejdź metodycznie, nie technologicznie
Kapitalizacja projektów cloud-based w ujęciu MSR38 jest możliwa jak wskazuje powyższa analiza. To, że projekt dzieje się w chmurze, nie wyklucza kapitalizacji o ile firma tworzy i kontroluje własne, identyfikowalne aktywo przynoszące korzyści. Kluczem do sukcesu jest dokumentacja, podział etapów, prawa IP i miarodajne KPI. Dobrze przygotowana polityka rachunkowości i ścieżka dowodowa sprawią, że decyzja o ujęciu aktywa będzie obroniona zarówno przed audytem, jak i w oczach decydentów wewnętrznych. Najlepszą praktyką jest planowanie księgowe równolegle z planem projektu IT – wtedy rozdział research/development, dowody kontroli i korzyści nie są sztucznie dorabiane po fakcie.
Jeśli wdrażasz projekt chmurowy i chcesz wiedzieć, które koszty możesz kapitalizować – skontaktuj się z nami. Pomożemy Ci sprawić, że proces kapitalizacji stanie się sprawny i przyjemny.
Opis usług znajdziesz w sekcji: Księgowość, Sprawozdania i Konsolidacja
Piotr Druszcz, Partner
Sprawozdawczość i Konsolidacja
druszcz.piotr@dbafinanse.pl