Gamedev i usługi kreatywno-produkcyjne: jak kontrola rozróżnia design, assety, integrację i „elementy oprogramowania” w praktyce dowodowej

04.05.2026

Gamedev i usługi kreatywno-produkcyjne: jak kontrola rozróżnia design, assety, integrację i „elementy oprogramowania” w praktyce dowodowej

Kontrola celno-skarbowa to formalne działania organów Krajowej Administracji Skarbowej służące weryfikacji, czy przedsiębiorca prawidłowo wywiązuje się z obowiązków podatkowych i celnych, w tym w zakresie rozliczeń usług niematerialnych, licencji oraz wytwarzania i przenoszenia praw do elementów gier. W branży gamedev spór zwykle nie dotyczy „czy usługa była”, tylko „czym była” w sensie dowodowym i prawnopodatkowym: usługą kreatywną, dostawą assetów, integracją techniczną czy wytworzeniem elementu oprogramowania.

W praktyce to rozróżnienie wpływa na ryzyka: kwalifikację przychodu i kosztu, zasady dokumentowania, obowiązki w VAT (w tym miejsce świadczenia), ryzyka w WHT przy płatnościach transgranicznych, a także odpowiedzialność członków zarządu za rozliczenia (w tym na gruncie KKS). Materiał ma charakter informacyjny i nie stanowi porady prawnej.

Dlaczego organ rozbija „gamedev” na design, assety, integrację i oprogramowanie

Organ nie bada projektu gry w kategoriach artystycznych, tylko rekonstruuje fakty: co dokładnie zostało wytworzone, przekazane i na jakich prawach. W postępowaniach dowodowych typowe jest „odklejenie” etykiet z umowy (np. „game development services”) od tego, co wynika z ticketów, repozytoriów, buildów, pipeline’u i rozliczeń godzinowych.

W uproszczeniu kontrola szuka odpowiedzi na pytania:

• czy rezultat ma postać utworu (grafika, animacja, muzyka, narracja) czy kodu, czy kombinacji;
• czy przeniesiono autorskie prawa majątkowe, udzielono licencji, czy tylko wykonano usługę bez transferu praw;
• czy doszło do stworzenia „elementów oprogramowania” (np. skrypty, narzędzia, moduły) i kto jest ich właścicielem;
• czy wynagrodzenie dotyczy pracy (time & material) czy efektu (deliverables), i jak to skorelowano z dokumentacją.

Design: koncepcja, dokumentacja i ryzyko „niematerialności” bez śladu

Design (game design, level design, UX) bywa kwalifikowany jako usługa kreatywno-koncepcyjna, której rezultatem są dokumenty: GDD, makiety, flow, scenariusze, specyfikacje. W kontroli problemem jest, że „kreatywność” bywa rozliczana godzinowo, a dowody są rozproszone.

Ryzyka praktyczne:

• zakwestionowanie kosztu jako niedostatecznie udokumentowanego (brak przypisania do projektu, brak akceptacji deliverable);
• spór o to, czy wynagrodzenie obejmuje przeniesienie praw autorskich do dokumentacji i koncepcji (a jeśli tak, to na jakich polach eksploatacji);
• przy transgranicznych płatnościach ryzyko kwalifikacji części wynagrodzenia jako należności licencyjnych, co może uruchamiać analizę WHT (zależnie od stanu faktycznego i umów o UPO).

Assety: grafika, animacje, audio i „deliverable-first” w praktyce dowodowej

Assety (modele 3D, tekstury, rig, animacje, UI, muzyka, SFX) są najczęściej „namacalne” dowodowo: pliki, paczki, wersjonowanie, check-listy. Organ zwykle oczekuje, że przedsiębiorca potrafi powiązać fakturę z konkretną listą assetów, datą przekazania i akceptacją jakości.

W tej kategorii powtarza się problem praw do bibliotek i materiałów zewnętrznych (stock, marketplace, AI): kto ponosi ryzyko naruszeń, czy licencje dopuszczają komercjalizację, sublicencjonowanie i dystrybucję w grze. Brak „łańcucha praw” może prowadzić do sporów nie tylko podatkowych, ale też reputacyjnych i kontraktowych.

Integracja i implementacja: kiedy „usługa” zaczyna wyglądać jak „oprogramowanie”

