Sprzedaż do Hiszpanii po zmianach w e-fakturowaniu: jak przygotować system księgowy?

W praktyce średnia firma e-commerce może równolegle obsługiwać kilka różnych reżimów. Część transakcji będzie podlegała polskim zasadom i KSeF, część będzie rozliczana jako sprzedaż wewnątrzunijna, sprzedaż B2C może wejść do procedury OSS, a niektóre lokalne transakcje w Hiszpanii mogą znaleźć się w zakresie hiszpańskiego e-fakturowania. Sytuacja staje się bardziej złożona, gdy polska spółka posiada zapasy w Hiszpanii, jest tam lokalnie zarejestrowana do VAT albo prowadzi działalność poprzez strukturę znajdującą się na terytorium Hiszpanii. W takich modelach trzeba ustalić, które konkretne transakcje podlegają hiszpańskim zasadom fakturowania, ponieważ sama lokalna rejestracja VAT nie przesądza jeszcze o objęciu całej sprzedaży hiszpańskim systemem e-faktur. Największym błędem byłoby więc potraktowanie całej „sprzedaży do Hiszpanii” jako jednego scenariusza i przypisanie mu jednej reguły w ERP. System powinien rozpoznawać rodzaj klienta, charakter sprzedaży, miejsce rozpoczęcia transportu, sposób rozliczenia VAT i właściwy reżim fakturowania, zanim zdecyduje, jak dokument ma zostać wystawiony i przesłany.

Przygotowanie do zmian nie powinno dlatego zaczynać się od szukania kolejnego modułu do generowania faktur, lecz od uporządkowania logiki całego procesu. Firma powinna wiedzieć, kiedy transakcja pozostaje w polskim reżimie, kiedy korzysta z zasad właściwych dla WDT lub OSS, a kiedy może zostać objęta hiszpańskim systemem. Dopiero na tej podstawie można projektować przepływ danych pomiędzy sklepem internetowym, ERP, księgowością, systemem płatności i kanałem odpowiedzialnym za elektroniczną wymianę dokumentów. Dobrze przygotowany system nie powinien wymagać ręcznej decyzji pracownika przy każdej fakturze ani kolejnej przebudowy, gdy firma uruchomi nowy magazyn, zwiększy sprzedaż B2B albo zmieni model logistyczny. Celem jest stworzenie architektury, w której obowiązki podatkowe i fakturowe wynikają z danych o konkretnej transakcji, a nie z uproszczonego założenia, że sprzedaż do jednego kraju zawsze działa w ten sam sposób.

Co właściwie zmieniło się w e-fakturowaniu w Hiszpanii?

Nowy model obowiązkowego e-fakturowania B2B

Hiszpański model e-fakturowania B2B zakłada odejście od sytuacji, w której elektroniczna faktura jest rozumiana przede wszystkim jako plik PDF przesłany kontrahentowi e-mailem. W przypadku transakcji objętych obowiązkiem faktura ma funkcjonować jako ustrukturyzowany komunikat elektroniczny, który może być automatycznie odczytany i przetworzony przez system odbiorcy. Rozporządzenie przewiduje wykorzystanie formatów zgodnych z europejskim modelem EN16931, w tym CII, UBL, EDIFACT i Facturae. Oznacza to, że sam wygląd dokumentu przestaje być najważniejszym elementem procesu. Kluczowe stają się poprawna struktura danych, ich zgodność z wymaganym standardem oraz możliwość wymiany informacji pomiędzy systemami stosowanymi przez sprzedawcę i nabywcę. Prywatne platformy uczestniczące w tym modelu mają zapewniać interoperacyjność, w tym możliwość transformacji pomiędzy dopuszczonymi formatami i komunikowania się z innymi rozwiązaniami. Publiczne rozwiązanie e-fakturowe ma natomiast wykorzystywać format UBL.

PDF nadal może pojawiać się obok faktury elektronicznej jako czytelna dla człowieka prezentacja dokumentu, ale w transakcjach objętych obowiązkiem nie zastępuje danych ustrukturyzowanych. Widać to również w przepisach przejściowych przewidzianych dla większych podmiotów. W pierwszych 12 miesiącach stosowania obowiązku przedsiębiorcy i profesjonaliści, których roczny wolumen operacji dla celów VAT przekracza 8 mln euro, mają co do zasady dołączać do e-faktury jej czytelną wersję w formacie PDF, chyba że odbiorca wyraźnie zgodzi się na otrzymywanie wyłącznie formatu źródłowego. Dobrze pokazuje to różnicę pomiędzy wizualizacją a właściwą fakturą elektroniczną: PDF może ułatwiać człowiekowi odczyt dokumentu, natomiast podstawą automatycznego obiegu są dane strukturalne. Dla firmy e-commerce przygotowującej ERP oznacza to konieczność myślenia nie tylko o eksporcie kolejnego rodzaju pliku, ale również o mapowaniu danych, walidacji pól, obsłudze różnych formatów i wymianie komunikatów pomiędzy systemami.

Nowy model nie kończy się również w momencie wystawienia faktury. Odbiorca będzie musiał obsługiwać komunikaty dotyczące jej dalszego statusu, w szczególności akceptacji albo komercyjnego odrzucenia oraz pełnej faktycznej zapłaty. Co do zasady informacja o takim zdarzeniu ma zostać przekazana wystawcy w terminie maksymalnie czterech dni kalendarzowych od jego wystąpienia, przy czym do tego terminu nie wlicza się sobót, niedziel i ogólnokrajowych dni świątecznych. Przepisy przewidują również możliwość przekazywania dodatkowych informacji, na przykład dotyczących częściowej płatności albo częściowej akceptacji faktury. Jednocześnie komunikacja z publicznym rozwiązaniem e-fakturowym została skonstruowana nieco inaczej i skupia się przede wszystkim na informacji o odrzuceniu oraz o pełnej zapłacie. Jeżeli nie nastąpi odrzucenie ani późniejsza korekta, faktura może być traktowana jako zaakceptowana zgodnie z mechanizmem przewidzianym w rozporządzeniu. Z technologicznego punktu widzenia oznacza to, że firma potrzebuje nie tylko narzędzia do wystawienia dokumentu, lecz także procesu pozwalającego zapisywać jego status, reakcję kontrahenta oraz informację o płatności.

Dla przedsiębiorcy prowadzącego sprzedaż na kilku rynkach takie podejście ma konkretne konsekwencje. ERP, księgowość, system obsługujący należności i dane bankowe nie powinny działać jak niezależne wyspy, między którymi pracownicy ręcznie przenoszą informacje. Jeżeli faktura zostanie odrzucona, opłacona częściowo albo rozliczona w późniejszym terminie, status powinien znaleźć odzwierciedlenie w jednym spójnym procesie. Przy większej skali ręczne uzgadnianie takich danych szybko prowadzi do rozbieżności: inny status może widzieć księgowość, inny dział obsługi klienta, a jeszcze inny system odpowiedzialny za windykację. Hiszpańskie zmiany zwiększają więc znaczenie spójności danych, bo elektroniczne fakturowanie przestaje być wyłącznie kwestią sposobu dostarczenia dokumentu. Staje się częścią szerszego procesu obejmującego wystawienie, odbiór, reakcję kontrahenta, płatność i późniejsze rozliczenie transakcji.

Kiedy nowe obowiązki zaczną faktycznie działać?

Real Decreto 238/2026 zostało opublikowane 31 marca 2026 r. i weszło w życie 20 kwietnia 2026 r., czyli 20 dni po publikacji. Nie oznacza to jednak, że od tej daty wszystkie firmy objęte zakresem przepisów muszą już korzystać z nowego modelu e-fakturowania. Faktyczne rozpoczęcie obowiązku zostało powiązane z kolejnym etapem regulacyjnym, czyli wejściem w życie ministerialnych przepisów technicznych rozwijających publiczne rozwiązanie e-fakturowe. To od tego momentu mają rozpocząć się okresy dostosowawcze przewidziane dla poszczególnych grup przedsiębiorców. Na 10 sierpnia 2026 r. nie ma więc jednej daty, którą można wskazać jako wspólny dzień rozpoczęcia obowiązku dla wszystkich firm. Sam fakt, że rozporządzenie już obowiązuje formalnie, nie jest równoznaczny z uruchomieniem pełnego obowiązku operacyjnego. Dla firmy planującej ekspansję do Hiszpanii ważniejsze jest dziś zrozumienie mechanizmu wdrożenia i wcześniejsze przygotowanie procesów niż wpisywanie do harmonogramu jednej pozornie pewnej daty granicznej.

Po wejściu w życie wymaganej regulacji ministerialnej rozpocznie się bieg dwóch różnych okresów przejściowych. Przedsiębiorcy i profesjonaliści, których volumen de operaciones, ustalany zgodnie z art. 121 hiszpańskiej ustawy o VAT, przekroczył 8 mln euro w poprzednim roku kalendarzowym, mają otrzymać 12 miesięcy na dostosowanie się do obowiązku. W mniej prawniczym ujęciu chodzi o podmioty, których roczny wolumen operacji dla celów VAT przekracza wskazany próg. Pozostałe podmioty objęte regulacją będą miały 24 miesiące. Rozporządzenie przewiduje ponadto, że publiczne rozwiązanie e-fakturowe powinno być dostępne co najmniej dwa miesiące przed pierwszym terminem faktycznego stosowania nowych zasad. Daje to przedsiębiorcom możliwość przetestowania integracji przed rozpoczęciem obowiązku, ale nie oznacza, że przygotowania warto odkładać do ostatnich tygodni. W średniej firmie e-commerce więcej czasu niż samo uruchomienie połączenia technicznego może zająć uporządkowanie kartotek kontrahentów, reguł VAT, źródeł danych, procesów płatniczych oraz sposobu rozróżniania transakcji podlegających różnym systemom.

Hiszpański model będzie przy tym różnił się od rozwiązania opartego wyłącznie na jednej centralnej bramce. Regulacja przewiduje funkcjonowanie zarówno prywatnych platform, jak i rozwiązania publicznego, a prywatne systemy mają współpracować ze sobą oraz z infrastrukturą publiczną. W określonym modelu informacje o fakturach będą więc krążyć pomiędzy przedsiębiorcami, prywatnymi operatorami i publicznym rozwiązaniem, a do centralnego repozytorium ma trafiać wierna elektroniczna kopia faktury w formacie UBL. Z perspektywy przygotowania ERP ma to duże znaczenie, ponieważ firma nie powinna projektować całego procesu jako prostego odpowiednika polskiego KSeF z innym adresem technicznym. Potrzebna jest raczej architektura pozwalająca przypisać transakcji właściwy reżim, wygenerować odpowiednią strukturę danych, skierować ją do odpowiedniego kanału i odebrać komunikaty zwrotne bez utraty spójności z systemem księgowym.

Okres 12 lub 24 miesięcy należy więc rozumieć jako czas przewidziany na dostosowanie po uruchomieniu kolejnego etapu regulacyjnego, a nie jako argument za odkładaniem analizy procesu. Firma, która już dziś prowadzi sprzedaż do Hiszpanii albo planuje zwiększyć ją w kolejnych latach, może wcześniej ustalić, które modele sprzedaży potencjalnie znajdą się w zakresie lokalnych przepisów, gdzie potrzebna będzie interoperacyjność systemów i jakie dane powinny być dostępne w ERP. Szczególnej uwagi wymagają przedsiębiorstwa łączące sprzedaż B2B i B2C, korzystające z OSS, przechowujące towary w zagranicznych magazynach albo posiadające lokalne rejestracje VAT. W takich przypadkach nie wystarczy wiedzieć, że klient jest z Hiszpanii. System musi potrafić rozpoznać, dlaczego dana transakcja jest rozliczana w określony sposób i jaki proces fakturowania powinien zostać dla niej uruchomiony.

Czy to jest dla mnie? Sprawdź, czy Twoja sprzedaż może podlegać hiszpańskim zasadom

Sprzedaję z Polski do hiszpańskiej firmy

