Dotacja na ERP, CRM i aplikacje biznesowe w chmurze: dlaczego licencja to nie jest wdrożenie
Jacek Szafader 2026-09-30 Czytasz:
- Scenariusz, który powtarza się przy każdym naborze
- Fundament: licencja to nie jest wdrożenie
- Dlaczego to rozdzielenie ma znaczenie akurat w dotacji
- Skąd bierze się zamieszanie wokół chmury
- Dwie ścieżki, które opisują regulaminy
- Pytania, które warto zadać dostawcy, zanim powstanie wniosek
- Dokumenty, o które warto poprosić
- Sygnały ostrzegawcze
- Czego dostawca IT nie powinien obiecywać
- Jak do tego podejść
Poradnik dla firm, które przygotowują wniosek o dofinansowanie wdrożenia systemu ERP, CRM lub innej aplikacji biznesowej
Scenariusz, który powtarza się przy każdym naborze
Średnich rozmiarów firma produkcyjna planuje wdrożenie systemu ERP w chmurze, na przykład Microsoft Dynamics 365 Business Central. Równie często w tym samym projekcie pojawia się system CRM do obsługi sprzedaży i serwisu, czyli Microsoft Dynamics 365 Sales albo Dynamics 365 Customer Service, obsługa zgłoszeń klientów w Dynamics 365 Contact Center, aplikacje Power Platform automatyzujące procesy lub funkcje Copilot wspierające pracę zespołów. Program dotacyjny pozwala sfinansować zakup i wdrożenie oprogramowania, więc inwestycja z odległych planów przesuwa się na najbliższy rok. Konsultant zaczyna pisać wniosek i po dwóch dniach przysyła pytanie, które brzmi niewinnie, a potrafi zatrzymać projekt na dwa tygodnie:
Czy subskrypcja chmurowa może zostać ujęta jako wartość niematerialna i prawna?
Za tym pytaniem stoi konkretna obawa dyrektora finansowego. Jeżeli największa pozycja kosztowa projektu okaże się niekwalifikowalna albo zostanie zakwestionowana dopiero przy rozliczeniu grantu, cały rachunek trzeba przeliczyć od nowa. To nie jest nadmierna ostrożność, tylko normalna praca osoby odpowiedzialnej za finanse. Pytanie trafia zwykle do dostawców IT i w tym miejscu pojawia się drugie nieporozumienie: dostawca oprogramowania nie jest ani biegłym rewidentem, ani instytucją oceniającą wniosek, więc nie rozstrzygnie kwalifikacji księgowej. Ma natomiast do przekazania fakty o modelu dostawy i licencjonowania, bez których nikt inny tego pytania nie rozstrzygnie.Fundament: licencja to nie jest wdrożenie
To zdanie brzmi banalnie i jest jednocześnie najczęściej pomijanym elementem całej układanki. W projekcie ERP, CRM czy dowolnej innej aplikacji biznesowej klient płaci za dwie zupełnie różne rzeczy, dwóm różnym podmiotom i na dwóch różnych podstawach. Jedna z nich jest produktem globalnego producenta oprogramowania, druga usługą lokalnego zespołu wdrożeniowego.
Połączenie ich w jedną pozycję oferty bywa wygodne handlowo, bo klient widzi jedną liczbę i jeden podpis. Przy projekcie finansowanym z dotacji jest to jednak najprostsza droga do kłopotów, ponieważ tej jednej liczby nikt później nie rozdzieli. W uproszczeniu podział wygląda tak:
Co obejmuje | Komu klient płaci | Charakter kosztu |
|---|---|---|
Subskrypcje systemu, na przykład Microsoft Dynamics 365 Business Central | Microsoft — zamawiane, aktywowane i fakturowane za pośrednictwem partnera | Opłata za dostęp do usługi w opłaconym okresie subskrypcji, rozliczana za użytkownika |
Wdrożenie, migracja danych, integracje, szkolenia, wsparcie po starcie | Partner wdrożeniowy | Usługa realizowana według harmonogramu projektu i odbierana etapami |
Umowa licencyjna na oprogramowanie chmurowe wiąże klienta bezpośrednio z producentem. W przypadku aplikacji Microsoft — Dynamics 365 Business Central, Dynamics 365 Sales, Dynamics 365 Contact Center, Power Platform czy Microsoft 365 Copilot — jest to Microsoft Customer Agreement i partner nie jest jej stroną. Partner występuje jako autoryzowany sprzedawca: subskrypcję zamawia, uruchamia i fakturuje, ale nie tworzy jej warunków i nie może ich dowolnie zmieniać. To jest ta część budżetu, którą klient płaci producentowi za pośrednictwem partnera.
Wdrożenie jest czymś zupełnie innym. To praca zespołu: analiza procesów, konfiguracja systemu, migracja danych, integracje, testy, uruchomienie produkcyjne, szkolenia użytkowników i wsparcie po starcie. Za to klient płaci partnerowi wdrożeniowemu, na podstawie odrębnej umowy, z własnym harmonogramem i własnymi odbiorami. Licencja bez wdrożenia jest pustym dostępem, a wdrożenie bez licencji nie ma czego konfigurować, ale to nadal dwie różne usługi.
Dlaczego to rozdzielenie ma znaczenie akurat w dotacji
Ponieważ każdy z tych elementów może być inaczej traktowany przy kwalifikowaniu kosztów, a niektóre z nich wykraczają poza okres kwalifikowalności. Subskrypcja biegnie dalej po zakończeniu projektu. Wdrożenie kończy się z odbiorem. Wsparcie zaczyna się dopiero po starcie produkcyjnym. Jeżeli wszystko to jest jedną kwotą na jednej fakturze, nikt — ani księgowość, ani instytucja — nie rozdzieli tego po fakcie.
Rozdzielenie pozycji nie jest więc zabiegiem kosmetycznym w ofercie. To warunek, żeby wniosek dało się napisać, a później obronić przy rozliczeniu. Zasada działa identycznie niezależnie od tego, co firma wdraża: system ERP w rodzaju Microsoft Dynamics 365 Business Central, CRM oparty na Dynamics 365 Sales, obsługę zgłoszeń w Dynamics 365 Customer Service lub Dynamics 365 Contact Center, aplikacje niskokodowe na Power Platform czy licencje Copilot. Za każdym razem firma kupuje osobno subskrypcję od producenta i osobno pracę zespołu wdrożeniowego. Różnica bywa jedynie w proporcjach: przy Business Central najcięższą pozycją jest zwykle wdrożenie i migracja danych, przy Copilocie czy Power Platform więcej waży sama subskrypcja.
Skąd bierze się zamieszanie wokół chmury
Przez dwadzieścia lat zakup systemu wyglądał tak samo. Kupowało się licencję, licencja była aktywem, aktywo się amortyzowało. Model chmurowy tego schematu nie odwzorowuje. W modelu SaaS, w którym sprzedawana jest dziś większość aplikacji biznesowych, nie nabywa się egzemplarza oprogramowania, tylko prawo dostępu do usługi na czas opłaconego okresu. Nie ma nośnika, nie ma wersji „na zawsze”, nie ma przeniesienia autorskich praw majątkowych ani prawa do modyfikacji kodu.
Regulaminy programów dotacyjnych zdążyły to zauważyć i zwykle opisują oba przypadki osobno: technologię cyfrową w formie wartości niematerialnej i prawnej oraz korzystanie z oprogramowania traktowane na równi z zakupem usługi. To dwie różne ścieżki rozliczenia, z różnymi konsekwencjami dla budżetu i dla okresu trwałości projektu. O tym, która z nich ma zastosowanie, decyduje treść umowy i sposób ujęcia księgowego, a nie nazwa produktu w ofercie.
Dwie ścieżki, które opisują regulaminy
Poniższy opis jest mapą pojęć, a nie interpretacją. Każdy nabór ma własny regulamin i to on jest wiążący, a rozstrzygnięcie należy do księgowości wnioskodawcy oraz instytucji prowadzącej nabór.
Oprogramowanie jako wartość niematerialna i prawna
W tym wariancie oprogramowanie musi spełniać warunki uznania za wartość niematerialną i prawną w rozumieniu ustawy o rachunkowości: stanowić aktywo wnioskodawcy, podlegać amortyzacji i pozostawać związane z projektem zwykle do końca okresu trwałości. Regulaminy dopuszczają tu licencję długoterminową lub bezterminową. We wniosku trzeba wówczas opisać charakter licencji, czyli czy jest wyłączna czy niewyłączna, a także zakres terytorialny, pola korzystania, zasady rozliczeń z dostawcą i planowany okres użytkowania technologii. To wariant naturalny dla licencji wieczystej instalowanej lokalnie, na przykład ERP w wersji on-premises.
Oprogramowanie chmurowe traktowane jak usługa
Jeżeli subskrypcja nie spełnia warunków uznania za wartość niematerialną i prawną, korzystanie z niej bywa traktowane na równi z zakupem usługi. Konsekwencja jest istotna dla budżetu: do kosztów kwalifikowalnych wchodzi wtedy zwykle wyłącznie koszt korzystania z systemu przypadający na okres kwalifikowalności, a opłaty po zakończeniu projektu firma finansuje ze środków własnych. Sam system powinien natomiast zwykle być użytkowany do końca okresu trwałości, żeby rezultaty projektu zostały zachowane.
Standardowe aplikacje biznesowe sprzedawane w modelu chmurowym odpowiadają drugiemu wariantowi. Dotyczy to zarówno systemu ERP, jak Microsoft Dynamics 365 Business Central Online, jak i rozwiązań CRM w rodzaju Dynamics 365 Sales, obsługi klienta w Dynamics 365 Contact Center, aplikacji zbudowanych na Power Platform czy licencji Copilot. Nie jest to wada ani przeszkoda, tylko inny sposób liczenia. Kłopot pojawia się dopiero wtedy, gdy wniosek zakłada pierwszy wariant, a umowa realizuje drugi. Jeżeli ujęcie jako wartość niematerialna i prawna jest warunkiem koniecznym, jedyną technicznie realną ścieżką bywa wersja instalowana lokalnie z licencją wieczystą — inny model, inna struktura kosztów i inne konsekwencje operacyjne, które warto wycenić porównawczo, zanim zapadnie decyzja.
Pytania, które warto zadać dostawcy, zanim powstanie wniosek
Zanim konsultant zacznie pisać, warto mieć od potencjalnych dostawców odpowiedź na kilka rzeczy. Każdą z nich da się rozstrzygnąć w jednym mailu, a odpowiedzi przydadzą się także przy porównywaniu ofert.
- W jakim modelu licencjonowania sprzedawany jest system i kto jest stroną umowy licencyjnej.
- Czy licencja jest wyłączna czy niewyłączna, na jaki okres i na jakim terytorium.
- Czy oferta rozdziela koszt licencji, wdrożenia, szkoleń i wsparcia na osobne pozycje.
- Czy okres subskrypcji można zsynchronizować z okresem realizacji projektu.
- Które prace kończą się wraz z odbiorem wdrożenia, a które są kosztem cyklicznym po starcie.
- Jakie dokumenty dostawca jest w stanie podpisać na potrzeby rozliczenia dotacji.
Dokumenty, o które warto poprosić
Dobrze przygotowany dostawca aplikacji biznesowych powinien być w stanie przedstawić komplet, który konsultant dołączy do wniosku, a księgowość wykorzysta przy rozliczeniu.
- Ofertę z rozbiciem na pozycje: subskrypcje i licencje, wdrożenie, szkolenia, wsparcie.
- Odrębną umowę wdrożeniową oraz odrębne zamówienie licencyjne.
- Harmonogram wdrożenia z jednoznacznie wskazanym okresem realizacji i etapami odbioru.
- Faktury wystawiane z wyodrębnionymi pozycjami, a nie jedną kwotą zbiorczą.
- Pisemne potwierdzenie modelu licencjonowania i warunków subskrypcji: zakresu uprawnień, liczby użytkowników, okresu i charakteru licencji.
Sygnały ostrzegawcze
Kilka rzeczy powinno zapalić lampkę ostrzegawczą jeszcze przed podpisaniem umowy.
- Jedna pozycja w ofercie brzmiąca „wdrożenie systemu wraz z licencjami”.
- Dostawca, który bez żadnych zastrzeżeń potwierdza na piśmie kwalifikację księgową kosztu.
- Brak wskazanego okresu subskrypcji albo brak dat granicznych wdrożenia.
- Wsparcie powdrożeniowe wliczone w cenę wdrożenia bez wyodrębnienia wartości.
Czego dostawca IT nie powinien obiecywać
Uczciwa odpowiedź dostawcy na pytanie o wartość niematerialną i prawną brzmi mniej więcej tak: przedstawiamy fakty o modelu dostawy oraz dokumenty, które te fakty potwierdzają, a kwalifikację księgową rozstrzyga Państwa księgowość lub audytor, natomiast kwalifikowalność kosztu — instytucja prowadząca nabór. Dostawca, który deklaruje więcej, bierze na siebie odpowiedzialność, której nie jest w stanie unieść, a ryzyko i tak zostaje po stronie beneficjenta.
Dlatego w projektach dotacyjnych warto zachować kolejność: najpierw jasny opis modelu i rozdzielone pozycje, potem decyzja księgowa po stronie klienta, na końcu opis we wniosku. Odwrotna kolejność kończy się korektą na etapie rozliczenia.
Jak do tego podejść
Nie zaczynać od pytania, czy to wartość niematerialna i prawna. Zacząć od rozłożenia projektu na części: co jest produktem producenta oprogramowania, co usługą partnera wdrożeniowego, co kończy się z odbiorem, a co biegnie dalej po starcie. Dopiero na tak rozłożonym projekcie księgowość i konsultant są w stanie podjąć decyzję, a dostawca potwierdzić ją dokumentami.
Jeżeli planują Państwo wdrożenie systemu ERP, CRM lub innej aplikacji biznesowej finansowane z dotacji i potrzebują oferty rozdzielonej w sposób, który obroni się przy rozliczeniu, chętnie usiądziemy do tego razem z Państwa konsultantem. Pracujemy na co dzień z Microsoft Dynamics 365 Business Central, Dynamics 365 Sales i Contact Center, Power Platform oraz Copilot, więc możemy pokazać strukturę kosztów na konkretnym przykładzie. To zwykle rozmowa na godzinę, która oszczędza tygodnie korekt.