KSeF w sklepie internetowym: jak faktura z zamówienia trafia do KSeF

Sklep internetowy, który sprzedaje firmom, od 1 kwietnia 2026 r. musi wystawiać im faktury w KSeF, a kary za niedopełnienie tego obowiązku obowiązują od 1 stycznia 2027 r. Faktura z zamówienia nie może więc powstawać jako sam PDF w panelu sklepu, tylko musi przejść przez API Krajowego Systemu e-Faktur i dostać numer. Opisujemy, kogo to dotyczy, co z klientem indywidualnym, jak połączyć sklep z systemem fakturowym albo ERP, jakie dane zbiera checkout i co przetestować. Piszemy jako zespół wdrażający takie integracje, nie jako doradca podatkowy, więc sprawy podatkowe skonsultuj z księgowością.

Czy sklep internetowy musi wystawiać faktury w KSeF?

Tak, jeśli wystawia faktury firmom albo jednostkom publicznym. Obowiązek wchodził etapami:

• 1 lutego 2026 r. dla podatników, których sprzedaż w 2024 r. przekroczyła 200 mln zł brutto. Od tego dnia wszyscy podatnicy muszą też odbierać faktury w KSeF.
• 1 kwietnia 2026 r. dla pozostałych podatników, czyli dla większości sklepów.
• 1 stycznia 2027 r. dla firm, u których sprzedaż dokumentowana fakturami nie przekracza 10 000 zł brutto miesięcznie.

Do końca 2026 r. nikt nie dostanie kary za błędy związane z KSeF. Z nowym rokiem zaczynają obowiązywać sankcje, a paragon z NIP przestaje być fakturą uproszczoną. Sklep, który do tej pory część klientów firmowych obsługiwał paragonem z NIP, ma więc mniej niż trzy miesiące na przestawienie procesu.

Co z fakturą dla klienta indywidualnego?

Faktury dla osób fizycznych nieprowadzących działalności są wyłączone z obowiązku KSeF. Sklep może je nadal wystawiać jak dotąd albo, dobrowolnie, w KSeF. W drugim przypadku konsument nie ma dostępu do systemu, więc dostaje fakturę mailem w PDF, a ta wizualizacja powinna mieć kod QR z numerem KSeF.

Technicznie prościej jest wysyłać do systemu wszystkie faktury, bo jeden przepływ łatwiej utrzymać niż dwa. Granicę między firmą a konsumentem wyznacza checkbox „Chcę fakturę na firmę” i pole NIP. Faktura bez NIP nabywcy też może tam trafić, wtedy w XML-u zaznacza się brak identyfikatora.

Jak wygląda droga faktury z zamówienia do KSeF?

Faktura w KSeF to plik XML w strukturze logicznej FA(3), a nie PDF. Typowy przepływ w sklepie wygląda tak:

1. Klient w checkoutcie zaznacza fakturę i podaje NIP, nazwę firmy i adres.
2. Po opłaceniu albo zrealizowaniu zamówienia sklep przekazuje dane do systemu fakturowego albo ERP.
3. System buduje XML w FA(3) i wysyła go przez API KSeF 2.0.
4. KSeF waliduje plik i nadaje mu numer albo odrzuca fakturę z kodem błędu.
5. Numer KSeF wraca do zamówienia w sklepie, a klient dostaje PDF z kodem QR.

Za dzień wystawienia faktury w trybie online uznaje się dzień, w którym plik dotarł do systemu, pod warunkiem że data w polu P_1 zgadza się z dniem wysyłki, co ma znaczenie przy kolejkach wysyłających faktury raz na dobę po północy. Jeśli Twój system tak działa, ustal z księgowością, jaką datę ma wpisywać w P_1.

Do API trzeba się uwierzytelnić tokenem KSeF albo certyfikatem KSeF. Ministerstwo Finansów zdecydowało, że tokeny zostaną w KSeF 2.0 bezterminowo, a certyfikat jest potrzebny m.in. do wystawiania faktur w trybach offline. Token przechowuj tak jak hasło do bramki płatności: w konfiguracji serwera, nie w kodzie motywu ani w repozytorium.