Sam fakt, że odbiorca ma siedzibę w Hiszpanii i posługuje się hiszpańskim numerem VAT, nie oznacza jeszcze, że polski sprzedawca musi objąć fakturę hiszpańskim obowiązkowym systemem e-fakturowania B2B. Trzeba najpierw ustalić, jakie przepisy o fakturowaniu mają zastosowanie do konkretnej transakcji. Dla typowej firmy handlowej ważnym przykładem jest sprzedaż towaru znajdującego się w Polsce do podatnika VAT w Hiszpanii, gdy towar jest transportowany z Polski do Hiszpanii. Przy spełnieniu odpowiednich warunków po stronie polskiego sprzedawcy taka transakcja jest rozliczana jako wewnątrzwspólnotowa dostawa towarów. Nie należy jej automatycznie traktować jak hiszpańskiej sprzedaży krajowej tylko dlatego, że odbiorca znajduje się w Hiszpanii. Podobna ostrożność jest potrzebna przy usługach. To, że klient jest hiszpańskim przedsiębiorcą, pozwala ustalić część zasad VAT, ale nadal trzeba sprawdzić miejsce świadczenia, status stron oraz przepisy regulujące obowiązek wystawienia faktury.

Dla systemu księgowego płynie z tego bardzo praktyczny wniosek: pole „kraj kontrahenta: Hiszpania” nie może samodzielnie decydować o sposobie wystawienia dokumentu. Przy kwalifikowaniu sprzedaży powinny być uwzględniane również status klienta, rodzaj transakcji, miejsce rozpoczęcia transportu, miejsce opodatkowania oraz rola poszczególnych jednostek przedsiębiorcy. W typowym modelu cross-border faktura dla hiszpańskiej firmy może nadal podlegać polskim zasadom fakturowania, mimo że handlowo cała transakcja jest określana jako sprzedaż do Hiszpanii. Dopiero po przeanalizowaniu konkretnej transakcji można ustalić, które państwo reguluje obowiązek fakturowania oraz czy dokument powinien zostać wystawiony w polskim KSeF, objęty hiszpańskim systemem B2B albo obsłużony według innego reżimu. To szczególnie istotne w szybko rosnącym e-commerce, gdzie jedna firma może jednocześnie wysyłać towary z Polski, korzystać z zagranicznych centrów logistycznych i obsługiwać klientów biznesowych oraz konsumentów.

Mam magazyn, zapasy lub stałą obecność w Hiszpanii

Sytuacja staje się bardziej złożona, gdy towary nie są już wysyłane wyłącznie z Polski. Jeśli firma przewozi własne zapasy do magazynu w Hiszpanii, a następnie sprzedaje je lokalnym odbiorcom, część transakcji może przestać przypominać klasyczną sprzedaż transgraniczną z Polski. Pojawiają się lokalne obowiązki VAT, konieczność właściwego rozliczenia przemieszczeń towarów oraz sprzedaż, której miejsce opodatkowania znajduje się w Hiszpanii. Jeszcze większej uwagi wymaga model, w którym przedsiębiorstwo posiada tam strukturę mogącą stanowić stałe miejsce prowadzenia działalności lub inną istotną obecność gospodarczą. Nie oznacza to jednak, że samo wynajęcie powierzchni magazynowej automatycznie tworzy stałe miejsce prowadzenia działalności albo że każda faktura od tego momentu podlega hiszpańskiemu e-fakturowaniu. Magazyn, lokalna rejestracja VAT i stałe miejsce prowadzenia działalności to trzy odrębne kwestie, które trzeba analizować osobno, uwzględniając rzeczywisty sposób prowadzenia działalności.

Z punktu widzenia ERP lokalny magazyn jest ważny przede wszystkim dlatego, że zmienia dane wejściowe, od których zależy kwalifikacja sprzedaży. System musi wiedzieć nie tylko, gdzie znajduje się klient, lecz również skąd fizycznie wychodzi towar i do jakiego miejsca jest dostarczany. Jeżeli ten sam produkt może zostać wysłany klientowi z magazynu w Polsce albo z zapasu znajdującego się już w Hiszpanii, dwie niemal identyczne sprzedaże widoczne w sklepie internetowym mogą wymagać zupełnie innego rozliczenia VAT i innego procesu fakturowania. WSTO rozpoczynające się w Polsce nie jest tym samym co lokalna dostawa ze stocku hiszpańskiego. Przy większej skali nie powinno się rozstrzygać tego ręcznie już po wystawieniu faktury. Informacja o lokalizacji zapasu, źródle realizacji zamówienia i statusie kontrahenta powinna trafiać do systemu finansowego razem z zamówieniem, aby właściwe zasady mogły zostać zastosowane jeszcze przed wygenerowaniem dokumentu.

Mam hiszpańską rejestrację VAT

Hiszpański numer VAT jest istotną informacją podatkową, ale nie należy traktować go jak przełącznika, który automatycznie kieruje wszystkie faktury firmy do hiszpańskiego systemu e-fakturowania. Przedsiębiorstwo może być zarejestrowane do VAT w Hiszpanii bez posiadania tam siedziby czy stałego miejsca prowadzenia działalności. Taka rejestracja może być potrzebna chociażby w związku z utrzymywaniem lokalnego zapasu lub dokonywaniem określonych transakcji na terytorium Hiszpanii. Jednocześnie ta sama polska spółka może nadal realizować inne sprzedaże bezpośrednio z Polski. Dlatego pytanie nie powinno brzmieć: „czy mamy hiszpański VAT?”, lecz raczej: „jaką rolę hiszpańska rejestracja VAT odgrywa w tej konkretnej transakcji?”. Dopiero odpowiedź na to pytanie pozwala prawidłowo ocenić sposób rozliczenia i fakturowania. Sam prefiks ES w numerze podatkowym przedsiębiorstwa nie wystarcza, aby zakwalifikować całą sprzedaż do jednego lokalnego modelu.

W praktyce system księgowy powinien pozwalać firmie korzystać z kilku identyfikacji podatkowych i wybierać właściwą na podstawie danych transakcyjnych, a nie na podstawie jednej domyślnej konfiguracji kontrahenta czy spółki. Ma to znaczenie szczególnie wtedy, gdy przedsiębiorca prowadzi sprzedaż z kilku magazynów lub stopniowo rozszerza działalność o nowe kraje. Fakt, że w jednej transakcji wykorzystywana jest hiszpańska rejestracja VAT, nie przesądza o sposobie dokumentowania innej sprzedaży realizowanej przez tę samą spółkę. W dobrze zaprojektowanym ERP numer VAT powinien być jednym z elementów reguły kwalifikacyjnej obok miejsca dostawy, miejsca rozpoczęcia transportu, rodzaju klienta, rodzaju towaru lub usługi oraz informacji o jednostce uczestniczącej w transakcji. Takie podejście ogranicza ryzyko, że po uzyskaniu lokalnej rejestracji firma zacznie błędnie wystawiać wszystkie faktury według jednego hiszpańskiego schematu.

Sprzedaję klientom indywidualnym w Hiszpanii

Sprzedaż do konsumentów wymaga oddzielenia od relacji B2B, ponieważ mechanizm rozliczania VAT jest inny, a obowiązkowy hiszpański system e-fakturowania B2B nie powinien być traktowany jako domyślna ścieżka dla sprzedaży detalicznej. W przypadku towarów wysyłanych przez polską firmę z Polski do konsumentów w Hiszpanii najczęściej trzeba analizować zasady wewnątrzwspólnotowej sprzedaży towarów na odległość, czyli WSTO. W unijnym systemie funkcjonuje wspólny próg 10 000 euro netto, który obejmuje łącznie określone WSTO oraz wskazane usługi telekomunikacyjne, nadawcze i elektroniczne. Nie jest to oddzielny limit dla Hiszpanii ani osobny próg dla każdego państwa UE. Jeżeli przedsiębiorca spełnia warunki stosowania unijnego progu 10 000 euro, w szczególności jest ustanowiony tylko w jednym państwie członkowskim, kwalifikująca się sprzedaż poniżej limitu może pozostać opodatkowana w państwie ustanowienia. Po przekroczeniu progu miejscem opodatkowania WSTO staje się co do zasady państwo zakończenia transportu, czyli przy dostawie do hiszpańskiego konsumenta Hiszpania.

Dla rozwijającego się e-commerce istotnym uproszczeniem jest procedura unijna OSS, dzięki której określoną sprzedaż konsumencką i usługi opodatkowane w innych państwach UE można rozliczać poprzez jedno państwo identyfikacji. Nie należy jednak wyciągać z tego wniosku, że OSS rozwiązuje każdy przypadek sprzedaży B2C do Hiszpanii. Jeśli firma przechowuje własne towary w hiszpańskim magazynie i sprzedaje je stamtąd hiszpańskim konsumentom, mamy do czynienia z innym modelem niż WSTO rozpoczynające się w Polsce i może powstać potrzeba lokalnego rozliczenia VAT. System powinien zatem rozpoznawać kraj rozpoczęcia wysyłki, kraj jej zakończenia, status konsumenta, miejsce ustanowienia przedsiębiorcy oraz to, czy dana sprzedaż może być rozliczana poprzez OSS. Sam adres dostawy w Hiszpanii nadal nie daje pełnej odpowiedzi na pytanie, jak rozliczyć transakcję.

Sprzedaję do hiszpańskiej administracji

Sprzedaż do administracji publicznej trzeba wydzielić jako osobny proces B2G, zamiast wrzucać ją do tego samego obiegu co zwykłych hiszpańskich klientów biznesowych. Hiszpania od lat posiada odrębny elektroniczny obieg faktur dla sektora publicznego, oparty między innymi na punktach wejścia takich jak FACe. Nie oznacza to jednak, że każda faktura kierowana do każdego podmiotu publicznego zawsze przechodzi dokładnie przez ten sam kanał. W zależności od administracji zastosowanie może mieć właściwy punkt wejścia, a przepisy przewidują także określone wyjątki. W praktyce wymagania mogą obejmować nie tylko odpowiedni format dokumentu, lecz również dane identyfikujące konkretną jednostkę publiczną, urząd odpowiedzialny za księgowanie czy jednostkę prowadzącą postępowanie. Dla polskiej firmy, która zdobywa pierwszy kontrakt publiczny w Hiszpanii, potraktowanie klienta B2G jak kolejnej spółki B2B może więc zakończyć się odrzuceniem dokumentu mimo prawidłowych wartości podatkowych.

W systemie warto dlatego posiadać oddzielny status klienta B2G i przypisać do niego wymagany kanał doręczenia oraz zestaw obowiązkowych danych. Pozwala to uniknąć sytuacji, w której dokument jest generowany prawidłowo z perspektywy księgowej, ale nie może zostać skutecznie przekazany do właściwej administracji. Hiszpański obieg faktur dla sektora publicznego funkcjonuje niezależnie od rozwijanego modelu obowiązkowego e-fakturowania pomiędzy przedsiębiorcami, dlatego oba procesy nie powinny zostać połączone w ERP tylko dlatego, że dotyczą tego samego kraju. Dla firmy wchodzącej na rynek hiszpański jest to kolejny przykład szerszej zasady: kierunek geograficzny sprzedaży jest dopiero pierwszą informacją. O prawidłowym obiegu dokumentu decydują również typ odbiorcy, charakter transakcji i przepisy właściwe dla konkretnej relacji.

Jak szybko ustalić właściwy scenariusz?

Najprostsze drzewko decyzyjne można sprowadzić do kilku kolejnych pytań, które system powinien potrafić rozstrzygnąć na podstawie danych o zamówieniu i kontrahencie. Najpierw trzeba ustalić, kim jest klient: B2B, B2C czy B2G. Następnie należy określić, czy sprzedawany jest towar czy usługa, ponieważ reguły dotyczące miejsca opodatkowania i fakturowania mogą być zupełnie inne. Kolejnym etapem jest ustalenie miejsca realizacji sprzedaży: czy towar wychodzi z Polski, z magazynu w Hiszpanii albo z zapasu w innym państwie, a w przypadku usług, z jakim miejscem związane jest świadczenie i który podmiot je nabywa. Dopiero potem należy uwzględnić lokalne rejestracje VAT, ewentualne stałe miejsce prowadzenia działalności oraz jednostkę faktycznie uczestniczącą w transakcji. Taka kolejność pozwala uniknąć sytuacji, w której jedna informacja, na przykład hiszpański numer VAT klienta, przesądza o całym procesie.