Integracja (np. implementacja assetów do silnika, ustawienie shaderów, konfiguracja pipeline’u, optymalizacja, przygotowanie buildów) bywa opisywana jako usługa techniczna. Jednak w praktyce kontrola sprawdza, czy częścią wynagrodzenia nie jest wytworzenie kodu lub narzędzi, czyli „elementów oprogramowania”.

Dowodowo istotne są: commity w repozytorium, pull requesty, przeglądy kodu, dokumentacja techniczna, logi CI/CD, a także to, kto miał dostęp i kontrolę nad repozytorium. Jeżeli wykonawca wytwarza moduł i przekazuje go jako gotowy komponent, organ może badać, czy to nadal „usługa”, czy w praktyce dostarczenie elementu software’u wraz z prawami.

„Elementy oprogramowania”: co organ zwykle uznaje za przesądzające

Pod pojęciem „elementów oprogramowania” w gamedev najczęściej mieszczą się: skrypty gameplay, narzędzia edytorowe, pluginy, integracje SDK, systemy monetizacji, rozwiązania sieciowe, a także narzędzia automatyzujące pipeline. Kwalifikacja prawna nie wynika z nazwy, tylko z treści świadczenia i praw.

W postępowaniach dowodowych przesądzające bywają:

• postanowienia o przeniesieniu praw lub licencji do kodu oraz o polach eksploatacji;
• zapisy o prawach do modyfikacji, tworzenia utworów zależnych, sublicencjonowania i dystrybucji;
• faktyczna niezależność komponentu (czy działa jako odrębny moduł, czy jest tylko drobną konfiguracją);
• model rozliczeń: „za moduł” vs „za godzinę wsparcia”;
• praktyka akceptacji: protokoły odbioru, testy, definicja „done”.

Dokumenty i artefakty, które „robią robotę” w kontroli

W gamedev wiarygodność podatkowa często zależy od jakości ścieżki audytowej. Najczęściej organ oczekuje spójności między umową, fakturą i „śladami pracy”. Praktyczne minimum dowodowe obejmuje:

1. Umowy i zamówienia: zakres, deliverables, zasady praw autorskich/licencji, pola eksploatacji, zasady korzystania z third-party.
2. Załączniki produkcyjne: backlog, specyfikacje, listy assetów, milestone’y, kryteria odbioru.
3. Dowody przekazania i akceptacji: protokoły, e-maile, tickety z decyzją, linki do paczek, podpisy lub akceptacje w narzędziach.
4. Repozytoria i pipeline: logi commitów, release notes, tagi wersji, CI/CD.
5. Spójność rozliczeń: timesheety przypięte do zadań, a zadania do projektu i faktury.

Odpowiedzialność zarządu: ryzyka finansowe, karne-skarbowe i ciągłość działania

Po stronie spółki typowe konsekwencje to doszacowania, odsetki i sankcje administracyjne, a także wielomiesięczne koszty obsługi postępowań. Po stronie osób zarządzających ryzyko zależy od roli, procedur i reakcji na sygnały o nieprawidłowościach. Faktem jest, że Kodeks karny skarbowy przewiduje odpowiedzialność za przestępstwa i wykroczenia skarbowe w razie naruszeń obowiązków podatkowych; ocena zawsze zależy od stanu faktycznego i winy.

W realiach gamedev krytyczne jest zabezpieczenie ciągłości działania: kontrola celno-skarbowa może żądać przedstawienia dowodów i dokumentów związanych z przedmiotem kontroli, w tym danych przechowywanych w systemach informatycznych, co bywa realizowane przez żądania udostępnienia lub przekazania danych (np. eksportów z narzędzi takich jak Jira, Slack, Git). Brak przygotowania zwiększa ryzyko chaosu dowodowego i niezamierzonych niespójności.

Jak przygotować firmę: praktyczny „compliance” dla usług kreatywno-produkcyjnych

Skuteczne przygotowanie nie polega na „ładnych umowach”, tylko na powtarzalnym procesie dowodowym. W praktyce warto wdrożyć:

• matrycę kwalifikacji świadczeń: kiedy coś jest designem, assetem, integracją, a kiedy elementem software’u;
• standard odbioru: protokół lub workflow akceptacji w narzędziu, zawsze powiązany z fakturą;
• zasady praw IP: minimalne klauzule o przeniesieniu praw/licencjach, third-party i AI, plus kontrola pól eksploatacji;
• politykę repozytoriów: dostęp, uprawnienia, archiwizacja, retencja logów, eksport na wypadek żądań organu;
• przeglądy okresowe: losowa weryfikacja 5–10 faktur pod kątem dowodów (umowa, deliverable, akceptacja, ślad pracy).