Wtyczka, system fakturowy czy ERP: jak spiąć sklep z KSeF?

Są trzy drogi. Wybór zależy głównie od tego, gdzie dziś powstaje faktura.

Subiekt nexo, Comarch ERP Optima i BaseLinker obsługują KSeF, ale zakres tej obsługi różni się wersją i konfiguracją, więc sprawdź go w dokumentacji producenta. Jeśli faktury powstają już w ERP, zwykle nie ma sensu dokładać osobnej wtyczki KSeF do sklepu. Sklep musi wtedy przekazać kompletne dane nabywcy, a resztę robi ERP. Synchronizację zamówień z BaseLinkerem opisujemy w ofercie integracji BaseLinker.

Jakie dane musi zebrać checkout?

KSeF odrzuci fakturę z błędną strukturą, ale nie sprawdzi, czy klient wpisał właściwą firmę. To zadanie checkoutu. Minimum to:

• NIP nabywcy, a przy kontrahencie z UE prefiks kraju i numer VAT,
• pełna nazwa firmy, nie imię i nazwisko osoby zamawiającej,
• adres siedziby, który może się różnić od adresu dostawy,
• dane odbiorcy, jeśli jest inny niż nabywca (ważne przy jednostkach samorządu),
• informacja, czy klient chce fakturę, zapisana w tym samym polu niezależnie od metody płatności.

Ostatni punkt brzmi banalnie, ale łatwo go przeoczyć. W sklepie KwiatyDonice na WooCommerce zamówienia z InPost Pay omijają zwykły checkout. Wtyczka zapisuje dane do faktury w metadanych z prefiksem impost_invoice_, a motyw i integracje szukały NIP-u w polu sklepu. Zmapowaliśmy te dane na pole NIP i znacznik „chcę fakturę”, żeby faktura z takiego zamówienia miała poprawne dane nabywcy. Szczegóły są w artykule o wdrożeniu InPost Pay w WooCommerce. Każda płatność typu „kup jednym kliknięciem” może mieć podobny problem, więc sprawdź ją przed spięciem sklepu z KSeF.

Jak sprawdzać NIP w sklepie?

NIP sprawdzamy w trzech warstwach:

• Suma kontrolna. NIP ma 10 cyfr, a ostatnia jest cyfrą kontrolną, więc kilka linii JavaScriptu w formularzu łapie literówki, zanim klient kliknie „Zamawiam”.
• GUS. Rejestr REGON zwraca nazwę i adres firmy po NIP. W KwiatyDonice klient wpisuje NIP, a nazwa i adres firmy uzupełniają się same, co ogranicza ręczne przepisywanie.
• VIES. Dla kontrahentów z innych krajów UE sprawdza, czy numer VAT jest aktywny w wymianie wewnątrzwspólnotowej.

Pobieranie danych z rejestru po NIP jest bezpieczne, bo to dane publiczne. Inaczej jest z danymi klientów sklepu. W jednym projekcie rozważaliśmy wyszukiwanie zapisanych danych klienta po adresie e-mail i odrzuciliśmy ten pomysł: publiczny endpoint, który po wpisaniu maila zwraca adres i NIP, to gotowy wyciek danych osobowych. Dane zalogowanego klienta i tak są w sesji, więc formularz wypełnia się z niej.

Jak sklep może obsłużyć zamówienia od jednostek publicznych?

Szkoły, urzędy i jednostki samorządu zamawiają inaczej niż firmy. Nabywcą na fakturze jest często gmina albo powiat, a towar trafia do szkoły czy ośrodka, który ma własne dane. W FA(3) taka jednostka podrzędna występuje jako Podmiot3 z rolą „JST – odbiorca”, z własnym NIP-em albo identyfikatorem wewnętrznym, żeby faktura dotarła do niej w KSeF.