Wynikiem tej kwalifikacji powinny być dwie niezależne decyzje. Pierwsza dotyczy sposobu rozliczenia VAT: transakcja może być na przykład WDT, podlegać mechanizmowi reverse charge, zostać rozliczona przez OSS albo stanowić lokalną sprzedaż opodatkowaną w Hiszpanii. Druga decyzja dotyczy tego, jak wystawić i przekazać dokument: czy zastosowanie ma KSeF, hiszpański system e-fakturowania B2B, proces B2G z właściwym punktem wejścia takim jak FACe, czy inny dopuszczalny kanał fakturowania. Rozdzielenie tych dwóch warstw ma ogromne znaczenie w ERP, ponieważ sposób rozliczenia VAT nie jest tym samym co sposób wysłania faktury. Przy setkach lub tysiącach transakcji miesięcznie ta logika powinna wynikać z danych i reguł systemowych, a do ręcznej analizy powinny trafiać przede wszystkim wyjątki.

Nie ma jednej „sprzedaży do Hiszpanii”. Najpierw rozdziel 5 scenariuszy

Towary B2B wysyłane z Polski do firmy w Hiszpanii

Dla polskiego przedsiębiorcy jednym z najczęstszych scenariuszy będzie sprzedaż towaru, który fizycznie wyjeżdża z Polski i trafia do hiszpańskiego kontrahenta będącego podatnikiem. Przy spełnieniu wymaganych warunków transakcja może zostać rozliczona w Polsce jako wewnątrzwspólnotowa dostawa towarów ze stawką 0% VAT. Nie wystarczy jednak samo wystawienie faktury bez kwoty polskiego podatku. Znaczenie ma między innymi status podatkowy nabywcy oraz posługiwanie się właściwym numerem VAT UE, a sprzedawca musi również prawidłowo udokumentować przemieszczenie towarów z Polski do innego państwa członkowskiego. Zakres wymaganych dowodów należy oceniać zgodnie z polską ustawą o VAT oraz, tam gdzie mają zastosowanie, unijnym domniemaniem dokumentacyjnym dotyczącym WDT. Nie należy więc zakładać, że dowolny zestaw dokumentów transportowych lub wewnętrznych automatycznie wystarczy do obrony stawki 0%.

Transakcja musi być również prawidłowo ujęta w wymaganym raportowaniu VAT, w tym w informacji podsumowującej VAT-UE, jeżeli spełnione są ustawowe warunki jej wykazania. Dla e-commerce ważne jest, aby dokumentacja dotycząca WDT nie funkcjonowała poza głównym procesem sprzedażowym. Przy kilkudziesięciu przesyłkach można jeszcze ręcznie odszukiwać dowód dostawy w poczcie lub panelu przewoźnika, ale przy kilku tysiącach dostaw miesięcznie taki model staje się trudny do kontrolowania. ERP powinien pozwalać powiązać numer zamówienia, fakturę, kontrahenta, przesyłkę i dokumenty dotyczące transportu, tak aby w razie potrzeby można było odtworzyć pełną historię transakcji. Co równie ważne, fakt, że odbiorcą jest hiszpańska firma, nie powinien samoczynnie kierować takiej faktury do hiszpańskiego systemu B2B. Najpierw trzeba ustalić, jakie przepisy fakturowe mają zastosowanie do tej konkretnej dostawy.

Usługi B2B dla hiszpańskiej firmy

W przypadku wielu usług świadczonych przez polską firmę na rzecz hiszpańskiego przedsiębiorcy miejscem świadczenia jest zgodnie z regułą ogólną państwo, w którym usługobiorca posiada siedzibę działalności gospodarczej albo właściwe stałe miejsce prowadzenia działalności, jeżeli to ono jest odbiorcą danej usługi. Jeżeli więc usługobiorcą jest hiszpański przedsiębiorca, miejscem opodatkowania może być Hiszpania. To jednak dopiero pierwszy etap analizy. Miejsce świadczenia nie przesądza automatycznie o reverse charge. Następnie trzeba odrębnie ustalić, kto jest zobowiązany do rozliczenia podatku z tytułu konkretnej transakcji. W typowym modelu transgranicznym, w którym polski usługodawca nie posiada w Hiszpanii odpowiedniej jednostki uczestniczącej w świadczeniu, obowiązek rozliczenia VAT będzie często przechodził na hiszpańskiego nabywcę w mechanizmie reverse charge. System nie powinien jednak przyjmować tego rezultatu wyłącznie na podstawie kraju klienta.

Nie każda usługa B2B działa według reguły ogólnej. Przepisy VAT przewidują szczególne zasady między innymi dla określonych usług związanych z nieruchomościami, transportem, wydarzeniami czy innymi kategoriami wskazanymi w regulacjach. Dlatego stworzenie w ERP jednej reguły „usługa dla firmy z Hiszpanii = reverse charge” jest ryzykowne. Katalog usług powinien zawierać informację podatkową pozwalającą odróżnić standardową usługę B2B od świadczenia wymagającego osobnej analizy, a system powinien rozdzielać ustalenie miejsca opodatkowania od ustalenia podmiotu zobowiązanego do zapłaty VAT. Jest to szczególnie istotne dla e-commerce, który z czasem rozszerza działalność poza prostą sprzedaż towarów, na przykład o instalację, szkolenia, usługi marketingowe, obsługę wydarzeń czy usługi powiązane z lokalną infrastrukturą. Im szerszy katalog świadczeń, tym mniej bezpieczne stają się automatyczne reguły oparte wyłącznie na kraju kontrahenta.

Towary B2C

Przy sprzedaży towarów konsumentom trzeba zacząć od ustalenia, gdzie rozpoczyna się transport. Jeśli polska firma wysyła towar z Polski bezpośrednio do konsumenta w Hiszpanii, transakcja może stanowić WSTO. W tym modelu znaczenie może mieć unijny próg 10 000 euro netto, obejmujący łącznie określone wewnątrzwspólnotowe dostawy towarów na odległość oraz wskazane usługi telekomunikacyjne, nadawcze i elektroniczne. Nie jest to osobny limit 10 000 euro dla Hiszpanii ani oddzielny próg dla każdego państwa członkowskiego. Co ważne, uproszczenie nie działa automatycznie dla każdego sprzedawcy. Jeżeli przedsiębiorca spełnia warunki stosowania tego progu, w szczególności jest ustanowiony tylko w jednym państwie członkowskim, kwalifikująca się sprzedaż poniżej limitu może pozostać opodatkowana w państwie ustanowienia. Po przekroczeniu progu miejscem opodatkowania WSTO staje się co do zasady państwo zakończenia transportu, czyli przy dostawie do hiszpańskiego konsumenta Hiszpania.

W praktyce rosnący sklep internetowy najczęściej będzie zainteresowany procedurą OSS, która pozwala rozliczać kwalifikujące się transgraniczne dostawy B2C i usługi w jednym państwie identyfikacji. System musi wtedy potrafić ustalić właściwe państwo konsumpcji, zastosować prawidłową stawkę VAT oraz przygotować dane potrzebne do rozliczenia OSS. Trzeba jednak oddzielić tę sytuację od sprzedaży towarów znajdujących się już w hiszpańskim magazynie. Dostawa z lokalnego zapasu do lokalnego konsumenta nie jest tym samym przepływem co WSTO rozpoczynające się w Polsce i może wymagać lokalnego rozliczenia VAT. Dlatego wraz z uruchomieniem zagranicznego magazynu dotychczasowa konfiguracja OSS powinna zostać ponownie przeanalizowana. W ERP nie powinno być jednej reguły „konsument z Hiszpanii = OSS”, ponieważ o sposobie rozliczenia decyduje również miejsce, z którego towar faktycznie rozpoczyna drogę do klienta.

Usługi B2C

Usługi świadczone konsumentom są dobrym przykładem tego, dlaczego w systemie nie powinno istnieć jedno ustawienie „B2C Hiszpania”. W sprzedaży konsumenckiej punktem wyjścia jest inna reguła niż w przypadku usług B2B, a jednocześnie przepisy przewidują liczne wyjątki zależne od charakteru świadczenia. Inaczej mogą być traktowane standardowe usługi objęte regułą ogólną, inaczej usługi elektroniczne, telekomunikacyjne i nadawcze, a jeszcze inaczej świadczenia związane z nieruchomościami, wydarzeniami czy określonym miejscem faktycznego wykonania. Procedura OSS może być wykorzystywana do rozliczania wielu usług B2C, gdy VAT jest należny w innym państwie członkowskim, ale samo to nie rozwiązuje pytania, gdzie dana usługa powinna zostać opodatkowana. Najpierw potrzebna jest prawidłowa kwalifikacja świadczenia, następnie ustalenie miejsca opodatkowania, a dopiero później wybór sposobu rozliczenia.

Dla firmy, która zaczynała jako klasyczny sklep internetowy, problem może pojawić się dopiero wraz z rozszerzaniem oferty. Sprzedaż produktu może zostać połączona z instalacją, usługą cyfrową, abonamentem, dostępem do treści albo innym świadczeniem dodatkowym. Jeśli ERP widzi wszystkie te pozycje po prostu jako „sprzedaż do konsumenta w Hiszpanii”, może zastosować nieprawidłową regułę VAT. Dlatego w kartotece produktów i usług warto rozdzielić klasyfikację handlową od podatkowej. System powinien wiedzieć, że dwa elementy sprzedawane temu samemu klientowi mogą mieć różne reguły miejsca opodatkowania i wymagać innego sposobu wykazania w rozliczeniach. Takie przygotowanie jest znacznie prostsze przed skalowaniem sprzedaży niż po uruchomieniu kilku rynków, kiedy jedna błędnie ustawiona reguła może wpływać na tysiące transakcji miesięcznie.

B2G

Sprzedaż do hiszpańskiego sektora publicznego należy traktować jako odrębny proces od początku tworzenia oferty i konfiguracji kontrahenta. Hiszpania posiada obowiązkowy elektroniczny obieg faktur dla określonych kategorii dostawców sektora publicznego, a jednym z kluczowych punktów wejścia jest FACe. Nie oznacza to jednak, że każda faktura B2G kierowana do dowolnej administracji zawsze musi przejść właśnie przez FACe. Poszczególne jednostki mogą korzystać z właściwego punktu wejścia, a przepisy przewidują również określone wyjątki. W praktyce poprawna nazwa kontrahenta i numer podatkowy mogą więc nie wystarczyć. Faktura może wymagać odpowiedniej struktury oraz dodatkowych danych pozwalających zidentyfikować jednostkę księgową, organ odpowiedzialny za obsługę dokumentu czy jednostkę prowadzącą daną sprawę. Brak tych informacji może zatrzymać dokument jeszcze zanim rozpocznie się zwykły proces płatności.

Warto dlatego już na poziomie kartoteki kontrahenta rozpoznawać jednostkę publiczną jako B2G, a nie jako kolejnego klienta B2B z Hiszpanii. Taki status może uruchamiać osobny zestaw wymaganych pól, format dokumentu oraz sposób doręczenia do właściwego punktu wejścia. Jest to również ważne z perspektywy przyszłego obowiązkowego modelu B2B, ponieważ oba elektroniczne procesy nie są tym samym systemem i nie powinny zostać połączone w jedną regułę wyłącznie ze względu na kraj odbiorcy. Firma, która chce skalować sprzedaż w Hiszpanii, potrzebuje więc przynajmniej osobnego rozpoznania sprzedaży do przedsiębiorców, konsumentów i sektora publicznego. Dopiero na tym poziomie można bezpiecznie automatyzować dalsze decyzje dotyczące VAT, sposobu wystawienia faktury oraz kanału jej przekazania.

