Programista na B2B nie wystawia „faktury za pracę”. Wystawia dokument za konkretną usługę: development, utrzymanie systemu, konsultacje, analizę, testy, integrację API, audyt kodu albo wsparcie zespołu. To drobna różnica językowa, ale w praktyce ważna. Od opisu usługi, statusu VAT, kraju klienta i zapisów w kontrakcie zależy, czy na dokumencie pojawi się 23% VAT, adnotacja o zwolnieniu z VAT, informacja o odwrotnym obciążeniu, czy zwykła faktura sprzedażowa wystawiona w KSeF.
Najczęstszy błąd? Traktowanie każdej faktury tak samo. Przy jednym kliencie w Polsce to zwykle działa przez jakiś czas. Problem zaczyna się wtedy, gdy programista łapie kontrakt z firmą z Niemiec, wystawia fakturę dla software house’u z USA, przechodzi na VAT albo miesza usługi programistyczne z konsultingiem. Wtedy księgowość pyta o szczegóły, a kontrahent potrafi odesłać dokument do poprawy, bo brakuje jednego oznaczenia.
Faktura VAT, faktura bez VAT i rachunek — co naprawdę wystawia programista
Programista prowadzący jednoosobową działalność gospodarczą wystawia przede wszystkim faktury, a nie „rachunki” w potocznym rozumieniu. Rachunek może jeszcze pojawiać się w rozmowach z klientami, ale w działalności gospodarczej standardem jest faktura: z VAT albo bez VAT, zależnie od statusu przedsiębiorcy.
Najprostszy podział wygląda tak:
- faktura VAT — dla programisty zarejestrowanego jako czynny podatnik VAT;
- faktura bez VAT — dla przedsiębiorcy korzystającego ze zwolnienia z VAT;
- faktura eksportowa lub dla kontrahenta zagranicznego — gdy klient ma siedzibę poza Polską;
- faktura korygująca — gdy trzeba poprawić kwotę, dane, zakres usługi albo stawkę;
- faktura zaliczkowa — gdy programista otrzymuje część zapłaty przed wykonaniem usługi;
- faktura końcowa — gdy wcześniej była zaliczka, a po zakończeniu etapu trzeba rozliczyć całość.
Jeżeli programista jest czynnym podatnikiem VAT i świadczy usługę dla polskiej firmy, najczęściej wystawia fakturę ze stawką 23% VAT. Przykład jest prosty: wynagrodzenie netto z kontraktu wynosi 20 000 zł, więc na fakturze pojawia się 20 000 zł netto, 4 600 zł VAT i 24 600 zł brutto. Dla kontrahenta będącego VAT-owcem nie zawsze jest to problem, bo zwykle może odliczyć VAT. Dla klienta zwolnionego z VAT albo osoby prywatnej cena brutto staje się jednak realnym kosztem.
Programista korzystający ze zwolnienia podmiotowego z VAT wystawia fakturę bez doliczonego VAT. To rozwiązanie bywa wygodne na początku działalności albo przy mniejszych przychodach, ale ma twardy limit: co do zasady zwolnienie dotyczy sprzedaży do 200 000 zł rocznie. Po przekroczeniu limitu zwolnienie traci moc od czynności, którą ten limit przekroczono. To nie jest moment na spokojne „ogarnę później”. Trzeba pilnować przychodów narastająco, zwłaszcza przy wysokich miesięcznych stawkach.
Przy kontrakcie B2B w IT limit można przekroczyć szybko. Stawka 18 000 zł miesięcznie daje 216 000 zł w skali roku. Przy takim poziomie przychodów zwolnienie z VAT może skończyć się jeszcze przed grudniem. Jeżeli programista podpisuje kontrakt na 20 000–25 000 zł miesięcznie i startuje od stycznia, decyzja o rejestracji do VAT nie jest teorią — to raczej kwestia zaplanowania jej z księgowym zanim pojawi się błąd na fakturze.
Opis usługi na fakturze powinien być konkretny, ale nie przesadnie techniczny. Dobre przykłady:
- Usługi programistyczne — rozwój aplikacji webowej za maj 2026
- Utrzymanie i rozwój systemu backendowego zgodnie z umową B2B
- Konsultacje IT oraz analiza techniczna modułu płatności
- Implementacja integracji API w projekcie e-commerce
Słabe przykłady to „usługa”, „praca IT”, „programowanie” bez kontekstu albo opis niezgodny z umową. Dlaczego to ma znaczenie? Bo opis faktury powinien pasować do kontraktu, ewidencji przychodów, stawki ryczałtu oraz rzeczywiście wykonanej usługi. Jeżeli w umowie jest tworzenie oprogramowania, a na fakturze pojawia się „doradztwo strategiczne”, księgowość może mieć uzasadnione pytania.
Kontrakt B2B z polską firmą, klientem z UE i spoza UE — jak dobrać dokument
Najłatwiejszy przypadek to polski klient i polski programista. Jeżeli obie strony mają siedzibę w Polsce, dokument jest zwykle klasyczną fakturą krajową: z VAT albo bez VAT. Trzeba podać dane sprzedawcy, dane nabywcy, NIP, datę wystawienia, datę sprzedaży lub wykonania usługi, nazwę usługi, kwotę, walutę, termin płatności i numer faktury.
Przy klientach zagranicznych zaczynają się niuanse. Programista pracujący dla firmy z UE często wystawia fakturę bez polskiego VAT z adnotacją o odwrotnym obciążeniu. W praktyce kontrahent rozlicza VAT u siebie, a polski wykonawca musi zadbać o prawidłowe dane nabywcy, numer VAT UE oraz właściwe ujęcie transakcji w rozliczeniach. Tu nie wystarczy wpisać „0% VAT”, bo to może sugerować inną podstawę opodatkowania. Częściej chodzi o usługę niepodlegającą opodatkowaniu VAT w Polsce z mechanizmem reverse charge.
Przy klientach spoza UE, na przykład z USA, Wielkiej Brytanii albo Szwajcarii, faktura również często nie zawiera polskiego VAT, ale podstawa rozliczenia jest inna niż przy kontrahencie unijnym. Trzeba ustalić miejsce świadczenia usługi i sprawdzić, czy klient jest firmą, czy osobą prywatną. Dla typowego kontraktu B2B z zagraniczną spółką programista najczęściej wystawia fakturę bez polskiego VAT, ale nie powinien kopiować szablonu z faktury dla Niemiec na fakturę dla USA bez sprawdzenia adnotacji.
Praktyczna zasada jest taka: kraj klienta wpływa na VAT, ale nie zwalnia z porządku w dokumentach. Na fakturze nadal musi być jasne, za co klient płaci, za jaki okres, w jakiej walucie i na jakich warunkach.
Przy fakturach walutowych trzeba dopilnować trzech rzeczy:
- waluta faktury — np. EUR, USD albo GBP;
- kurs do rozliczeń podatkowych — zwykle ustalany według właściwych zasad podatkowych, a nie „po kursie z banku”;
- różnice kursowe — mogą powstać między datą przychodu a datą faktycznej zapłaty.
To detal, który programiści często lekceważą, bo pieniądze „przecież przyszły”. Księgowo jednak liczy się nie tylko wpływ na konto, ale też prawidłowe rozpoznanie przychodu i kursu. Przy większych kwotach różnice kursowe potrafią być zauważalne.
Osobny temat to ryczałt. Wielu programistów rozlicza się ryczałtem od przychodów ewidencjonowanych, ale faktura sama w sobie nie „ustawia” stawki podatku. Stawka zależy od rodzaju faktycznie świadczonej usługi i jej klasyfikacji. Jeżeli ktoś wystawia faktury za rozwój oprogramowania, konsultacje architektoniczne, zarządzanie projektem i wsparcie techniczne, może mieć kilka różnych typów przychodów. Wtedy opis usługi przestaje być formalnością — pomaga przypisać przychód do właściwej stawki.
Największy priorytet? Uporządkować trzy rzeczy przed wystawieniem pierwszej faktury dla nowego klienta:
- status VAT programisty — czynny VAT czy zwolnienie;
- status i kraj klienta — Polska, UE, poza UE;
- rzeczywisty zakres usługi — kodowanie, testy, konsultacje, utrzymanie, audyt, management.
Dopiero potem ma sens dobieranie szablonu faktury. Odwrotna kolejność kończy się poprawkami.
Terminy, opisy usług i błędy, które potrafią kosztować najwięcej
Podstawowa zasada jest prosta: fakturę wystawia się zasadniczo nie później niż 15. dnia miesiąca następującego po miesiącu wykonania usługi. Jeżeli programista świadczył usługi w maju, faktura powinna być wystawiona najpóźniej 15 czerwca. W praktyce większość kontraktów B2B narzuca też własny rytm: faktura po zaakceptowaniu timesheetu, po zamknięciu sprintu, po podpisaniu protokołu albo po zakończeniu miesiąca.
Tu pojawia się realny konflikt. Podatki mają swoje terminy, a korporacyjny proces akceptacji faktury swoje. Jeżeli klient akceptuje timesheet dopiero 18. dnia miesiąca, programista może mieć problem. Dlatego w umowie warto dopisać, kiedy usługa jest uznana za wykonaną i kiedy można wystawić fakturę. Im bardziej rozmyty zapis, tym większa szansa, że płatność przesunie się o tydzień lub dwa.
Na fakturze warto pilnować szczególnie:
- numeru faktury — najlepiej według stałego schematu, np. 5/2026 albo FV/2026/05/001;
- daty wykonania usługi — zwykle ostatni dzień okresu rozliczeniowego;
- terminu płatności — np. 7, 14 albo 30 dni;
- opisu usługi — zgodnego z umową i faktycznym zakresem prac;
- stawki VAT lub podstawy zwolnienia;
- waluty i konta bankowego;
- danych nabywcy — szczególnie NIP/VAT UE przy firmach zagranicznych.
Od 2026 roku trzeba też uwzględnić KSeF, czyli Krajowy System e-Faktur. Obowiązek wystawiania faktur w KSeF wszedł etapami: od 1 lutego 2026 roku dla największych podatników, którzy w 2024 roku przekroczyli 200 mln zł sprzedaży brutto, a od 1 kwietnia 2026 roku dla pozostałych podatników. Do końca 2026 roku przewidziano ułatwienie dla podatników, u których miesięczna wartość sprzedaży dokumentowanej fakturami poza KSeF nie przekracza 10 000 zł brutto. Dla programisty na standardowym kontrakcie B2B ta ulga często będzie bez znaczenia, bo jedna miesięczna faktura potrafi przekroczyć ten limit.
KSeF zmienia praktykę, nie tylko technikę wystawiania dokumentu. Faktura ustrukturyzowana jest uznawana za wystawioną po przesłaniu do systemu i nadaniu numeru KSeF. Nie wystarczy więc „wygenerować PDF-a” w programie księgowym, jeśli dana faktura powinna przejść przez KSeF. To ważne przy klientach, którzy mają swoje procedury: jedni będą chcieli numer KSeF, inni wizualizację faktury, a jeszcze inni będą odbierać dokument bezpośrednio w systemie.
Najczęstsze błędy programistów na B2B są powtarzalne:
- wystawienie faktury z VAT mimo korzystania ze zwolnienia;
- brak adnotacji przy fakturze bez VAT;
- wpisanie błędnego NIP albo numeru VAT UE klienta;
- opis „usługi IT” zamiast konkretnego zakresu;
- używanie jednej stawki ryczałtu dla różnych usług bez sprawdzenia klasyfikacji;
- faktura po terminie, bo klient późno zatwierdził timesheet;
- brak rozróżnienia między fakturą dla klienta z Polski, UE i spoza UE;
- traktowanie kwoty brutto z faktury VAT jak pieniędzy w całości „dla siebie”.
Ten ostatni błąd jest najbardziej praktyczny. Jeżeli faktura opiewa na 24 600 zł brutto, a 4 600 zł to VAT, te pieniądze nie są wynagrodzeniem programisty. Powinny zostać zabezpieczone na rozliczenie z urzędem. To samo dotyczy podatku dochodowego i składek. Dobra praktyka: po każdej płatności odłożyć VAT, PIT/ryczałt i ZUS na osobne konto. Nie dlatego, że tak ładniej wygląda budżet, tylko dlatego, że po kilku miesiącach nieregularnych przelewów łatwo pomylić przychód z dochodem.
Decyzja graniczna jest prosta: jeżeli programista pracuje wyłącznie dla jednej polskiej firmy i ma stabilny miesięczny kontrakt, powinien mieć jeden dopracowany szablon faktury oraz procedurę miesięczną. Jeżeli ma klientów z różnych krajów, różne waluty albo różne typy usług, nie powinien polegać na kopiowaniu poprzedniego dokumentu. Wtedy bezpieczniej przygotować osobne schematy faktur: Polska VAT, Polska zwolnienie, UE B2B, poza UE B2B, korekta i zaliczka.
FAQ: faktury programisty na B2B
Czy programista na B2B musi wystawiać fakturę VAT?
Nie zawsze. Fakturę VAT wystawia programista zarejestrowany jako czynny podatnik VAT. Jeżeli korzysta ze zwolnienia z VAT, wystawia fakturę bez VAT z odpowiednią podstawą zwolnienia.
Czy programista może wystawić fakturę bez VAT dla polskiej firmy?
Tak, jeżeli ma prawo do zwolnienia z VAT, na przykład nie przekroczył limitu sprzedaży i nie wykonuje usług wyłączających to zwolnienie. Trzeba jednak pilnować limitu i prawidłowej adnotacji na fakturze.
Jaka stawka VAT najczęściej dotyczy usług programistycznych w Polsce?
Przy krajowych usługach programistycznych świadczonych przez czynnego podatnika VAT najczęściej stosuje się 23% VAT. Wyjątki wymagają sprawdzenia konkretnej usługi, umowy i podstawy prawnej.
Czy faktura dla klienta z UE powinna mieć polski VAT?
Przy typowej usłudze B2B dla firmy z UE często stosuje się mechanizm odwrotnego obciążenia, więc polski VAT nie pojawia się na fakturze. Trzeba jednak sprawdzić numer VAT UE klienta i poprawnie opisać transakcję.
Czy faktura dla klienta z USA wygląda tak samo jak faktura dla klienta z Niemiec?
Nie powinna być kopiowana bezmyślnie. Obie mogą być bez polskiego VAT, ale inna jest podstawa rozliczenia i inna logika dokumentowania transakcji. Przy USA nie ma numeru VAT UE, więc faktura wymaga innego podejścia.
Do kiedy trzeba wystawić fakturę za usługi programistyczne?
Zasadniczo najpóźniej do 15. dnia miesiąca następującego po miesiącu wykonania usługi. Jeżeli usługa była wykonana w maju, termin wypada 15 czerwca.
Czy programista musi korzystać z KSeF?
W 2026 roku obowiązek KSeF został wdrożony etapami. Dla większości mniejszych przedsiębiorców obowiązek wystawiania faktur w KSeF obowiązuje od 1 kwietnia 2026 roku, z czasowym wyjątkiem do końca 2026 roku dla miesięcznej sprzedaży fakturowanej poza KSeF do 10 000 zł brutto.
Czy opis na fakturze ma znaczenie przy ryczałcie?
Tak. Opis powinien odpowiadać faktycznej usłudze, bo przy ryczałcie stawka zależy od rodzaju działalności. Ogólny opis może utrudnić przypisanie przychodu do właściwej stawki.
Co sprawdzić przed wystawieniem pierwszej faktury dla nowego klienta?
Najpierw status VAT, kraj i status klienta, numer NIP lub VAT UE, zakres usługi, walutę, termin płatności oraz to, czy faktura powinna trafić do KSeF. Dopiero potem warto wybrać szablon dokumentu.
Najrozsądniej zacząć od uporządkowania szablonów faktur. Jeden dla polskiego klienta, drugi dla klienta z UE, trzeci dla klienta spoza UE, osobny dla korekt i zaliczek. To usuwa najczęstszy błąd: wystawianie faktur „na pamięć”. Przy B2B w IT kwoty są zbyt wysokie, żeby liczyć na to, że księgowość albo klient zawsze wyłapie pomyłkę przed terminem rozliczenia.
Więcej na stronie: księgowość dla programistów.