W razie wszczęcia postępowania kluczowe jest szybkie uporządkowanie materiału dowodowego i spójna narracja: co dostarczono, kiedy, na jakich prawach i jak to się łączy z rozliczeniem. Wsparcie doradcze zwykle obejmuje również plan komunikacji wewnętrznej, aby ograniczyć ryzyka reputacyjne.

W sprawach, gdzie w grę wchodzą rozliczenia usług gamedev i spór o kwalifikację deliverables w toku kontroli celno-skarbowej, Kopeć & Zaborowski może przeprowadzić analizę dowodową umów i artefaktów produkcyjnych oraz wskazać realistyczne scenariusze obrony, dlatego w razie potrzeby warto skorzystać z opcji: Skontaktuj się z nami.

FAQ: Gamedev i usługi kreatywno-produkcyjne: jak kontrola rozróżnia design, assety, integrację i „elementy oprogramowania” w praktyce dowodowej

1) Czy nazwa usługi na fakturze („game development”) wystarcza?

Zwykle nie. Organ ocenia treść świadczenia i dowody wykonania. Etykieta jest wtórna wobec ticketów, repozytorium, list assetów i zasad przeniesienia praw.

2) Co najczęściej przesądza, że mamy do czynienia z „elementem oprogramowania”?

Najczęściej: powstanie kodu lub narzędzia możliwego do wyodrębnienia, zasady przeniesienia praw/licencji do kodu oraz sposób odbioru (testy, release, tagi). Ocena zależy od stanu faktycznego.

3) Jakie dowody są najbardziej przekonujące dla assetów?

Pakiety plików z wersjonowaniem, lista assetów powiązana z zamówieniem, protokoły odbioru/akceptacji, a także ślady przekazania (linki, logi wysyłki, repo LFS).

4) Czy timesheety mogą być jedynym dowodem wykonania designu?

To ryzykowne. Timesheet powinien być spięty z konkretnymi deliverables: dokumentacją, makietami, decyzjami projektowymi, wersjami plików i akceptacją przez zamawiającego.

5) Czy ryzyka dotyczą tylko podatków?

Nie. Braki w „łańcuchu praw” do assetów i kodu mogą prowadzić do sporów kontraktowych, problemów z wydawcą, a także ryzyk reputacyjnych, niezależnie od wątku podatkowego.

6) Kiedy warto robić audyt wewnętrzny przed kontrolą?

Przy częstych rozliczeniach z podwykonawcami, pracy transgranicznej, wykorzystywaniu third-party assetów lub gdy model rozliczeń miesza deliverables i time & material. Audyt powinien koncentrować się na ścieżce dowodowej i prawach IP.

Bibliography

[1] Ustawa z dnia 16 listopada 2016 r. o Krajowej Administracji Skarbowej (t.j. Dz.U. z 2024 r. poz. 863, z późn. zm.).

[2] Ustawa z dnia 29 sierpnia 1997 r. – Ordynacja podatkowa (t.j. Dz.U. z 2025 r., z późn. zm.).

[3] Ustawa z dnia 10 września 1999 r. – Kodeks karny skarbowy (t.j. Dz.U. z 2024 r., z późn. zm.).

[4] Ustawa z dnia 4 lutego 1994 r. o prawie autorskim i prawach pokrewnych (t.j. Dz.U. z 2025 r., z późn. zm.).

[5] Dyrektywa Rady 2006/112/WE z dnia 28 listopada 2006 r. w sprawie wspólnego systemu podatku od wartości dodanej.

[6] Rozporządzenie wykonawcze Rady (UE) nr 282/2011 z dnia 15 marca 2011 r. ustanawiające środki wykonawcze do dyrektywy 2006/112/WE.

Jeżeli w danej sprawie potrzebna jest weryfikacja, jak organ może zakwalifikować design, assety, integrację i kod na podstawie realnych dowodów projektowych, najlepiej rozpocząć od przeglądu dokumentacji i artefaktów produkcyjnych, dlatego: Skontaktuj się z nami.