Jak przygotować system księgowy do sprzedaży do Hiszpanii?

Krok 1. Dodaj „reżim fakturowania”, a nie tylko kraj klienta

Najważniejsza zmiana w konfiguracji systemu powinna dotyczyć sposobu kwalifikowania transakcji. Pole „kraj klienta = Hiszpania” mówi za mało, żeby na jego podstawie zdecydować o VAT, sposobie wystawienia faktury i kanale jej przekazania. Hiszpańskim klientem może być konsument kupujący towar wysyłany z Polski, firma otrzymująca dostawę rozliczaną jako WDT, przedsiębiorca kupujący usługę, jednostka administracji publicznej albo odbiorca lokalnej sprzedaży z magazynu w Hiszpanii. Każda z tych sytuacji może prowadzić do innego rezultatu. Dlatego system nie powinien posiadać jednej reguły typu „ES = hiszpańska faktura”. Powinien najpierw ustalić charakter transakcji, a dopiero później uruchomić właściwą ścieżkę podatkową i dokumentową. To rozróżnienie staje się szczególnie ważne w e-commerce, gdzie sposób realizacji zamówienia może zmieniać się automatycznie w zależności od dostępności towaru w poszczególnych magazynach.

W praktyce warto pójść o krok dalej i nie zamykać całej logiki w jednym polu nazwanym „reżimem fakturowania”. System powinien przechowywać przynajmniej dwie niezależne decyzje. Pierwsza określa sposób rozliczenia podatkowego, na przykład WDT, lokalną sprzedaż krajową, reverse charge, OSS albo lokalne rozliczenie VAT. Druga wskazuje sposób wystawienia i przekazania dokumentu, na przykład KSeF, hiszpański obieg B2B, proces B2G albo inny właściwy kanał. To ważne, ponieważ WDT jest rodzajem transakcji, reverse charge mechanizmem rozliczenia, a OSS procedurą VAT, dlatego nie powinny być traktowane jako techniczne kanały wystawiania faktur. Taki podział pozwala uniknąć błędu, w którym jedna etykieta próbuje jednocześnie sterować podatkiem, formatem faktury i sposobem wysyłki. Przy ekspansji na kolejne rynki ta sama architektura może zostać rozbudowana o następne państwa bez tworzenia od początku nowej logiki dla każdego kraju.

Krok 2. Rozbuduj kartotekę hiszpańskiego kontrahenta

Dobrze przygotowana kartoteka kontrahenta nie może ograniczać się do nazwy firmy, adresu, kraju i jednego numeru VAT. System powinien rozpoznawać przede wszystkim, czy odbiorca jest przedsiębiorcą, konsumentem czy jednostką sektora publicznego, a także przechowywać poszczególne identyfikatory w osobnych polach. W zależności od relacji mogą to być między innymi numer VAT UE, lokalny hiszpański NIF, identyfikator wymagany w obiegu B2G czy dane konkretnej jednostki administracyjnej. Warto również zapisywać wynik oraz datę weryfikacji numeru VAT UE, ponieważ status kontrahenta może mieć znaczenie dla sposobu rozliczenia transakcji. Osobno powinny być przechowywane adres siedziby, adres dostawy i inne miejsca istotne dla realizacji zamówienia. W działalności e-commerce nie zawsze są one takie same, a różnica pomiędzy nimi może mieć znaczenie podatkowe. Jeżeli system przechowuje wyłącznie adres do faktury, dział finansowy może nie mieć informacji, że towar w rzeczywistości został dostarczony do innego państwa albo że zamówienie zostało zrealizowane z lokalnego magazynu.

Kartoteka powinna obejmować również dane potrzebne już po zakwalifikowaniu transakcji. Jeżeli klient korzysta z określonego kanału elektronicznego odbioru dokumentów, informacja ta powinna być zapisana w sposób umożliwiający automatyczne kierowanie faktury do właściwego procesu. Podobnie warto traktować warunki płatności, termin wymagalności, uzgodniony sposób przekazania faktury czy dane jednostki organizacyjnej uczestniczącej w transakcji. Jeżeli pojawia się informacja o stałym miejscu prowadzenia działalności, powinna ona zostać odróżniona od samego adresu, magazynu lub lokalnej rejestracji VAT. System nie powinien na podstawie jednego pola automatycznie wyciągać wniosku, że klient albo sprzedawca posiada określony status podatkowy. Chodzi o stworzenie kartoteki, która dostarcza danych do decyzji, a nie sama zastępuje analizę podatkową. Dzięki temu konfiguracja pozostaje użyteczna również wtedy, gdy firma zmienia model logistyczny albo zaczyna korzystać z kilku rejestracji VAT jednocześnie.

Krok 3. Zautomatyzuj weryfikację warunków WDT

W przypadku sprzedaży towarów B2B z Polski do Hiszpanii stawka 0% VAT nie powinna być w ERP traktowana jak zwykła pozycja w cenniku podatkowym, którą pracownik może wybrać z rozwijanego menu. Jej zastosowanie przy WDT zależy od spełnienia określonych warunków, dlatego system powinien kontrolować całą sekwencję zdarzeń prowadzących do prawidłowego rozliczenia. Musi wiedzieć, kto jest nabywcą i jakim numerem VAT UE się posługuje, czy towar rzeczywiście został przemieszczony z Polski do innego państwa członkowskiego oraz czy firma posiada dokumentację wymaganą do zastosowania stawki 0%. Powinien również pozwalać na powiązanie transakcji z prawidłowym raportowaniem, w tym z informacją podsumowującą VAT-UE, jeżeli istnieje obowiązek jej złożenia. W takiej konfiguracji stawka 0% jest rezultatem spełnienia reguł, a nie punktem wyjścia procesu.

W praktyce warto potraktować WDT jak serię kontrolowanych statusów: od wystawienia faktury, przez weryfikację danych VAT UE i potwierdzenie transportu, po zebranie wymaganej dokumentacji i ujęcie sprzedaży w odpowiedniej ewidencji. Zakres dowodów pozwalających zastosować 0% powinien odpowiadać polskiej ustawie o VAT oraz, w sytuacjach, w których ma zastosowanie, unijnym zasadom dotyczącym domniemania przemieszczenia towarów. ERP nie musi samodzielnie prowadzić analizy prawnej każdego dokumentu, ale powinien sygnalizować brak wymaganych elementów i umożliwiać powiązanie dowodu z konkretną dostawą. Jeżeli dokument przewozowy znajduje się w panelu operatora logistycznego, potwierdzenie odbioru w innym systemie, a faktura w księgowości, firma nie ma jednego obrazu transakcji. Przy dużej liczbie wysyłek taka luka szybko przestaje być problemem administracyjnym i zaczyna wpływać na możliwość prawidłowego rozliczenia VAT.

Krok 4. Rozdziel KSeF od hiszpańskiego e-fakturowania

Polski KSeF i rozwijany hiszpański system e-fakturowania B2B trzeba traktować jako dwa odrębne porządki prawne i technologiczne. Obowiązek wystawienia faktury w KSeF należy oceniać według polskich przepisów. To, że zagraniczny kontrahent nie odbiera dokumentu bezpośrednio przez KSeF, nie oznacza automatycznie, że polski sprzedawca nie ma obowiązku wystawienia go w tym systemie. Faktury dokumentujące między innymi WDT czy określone świadczenie usług na rzecz zagranicznych podatników mogą podlegać obowiązkowi wystawienia w KSeF, mimo że sposób przekazania dokumentu zagranicznemu odbiorcy wygląda inaczej niż w relacji z krajowym nabywcą. Dokument trzeba wtedy udostępnić kontrahentowi zgodnie z obowiązującymi zasadami i w odpowiedni sposób. Hiszpańskie przepisy trzeba natomiast analizować oddzielnie, aby ustalić, czy konkretna transakcja znajduje się w zakresie tamtejszego obowiązku e-fakturowania B2B.

Jednocześnie nie należy budować konfiguracji na założeniu, że polski i hiszpański system są swoimi odpowiednikami, a każdą fakturę wystarczy wysłać do jednej z dwóch bramek. W określonym modelu sprzedaży trzeba najpierw ustalić obowiązek wystawienia dokumentu według polskich zasad, następnie zakres ewentualnych hiszpańskich wymogów, a na końcu sposób jego skutecznego udostępnienia odbiorcy. Jedna transakcja nie musi oznaczać jednego kanału technologicznego. System powinien więc przechowywać osobno status wystawienia dokumentu, status jego przekazania kontrahentowi i ewentualne komunikaty wymagane przez zagraniczny proces. Pozwala to uniknąć sytuacji, w której uzyskanie potwierdzenia z jednego systemu jest błędnie interpretowane jako zakończenie całego procesu fakturowania. Dla firmy działającej w kilku państwach taka separacja staje się podstawą skalowalnej architektury.

Krok 5. Zbuduj jedno źródło danych

Najbezpieczniejszy model zakłada, że informacje potrzebne do kwalifikacji transakcji powstają raz i są później wykorzystywane przez wszystkie elementy procesu. ERP lub centralny system finansowy powinien otrzymać dane o zamówieniu, kontrahencie, statusie B2B lub B2C, miejscu rozpoczęcia transportu, magazynie realizującym wysyłkę, numerze VAT, rodzaju produktu lub usługi i warunkach płatności. Na tej podstawie powinien zostać ustalony sposób rozliczenia VAT oraz kanał fakturowania. System powinien jednak zapisywać nie tylko końcowy rezultat, ale także historię decyzji podatkowej, czyli informacje pozwalające później odtworzyć, dlaczego transakcja została zakwalifikowana w określony sposób. Jeżeli wynikiem jest WDT, w historii powinno być możliwe sprawdzenie między innymi statusu B2B nabywcy, wyniku weryfikacji VAT UE, trasy transportu z Polski do Hiszpanii oraz informacji o dokumentach potwierdzających dostawę.

Takie podejście jest szczególnie wartościowe podczas kontroli, audytu albo późniejszej korekty. Sam zapis „wynik = WDT” niewiele mówi, jeśli po dwóch latach nie można ustalić, na podstawie jakich danych system podjął tę decyzję. Dlatego dobrze zaprojektowane rozwiązanie powinno zachowywać nie tylko aktualny stan transakcji, ale również istotne dane wejściowe i datę ich weryfikacji. Następnie ten sam rekord powinien przyjmować kolejne informacje: numer i identyfikator faktury, potwierdzenie wysyłki, odpowiedź systemu zewnętrznego, ewentualne odrzucenie, korektę, płatność i status raportowania podatkowego. Dzięki temu dział księgowy nie musi rekonstruować przebiegu sprzedaży z kilku ekranów i plików, gdy pojawia się problem z konkretnym zamówieniem.

Największym zagrożeniem w rosnącym e-commerce jest ręczne kopiowanie danych między sklepem, ERP, narzędziem fakturowym, bankiem i systemem używanym do rozliczeń VAT. Na niewielkiej skali takie obejścia wydają się tanie, ale wraz ze wzrostem sprzedaży zaczynają tworzyć różne wersje tej samej transakcji. Korekta może zostać zapisana w księgowości, ale nie w systemie odpowiedzialnym za wysyłkę e-faktury; płatność może zostać rozliczona w banku, ale nadal widnieć jako otwarta w module należności; dokument transportowy może zostać przypisany do zamówienia, ale nie do właściwej faktury. Docelowy przepływ powinien więc wyglądać jak jeden łańcuch: dane źródłowe, kwalifikacja transakcji, historia decyzji podatkowej, właściwy kanał dokumentu, status, płatność i raportowanie VAT. Poszczególne systemy mogą nadal wykonywać różne zadania, ale nie powinny tworzyć niezależnych i sprzecznych źródeł prawdy.

Jakich funkcji technicznych będzie potrzebował system?

Obsługa faktur ustrukturyzowanych

