Faktura zagraniczna w KSeF: co przechodzi, a co system odrzuca
Struktura FA ma osobne pola na kontrahenta z Unii i spoza niej. Przy sprzedaży zagranicznej fakturę zatrzymuje zwykle nie nabywca, tylko stawka VAT — 858 z 1 190 nieudanych wysyłek w naszych danych.
Struktura KSeF przewiduje fakturę dla kontrahenta z Unii Europejskiej i spoza niej — ma osobne pola na jego kod kraju i numer. Wyłączone z systemu są natomiast dokumenty wystawiane w procedurach OSS, IOSS i SME: tych nie da się w KSeF wystawić nawet dobrowolnie.
Czy Twoja konkretna sprzedaż podlega jednej z tych procedur, rozstrzyga księgowy. Walidacja schematu tego nie sprawdza i tej decyzji nie zastępuje.
Ten tekst jest o fakturze, która do KSeF pojechać ma — i o tym, dlaczego przy sprzedaży zagranicznej zatrzymuje ją zwykle nie nabywca, tylko stawka VAT.
W 1 190 nieudanych wysyłkach, które przeanalizowaliśmy, 858 to stawki spoza polskiej listy.
Jak KSeF identyfikuje nabywcę z zagranicy
To pytanie wraca najczęściej, więc warto je rozstrzygnąć od razu: schemat ma osobny wariant dla każdego rodzaju nabywcy.
Blok identyfikacyjny nabywcy przyjmuje NIP, kod kraju z numerem VAT UE, kod kraju z identyfikatorem spoza Unii albo znacznik jego braku.
Numer VAT wpisuj z prefiksem kraju
Prefiks decyduje o tym, który wariant identyfikacji trafi na fakturę. Bez niego program musi wywnioskować kraj z adresu, a to nie zawsze daje ten sam wynik.
Grecja pokazuje dlaczego. W adresie kraj ten ma kod GR, ale jego prefiks numeru VAT UE to EL — i te słowniki nie są wymienne.
Nasza integracja rozpoznaje prefiksy dopuszczone przez FA(3), razem z EL dla Grecji i XI dla Irlandii Północnej, i odcina prefiks od reszty numeru.
Numer podany bez prefiksu trafia natomiast do wariantu identyfikatora spoza Unii. Dokument przejdzie walidację, ale opisze kupującego inaczej, niż zamierzasz.
Dlatego samo pochodzenie kupującego rzadko jest przyczyną odrzucenia. Problem zaczyna się o jeden poziom niżej — na pozycji faktury, przy stawce podatku.
Poradniki o fakturach ustrukturyzowanych pisane są z perspektywy biura rachunkowego, w której dokument wypełnia człowiek znający kontrahenta.
Na marketplace jest odwrotnie: dane wpisuje kupujący, którego nigdy nie zobaczysz, a faktura powstaje z nich automatycznie.
Trzy wynikające z tego sytuacje są całkowicie normalne w sprzedaży i całkowicie nieakceptowalne dla walidacji.
Skala problemu w liczbach — nasze dane
Zanim przejdziemy do poszczególnych przypadków, warto zobaczyć proporcje. Poniższe liczby pochodzą z faktur wysyłanych do KSeF przez sprzedawców korzystających z easySales od 15 maja 2026. Publikujemy je zbiorczo, bez podziału na konta.
Faktur przyjętych z numerem KSeF: 6 132. Nieudanych wysyłek: 1 190. Poniżej to, co je zatrzymało:
- Stawka VAT spoza polskiej listy schematu — 858 wysyłek (72,1%). Bezkonkurencyjnie najczęstsza przyczyna i temat pierwszego punktu poniżej.
- Nie udało się otworzyć sesji — 218 wysyłek (18,3%). To w ogóle nie jest odrzucenie faktury i mylenie tych dwóch rzeczy kosztuje najwięcej czasu przy szukaniu przyczyny.
- Pole numeru identyfikacyjnego nie jest NIP-em — 72 wysyłki (6,1%). Przedrostki w polu numeru i numery zagraniczne.
- Niekompletny blok danych identyfikacyjnych nabywcy — 15 wysyłek (1,3%). Najczęściej brak nazwy przy sprzedaży konsumenckiej.
- Pozostałe — 27 wysyłek (1,6%). Pole kontaktowe, duplikaty, data wystawienia, numer VAT UE i drobne pojedyncze przypadki.
Jedna uwaga metodyczna, bo bez niej te liczby wprowadzają w błąd: liczymy wysyłki, a nie wpisy błędów. Nieudana wysyłka jest ponawiana i przy każdej próbie dokłada kolejny wpis — te 1 190 wysyłek ma po swojej stronie ponad pięć tysięcy zapisów błędów.
Kto policzy wpisy zamiast wysyłek, dostanie obraz cztery razy gorszy od rzeczywistego.
Trzy przyczyny, przez które faktura nie przechodzi
Każda z nich jest normalną sytuacją sprzedażową, której schemat FA po prostu nie przewiduje w tej postaci.
1. Kupujący z inną stawką VAT
To jest, licząc nieudane wysyłki, największy problem tej listy — u nas 858 na 1 190. Pole P_12, w którym schemat FA oczekuje stawki podatku, korzysta z zamkniętego słownika wartości stosowanych w Polsce.
Pozycja ze stawką 19, 20, 21 albo 27 nie przechodzi walidacji, i to zanim ktokolwiek spojrzy na treść dokumentu.
Skąd się biorą? Ze sprzedaży transgranicznej: zamówienie z zagranicznej platformy albo wysyłka do kupującego z innego kraju UE przynosi stawkę obowiązującą tam.
System fakturujący przepisuje ją wiernie, bo tak ma działać, a walidacja schematu ją zatrzymuje, bo P_12 takiej wartości nie przewiduje.
Dla unijnej procedury OSS struktura FA(3) ma osobne pole P_12_XII. Nasza integracja wypełnia wyłącznie P_12, więc sprzedaży rozliczanej w OSS przez nią nie prześlesz.
Dlaczego poprawianie stawki nie pomaga
Polega na tym, żeby te faktury nie trafiały do wysyłki. Zawęź zakres przepływu do dokumentów, które rzeczywiście mają tam jechać — to decyzja o zakresie, nie obejście.
Stawka spoza polskiej listy to 72% wszystkich naszych odrzuceń. Nie jest to błąd faktury ani błąd integracji — to dokument wysłany tam, gdzie schemat go nie przyjmuje.
Jeśli sprzedajesz za granicę, ta jedna decyzja o zakresie wysyłki załatwia większość problemu, zanim się pojawi.
Jak zawęzić zakres wysyłki w praktyce
Skoro najczęstsza przyczyna odrzuceń to dokumenty, które nie powinny tam trafiać, warto powiedzieć konkretnie, jak je odsiać. To ustawienie, nie programowanie.
Wysyłką steruje reguła, więc pytanie brzmi: po czym poznać dokument, który ma pojechać? W praktyce sprawdzają się trzy warunki, zwykle użyte razem:
- Kanał sprzedaży. Najprostsze i najskuteczniejsze kryterium. Jeśli sprzedaż zagraniczna idzie przez osobne konto albo osobny kanał, wystarczy ograniczyć regułę do kanałów krajowych.
- Kraj nabywcy lub kraj dostawy. Przydatne, gdy ten sam kanał obsługuje oba rodzaje sprzedaży — wtedy rozstrzyga adres, a nie źródło zamówienia.
- Stawka VAT na pozycjach. Warunek awaryjny, który wyłapuje przypadki, których dwa poprzednie nie objęły. Działa jak siatka bezpieczeństwa, a nie jak główne kryterium.
Dwie rzeczy warto przy tym zapamiętać. Po pierwsze, zawężenie zakresu nie oznacza, że te faktury przestają istnieć — powstają normalnie w programie księgowym, mają numer i trafiają do rozliczenia.
Zmienia się tylko to, że nie są wysyłane tam, gdzie schemat ich nie przyjmuje.
Po drugie, zakres warto ustalić przed pierwszą wysyłką, a nie po serii odrzuceń.
Odrzucone dokumenty zostają w kolejce i każde ponowienie generuje kolejne wpisy — a im dłużej to trwa, tym trudniej odróżnić stare przypadki od nowych.
2. Faktura dla osoby fizycznej — kupujący bez NIP
Faktura dla osoby fizycznej to na marketplace codzienność, a blok danych identyfikacyjnych nabywcy wymaga kompletu — również wtedy, gdy kupujący jest bez NIP.
Kłopot nie polega na samym braku numeru — to jest przewidziane — tylko na tym, że przy zamówieniach od osób fizycznych czasem nie dojeżdża też nazwa nabywcy.
Dokument wygląda w panelu poprawnie i nie przechodzi walidacji.
To jedyny przypadek z tej listy, w którym naprawdę trzeba zajrzeć w konkretne zamówienie, a nie w ustawienia: danych brakuje już na wejściu.
Faktura dla osoby fizycznej w KSeF — co musi się zgadzać
Ponieważ to najczęstszy typ dokumentu w sprzedaży na marketplace, warto rozłożyć go na części.
Faktura dla osoby fizycznej w KSeF jest w pełni przewidziana — schemat nie wymaga, żeby każdy nabywca miał numer identyfikacji podatkowej.
Problem nie leży w braku NIP-u, tylko w tym, co musi być na jego miejscu.
Blok danych identyfikacyjnych nabywcy musi być kompletny jako całość. Przy sprzedaży konsumenckiej to oznacza przede wszystkim nazwę nabywcy — imię i nazwisko kupującego.
I to jest dokładnie to pole, które przy zamówieniach z marketplace potrafi nie dojechać:
- kupujący złożył zamówienie na dane, w których nazwa jest pusta albo skrócona do inicjału;
- zamówienie zostało zaimportowane z pliku, w którym kolumny z nazwą po prostu nie było;
- dane odbiorcy przesyłki są kompletne, ale dane nabywcy — czyli te, które trafiają na fakturę — już nie.
Efekt jest mylący: dokument wygląda w panelu poprawnie, bo widzisz adres wysyłki i pozycje, a mimo to nie przechodzi walidacji.
To jedyny przypadek z całej listy, w którym trzeba zajrzeć w konkretne zamówienie, a nie w ustawienia przepływu — danych brakuje już na wejściu i żadna konfiguracja ich nie wytworzy.
Praktyczna wskazówka: jeśli faktura dla osoby fizycznej wraca odrzucona, otwórz zamówienie i porównaj dane nabywcy z danymi do wysyłki. W dziewięciu przypadkach na dziesięć różnica jest właśnie tam.
Uzupełnienie nazwy przed ponowną wysyłką rozwiązuje sprawę — a jeśli takie zamówienia zdarzają się regularnie, warto dodać regułę, która uzupełnia nazwę nabywcy z danych odbiorcy, zanim dokument w ogóle powstanie.
Brak NIP-u przy sprzedaży konsumenckiej jest normalny i przewidziany. Schemat nie wymaga, żeby każdy nabywca miał numer identyfikacji podatkowej.
Odrzucenia w tej kategorii biorą się z braku nazwy nabywcy, a nie z braku numeru — i dlatego szuka się ich w danych zamówienia, a nie w ustawieniach.
3. Kupujący z zagranicy, który wpisuje swój numer
Kupujący z Czech albo ze Słowacji wpisuje w pole numeru identyfikacyjnego IČO albo DIČ.
Z jego perspektywy to jest poprawny numer firmy — bo jest. Z perspektywy schematu to nie jest NIP i dokument wraca.
Wariant krajowy tego samego: kupujący wpisuje NIP: 1234567890 zamiast samego numeru i przedrostek jedzie razem z numerem. Na marketplace nikt tego pola po drodze nie waliduje — wypełnia je klient.
Rozwiązanie: oczyszczaj dane identyfikacyjne na etapie przetwarzania zamówienia, zanim powstanie faktura. Usuwanie przedrostków i odrzucanie numerów w niewłaściwym formacie jest banalne przed wystawieniem dokumentu i kosztowne po.
Kiedy już znajdziesz przyczynę, poprawka jest zwykle prostsza, niż się wydaje.
Nie potrzebujesz nowej faktury
Uzupełniasz brakującą nazwę albo czyścisz numer identyfikacyjny i ponawiasz wysyłkę tego samego dokumentu.
Warto tylko wiedzieć, że automatyczne ponawianie samo w sobie niczego nie naprawia. Dokument ze stawką spoza listy będzie odrzucany za każdym razem, aż zmienisz zakres wysyłki albo dane.
Czwarta przyczyna, o której nikt nie pisze: sesja
Prawie co piąta nieudana wysyłka w naszych danych — 218 z 1 190 — nie jest odrzuceniem faktury.
To nieudane otwarcie sesji z systemem. Rozróżnienie jest kluczowe, bo szuka się ich zupełnie gdzie indziej.
Odrzucona faktura to dokument, który dotarł i został oceniony jako niezgodny ze schematem.
Nieudana sesja oznacza, że dokument nigdy nie wyszedł — połączenie nie zostało nawiązane, więc treść faktury nie ma z tym nic wspólnego.
Możesz poprawiać stawki i dane nabywcy do wieczora i nic to nie zmieni.
Typowe przyczyny leżą po stronie uprawnień i tokenów: token wygasł, został wygenerowany dla innego zakresu uprawnień albo dla innego podmiotu niż ten, w imieniu którego wysyłasz.
Zdarza się też, że uprawnienia nadano poprawnie, ale nie objęły one wystawiania faktur.
Jak je rozpoznać: nieudane sesje przychodzą seriami. Jeśli w krótkim czasie nie wychodzi wszystko, niezależnie od tego, jak różne są to dokumenty, to prawie na pewno sesja, a nie treść.
Odrzucenia schematu są odwrotne — dotyczą pojedynczych faktur o wspólnej cesze, na przykład tej samej stawce.
To rozróżnienie jest pierwszą rzeczą, którą warto sprawdzić przy każdym zgłoszeniu „KSeF nie działa". Odpowiedź „nie działa nic" i „nie działa część" prowadzą do dwóch różnych miejsc.
Duplikaty: kiedy odrzucenie nie jest problemem
Osobna kategoria, która wygląda groźnie, a zwykle nie jest błędem: zgłoszenie duplikatu. System wykrywa, że dana faktura została już przyjęta, i odsyła informację razem z numerem dokumentu pierwotnego.
Jeśli wskazany dokument to ta sama faktura — a tak jest w większości przypadków — sytuacja jest w porządku i nie ma czego naprawiać.
Numer i potwierdzenie przypisują się do dokumentu, który już masz. Ponowna wysyłka po prostu trafiła na dokument wysłany wcześniej, na przykład przy ponowieniu po chwilowym problemie z połączeniem.
Uwaga należy się jedynie sytuacji odwrotnej: gdy zgłoszony duplikat wskazuje na inną fakturę.
To znaczy, że dwa różne dokumenty mają ten sam numer w Twojej numeracji — i to jest realny problem, tyle że w programie księgowym, nie w integracji.
Jak sprawdzić własne dane, zanim włączysz wysyłkę
Wszystkie powyższe przyczyny da się wyłapać zawczasu. Przegląd zajmuje kwadrans i oszczędza tydzień odrzuceń.
Przegląd na kwadrans, przed włączeniem wysyłki
- Wyfiltruj zamówienia ze stawkami spoza polskiej listy. Jeśli jakiekolwiek są, zdecyduj o zakresie wysyłki, zanim ją włączysz — a nie po pierwszych odrzuceniach.
- Sprawdź zamówienia bez nazwy nabywcy. To ta sama lista, która potem generuje odrzucenia bloku danych identyfikacyjnych.
- Przejrzyj pole numeru identyfikacyjnego pod kątem przedrostków i numerów zagranicznych. Wyszukanie wartości zawierających litery załatwia większość przypadków.
- Zweryfikuj zakres uprawnień tokenu na jednym dokumencie testowym, zanim puścisz cały dzień sprzedaży.
- Ustal, co ma się dziać z korektami — idą inną ścieżką niż faktury pierwotne i konfiguruje się je osobno.
Jest w tym wszystkim wniosek, który warto powiedzieć wprost: żadna z tych przyczyn nie wraca co miesiąc.
Zakres wysyłki ustawia się raz. Reguła czyszcząca numer identyfikacyjny działa dalej sama. Uzupełnienie nazwy nabywcy poprawia przy okazji etykiety i korespondencję z kupującym.
To jest tydzień porządków w danych, a nie stały koszt obsługi — choć w pierwszym miesiącu wygląda dokładnie odwrotnie.
Jak sprawdzić, czy faktura naprawdę przeszła
Ostatnia rzecz, bez której cała ta lista jest niepełna: skąd wiadomo, że dokument został przyjęty.
Dowodem jest numer nadany przez system i potwierdzenie odbioru. Nic innego.
Status „wysłano" mówi tylko, że próba została podjęta. Faktura bez numeru jest albo w drodze, albo odrzucona — i to drugie jest znacznie częstsze.
Dlatego warto raz na jakiś czas przejrzeć wysłane dokumenty pod kątem brakujących numerów, zamiast czekać na sygnał.
Odrzucenia nie zgłaszają się same, a im starsze, tym trudniej ustalić, co dokładnie było w danych zamówienia w momencie wystawienia.
Przy korektach ten przegląd jest jeszcze ważniejszy. Korekta idzie inną ścieżką niż faktura pierwotna i bywa, że wychodzą faktury, a korekty nie — przez miesiące, zanim ktokolwiek to zauważy.
Wspólny mianownik
We wszystkich trzech przypadkach faktura jest wystawiona poprawnie w sensie księgowym. Nikt nie pomylił się w kwocie, stawce ani w dacie.
Odrzucenie bierze się z tego, że dane przyszły z zewnątrz — od kupującego, z platformy, czasem z innego kraju — a walidacja schematu tego nie wybacza.
Dlatego przy sprzedaży na marketplace przygotowanie do wysyłki ustrukturyzowanej to w większości praca nad jakością danych zamówienia, a nie nad fakturowaniem. Kto potraktuje to jako temat księgowy, będzie szukał błędu w niewłaściwym miejscu.
Jest w tym też wniosek pozytywny. Wszystkie te przyczyny są jednorazowe. Stawka spoza listy to decyzja o zakresie, podjęta raz.
Przedrostek w numerze to reguła czyszcząca, ustawiona raz. Brakująca nazwa nabywcy to uzupełnienie danych, które przy okazji poprawia też etykiety i korespondencję z kupującym.
Innymi słowy: to nie jest praca, którą wykonuje się co miesiąc. To jest tydzień porządków w danych zamówień, po którym wysyłka przestaje wymagać uwagi.
Nasze własne liczby to potwierdzają — 6 132 przyjętych dokumentów wobec 1 190 nieudanych wysyłek oznacza, że przy uporządkowanych danych ta ścieżka działa cicho, a odrzucenia skupiają się tam, gdzie dane przychodzą z zewnątrz i nikt ich po drodze nie sprawdza.
Konfigurację krok po kroku opisujemy w przewodniku: KSeF i faktury ustrukturyzowane. Samo połączenie: integracja z KSeF.