W jednym ze sklepów na PrestaShop zrobiliśmy dla takich klientów osobną ścieżkę. Gdy klient wybierze w checkoutcie „Faktura”, pojawia się box dla jednostek publicznych. Kliknięcie otwiera formularz z danymi nabywcy (nazwa, NIP, adres, e-mail, telefon), wstępnie wypełniony danymi z sesji, oraz z opcją „Odbiorca inny niż nabywca”, która odsłania pola odbiorcy. Formularz sprawdza sumę kontrolną NIP i format kodu pocztowego. Zamówienie trafia mailem do sklepu, a kopia do klienta, a handlowiec kontaktuje się z klientem, mając już komplet danych nabywcy i odbiorcy. Endpoint, który wysyła te maile, jest publiczny, dlatego chroni go token sesji i limit wysyłek.

Co zrobić, gdy KSeF jest niedostępny?

Sklep działa całą dobę, a KSeF ma przerwy techniczne i awarie. Przepisy przewidują na to dwa tryby:

• Offline24. Fakturę w FA(3) wystawia się poza systemem, np. przy braku internetu po stronie sprzedawcy, i przesyła najpóźniej następnego dnia roboczego.
• Tryb awaryjny. Przy awarii KSeF ogłoszonej przez ministerstwo faktury przesyła się w ciągu 7 dni roboczych od jej zakończenia.

Faktura przekazana klientowi poza KSeF, zanim dostanie numer, ma dwa kody QR: „OFFLINE” i „CERTYFIKAT”. Po stronie technicznej oznacza to kolejkę. Zamówienie zostaje zapisane, faktura czeka ze statusem „do wysłania”, a zadanie w tle ponawia wysyłkę i zapisuje numer, gdy system odpowie. Integracja, która po błędzie API tylko zapisuje wpis w logu, zgubi faktury przy pierwszej dłuższej przerwie.

Co przetestować przed uruchomieniem?

KSeF ma środowisko testowe, więc te scenariusze da się sprawdzić bez wysyłania prawdziwych faktur:

1. Zamówienie firmowe z poprawnym NIP: faktura dostaje numer KSeF, a numer widać w panelu zamówienia.
2. NIP z błędną sumą kontrolną: checkout blokuje zamówienie z czytelnym komunikatem.
3. Zamówienie bez faktury: sklep nie wysyła faktury firmowej.
4. Każda metoda płatności po kolei, w tym szybkie płatności omijające checkout: NIP i znacznik faktury są w zamówieniu.
5. Kontrahent z UE: prefiks kraju i numer VAT przechodzą do XML-a.
6. Nabywca i odbiorca różni, np. gmina i szkoła: odbiorca jest w XML-u jako Podmiot3.
7. Korekta albo zwrot: korekta przechodzi przez system i wskazuje numer KSeF faktury pierwotnej.
8. Wyłączone API albo zły token: faktura czeka w kolejce i wysyła się po przywróceniu połączenia.

Jak wdrażamy KSeF w sklepach w ASAPDevs?

W ASAPDevs wdrażaliśmy KSeF w e-commerce w takim właśnie przepływie: klient w sklepie zaznacza, że chce fakturę, podaje dane firmy, a faktura wystawia się i trafia też do KSeF. Zaczynamy od sprawdzenia, gdzie dziś powstaje faktura i które ścieżki zamówienia omijają checkout. Potem ustawiamy przekazywanie danych do systemu fakturowego albo ERP, kolejkę wysyłki i testy z listy powyżej.

Pracujemy na WooCommerce i PrestaShop. Przy sprzedaży hurtowej zobacz też, jak projektujemy sklepy B2B, z osobnym kontem klienta hurtowego, akceptacją nowych kont i cenami widocznymi dopiero po zalogowaniu, bo tam faktura na firmę jest normalną ścieżką zamówienia, a nie wyjątkiem.

Masz sklep na WooCommerce albo PrestaShop i chcesz, żeby faktury z zamówień trafiały do KSeF bez ręcznego przepisywania? Zobacz, jak łączymy sklepy z ERP i KSeF →