System przygotowany do działalności w Polsce i Hiszpanii nie może zakładać, że elektroniczna faktura zawsze będzie miała ten sam format. Polski KSeF wykorzystuje własną strukturę logiczną faktury, w tym obowiązującą strukturę FA(3), podczas gdy hiszpański model B2B przewiduje ustrukturyzowane komunikaty zgodne z europejskim modelem danych EN16931 i dopuszcza kilka składni, między innymi UBL, CII, EDIFACT oraz Facturae. Publiczne rozwiązanie hiszpańskie ma wykorzystywać UBL. Dla firmy oznacza to, że ERP nie powinien być projektowany wokół jednego konkretnego pliku. Znacznie ważniejsza jest warstwa danych biznesowych, z której można wygenerować odpowiednią strukturę zależnie od obowiązującego procesu. Numer faktury, strony transakcji, pozycje, stawki, waluty, terminy płatności i pozostałe wymagane informacje powinny mieć jedno spójne źródło, nawet jeżeli później są mapowane do różnych schematów technicznych.

Warto więc przy ocenie systemu zwrócić uwagę nie tylko na możliwość „eksportu XML”, lecz na sposób mapowania i walidacji danych. XML jest jedynie sposobem zapisania informacji; sam fakt wygenerowania pliku w tym formacie nie oznacza jeszcze zgodności z wymaganiami konkretnego systemu. Rozwiązanie powinno potrafić kontrolować obowiązkowe pola, wersję schematu, format identyfikatorów oraz relacje pomiędzy danymi, zanim dokument zostanie wysłany. Przy hiszpańskim modelu dodatkowego znaczenia nabiera interoperacyjność, ponieważ prywatne platformy mają umożliwiać wymianę faktur pomiędzy użytkownikami różnych rozwiązań i, gdy jest to potrzebne, transformację komunikatów pomiędzy odpowiednimi składniami. Dla przedsiębiorcy praktyczny cel jest prosty: zmiana operatora albo kanału wymiany nie powinna wymuszać ręcznego przebudowania danych źródłowych w całym ERP.

API i automatyczna wymiana komunikatów

Przy większej liczbie transakcji integracja przez API nie jest dodatkiem poprawiającym wygodę pracy, lecz podstawą bezpiecznego obiegu dokumentów. System powinien automatycznie przekazywać fakturę do odpowiedniego kanału, odebrać odpowiedź i zapisać ją przy właściwej transakcji. Ważne jest przy tym rozróżnienie pomiędzy odpowiedzią techniczną a biznesową. Odpowiedź techniczna informuje, czy komunikacja z systemem się udała, czy żądanie zostało prawidłowo odebrane i czy nie wystąpił błąd połączenia lub formatu. Pozytywna odpowiedź na tym poziomie nie oznacza jeszcze, że faktura została zaakceptowana biznesowo. Osobnym zdarzeniem może być odrzucenie dokumentu przez odbiorcę, zmiana jego statusu czy przekazanie informacji o płatności. ERP musi rozumieć tę różnicę, ponieważ komunikat „wysłano poprawnie” i komunikat „faktura zaakceptowana” opisują dwa różne etapy procesu.

W przypadku korekty nowy dokument powinien zostać jednoznacznie powiązany z fakturą pierwotną. Jeśli wysyłka nie powiedzie się z powodu krótkotrwałego problemu technicznego, rozwiązanie powinno pozwalać na bezpieczne ponowienie próby, zamiast zmuszać pracownika do tworzenia kolejnej faktury. Hiszpański model dodatkowo zwiększa znaczenie komunikacji dwukierunkowej. Przepisy przewidują wymianę informacji o statusach faktury pomiędzy stronami, w szczególności o akceptacji lub komercyjnym odrzuceniu oraz pełnej faktycznej zapłacie, a określone informacje o odrzuceniu i płatności mają trafiać także do rozwiązania publicznego. Integracja nie może więc kończyć się na technicznym komunikacie potwierdzającym przesłanie danych. System finansowy powinien przyjmować późniejsze zdarzenia dotyczące tego samego dokumentu, zachowywać ich czas i źródło oraz aktualizować stan transakcji bez tworzenia kolejnych niezależnych rekordów.

Kontrola błędów i duplikatów

Automatyzacja jest użyteczna tylko wtedy, gdy system potrafi bezpiecznie obsłużyć sytuację, w której proces nie przebiega prawidłowo. Dokument może zostać odrzucony z powodu braku wymaganego pola, błędnego identyfikatora, niezgodności struktury albo problemu technicznego podczas komunikacji. Takie przypadki nie powinny znikać w logach dostępnych wyłącznie dla administratora. Potrzebna jest kolejka błędów pokazująca, którego klienta i której faktury dotyczy problem, na jakim etapie wystąpił oraz czy wymaga reakcji księgowości, IT czy osoby odpowiedzialnej za dane kontrahenta. System powinien również rozróżniać błąd merytoryczny od czasowej niedostępności usługi. W pierwszym przypadku automatyczne ponawianie wysyłki niczego nie naprawi, w drugim może być właściwym działaniem po określonym czasie.

Szczególnie ważne jest zabezpieczenie przed podwójną wysyłką. Integracja powinna wykorzystywać jednoznaczny identyfikator operacji, czyli w praktyce idempotency key lub równoważny mechanizm idempotencji, dzięki któremu ponowienie tego samego żądania nie tworzy kolejnego dokumentu reprezentującego tę samą sprzedaż. Jeśli użytkownik kliknie ponownie przycisk po kilku sekundach albo integracja powtórzy żądanie po przerwanym połączeniu, system powinien najpierw sprawdzić stan wcześniejszej operacji. Pełna historia komunikacji, identyfikatory żądań i odpowiedzi oraz jasny status ostatniej udanej operacji pozwalają rozstrzygnąć, czy dokument wymaga ponownej wysyłki, korekty czy wyłącznie technicznego sprawdzenia. Przy dużej skali sprzedaży właśnie takie pozornie drobne mechanizmy decydują o tym, czy automatyzacja zmniejsza liczbę błędów, czy tylko pozwala tworzyć je szybciej.

Elektroniczne archiwum

Archiwum powinno być budowane wokół transakcji, a nie wokół pojedynczych plików. Dla jednej sprzedaży firma może posiadać dane zamówienia, fakturę ustrukturyzowaną, jej czytelną wizualizację, numer nadany przez system publiczny, techniczne potwierdzenie przekazania, późniejsze komunikaty o statusie, dokumentację transportową, korektę oraz informację o płatności. Jeżeli każdy z tych elementów trafia do innego folderu lub aplikacji, formalnie dokumenty mogą być zachowane, ale praktycznie odtworzenie przebiegu transakcji nadal wymaga pracy kilku osób. Lepszy model polega na tym, że z poziomu jednego rekordu można przejść do wszystkich związanych z nim dokumentów i zdarzeń. Użytkownik powinien widzieć zarówno aktualny stan faktury, jak i chronologiczną historię tego, co wydarzyło się od momentu złożenia zamówienia.

Nie należy przy tym utożsamiać archiwum z katalogiem plików PDF. W środowisku e-fakturowania kluczowe znaczenie ma odpowiednia struktura danych, natomiast PDF może pełnić funkcję wizualizacji dokumentu ustrukturyzowanego i ułatwiać jego odczyt użytkownikowi. System powinien więc zachowywać oryginalny komunikat, wersję struktury, identyfikatory nadane przez zewnętrzne systemy i informacje potwierdzające przebieg wymiany. Przy WDT do tej samej historii powinny zostać przypisane dowody związane z transportem, a po zapłacie także dane umożliwiające powiązanie należności z płatnością. W efekcie pełny zapis procesu powinien łączyć fakturę, dane strukturalne, wizualizację, identyfikatory, dokumenty transportowe, statusy i płatność. Takie archiwum służy nie tylko księgowości, ale także finansom, obsłudze klienta i osobom odpowiedzialnym za kontrolę procesu podczas dalszej ekspansji.

Faktura to dopiero początek. Przygotuj system również na statusy i płatności

Akceptacja i odrzucenie faktury

W klasycznym modelu fakturowania proces często kończy się w chwili, gdy dokument zostaje wygenerowany i wysłany klientowi. W hiszpańskim modelu e-fakturowania B2B to za mało. System powinien być przygotowany również na obsługę informacji o dalszym losie faktury, w szczególności jej akceptacji albo komercyjnego odrzucenia. Z punktu widzenia ERP warto rozdzielić dwa poziomy informacji: status techniczny, który mówi, czy dokument został wysłany i skutecznie dostarczony do właściwego kanału, oraz status biznesowy, który wskazuje, czy odbiorca fakturę zaakceptował, odrzucił albo zgłosił problem wymagający dalszej obsługi. Poprawne techniczne przekazanie dokumentu nie oznacza bowiem, że kontrahent uznał należność za prawidłową. Faktura może przejść walidację systemową, a następnie zostać odrzucona z powodu niezgodności z zamówieniem, błędnych warunków handlowych, różnicy w ilości towaru albo innego sporu dotyczącego samej transakcji.

Dla średniej firmy prowadzącej dużą liczbę transakcji ma to bezpośredni wpływ na organizację pracy. Odrzucona faktura nie powinna trafiać do ogólnej skrzynki e-mailowej ani wymagać ręcznego sprawdzania panelu zewnętrznego systemu. ERP powinien automatycznie powiązać komunikat z właściwym dokumentem i przekazać go do osoby odpowiedzialnej za dalsze działanie. Innego rodzaju reakcja będzie potrzebna przy błędzie w danych kontrahenta, innego przy rozbieżności cenowej, a jeszcze innego przy sporze dotyczącym dostawy. Dzięki temu status biznesowy faktury staje się elementem procesu finansowego, a nie dodatkową informacją funkcjonującą poza księgowością. Przy rosnącej sprzedaży pozwala to szybciej reagować na problemy i ograniczać liczbę dokumentów, które technicznie zostały dostarczone, ale w praktyce utknęły po stronie odbiorcy i blokują dalszy proces płatności.

Data rzeczywistej zapłaty

Kolejnym elementem, którego nie można traktować jako dodatku do faktury, jest informacja o pełnej faktycznej zapłacie. W hiszpańskim modelu znaczenie ma nie tylko termin płatności wpisany na dokumencie, lecz także moment, w którym należność została rzeczywiście uregulowana w całości. System finansowy powinien więc potrafić połączyć konkretną fakturę z informacją o pełnej zapłacie i przechowywać datę tego zdarzenia. To inna informacja niż data wymagalności, dzień zlecenia przelewu przez klienta czy data wystawienia dokumentu. W praktyce oznacza to konieczność integracji danych fakturowych z modułem należności, bankiem albo innym źródłem informacji o płatnościach. Jeżeli status jest aktualizowany ręcznie raz na kilka dni, firma może mieć problem z terminowym i prawidłowym odzwierciedleniem rzeczywistego stanu należności.

Dla przedsiębiorcy prowadzącego e-commerce taka integracja ma wartość znacznie wykraczającą poza sam obowiązek obsługi statusów. Pozwala mierzyć rzeczywisty czas od wystawienia faktury do zapłaty, szybciej identyfikować kontrahentów przekraczających terminy oraz oceniać, czy wzrost sprzedaży B2B nie jest finansowany coraz dłuższym kredytem kupieckim. System powinien więc odróżniać co najmniej termin płatności, datę otrzymania środków, moment pełnego rozliczenia należności oraz aktualne saldo faktury. Dopiero wtedy możliwe jest zbudowanie wiarygodnego obrazu należności. Jeżeli te dane znajdują się w różnych aplikacjach i nie są automatycznie synchronizowane, księgowość może uznawać fakturę za otwartą mimo zaksięgowanej płatności albo odwrotnie, a późniejsze przekazywanie informacji o pełnej zapłacie staje się kolejnym ręcznym procesem podatnym na błędy.

Płatności częściowe i spory

Nie każda faktura kończy się jednym przelewem na pełną kwotę. W sprzedaży B2B często występują zaliczki, płatności częściowe, potrącenia, kompensaty lub sytuacje, w których klient reguluje tylko część należności, ponieważ kwestionuje fragment dostawy. Dlatego system nie powinien ograniczać statusu faktury do prostego wyboru „zapłacona” albo „niezapłacona”. Powinien przechowywać kwotę już rozliczoną, saldo pozostałe do zapłaty, daty poszczególnych płatności oraz informacje o ewentualnym sporze. Hiszpańskie regulacje przewidują możliwość obsługi dodatkowych informacji dotyczących między innymi częściowych płatności czy częściowej akceptacji, co jeszcze bardziej przemawia za projektowaniem modelu danych w sposób bardziej szczegółowy niż tradycyjna flaga zapłacona/niezapłacona.

Ma to znaczenie także dla procesu korekt. Jeżeli klient kwestionuje część faktury, nie powinno się automatycznie traktować całego dokumentu jako odrzuconego albo całej należności jako bezspornej. ERP powinien pozwalać powiązać płatność z odpowiednią częścią zobowiązania oraz zachować informację o kwocie pozostającej przedmiotem wyjaśnienia. W przeciwnym razie dział finansowy może prowadzić windykację kwoty, która jest już przedmiotem uzgodnionej korekty, albo uznać fakturę za rozliczoną mimo pozostałego salda. Wraz ze wzrostem sprzedaży zagranicznej takie przypadki przestają być wyjątkami. Dlatego sposób obsługi płatności częściowych, korekt, kompensat i sporów powinien zostać zaprojektowany przed automatyzacją raportowania statusów, a nie dopiero wtedy, gdy pierwszy większy kontrahent zacznie rozliczać faktury w kilku transzach.

Automatyczne dopasowanie przelewu do faktury

Sama informacja o wpływie pieniędzy na rachunek nie wystarczy, jeśli system nie potrafi jednoznacznie określić, której należności dotyczy płatność. Przy niewielkiej liczbie klientów księgowość może ręcznie dopasowywać przelewy do dokumentów, ale przy dużej sprzedaży B2B proces szybko staje się wąskim gardłem. ERP powinien automatycznie analizować numer faktury, kwotę, dane płatnika, tytuł przelewu, unikalny identyfikator referencyjny płatności oraz inne dostępne dane pozwalające połączyć wpływ z właściwym dokumentem. Jest to istotne również dlatego, że kontrahenci w różnych krajach nie zawsze posługują się numerem faktury jako podstawową referencją przelewu. Jeżeli dopasowanie nie jest jednoznaczne, transakcja powinna trafić do kolejki wyjątków, zamiast zostać przypisana wyłącznie na podstawie zbliżonej kwoty albo nazwy płatnika.

Automatyczne uzgadnianie płatności pozwala zamknąć lukę pomiędzy bankiem a systemem fakturowania. Po prawidłowym dopasowaniu przelewu ERP może zmienić saldo należności, zarejestrować datę płatności, ustalić moment pełnego rozliczenia faktury i uruchomić dalszy komunikat dotyczący jej statusu. Jeśli wszystkie te czynności wymagają ręcznej pracy, firma może mieć technicznie poprawne e-fakturowanie, ale nadal działać na procesie finansowym, który nie skaluje się wraz ze sprzedażą. Dobrze zaprojektowana integracja powinna więc obejmować nie tylko generowanie i wysyłanie dokumentów, lecz również automatyczne zamykanie cyklu należności. Dzięki temu informacje przekazywane dalej wynikają z rzeczywistych danych bankowych i księgowych, a nie z ręcznej aktualizacji wykonywanej po otrzymaniu wyciągu.

Monitoring należności

Połączenie statusów faktur z danymi o płatnościach pozwala zbudować monitoring należności znacznie bardziej użyteczny niż zwykła lista dokumentów po terminie. Dział finansowy powinien widzieć, które faktury zostały wystawione, które skutecznie przekazano, które zostały zaakceptowane, które są przedmiotem sporu, które oczekują na zapłatę i które zostały później skorygowane. Dzięki temu można odróżnić klienta, który po prostu spóźnia się z przelewem, od sytuacji, w której płatność nie nastąpiła dlatego, że faktura została odrzucona albo zawiera nierozwiązaną rozbieżność. To istotna różnica. Automatyczne przypomnienie o płatności wysłane w trakcie trwającego sporu nie przyspieszy odzyskania należności, a może pogorszyć relację z klientem. System powinien więc wykorzystywać pełny status procesu, a nie wyłącznie liczbę dni od terminu płatności.

Docelowy raport powinien pozwalać prześledzić drogę dokumentu od momentu wystawienia aż do jego podatkowego i finansowego zamknięcia: wystawiona wysłana dostarczona zaakceptowana zapłacona skorygowana, jeżeli wystąpi korekta rozliczona podatkowo. Nie każda transakcja przejdzie przez wszystkie etapy w dokładnie tej kolejności, ponieważ korekta może pojawić się także wcześniej, a dokument może zostać odrzucony albo opłacony częściowo. Dlatego model powinien pozwalać na statusy wyjątkowe i zachowywać chronologię zmian. Dla zarządu taki raport daje odpowiedź nie tylko na pytanie, ile firma sprzedała, ale również jak szybko sprzedaż zamienia się w gotówkę, jaka część należności znajduje się w sporze i na którym etapie procesu najczęściej powstają problemy. Przy ekspansji zagranicznej właśnie ta widoczność pozwala odróżnić wzrost przychodów od rzeczywiście zdrowego wzrostu operacyjnego.

Co się stanie, jeśli tego nie zrobisz?

Możesz wystawiać faktury w niewłaściwym reżimie

Najbardziej podstawowy błąd wynika z pozornie logicznego założenia: skoro klient jest z Hiszpanii, każda sprzedaż powinna zostać obsłużona według jednego „hiszpańskiego” procesu. W rzeczywistości ta sama firma może jednocześnie realizować WDT z Polski, lokalne dostawy z hiszpańskiego magazynu, sprzedaż B2C rozliczaną przez OSS, usługi B2B oraz transakcje z administracją publiczną. Jeżeli ERP rozpoznaje tylko kraj odbiorcy, pojawiają się dwa odrębne rodzaje ryzyka. Pierwszym jest błędne rozliczenie VAT, na przykład zastosowanie niewłaściwego mechanizmu lub potraktowanie lokalnej sprzedaży tak jak transakcji transgranicznej. Drugim jest błędny kanał fakturowania, czyli skierowanie dokumentu do systemu, który w danej transakcji nie powinien być używany, albo pominięcie kanału, który jest wymagany. Te dwa błędy mogą wystąpić razem, ale nie muszą, dlatego system powinien kontrolować je niezależnie.

Ryzyko rośnie wraz ze skalą działalności, ponieważ błędna reguła w systemie nie powoduje jednego błędu. Powtarza go automatycznie dla każdej kolejnej transakcji spełniającej te same warunki. Jeżeli firma ma kilkuset hiszpańskich klientów i kilka magazynów, źle skonfigurowana logika może w krótkim czasie objąć tysiące dokumentów. Dlatego automatyzacja bez prawidłowej kwalifikacji podatkowej jest szczególnie niebezpieczna. System powinien najpierw odpowiedzieć na pytanie, czym jest transakcja i jak należy rozliczyć VAT, a niezależnie od tego określić, w jaki sposób faktura powinna zostać wystawiona i przekazana odbiorcy. W przeciwnym razie technologia przyspiesza nie tylko sprzedaż, lecz również powielanie błędnych decyzji podatkowych i technicznych.

Możesz stracić możliwość bezpiecznego zastosowania 0% VAT przy WDT

Przy WDT problem nie sprowadza się do tego, czy faktura została poprawnie wysłana. Stawka 0% VAT jest związana ze spełnieniem określonych warunków, w tym dotyczących statusu nabywcy, numeru VAT UE, rzeczywistego przemieszczenia towarów i wymaganej dokumentacji. Jeżeli firma nie kontroluje tych danych w jednym procesie, może stosować 0% na podstawie niepełnych informacji. Przy dużej liczbie wysyłek szczególnie łatwo o sytuację, w której faktura została oznaczona jako WDT, ale dowód transportu nie został pozyskany, nie został właściwie przypisany albo status VAT UE kontrahenta nie został odpowiednio zweryfikowany. W takim przypadku problem nie dotyczy już wygody działania systemu, lecz bezpieczeństwa samego rozliczenia podatku.

ERP powinien więc pozwalać odtworzyć ścieżkę decyzyjną i uzasadnienie kwalifikacji podatkowej, a nie tylko przechowywać końcowy rezultat „WDT”. Po czasie powinno być możliwe sprawdzenie, jakie dane były dostępne w momencie podjęcia decyzji, jaki status miał numer VAT UE kontrahenta, skąd i dokąd przemieszczał się towar oraz jakie dokumenty potwierdzały dostawę. Jeżeli po roku firma posiada wyłącznie końcową fakturę ze stawką 0%, ale nie potrafi szybko odtworzyć podstaw tej kwalifikacji, kontrola staje się znacznie trudniejsza. Przy ekspansji często jest to niewidoczny koszt wzrostu: sprzedaż rośnie szybciej niż proces zbierania dowodów. Dlatego automatyzacja WDT powinna obejmować zarówno decyzję podatkową, jak i dane, które pozwalają później wyjaśnić, dlaczego system podjął właśnie taką decyzję.

PDF może przestać wystarczać

Przez lata „e-faktura” dla wielu firm oznaczała po prostu PDF wygenerowany przez system księgowy i wysłany klientowi e-mailem. W modelu opartym na fakturze ustrukturyzowanej takie podejście nie wystarczy w transakcjach objętych obowiązkiem. Kluczowe stają się dane zapisane w wymaganej strukturze i przekazane w sposób, który pozwala systemowi odbiorcy automatycznie je odczytać. PDF może nadal pełnić funkcję wizualizacji dokumentu ustrukturyzowanego, ale sam fakt, że wygląda poprawnie i zawiera wszystkie informacje widoczne dla człowieka, nie oznacza zgodności z wymaganym procesem elektronicznym. Dla przedsiębiorcy oznacza to, że funkcja „generuj PDF” w obecnym systemie nie odpowiada jeszcze na pytanie, czy firma jest gotowa na hiszpańskie e-fakturowanie B2B.

Najczęstszy problem pojawi się w firmach, których system potrafi stworzyć poprawny dokument wizualny, ale nie przechowuje wszystkich danych w sposób umożliwiający ich prawidłowe mapowanie do wymaganej struktury. Wtedy przygotowanie e-faktury wymaga ręcznego uzupełniania pól albo dodatkowych transformacji poza ERP. Przy kilkunastu dokumentach miesięcznie można to obejść, lecz przy większej skali szybko powstaje kolejny manualny proces. Dlatego warto sprawdzić nie tylko, co obecny program potrafi wygenerować dla użytkownika, ale również jakie dane posiada pod spodem, jak je waliduje i czy może przekazać je przez API do właściwego kanału. W nowoczesnym obiegu faktur sposób prezentacji dokumentu pozostaje ważny dla człowieka, ale dla automatycznej wymiany równie istotna jest jakość, kompletność i struktura danych.

Ręczne przepisywanie danych zwiększy ryzyko rozbieżności

Ręczne przenoszenie informacji między sklepem, ERP, systemem księgowym, platformą do e-fakturowania i bankiem może działać przez długi czas, dopóki skala jest niewielka. Problem zaczyna się wtedy, gdy liczba zamówień rośnie, pojawiają się korekty, kilka magazynów i różne rejestracje VAT. Ta sama transakcja może wtedy mieć inną kwotę w systemie sprzedażowym, inną datę w księgowości i inny numer podatkowy klienta w narzędziu odpowiedzialnym za wysłanie dokumentu. Korekta może zostać poprawnie zaksięgowana, ale nie przesłana do właściwego kanału. Zmiana danych kontrahenta może zostać wprowadzona w CRM, lecz nie dotrzeć do systemu fakturowego. Im więcej systemów posiada własną kopię tych samych danych, tym większe ryzyko utraty spójności. Każdy kolejny ręczny punkt synchronizacji zwiększa też prawdopodobieństwo, że błąd zostanie zauważony dopiero po wystawieniu lub zaksięgowaniu dokumentu.

Jeszcze większym problemem jest utrata historii. Jeśli pracownik poprawia dane ręcznie przed wysłaniem faktury, ale zmiana nie trafia z powrotem do systemu źródłowego, po kilku miesiącach trudno ustalić, dlaczego ostateczny dokument różni się od pierwotnego zamówienia. To samo dotyczy statusów i płatności. Należność może zostać uznana za opłaconą w księgowości, ale nadal pozostawać otwarta w systemie obsługi klienta, przez co kontrahent otrzyma automatyczne przypomnienie. Integracje nie eliminują wszystkich błędów, ale pozwalają ograniczyć liczbę miejsc, w których człowiek musi ponownie wpisywać tę samą informację. Przy ekspansji jest to jedna z najważniejszych zasad projektowych: każde pole, które trzeba ręcznie przepisać pomiędzy systemami, staje się potencjalnym źródłem rozbieżności i dodatkowej pracy przy późniejszym uzgadnianiu danych.

Dowiesz się o problemie dopiero przy odrzuconej fakturze lub opóźnionej płatności

Najbardziej kosztowne problemy z fakturowaniem często nie pojawiają się podczas wdrożenia, lecz dopiero wtedy, gdy proces zaczyna wpływać na sprzedaż i cash flow. Jeżeli firma nie przetestowała sposobu przekazywania e-faktur, może przez długi czas zakładać, że wszystko działa prawidłowo, ponieważ dokument został wygenerowany i opuścił ERP. Dopiero komunikat od klienta, że faktura nie została przyjęta, pokaże, że zabrakło wymaganych danych, użyto niewłaściwego kanału albo status dokumentu nigdy nie wrócił do systemu finansowego. Jeszcze gorzej, jeśli problem zostanie zauważony dopiero dlatego, że płatność nie wpłynęła w terminie. Wtedy błąd techniczny zaczyna bezpośrednio wpływać na kapitał obrotowy i może blokować kolejne etapy współpracy z kontrahentem.

Przy ważnych klientach B2B jedna nieprzyjęta faktura może oznaczać przesunięcie płatności o cały kolejny cykl rozliczeniowy, szczególnie jeśli kontrahent ma sztywne terminy zamykania zobowiązań. Dlatego przygotowanie integracji nie powinno rozpoczynać się od dnia, w którym dotychczasowy kanał przestaje działać. Proces warto wcześniej przetestować na realistycznych scenariuszach: zwykłej fakturze, korekcie, odrzuceniu, ponowieniu wysyłki, płatności częściowej i pełnym rozliczeniu. Najdroższy moment na rozpoczęcie integracji to dzień, w którym kluczowy klient przestaje akceptować dotychczasowy sposób fakturowania, ponieważ od tego momentu projekt informatyczny przestaje być projektem rozwojowym i staje się projektem awaryjnym. W takim układzie firma traci przestrzeń na spokojne testowanie i musi jednocześnie naprawiać proces, chronić relację z klientem oraz pilnować, żeby problem z fakturą nie zamienił się w problem z płynnością.

Jak powinien wyglądać poprawny proces? Przykład od zamówienia do płatności

Identyfikacja klienta i weryfikacja danych przed sprzedażą

Załóżmy, że polska firma sprzedaje towar hiszpańskiemu kontrahentowi B2B, a zamówienie ma zostać zrealizowane z magazynu w Polsce. Proces powinien rozpocząć się jeszcze zanim system wystawi fakturę. ERP powinien ustalić status nabywcy na podstawie dostępnych danych, w tym numeru VAT UE i wyniku jego weryfikacji, a następnie zapisać informacje, które będą potrzebne do późniejszej kwalifikacji podatkowej. Sam fakt, że kontrahent podał nazwę firmy albo zaznaczył podczas składania zamówienia opcję „firma”, nie powinien wystarczać do automatycznego przypisania mu określonego statusu podatkowego. System powinien również wiedzieć, skąd towar będzie faktycznie wysyłany. Jeżeli zamówienie zostanie zrealizowane z Polski, analiza będzie inna niż w przypadku identycznego klienta, któremu ten sam produkt zostanie wysłany z zapasu znajdującego się już w Hiszpanii.

Dopiero na podstawie tych danych można przeprowadzić kwalifikację podatkową. Jeżeli towar przemieszcza się z Polski do Hiszpanii, a pozostałe warunki są spełnione, sprzedaż może zostać rozliczona jako WDT. System powinien zapisać nie tylko wynik tej decyzji, ale również jej ścieżkę decyzyjną: status klienta, wykorzystany numer VAT UE, wynik jego weryfikacji, miejsce rozpoczęcia i zakończenia transportu oraz informacje potrzebne do późniejszego potwierdzenia prawidłowości rozliczenia. Na tym etapie nie należy jeszcze wyciągać wniosku, że skoro odbiorcą jest firma z Hiszpanii, faktura powinna zostać skierowana do hiszpańskiego systemu B2B. Kwalifikacja VAT i ustalenie właściwego sposobu fakturowania są odrębnymi decyzjami, które mogą prowadzić do różnych rezultatów w ramach tej samej transakcji.

Wystawienie faktury i wybór właściwego kanału elektronicznego

Po prawidłowym zakwalifikowaniu transakcji system może przejść do wystawienia faktury. Jeżeli polski sprzedawca podlega obowiązkowi korzystania z KSeF dla danego dokumentu, faktura powinna zostać wystawiona w tym systemie zgodnie z polskimi zasadami, nawet jeśli jej odbiorcą jest zagraniczny kontrahent. To, że hiszpański klient nie korzysta z KSeF w taki sposób jak polski nabywca, nie jest samo w sobie podstawą do pominięcia polskiego obowiązku. Faktury dokumentujące między innymi WDT, eksport czy określone usługi dla zagranicznych podatników mogą podlegać obowiązkowi wystawienia w KSeF, jeżeli sprzedawca znajduje się w zakresie tego obowiązku. Zagranicznemu nabywcy dokument trzeba następnie przekazać dodatkowo w uzgodniony sposób, zgodnie z zasadami właściwymi dla danej transakcji.

W tym miejscu najłatwiej popełnić błąd wynikający z nadmiernej automatyzacji. ERP nie powinien działać według prostej reguły „hiszpański numer VAT = hiszpański kanał B2B”. Najpierw trzeba ustalić, czy konkretna transakcja podlega hiszpańskim zasadom fakturowania. Jeśli klasyczna sprzedaż towaru z Polski do hiszpańskiego podatnika jest po stronie polskiego sprzedawcy rozliczana jako WDT i nie znajduje się w zakresie hiszpańskiego obowiązku e-fakturowania B2B, system nie powinien wysyłać dokumentu do tego obiegu tylko dlatego, że odbiorca ma adres lub numer podatkowy w Hiszpanii. Kanał elektroniczny powinien być skutkiem prawidłowej kwalifikacji, a nie skrótem zastępującym analizę. Dlatego system powinien osobno przechowywać informację o tym, gdzie faktura została formalnie wystawiona, jak została przekazana odbiorcy oraz czy konkretna transakcja podlega dodatkowemu lokalnemu obowiązkowi.

Transport, potwierdzenie dostawy i kompletowanie dokumentacji

Po wystawieniu dokumentu proces podatkowy nadal nie jest zakończony. W przypadku WDT system powinien śledzić fizyczne przemieszczenie towaru i umożliwiać powiązanie dokumentów dotyczących transportu z konkretną sprzedażą. Numer przesyłki, dane przewoźnika, potwierdzenia odbioru oraz inne dokumenty związane z przemieszczeniem towaru nie powinny funkcjonować jako luźne załączniki w skrzynkach pocztowych pracowników. Powinny zostać przypisane do tego samego rekordu, w którym znajdują się zamówienie, klient i faktura. Dzięki temu można później szybko odtworzyć, że określony towar faktycznie opuścił Polskę i dotarł do innego państwa członkowskiego, a także sprawdzić kompletność dokumentacji wymaganej dla zastosowania stawki 0%, ocenianej zgodnie z polskimi przepisami i właściwymi zasadami unijnymi.

Warto również rozdzielić potwierdzenie fizycznego dostarczenia towaru od statusu elektronicznej faktury. Kurier może potwierdzić odbiór przesyłki, podczas gdy dokument finansowy nadal oczekuje na przetworzenie albo został odrzucony z przyczyn biznesowych. To dwa różne procesy, choć dotyczą tej samej sprzedaży. Dobrze zaprojektowany ERP powinien pokazać oba stany równolegle: towar dostarczony, faktura przekazana, status dokumentu, stan należności oraz kompletność dowodów dotyczących WDT. Dzięki temu księgowość nie musi wnioskować o prawidłowości całej transakcji na podstawie jednego zielonego statusu w systemie logistycznym.

Dopasowanie płatności i zamknięcie należności

Kiedy klient dokonuje płatności, system powinien automatycznie spróbować dopasować wpływ do właściwej faktury. Może wykorzystać numer dokumentu, kwotę, dane płatnika, tytuł przelewu oraz unikalny identyfikator referencyjny. Jeżeli płatność obejmuje kilka faktur albo kwota nie zgadza się z saldem, transakcja powinna trafić do obsługi wyjątków, a nie zostać automatycznie zamknięta na podstawie niedokładnego dopasowania. Po prawidłowym rozliczeniu system powinien zapisać datę płatności, aktualne saldo i moment pełnej faktycznej zapłaty. Jeżeli wcześniej wystąpiła płatność częściowa, korekta, kompensata lub spór, historia tych zdarzeń powinna pozostać widoczna także po ostatecznym zamknięciu należności.

Tak skonfigurowany proces daje znacznie więcej niż automatyczne księgowanie banku. Pozwala powiązać sprzedaż, fakturę, transport i gotówkę w jednym ciągu zdarzeń. Dział finansowy może wtedy zobaczyć, czy opóźnienie płatności wynika z zachowania kontrahenta, odrzucenia faktury, brakującej korekty czy problemu technicznego z jej przekazaniem. W przypadku transakcji objętych hiszpańskimi wymogami dotyczącymi statusów płatności system posiada już dane potrzebne do dalszej obsługi komunikatów, zamiast wymagać ich ręcznego odtwarzania po kilku dniach. Jest to szczególnie istotne w modelu, w którym podstawowym raportowanym zdarzeniem jest pełna faktyczna zapłata, a dodatkowo mogą pojawiać się informacje o płatnościach częściowych.

Raportowanie VAT i zamknięcie ścieżki podatkowej

Ostatnim etapem jest prawidłowe ujęcie transakcji w rozliczeniach VAT. W przypadku WDT system powinien powiązać sprzedaż z właściwą ewidencją oraz informacją podsumowującą VAT-UE, zgodnie z obowiązującymi warunkami i statusem rejestracyjnym podatnika. Powinien również kontrolować, czy dane użyte przy rozliczeniu są zgodne z tym, co zostało zapisane w procesie sprzedażowym: numer VAT UE kontrahenta, wartość transakcji, data oraz status dokumentacji dotyczącej przemieszczenia towarów. Dzięki temu raportowanie nie jest osobnym procesem, w którym księgowość ponownie rekonstruuje transakcję, ale ostatnim etapem tego samego przepływu danych rozpoczętego w chwili przyjęcia zamówienia.

W poprawnym modelu firma może więc prześledzić całą sprzedaż od identyfikacji klienta, przez kwalifikację podatkową, wystawienie i przekazanie faktury, transport, kompletowanie dokumentacji i płatność, aż po raportowanie VAT. Najważniejsza zasada pozostaje przy tym niezmienna: jeżeli konkretna transakcja nie podlega hiszpańskim regułom fakturowania B2B, system nie powinien automatycznie wysyłać jej do hiszpańskiego obiegu tylko dlatego, że kontrahent ma siedzibę w Hiszpanii. Automatyzacja powinna realizować decyzję wynikającą z prawidłowej kwalifikacji, a nie zastępować tę kwalifikację.

Checklist: czy Twój system jest gotowy na sprzedaż do Hiszpanii?

Przed rozpoczęciem większej ekspansji warto sprawdzić nie tylko, czy system potrafi wystawić fakturę dla zagranicznego klienta, ale czy rozumie cały kontekst transakcji. Poniższa lista pozwala szybko wychwycić najważniejsze luki w konfiguracji ERP, księgowości i integracjach.

• System rozróżnia klientów B2B, B2C i B2G.
• System potrafi odróżnić sprzedaż towaru od świadczenia usługi i zastosować właściwą logikę podatkową.
• Wiemy, z którego magazynu rozpoczyna się transport w każdej transakcji i informacja ta trafia do ERP.
• Weryfikujemy numery VAT UE i zapisujemy wynik oraz datę weryfikacji.
• System potrafi rozpoznać między innymi WDT, WSTO i sprzedaż lokalną oraz zastosować właściwy mechanizm rozliczenia, na przykład reverse charge lub OSS.
• Rozdzielamy decyzję o sposobie rozliczenia VAT od decyzji o sposobie wystawienia i przekazania faktury.
• KSeF nie jest utożsamiany z hiszpańskim e-fakturowaniem, a obowiązek korzystania z każdego systemu jest analizowany osobno.
• System potrafi wygenerować i przekazać dane w wymaganym formacie strukturalnym, mapować je do odpowiedniego schematu oraz walidować przed wysyłką.
• Przechowujemy dokumenty transportowe, potwierdzenia i inne dowody potrzebne do uzasadnienia kwalifikacji podatkowej zgodnie z właściwymi przepisami.
• ERP zapisuje ścieżkę decyzyjną, dzięki której można później odtworzyć, dlaczego dana transakcja została rozliczona w określony sposób.
• System rozróżnia status techniczny faktury od jej statusu biznesowego oraz przechowuje informacje o korektach i płatnościach.
• Płatności są automatycznie lub półautomatycznie dopasowywane do właściwych dokumentów z użyciem numerów faktur i identyfikatorów referencyjnych.
• Wiemy, czy magazyn, lokalna rejestracja VAT albo inna obecność w Hiszpanii powoduje dodatkowe obowiązki dla konkretnych transakcji.
• Proces obsługi błędów, odrzuceń, duplikatów, korekt i ponowień wysyłki został przetestowany na realistycznych scenariuszach.
• Firma monitoruje kolejne etapy wejścia hiszpańskich regulacji w życie i potrafi zmienić reguły bez przebudowy całego ERP.
• Dla każdej transakcji można odtworzyć pełną historię od zamówienia, przez fakturę i transport, aż po płatność i raportowanie VAT.

Jeżeli na kilka z tych punktów odpowiedź brzmi „nie” albo „nie wiemy”, nie musi to jeszcze oznaczać konieczności wymiany całego systemu. Często większe znaczenie ma uporządkowanie danych, rozdzielenie logiki podatkowej od kanałów fakturowania i poprawienie integracji pomiędzy istniejącymi rozwiązaniami. Warto jednak zrobić to przed zwiększeniem wolumenu sprzedaży, ponieważ każda ręczna czynność, która przy stu zamówieniach miesięcznie jest tylko niedogodnością, przy kilku tysiącach może stać się stałym źródłem błędów, kosztów i opóźnień w płatnościach.

Kiedy warto skonsultować model sprzedaży do Hiszpanii?

Im bardziej złożony model sprzedaży, tym mniej wystarcza standardowa konfiguracja

Konsultacja staje się szczególnie potrzebna wtedy, gdy działalność w Hiszpanii przestaje sprowadzać się do prostego wysyłania towaru z Polski do jednego rodzaju klientów. Pierwszym sygnałem jest zwykle pojawienie się lokalnego magazynu lub zapasu. Od tego momentu część zamówień może być realizowana jako sprzedaż transgraniczna, a część jako dostawy lokalne, mimo że z perspektywy sklepu internetowego klient nadal znajduje się w tym samym kraju. Podobnie jest z hiszpańską rejestracją VAT. Sam lokalny numer podatkowy nie przesądza jeszcze, że cała sprzedaż powinna być rozliczana lub fakturowana według hiszpańskich zasad, ale oznacza, że trzeba ustalić, do których transakcji dana rejestracja faktycznie się odnosi. Jeszcze bardziej złożona analiza może być potrzebna, gdy firma posiada strukturę mogącą stanowić stałe miejsce prowadzenia działalności. Magazyn, rejestracja VAT i stałe miejsce prowadzenia działalności pozostają odrębnymi zagadnieniami i nie powinny być automatycznie sprowadzane do jednego statusu w ERP.

Drugim momentem, w którym warto zweryfikować model, jest łączenie kilku kanałów i rodzajów sprzedaży. Firma może jednocześnie prowadzić B2B, sprzedaż konsumencką przez OSS, dostawy ze stocku w Hiszpanii, usługi oraz pojedyncze kontrakty z sektorem publicznym. Jeżeli do tego dochodzą różne magazyny lub operatorzy logistyczni, samo pytanie „jak wystawić fakturę do Hiszpanii?” przestaje mieć jedną odpowiedź. Trzeba najpierw określić sposób rozliczenia VAT, a następnie osobno ustalić obowiązek fakturowania i właściwy kanał techniczny. Konsultacji wymaga również sytuacja, w której dział księgowy nie potrafi jednoznacznie odpowiedzieć, czy konkretną fakturę obejmują polskie zasady i KSeF, hiszpański model B2B, lokalny obieg B2G czy inny sposób dokumentowania. Im więcej takich decyzji jest dziś podejmowanych ręcznie przez pojedyncze osoby, tym większe ryzyko, że wzrost sprzedaży zacznie zwiększać nie tylko przychody, ale również liczbę błędów i wyjątków wymagających ręcznej obsługi.

Najpierw zweryfikuj obowiązki, dopiero potem projektuj integrację

Najbardziej użyteczna konsultacja nie powinna zaczynać się od pytania, jakie narzędzie wdrożyć do hiszpańskiego e-fakturowania. Najpierw trzeba odwzorować rzeczywisty model biznesowy: kto kupuje, co jest sprzedawane, z którego kraju lub magazynu rozpoczyna się dostawa, jakie numery VAT posiada firma, gdzie powstają lokalne obowiązki oraz które przepisy regulują wystawienie konkretnego dokumentu. Dopiero na tej podstawie można ustalić, jakie dane powinny znaleźć się w ERP, jakie reguły należy zautomatyzować i które kanały elektroniczne rzeczywiście będą potrzebne. Takie podejście ogranicza ryzyko zbudowania kosztownej integracji dla transakcji, które wcale jej nie wymagają, albo pominięcia procesu, który stanie się istotny po zmianie modelu logistycznego, uruchomieniu lokalnego magazynu czy rozszerzeniu działalności o nowy segment klientów.

W przypadku sprzedaży do Hiszpanii amavat może wspierać firmę przede wszystkim w weryfikacji obowiązków VAT i fakturowania oraz ustaleniu właściwego modelu rozliczeń dla konkretnych przepływów sprzedażowych. Jest to szczególnie istotne przed uruchomieniem lokalnego magazynu, zmianą sposobu realizacji zamówień, wejściem w B2B albo zwiększeniem skali działalności wymagającej kolejnych rejestracji VAT. Rezultatem takiej analizy powinien być nie tylko wykaz obowiązków, lecz również jasny podział transakcji na scenariusze, który można następnie przełożyć na reguły w ERP i procesach finansowych. Dzięki temu system księgowy nie musi zgadywać na podstawie kraju klienta, a zespół IT otrzymuje konkretną logikę biznesową, którą można bezpiecznie zautomatyzować.

FAQ – sprzedaż do Hiszpanii i e-fakturowanie

Czy każda polska firma sprzedająca do Hiszpanii będzie musiała korzystać z hiszpańskiego systemu e-faktur?

Nie. Sam fakt, że klient ma siedzibę w Hiszpanii, nie oznacza automatycznie objęcia faktury hiszpańskim systemem B2B. Trzeba ustalić, jakie przepisy regulują obowiązek fakturowania w konkretnej transakcji. Klasycznej dostawy z Polski do hiszpańskiego podatnika, rozliczanej jako WDT, nie należy automatycznie traktować jak krajowej sprzedaży B2B w Hiszpanii.

Czy fakturę dla hiszpańskiego klienta trzeba wystawić w KSeF?

Jeżeli polski sprzedawca znajduje się w zakresie obowiązkowego KSeF, faktury dokumentujące między innymi WDT, eksport towarów czy świadczenie usług na rzecz zagranicznych podatników co do zasady również wystawia w KSeF. To, że zagraniczny klient nie odbiera faktury przez KSeF tak jak polski nabywca, nie oznacza braku obowiązku po stronie wystawcy. Dokument trzeba następnie przekazać odbiorcy w sposób przewidziany przepisami i uzgodniony między stronami.

Czy PDF wysłany e-mailem nadal wystarczy?

Nie w przypadku transakcji objętych obowiązkiem faktury ustrukturyzowanej. PDF może nadal pełnić funkcję czytelnej wizualizacji dokumentu, ale nie zastępuje wymaganych danych strukturalnych. System powinien potrafić nie tylko wygenerować dokument dla użytkownika, ale również zwalidować dane, zamapować je do właściwej struktury i przekazać odpowiednim kanałem.

Czy sprzedaż B2B i B2C do Hiszpanii rozlicza się tak samo?

Nie. W B2B trzeba analizować między innymi WDT, miejsce świadczenia usług i możliwość zastosowania reverse charge. W B2C znaczenie mogą mieć WSTO, państwo konsumpcji i procedura OSS. Status klienta powinien więc być jednym z pierwszych parametrów branych pod uwagę przez ERP.

Czy posiadanie magazynu w Hiszpanii zmienia obowiązki?

Może je istotnie zmienić. Sprzedaż towaru wysłanego z Polski do Hiszpanii i sprzedaż tego samego produktu z zapasu znajdującego się już w Hiszpanii mogą wymagać innej kwalifikacji podatkowej. Sam magazyn nie oznacza jednak automatycznie powstania stałego miejsca prowadzenia działalności ani objęcia każdej faktury hiszpańskim e-fakturowaniem.

Jakie dane hiszpańskiego kontrahenta powinien przechowywać system księgowy?

System powinien rozpoznawać status B2B, B2C lub B2G oraz przechowywać właściwe identyfikatory podatkowe, na przykład lokalny NIF oraz, odrębnie, numer VAT UE i wynik jego weryfikacji w VIES. Ważne są również adres siedziby i dostawy, dane potrzebne do obsługi jednostek publicznych, warunki płatności oraz właściwy kanał przekazywania dokumentów. NIF nie powinien być traktowany jako automatyczne potwierdzenie aktywnego statusu VAT UE.

Czy KSeF i hiszpański system e-fakturowania można obsługiwać z jednego ERP?

Tak, jeżeli ERP oddziela dane biznesowe od poszczególnych kanałów fakturowania. Jeden system może być źródłem danych dla KSeF, hiszpańskiego obiegu B2B i procesów B2G, ale powinien najpierw ustalać, który obowiązek dotyczy konkretnej transakcji. Dzięki temu jedno źródło danych może obsługiwać wiele różnych kanałów bez mieszania ich logiki.

Kiedy przy sprzedaży do Hiszpanii można zastosować 0% VAT?

WDT z Polski do Hiszpanii może korzystać ze stawki 0%, jeżeli spełnione są warunki przewidziane w przepisach. Znaczenie mają między innymi właściwy status i numer VAT UE nabywcy, rzeczywiste przemieszczenie towaru, odpowiednia dokumentacja oraz prawidłowe wykonanie obowiązków ewidencyjnych i raportowych. System powinien przechowywać ścieżkę decyzyjną pozwalającą później uzasadnić zastosowaną kwalifikację, ponieważ samo pojedyncze potwierdzenie dostawy nie zawsze wyczerpuje wymagania konkretnego przypadku.