KSeF a zwroty i reklamacje w e-commerce: jak obsługiwać korekty przy dużej liczbie zamówień?

KSeF zmienia sposób wystawiania i obiegu faktur, ale sam w sobie nie automatyzuje procesu zwrotu ani reklamacji. System nie wie, że klient odesłał jeden z trzech zakupionych produktów, że magazyn zaakceptował zwrot, że reklamacja zakończyła się obniżeniem ceny albo że dział obsługi zdecydował o wymianie towaru. KSeF obsługuje dokument faktury, natomiast informacje o tym, co faktycznie wydarzyło się w procesie sprzedaży, powstają poza nim. Przy większej skali kluczowe staje się więc stworzenie ciągłego powiązania między zamówieniem, konkretną pozycją zamówienia, zwrotem lub reklamacją, fakturą pierwotną oraz wystawioną później korektą. W dobrze zaprojektowanym procesie odpowiednie zdarzenie biznesowe powinno uruchamiać właściwą ścieżkę dokumentową, a firma powinna móc bez ręcznego przeszukiwania kilku systemów ustalić, dlaczego powstała dana korekta i jakiej sprzedaży dotyczy.

W e-commerce trzeba przy tym pamiętać o istotnym rozróżnieniu między sprzedażą B2B i B2C. Faktury wystawiane konsumentom nie są objęte obowiązkowym KSeF także po wejściu obligatoryjnego systemu, chociaż przedsiębiorca może dobrowolnie wystawiać je za jego pośrednictwem. Oznacza to, że nie każdy zwrot konsumencki w sklepie internetowym będzie automatycznie oznaczał konieczność obsługi faktury korygującej w KSeF. Zasady opisane poniżej dotyczą przede wszystkim dokumentów, które faktycznie zostały wystawione w KSeF, niezależnie od tego, czy trafiły tam w ramach obowiązku, czy decyzji przedsiębiorcy o dobrowolnym korzystaniu z systemu. Dla firm prowadzących jednocześnie sprzedaż konsumencką i biznesową oznacza to potrzebę rozdzielenia procesów, ponieważ ten sam rodzaj zdarzenia, na przykład zwrot produktu, może uruchamiać inną ścieżkę dokumentową w zależności od statusu nabywcy i sposobu wystawienia faktury pierwotnej.

Zwrot lub reklamacja w KSeF nie oznacza anulowania faktury

W obsłudze zwrotów i reklamacji jednym z najważniejszych założeń jest rozdzielenie samego zdarzenia handlowego od dokumentu, który został już skutecznie wystawiony. Klient może odstąpić od umowy, zwrócić cały zakup, odesłać jedną pozycję z większego zamówienia albo złożyć reklamację, która zakończy się obniżką ceny. Takie zdarzenie zmienia ekonomiczny obraz transakcji, ale nie powoduje, że wcześniejsza faktura wystawiona w KSeF może zostać po prostu cofnięta, usunięta lub zastąpiona nową wersją. Dlatego przy projektowaniu procesów nie wystarczy wiedzieć, że „pojawił się zwrot”. Trzeba również ustalić status dokumentu źródłowego, rodzaj zdarzenia, jego skutek finansowy oraz to, czy istnieje podstawa do wystawienia faktury korygującej. Dopiero połączenie tych informacji pozwala zdecydować, jaki dokument powinien powstać i w którym momencie należy przekazać go do KSeF.

Dlaczego faktury przyjętej przez KSeF nie można po prostu usunąć lub zmienić?

Jeżeli faktura została skutecznie przesłana do KSeF, pozytywnie zweryfikowana i otrzymała numer KSeF, weszła do obrotu jako wystawiony dokument. Nie można później otworzyć jej w systemie, zmienić niewłaściwej ceny, podmienić danych nabywcy, usunąć jednej pozycji i zapisać poprawionej wersji w miejsce poprzedniej. Błędy lub późniejsze zmiany dotyczące transakcji są dokumentowane za pomocą faktury korygującej. Korekta nie zastępuje przy tym faktury pierwotnej, lecz tworzy kolejny element historii transakcji i pokazuje, co oraz z jakiego powodu zostało zmienione. Zależnie od sytuacji może wykazywać zmianę podstawy opodatkowania, kwoty VAT, ilości lub ceny towaru albo innych danych znajdujących się na fakturze. Dla firmy prowadzącej e-commerce oznacza to konieczność zachowania trwałego powiązania pomiędzy dokumentem pierwotnym i każdą kolejną korektą, zamiast traktowania korekty jako nowej wersji wcześniejszej faktury.

Inaczej wygląda sytuacja, gdy plik XML zostanie przesłany do KSeF, ale nie przejdzie pozytywnie weryfikacji. W takim przypadku system nie przydziela numeru KSeF, a faktura nie zostaje skutecznie wystawiona w KSeF. Nie wystawia się więc korekty do odrzuconego dokumentu, lecz usuwa przyczynę błędu i ponownie przesyła prawidłowy plik. Z perspektywy integracji oznacza to, że status „wysłana” nie może być utożsamiany ze statusem „przyjęta”. System obsługujący sprzedaż powinien rozróżniać co najmniej dokument przygotowany, przekazany do wysyłki, znajdujący się w przetwarzaniu, przyjęty z nadanym numerem KSeF oraz odrzucony. Pozytywne przetworzenie i nadanie numeru KSeF powinno stanowić potwierdzenie skutecznego wystawienia dokumentu w systemie, nie oznacza to jednak, że data przydzielenia tego numeru jest zawsze datą wystawienia faktury.

W standardowym trybie online datą wystawienia faktury jest co do zasady data jej przesłania do KSeF, przy zachowaniu właściwych zasad dotyczących daty wskazywanej w strukturze faktury. W praktyce dokument może więc zostać wysłany późnym wieczorem jednego dnia, a numer KSeF otrzymać dopiero po północy następnego dnia, bez zmiany wynikającej z tego faktu daty jego wystawienia. To rozróżnienie jest szczególnie istotne na przełomie dnia, miesiąca lub okresu rozliczeniowego, ponieważ system finansowo-księgowy nie powinien automatycznie utożsamiać momentu otrzymania numeru KSeF z datą wystawienia. Trzeba również pamiętać, że KSeF przewiduje tryby inne niż standardowy obieg online, między innymi rozwiązania stosowane przy wystawianiu faktur offline. W takich przypadkach zasady ustalania momentu wystawienia i późniejszego przekazywania dokumentów do KSeF mogą wyglądać inaczej, dlatego logika automatyzacji powinna uwzględniać tryb, w którym powstała faktura.

Kiedy wystawić korektę, a kiedy poprawić i ponownie wysłać fakturę?

Podstawowy podział zaczyna się od ustalenia, czy faktura została już skutecznie przyjęta przez KSeF. Jeżeli przesłany plik został odrzucony, nie ma wystawionej w KSeF faktury, do której należałoby tworzyć korektę. Dane trzeba poprawić i ponowić wysyłkę. Jeżeli natomiast dokument został pozytywnie przetworzony i otrzymał numer KSeF, późniejszego błędu lub zmiany dotyczącej transakcji nie naprawia się poprzez przesłanie poprawionej wersji tej samej faktury. W zależności od rodzaju zdarzenia konieczne może być wystawienie faktury korygującej. Pełny zwrot całego zakupu może prowadzić do korekty zmniejszającej odpowiednie wartości do zera, natomiast przy zwrocie częściowym korekta powinna odzwierciedlać faktyczny zakres zmiany, na przykład jedną zwróconą pozycję albo część jej ilości. Jeżeli reklamacja kończy się obniżeniem ceny, jej skutkiem może być korekta in minus. Sama wymiana wadliwego produktu na sprawny egzemplarz, bez zmiany ceny, nabywcy i pozostałych danych wymagających korekty, nie musi natomiast prowadzić do zmiany faktury.

Ważne jest jednak, aby w dużym e-commerce nie sprowadzać automatyzacji do prostej reguły „magazyn przyjął zwrot, więc wystaw korektę”. Przyjęcie paczki jest zdarzeniem operacyjnym, ale nie zawsze samo w sobie przesądza o momencie i sposobie ujęcia skutków podatkowych. Bezpieczniejszy proces zakłada, że po zaakceptowaniu zwrotu system ustala jego rzeczywisty skutek finansowy, weryfikuje warunki wymagane do dokonania korekty, a dopiero następnie generuje fakturę korygującą i przekazuje ją do KSeF. Po wysyłce powinien jeszcze monitorować wynik przetwarzania i zapisać numer KSeF korekty albo skierować odrzucony dokument do odpowiedniej obsługi. Przy kilku zwrotach miesięcznie taki ciąg czynności można kontrolować ręcznie. Przy setkach lub tysiącach przypadków jego prawidłowe zaprojektowanie decyduje o tym, czy automatyzacja rzeczywiście ogranicza pracę operacyjną, czy jedynie szybciej powiela te same błędy.

Osobnej ścieżki wymagają błędy dotyczące nabywcy. Jeżeli wskazany na fakturze NIP identyfikuje inny podmiot niż rzeczywisty nabywca, nie koryguje się tego numeru na właściwy w ramach jednej faktury korygującej tak, jak można skorygować cenę lub inną daną transakcji. Faktura została bowiem w KSeF przypisana do niewłaściwego podatnika. W takiej sytuacji należy wystawić korektę do zera odnoszącą się do dokumentu wystawionego na błędnego nabywcę, a następnie wystawić nową fakturę pierwotną z prawidłowymi danymi rzeczywistego nabywcy. Jest to istotne zwłaszcza w sprzedaży B2B, gdzie dane do faktury mogą pochodzić bezpośrednio z formularza zamówienia, konta klienta albo integracji z innym systemem. Automatyczne przepisanie błędnego NIP do dokumentu może więc uruchomić znacznie bardziej złożony proces niż zwykła korekta wartości.

Właśnie dlatego system obsługujący sprzedaż nie powinien traktować wszystkich zwrotów, reklamacji i błędów fakturowych jako jednego typu zdarzenia. Pełny zwrot, zwrot jednej pozycji, częściowe obniżenie ceny, wymiana reklamacyjna, odrzucony przez KSeF plik oraz faktura wystawiona na innego nabywcę mogą na pierwszy rzut oka wyglądać jak zadania dla księgowości, ale wymagają różnych działań. Przy większej skali najważniejsza staje się więc nie sama możliwość technicznego wygenerowania faktury korygującej, lecz prawidłowe rozpoznanie zdarzenia, określenie jego skutku i skierowanie go do właściwej ścieżki. Dopiero na końcu tego procesu powinno pojawić się wygenerowanie dokumentu i przekazanie go do KSeF.

Czy ten temat dotyczy Twojego e-commerce?

Nie każdy sklep internetowy od razu potrzebuje rozbudowanego modelu obsługi korekt. Jeżeli firma wystawia niewiele faktur, ma niski poziom zwrotów i większość przypadków można szybko prześledzić od zamówienia do dokumentu księgowego, prostszy proces może być wystarczający. Sytuacja zmienia się jednak wraz ze wzrostem sprzedaży, liczbą kanałów oraz podziałem odpowiedzialności pomiędzy zespoły. Im więcej danych musi przejść między obsługą klienta, magazynem, sprzedażą, płatnościami i księgowością, tym większe znaczenie ma nie samo wystawienie korekty, lecz zachowanie spójności całej historii transakcji. Dla rozwijającego się e-commerce KSeF jest więc dobrym momentem, aby sprawdzić, czy proces zwrotów i reklamacji nadal odpowiada skali biznesu, czy opiera się już na ręcznym łączeniu informacji, które przy dalszej ekspansji zacznie generować opóźnienia, dodatkową pracę i większe ryzyko błędów.

Powinieneś uporządkować proces korekt szczególnie wtedy, gdy…

Pierwszym sygnałem ostrzegawczym jest sytuacja, w której zwrotu nie da się prześledzić od początku do końca w jednym spójnym procesie. Klient zgłasza go w jednym miejscu, magazyn rejestruje przyjęcie produktu gdzie indziej, informacja o zwrocie pieniędzy znajduje się w systemie płatniczym, a księgowość osobno szuka faktury, której dotyczy dana operacja. Przy kilkunastu zamówieniach można jeszcze polegać na numerze zamówienia, wiadomości e-mail albo wiedzy konkretnego pracownika. Przy większej skali taka metoda przestaje być bezpieczna. Szczególnie dotyczy to sklepów, które regularnie obsługują zwroty częściowe, prowadzą jednocześnie sprzedaż B2B i B2C, korzystają z kilku kanałów sprzedaży albo wystawiają faktury obejmujące wiele produktów. W takich warunkach jeden zwrot nie oznacza już prostego scenariusza „zamówienie – faktura – korekta”, lecz wymaga ustalenia, która pozycja została zwrócona, jaki był jej udział w wartości transakcji i jaką ścieżkę dokumentową należy uruchomić.

Uporządkowania wymagają również procesy, w których korekty nadal są wystawiane ręcznie lub inicjowane na podstawie wiadomości przekazywanej między działami. Jeżeli pracownik księgowości musi samodzielnie odnajdywać fakturę odpowiadającą konkretnemu zwrotowi, porównywać pozycje z zamówieniem i sprawdzać, czy towar został rzeczywiście zaakceptowany przez magazyn, firma już dziś ponosi koszt braku integracji danych. Wraz ze wzrostem sprzedaży koszt ten rośnie szybciej niż liczba zamówień, ponieważ przybywa nie tylko dokumentów, ale również sytuacji nietypowych. Dodatkową komplikacją są zewnętrzne kanały sprzedaży, w których numer zamówienia, identyfikator produktu czy dane klienta mogą wyglądać inaczej niż w systemach wewnętrznych. Im częściej człowiek musi ręcznie ustalać, które rekordy opisują tę samą transakcję, tym większe jest ryzyko, że korekta zostanie przypisana do niewłaściwej faktury albo obejmie niewłaściwą pozycję.

Kiedy problem zaczyna być problemem skali?

Nie istnieje jedna liczba zamówień, po której e-commerce automatycznie powinien przebudować proces korekt. Dwa sklepy obsługujące po kilka tysięcy transakcji miesięcznie mogą mieć zupełnie inny poziom trudności. Jeden sprzedaje pojedyncze produkty, ma niski odsetek zwrotów i jeden kanał sprzedaży. Drugi realizuje zamówienia wielopozycyjne, prowadzi kilka wersji sklepu, sprzedaje przez dodatkowe kanały, obsługuje B2B i B2C, a reklamacje mogą kończyć się zwrotem, wymianą, rabatem albo częściową rekompensatą. W drugim przypadku rzeczywista złożoność procesu będzie wielokrotnie większa mimo podobnej liczby faktur. Problemem skali nie jest więc sama liczba dokumentów, lecz liczba możliwych relacji między zamówieniem, pozycjami, płatnością, zwrotem, magazynem, fakturą pierwotną i korektami.

Dobrym miernikiem dojrzałości procesu jest liczba przypadków, w których system nie potrafi samodzielnie odpowiedzieć na podstawowe pytania. Jeśli trzeba ręcznie ustalić, której faktury dotyczy zwrot, czy klient zwrócił jedną czy kilka pozycji, jaka wartość powinna zostać skorygowana albo czy dana reklamacja została już finansowo rozliczona, firma zaczyna mieć problem skali niezależnie od tego, czy obsługuje tysiąc, czy dziesięć tysięcy zamówień miesięcznie. Najbardziej kosztowne są właśnie wyjątki, ponieważ wymagają czasu pracowników i ograniczają możliwość pełnej automatyzacji. Dobrze zaprojektowany proces nie musi eliminować wszystkich nietypowych sytuacji. Powinien natomiast automatycznie obsługiwać przypadki standardowe, a wyjątki jednoznacznie wykrywać i kierować do ręcznej weryfikacji, zamiast pozostawiać pracownikowi samodzielne odkrywanie, że czegoś w danych brakuje.

Jak powinna wyglądać korekta zwrotu lub reklamacji w KSeF?

Faktura korygująca powinna wynikać z konkretnego zdarzenia i pozostawać jednoznacznie związana z dokumentem, którego dotyczy. W środowisku e-commerce jest to szczególnie ważne, ponieważ jedna transakcja może przejść przez kilka systemów, a zwrot nie zawsze obejmuje całe zamówienie. Dlatego poprawna korekta nie zaczyna się w momencie tworzenia dokumentu XML. Zaczyna się wcześniej, gdy firma potrafi ustalić, która sprzedaż została zmieniona, jaka była przyczyna tej zmiany, które pozycje są nią objęte i jaki jest jej skutek finansowy. Dopiero na tej podstawie można wygenerować fakturę korygującą, która prawidłowo odnosi się do dokumentu pierwotnego i odzwierciedla rzeczywisty przebieg transakcji.

Numer KSeF faktury pierwotnej jako kluczowe powiązanie

Jeżeli faktura korygowana została wystawiona w KSeF, jej numer KSeF jest nie tylko ważnym identyfikatorem procesowym, lecz również informacją wykazywaną w strukturze FA(3) faktury korygującej. Równolegle trzeba zachować własny numer faktury nadany przez podatnika, ponieważ również on służy do identyfikacji dokumentu korygowanego. Z punktu widzenia architektury danych oznacza to, że firma powinna przechowywać co najmniej relację między zamówieniem, własnym identyfikatorem faktury, numerem faktury oraz numerem KSeF, jeśli dokument został wystawiony w systemie. Dzięki temu późniejszy zwrot lub reklamacja może zostać przypisana nie tylko do rekordu sprzedażowego w systemie sklepu, lecz również do konkretnego dokumentu funkcjonującego w KSeF. Ma to szczególne znaczenie przy dużej liczbie transakcji, gdy wiele równoległych zwrotów i podobne dane zamówień zwiększają ryzyko pomyłki.

Z punktu widzenia sprawnego zarządzania sprzedażą warto pójść dalej i zbudować możliwość przechodzenia w obu kierunkach: od zwrotu do faktury pierwotnej oraz od faktury do wszystkich późniejszych zdarzeń dotyczących danej transakcji. Nie jest to dodatkowy wymóg podatkowy KSeF, lecz rekomendacja architektoniczna dla firmy, która chce automatyzować korekty bez ręcznego odtwarzania historii. KSeF identyfikuje faktury i formalne relacje między dokumentami, ale nie prowadzi za sklep kompletnej historii reklamacji, statusów magazynowych, refundów czy numerów zamówień. System sprzedażowy powinien więc wiedzieć, na której fakturze znajdowała się dana pozycja oraz, jeżeli faktura została wystawiona w KSeF, jaki numer KSeF otrzymał ten dokument. Jeden dokument pierwotny może być przy tym korygowany więcej niż raz, dlatego przy kolejnych korektach trzeba uwzględniać aktualny ekonomiczny stan transakcji po wcześniejszych zmianach, a nie traktować każdej korekty w oderwaniu od historii.

Jakie informacje powinny znaleźć się w korekcie?

Zakres danych na fakturze korygującej powinien pozwalać jednoznacznie ustalić, którego dokumentu i jakiej zmiany dotyczy korekta. Kluczowa jest identyfikacja faktury pierwotnej oraz prawidłowe dane stron transakcji, a także wskazanie elementów, które ulegają zmianie. W przypadku zwrotu częściowego będą to przede wszystkim pozycje lub ilości odpowiadające faktycznie zwróconym towarom. Jeżeli korekta wynika z obniżenia ceny po uznaniu reklamacji, dokument powinien odzwierciedlać zmianę wartości wynikającą z tej decyzji. W zależności od rodzaju zdarzenia korekta może wpływać na podstawę opodatkowania i kwotę VAT, ale może również dotyczyć danych niefinansowych. Faktura korygująca nie jest więc dokumentem zarezerwowanym wyłącznie dla zmian ceny, wartości netto czy podatku.

W procesie e-commerce warto również przechowywać przyczynę korekty i, gdy jest to użyteczne, wykazywać ją na fakturze korygującej. W strukturze FA(3) pole dotyczące przyczyny korekty jest fakultatywne, dlatego nie należy traktować go jako obowiązkowego elementu każdego dokumentu. Z punktu widzenia kontroli procesu informacja ta pozostaje jednak bardzo przydatna, ponieważ pozwala łatwiej powiązać fakturę z rzeczywistym zdarzeniem biznesowym, takim jak zwrot, rabat, obniżenie ceny czy uznana reklamacja. Przy dużej liczbie dokumentów taka informacja może znacząco ułatwić analizę historii transakcji, obsługę wyjątków i późniejsze wyjaśnianie rozbieżności między działem sprzedaży, magazynem i księgowością.

Dla e-commerce szczególnie ważne jest również to, aby wartości na korekcie wynikały z danych źródłowych, a nie z ręcznego przeliczania przez osobę wystawiającą dokument. Przy zamówieniach obejmujących różne stawki VAT, rabaty koszykowe, promocje lub wiele pozycji pozornie prosty zwrot jednego produktu może wymagać precyzyjnego odtworzenia wartości przypisanej właśnie do niego. Sama informacja, że klient otrzymał zwrot określonej kwoty, nie zawsze wystarczy do prawidłowego przygotowania korekty. Jeżeli dwa produkty kosztowały po 100 zł, ale klient otrzymał rabat 30 zł na całe zamówienie, zwrot jednego z nich nie powinien być automatycznie rozliczony według katalogowej ceny 100 zł, jeśli część rabatu została przypisana również do tej pozycji. System powinien więc znać wartość netto, stawkę VAT, zastosowane obniżki oraz rzeczywisty stan transakcji po wcześniejszych korektach.

Dlaczego warto identyfikować również poszczególne pozycje zamówienia?

Numer zamówienia jest dobrym punktem wyjścia, ale przy większym e-commerce często okazuje się zbyt ogólny. Jeżeli jedna transakcja zawiera kilka produktów, klient może zwrócić tylko jedną sztukę, zareklamować inną pozycję, a pozostałą część zamówienia zatrzymać. Jeszcze bardziej złożony przypadek powstaje wtedy, gdy ten sam produkt został kupiony w kilku sztukach, ale zwracana jest tylko część ilości. W takich sytuacjach samo powiązanie korekty z numerem zamówienia nie mówi jeszcze, czego dokładnie dotyczy zmiana. Dlatego warto przechowywać własny, trwały identyfikator każdej pozycji zamówienia i przenosić go przez kolejne etapy procesu: realizację, wysyłkę, zwrot, reklamację, fakturowanie i ewentualną korektę. Pozwala to uniknąć sytuacji, w której system próbuje dopasować produkty wyłącznie po nazwie, kodzie katalogowym albo kolejności na dokumencie.

KSeF nie wymaga tworzenia wewnętrznego identyfikatora pozycji zamówienia. Jest to rozwiązanie architektoniczne po stronie sprzedawcy, które znacząco ułatwia automatyzację korekt, szczególnie przy zwrotach częściowych. W firmie prowadzącej sprzedaż w wielu kanałach ten sam produkt może mieć różne oznaczenia w sklepie, magazynie lub zewnętrznym kanale sprzedaży, dlatego własny identyfikator pozycji pozwala zachować jednoznaczną relację niezależnie od źródła zamówienia. Docelowo system powinien być w stanie powiązać konkretną pozycję zamówienia z odpowiadającą jej pozycją na fakturze, a następnie z konkretnym zwrotem i ewentualną korektą. Nie jest to obowiązek wynikający z KSeF, lecz praktyczne rozwiązanie, które ogranicza liczbę przypadków wymagających ręcznego sprawdzania i pozwala bezpiecznie skalować proces obsługi zwrotów wraz ze wzrostem sprzedaży.

Częściowy zwrot w praktyce — jedna faktura, kilka produktów, jeden produkt zwrócony

Częściowy zwrot dobrze pokazuje, dlaczego przy większej skali sprzedaży sama możliwość wystawienia faktury korygującej nie wystarcza. W jednej transakcji może znajdować się kilka produktów, różne ilości, rabaty oraz pozycje opodatkowane według różnych stawek. Klient nie musi przy tym zwracać całego zamówienia. Może odesłać jedną sztukę konkretnego produktu, a pozostałe towary zatrzymać. W takiej sytuacji korekta powinna odzwierciedlić rzeczywistą zmianę transakcji, a nie wyzerować całą fakturę. Żeby zrobić to automatycznie, firma musi wiedzieć nie tylko, że pojawił się zwrot, lecz także dokładnie której pozycji dotyczy, na jakim dokumencie została ona zafakturowana i jaka wartość była do niej faktycznie przypisana po uwzględnieniu rabatów oraz pozostałych warunków sprzedaży.

Przykład korekty jednej pozycji

Załóżmy, że klient biznesowy kupił dwie lampy po 200 zł netto każda oraz stolik za 600 zł netto, a cała sprzedaż została objęta stawką VAT 23%. Łączna wartość faktury wynosi więc 1000 zł netto i 230 zł VAT. Po dostawie klient zwraca jedną lampę, natomiast druga lampa i stolik pozostają u niego. Jeżeli zwrot zostaje prawidłowo zaakceptowany i powstają warunki do dokonania korekty, nie ma podstaw do wyzerowania całej sprzedaży. Zmianie podlega wyłącznie część dotycząca jednej zwróconej lampy. Przy założeniu, że nie było dodatkowych rabatów ani innych elementów wpływających na cenę tej pozycji, podstawa opodatkowania zmniejszy się o 200 zł, a VAT o 46 zł. Po korekcie ekonomiczna wartość sprzedaży pozostającej u klienta wynosi 800 zł netto oraz 184 zł VAT. Dokument powinien więc odzwierciedlić dokładnie tę zmianę, zamiast tworzyć nowy obraz całego zamówienia od początku.

W rzeczywistym sklepie internetowym takie wyliczenie często jest bardziej złożone. Jeżeli przy pierwotnym zamówieniu zastosowano rabat koszykowy, kod promocyjny albo indywidualne obniżenie ceny, system nie powinien przyjmować, że zwracana lampa nadal ma katalogową wartość 200 zł netto. Powinien odtworzyć wartość faktycznie przypisaną tej pozycji na pierwotnej transakcji. Dopiero na tej podstawie można prawidłowo ustalić zmianę netto i VAT. Proces powinien zatem przebiegać od zdarzenia biznesowego do dokumentu: klient zwraca produkt, zwrot zostaje zweryfikowany, system identyfikuje odpowiednią pozycję i jej rzeczywistą wartość, ustala zakres zmiany, generuje fakturę korygującą, a następnie przekazuje ją do KSeF, jeśli korekta jest wystawiana w tym systemie. Dzięki temu kwota zwrócona klientowi nie staje się przypadkowo jedynym źródłem danych księgowych.

Jakie powiązania powinien zachować system?

Przy pojedynczym zwrocie człowiek jest zwykle w stanie samodzielnie połączyć informacje z kilku miejsc. Widzi numer zamówienia, odnajduje fakturę, porównuje nazwę produktu i sprawdza potwierdzenie zwrotu. Przy setkach takich operacji potrzebna jest jednak relacja zapisana w danych, a nie istniejąca wyłącznie w głowie pracownika. Dla faktury wystawionej w KSeF użyteczny model może wyglądać następująco: zamówienie zwrot lub RMA pozycja zamówienia faktura numer KSeF faktury korekta numer KSeF korekty. Poszczególne elementy nie muszą znajdować się w jednym systemie, ale powinny być ze sobą jednoznacznie powiązane. Jeśli faktura pierwotna została wystawiona poza KSeF, odpowiedni fragment łańcucha będzie wyglądał inaczej, ponieważ taki dokument nie będzie posiadał numeru KSeF.

Taki model pozwala odpowiedzieć na pytania, które przy dużym wolumenie pojawiają się codziennie. Firma może ustalić, który zwrot spowodował konkretną korektę, którego produktu dotyczyła zmiana, jaka faktura pierwotna dokumentowała sprzedaż oraz czy do tej samej transakcji powstały wcześniej inne korekty. Ma to szczególne znaczenie przy kilku częściowych zwrotach do jednego zamówienia. System nie powinien za każdym razem rozpoczynać obliczeń od pierwotnej wartości w oderwaniu od wcześniejszych zdarzeń. Powinien zachowywać stan pierwotny, pełną historię kolejnych zmian oraz aktualny stan wynikowy transakcji. Dzięki temu można zarówno prawidłowo obliczyć następną korektę, jak i później odtworzyć, w jaki sposób firma doszła do końcowych wartości. Nie jest to dodatkowy wymóg samego KSeF, lecz architektura procesowa po stronie sprzedawcy, która zwiększa audytowalność i pozwala bezpiecznie przejść od ręcznej obsługi pojedynczych przypadków do automatyzacji setek lub tysięcy operacji.

Jak obsługiwać setki lub tysiące korekt? Model procesu dla dużego e-commerce

Przy dużej liczbie zwrotów najgorszym rozwiązaniem jest próba automatyzowania istniejącego chaosu. Jeżeli dziś pracownik ręcznie ustala, czego dotyczy zwrot, szuka faktury w innym systemie i na podstawie własnej wiedzy decyduje o wartości korekty, samo dodanie automatycznej wysyłki do KSeF nie rozwiąże problemu. Może wręcz sprawić, że błędna decyzja zostanie wykonana szybciej i na większej liczbie dokumentów. Skalowalny proces powinien dlatego rozdzielać moment powstania zdarzenia, ustalenie jego skutku, przygotowanie danych do korekty, wysłanie dokumentu oraz kontrolę wyniku jego przetwarzania. Automatyzacja jest bezpieczna dopiero wtedy, gdy każde z tych przejść opiera się na jasno określonych regułach, a firma jest w stanie odtworzyć zarówno pierwotne dane transakcji, jak i historię wszystkich późniejszych zmian.

Krok 1. Określ zdarzenie, które uruchamia korektę

Samo zgłoszenie przez klienta „chcę zwrócić produkt” nie powinno automatycznie prowadzić do wystawienia faktury korygującej. Między intencją klienta a faktycznym zakończeniem zwrotu może wydarzyć się wiele rzeczy. Klient może nie nadać przesyłki, magazyn może otrzymać inny produkt, zwrot może dotyczyć tylko części ilości albo reklamacja może zakończyć się wymianą zamiast obniżenia ceny. Dlatego firma powinna określić konkretne statusy biznesowe, które pozwalają przejść do dalszej obsługi dokumentowej. W zależności od procesu może to być przyjęcie i pozytywna weryfikacja zwrotu, uznanie reklamacji, zatwierdzenie rabatu posprzedażowego albo decyzja o częściowym lub pełnym zwrocie należności. Nie chodzi przy tym o znalezienie jednego uniwersalnego statusu magazynowego, który zawsze automatycznie oznacza korektę, lecz o stworzenie reguły odpowiadającej rzeczywistemu rodzajowi zdarzenia.

W praktyce dobry mechanizm działa dwuetapowo. Najpierw zdarzenie operacyjne potwierdza, co faktycznie wydarzyło się z zamówieniem, a następnie warstwa reguł biznesowych i podatkowych określa konsekwencję dla faktury. Dzięki temu status „zwrot dostarczony” może oznaczać jedynie, że paczka dotarła do magazynu, podczas gdy dopiero dalsza weryfikacja pozwala ustalić, czy i jaka zmiana dokumentowa powinna nastąpić. Podobnie przy reklamacji samo jej zgłoszenie nie przesądza jeszcze, czy powstanie korekta. Dopiero decyzja o obniżeniu ceny, zwrocie odpowiedniej części należności albo innym skutku wpływającym na dane faktury może powodować potrzebę jej zmiany. Takie rozdzielenie ogranicza ryzyko wystawiania korekt do zdarzeń, które nie zostały jeszcze zakończone albo ostatecznie nie powodują zmiany sprzedaży.

Krok 2. Stwórz jeden łańcuch identyfikatorów dla całego procesu

Duży e-commerce zwykle nie ma jednego numeru opisującego całą transakcję od kliknięcia „kupuję” do zakończenia zwrotu. Zamówienie ma własne ID, płatność kolejne, magazyn może posługiwać się numerem przesyłki lub operacji, reklamacja otrzymuje RMA, a faktura ma zarówno własny numer nadany przez podatnika, jak i numer KSeF, jeśli została wystawiona w tym systemie. Problem zaczyna się wtedy, gdy te identyfikatory istnieją obok siebie, ale nie są trwale powiązane. Rejestr procesu powinien pozwalać po numerze zwrotu dotrzeć do zamówienia, konkretnej pozycji, klienta i faktury, a następnie do korekty. Powinien również przechowywać status zdarzenia, wartości przed i po zmianie oraz informację o przyczynie operacji, nawet jeśli sama przyczyna nie jest obowiązkowo wykazywana na fakturze korygującej.

W praktyce nie oznacza to konieczności budowania jednego ogromnego systemu obejmującego całą firmę. Ważniejsze jest to, aby dane miały wspólne klucze pozwalające je jednoznacznie zestawić. Dla dokumentu wystawionego w KSeF należy zachować zarówno własny numer faktury, jak i otrzymany numer KSeF, a później analogicznie identyfikować wystawioną korektę. Przydatne są także własne identyfikatory klienta, zamówienia, zwrotu i poszczególnych pozycji. Powód korekty może pozostać informacją operacyjną przechowywaną w systemie, nawet jeśli firma nie zdecyduje się wykazywać go w fakultatywnym polu faktury. Warto również zachowywać informacje o stanie transakcji przed zmianą, samej zmianie i stanie po jej zastosowaniu, tak aby kolejna korekta mogła zostać obliczona prawidłowo, a cała historia pozostała możliwa do prześledzenia.

Krok 3. Automatyzuj standardowe przypadki, nie wyjątki

Największą korzyść z automatyzacji daje obsługa sytuacji częstych i jednoznacznych. Jeżeli klient zwraca całe zamówienie, wszystkie pozycje są prawidłowo powiązane z fakturą, zwrot został zaakceptowany i system zna jego skutek finansowy, proces może w dużej mierze przebiegać automatycznie. Podobnie może wyglądać częściowy zwrot jednej jednoznacznie zidentyfikowanej pozycji albo standardowa obniżka ceny przeprowadzana według wcześniej zdefiniowanych reguł. Warunkiem jest jednak kompletność danych i brak sprzeczności. System powinien znać stan transakcji przed zmianą, uwzględniać wcześniejsze korekty i potrafić obliczyć prawidłowe wartości po zdarzeniu. Automatyzacja nie powinna polegać na tym, że brakujące informacje są uzupełniane według najbardziej prawdopodobnego scenariusza.

Im bardziej nietypowy przypadek, tym większy sens ma udział człowieka. Reklamacja jakościowa zakończona niestandardową rekompensatą, spór dotyczący płatności, wymiana z dopłatą, błąd identyfikujący innego nabywcę czy zestaw produktów rozliczany według nietypowych zasad może wymagać dodatkowej oceny. Takich przypadków nie trzeba na siłę wtłaczać w automatyczny proces tylko po to, aby osiągnąć deklarowany wysoki poziom automatyzacji. W dojrzałym modelu większość standardowych operacji przechodzi bez udziału pracownika, natomiast przypadki o podwyższonym ryzyku są świadomie zatrzymywane. Dzięki temu zespół nie zajmuje się każdą korektą, lecz tylko niewielką częścią zdarzeń, w których rzeczywiście potrzebna jest decyzja lub dodatkowa weryfikacja.

Krok 4. Zbuduj kolejkę wyjątków

Automatyzacja masowych korekt powinna mieć możliwość powiedzenia „nie wiem”. Jeżeli system nie potrafi jednoznacznie ustalić faktury, nie znajduje pozycji odpowiadającej zwróconemu produktowi, widzi sprzeczne wartości albo nie zna aktualnego stanu transakcji po wcześniejszej korekcie, proces nie powinien iść dalej. Zamiast generować dokument na podstawie przypuszczeń, przypadek powinien trafić do kolejki wyjątków z informacją o przyczynie zatrzymania. Podobnie należy postąpić, jeżeli wiadomo, że faktura pierwotna została wystawiona w KSeF, ale w danych brakuje jej numeru KSeF, który będzie potrzebny przy wystawianiu korekty. Sam brak numeru nie jest natomiast błędem, jeśli faktura pierwotna prawidłowo powstała poza KSeF. System musi więc znać również sposób wystawienia dokumentu, a nie stosować jednego warunku do wszystkich faktur.

Dobra kolejka wyjątków powinna pozwalać pracownikowi szybko zrozumieć, co wymaga decyzji, bez rozpoczynania analizy całej transakcji od początku. Zamiast komunikatu „nie udało się wystawić korekty” bardziej użyteczna jest informacja, że nie znaleziono powiązania pozycji zwrotu z pozycją faktury, że wartość zwrotu różni się od obliczonej wartości po rabacie albo że dokument pierwotny nadal oczekuje na numer KSeF. Po ręcznym rozwiązaniu problemu przypadek może wrócić do standardowego procesu. Taki mechanizm jest znacznie bardziej skalowalny niż model, w którym wszystkie korekty wymagają akceptacji pracownika. Człowiek zajmuje się wtedy wyjątkami, a nie rutynowymi dokumentami, które system jest w stanie rozliczyć jednoznacznie.

Krok 5. Kontroluj status dokumentu w KSeF

Wysłanie pliku do KSeF nie powinno być ostatnim krokiem procesu. System sprzedażowy musi kontrolować wynik przetwarzania dokumentu i zapisywać go przy konkretnej transakcji. Operacyjnie warto rozróżniać status przygotowania korekty, wysyłki, przetwarzania, pozytywnego przyjęcia z nadaniem numeru KSeF oraz odrzucenia. Jeśli dokument zostanie odrzucony, trzeba ustalić przyczynę błędu, przygotować prawidłowy plik i przesłać go ponownie. Nie wystawia się faktury korygującej do samego odrzuconego XML, ponieważ taki plik nie stał się skutecznie wystawioną fakturą w KSeF. W dużej firmie status powinien wracać automatycznie do systemu, z którego rozpoczęto proces, tak aby księgowość i obsługa klienta nie musiały oddzielnie sprawdzać, czy dokument faktycznie przeszedł weryfikację.

Trzeba również uważać na skrót myślowy „numer KSeF oznacza datę wystawienia”. W standardowym trybie online pozytywne przyjęcie i nadanie numeru KSeF potwierdza skuteczne przejście dokumentu przez system, ale data nadania numeru nie musi być datą wystawienia faktury. Sam numer KSeF jest generowany dopiero przez system po przyjęciu dokumentu, dlatego jego otrzymanie powinno być traktowane jako osobne zdarzenie i zapisane przy odpowiedniej fakturze lub korekcie. Z punktu widzenia architektury procesowej trzeba więc rozdzielić informację o momencie wystawienia dokumentu od informacji o późniejszym potwierdzeniu jego przyjęcia przez KSeF. Dla operacji wykonywanych na przełomie dnia lub miesiąca różnica ta może mieć praktyczne znaczenie, dlatego statusy techniczne powinny być przechowywane razem z właściwymi datami, zamiast sprowadzać cały obieg do pola „wysłano: tak/nie”.

Krok 6. Obsłuż tryby offline i awarie jako osobną ścieżkę

Proces zaprojektowany wyłącznie dla standardowej pracy online będzie niepełny. KSeF przewiduje również szczególne tryby wystawiania dokumentów, dlatego e-commerce obsługujący duży wolumen powinien mieć przygotowaną osobną ścieżkę dla sytuacji, w których faktura lub korekta powstaje bez bieżącego przesłania jej do systemu. W trybie offline24 fakturę należy przekazać do KSeF niezwłocznie, nie później niż w następnym dniu roboczym po dniu jej wystawienia. Inne zasady terminowe obowiązują podczas ogłoszonej niedostępności KSeF oraz awarii systemu, dlatego aplikacja nie powinna traktować wszystkich przypadków offline jednakowo. Osobną sytuacją jest awaria całkowita KSeF, dla której przewidziano odmienny sposób postępowania i dokumentów wystawionych w takim okresie nie obsługuje się później w taki sam sposób jak faktur z offline24. System powinien więc zapisywać podstawę zastosowania konkretnego trybu i na tej podstawie ustalać dalszą ścieżkę dokumentu.

Takie rozróżnienie jest ważne również z punktu widzenia automatyzacji terminów. Zamiast kodować jedną ogólną zasadę „dokument offline trzeba później wysłać”, system powinien wiedzieć, z jakiego powodu dokument nie został przekazany do KSeF w standardowym trybie i jakie konsekwencje wynikają właśnie z tej sytuacji. Pozwala to uniknąć błędnego stosowania terminów właściwych dla offline24 podczas ogłoszonej niedostępności, awarii albo awarii całkowitej. Dla średniego e-commerce, w którym fakturowanie odbywa się automatycznie przez całą dobę, ma to szczególne znaczenie: problem może pojawić się w nocy lub w weekend, gdy nikt nie kontroluje ręcznie kolejki dokumentów. Logika systemowa powinna więc rozpoznawać zastosowany tryb, przechowywać odpowiedni status i uruchamiać dalsze działania zgodnie z właściwą ścieżką.

Szczególnie ważna jest kolejność, gdy korekta dotyczy faktury pierwotnej wystawionej wcześniej w trybie offline24 albo w innym trybie, w którym dokument ma zostać później przekazany do KSeF i otrzymać numer systemowy. Jeśli faktura pierwotna wystawiona w offline24 nie otrzymała jeszcze numeru KSeF, najpierw trzeba przesłać ją do systemu i uzyskać ten numer, a dopiero następnie wystawić odnoszącą się do niej fakturę korygującą. Analogiczna zależność ma znaczenie przy fakturach pierwotnych wystawianych podczas oficjalnej niedostępności lub awarii KSeF, jeżeli zgodnie z właściwymi zasadami dokument ma następnie zostać przesłany do systemu i otrzymać numer KSeF. Dla e-commerce oznacza to potrzebę obsługi zależności pomiędzy dokumentami. Korekta nie powinna wyprzedzić faktury źródłowej tylko dlatego, że zdarzenie biznesowe zostało już zatwierdzone. System powinien zatrzymać ją do momentu, w którym możliwe będzie prawidłowe wskazanie dokumentu pierwotnego, a następnie wznowić proces bez konieczności ręcznego pilnowania kolejności.

Korekta faktury to nie wszystko — jak dokumentować sam zwrot lub reklamację?

Faktura korygująca dokumentuje zmianę dotyczącą wcześniej wystawionej faktury, ale nie zastępuje dokumentacji samego procesu zwrotu lub reklamacji. W e-commerce te dwa poziomy warto świadomie rozdzielić. Z jednej strony firma ma dokument podatkowy pokazujący, że cena, ilość, podstawa opodatkowania, VAT albo inne dane faktury uległy zmianie. Z drugiej strony istnieje zdarzenie biznesowe, które do tej zmiany doprowadziło: klient odstąpił od umowy, zwrócił konkretny produkt, reklamacja została uznana albo sprzedawca zdecydował o obniżeniu ceny. Przy większej liczbie zamówień oba poziomy powinny pozostawać ze sobą powiązane, tak aby po kilku miesiącach można było odtworzyć nie tylko samą korektę, ale również odpowiedzieć na pytanie, dlaczego powstała, czego dotyczyła i na jakiej podstawie została wystawiona.

Jakich dowodów potrzebuje e-commerce?

Nie ma jednego uniwersalnego zestawu dokumentów, który trzeba gromadzić przy każdym zwrocie i każdej reklamacji. Zakres danych powinien odpowiadać rzeczywistemu przebiegowi sprawy oraz rodzajowi obowiązków, których dotyczy. Część informacji może mieć znaczenie podatkowe, część wynikać z przepisów dotyczących praw konsumenta, rachunkowości albo potrzeb kontroli wewnętrznej firmy. W praktyce warto zachowywać zgłoszenie zwrotu albo reklamacji, a przy odstąpieniu od umowy także informację pozwalającą wykazać, kiedy i w jaki sposób klient złożył odpowiednie oświadczenie. Przydatny jest własny numer zwrotu lub RMA, który łączy zgłoszenie z konkretnym zamówieniem i pozycją. Kolejnymi elementami historii mogą być potwierdzenie otrzymania przesyłki, wynik kontroli zwróconego produktu, decyzja reklamacyjna oraz informacja o tym, jaki skutek finansowy zaakceptowano. Jeśli sprawa kończy się zwrotem pieniędzy albo obniżeniem ceny, warto zachować również dane potwierdzające wykonanie tej decyzji. Nie wszystkie te informacje muszą istnieć jako osobne dokumenty; mogą funkcjonować jako statusy i rekordy w systemie, o ile pozwalają wiarygodnie odtworzyć przebieg sprawy.

W większym e-commerce najważniejsze staje się trwałe połączenie tych informacji. Sam zapis refundu nie mówi jeszcze, której pozycji dotyczyła operacja ani dlaczego klient otrzymał określoną kwotę. Sam status „towar przyjęty” nie wyjaśnia z kolei, czy produkt został zaakceptowany jako zwrot, czy trafił dopiero do dalszej weryfikacji reklamacyjnej. Dlatego dokumentacja powinna prowadzić od zgłoszenia przez identyfikator zwrotu, zamówienie i konkretną pozycję aż do decyzji finansowej i odpowiedniej faktury. Jeśli faktura została wystawiona w KSeF, w tym łańcuchu należy również zachować jej numer KSeF oraz numer KSeF późniejszej korekty. Jest to szczególnie istotne przy kilku zwrotach do jednego zamówienia, kiedy każda sprawa może dotyczyć innego produktu i zakończyć się w innym terminie.

Dlaczego KSeF nie zastępuje dokumentacji procesu?

KSeF przechowuje i identyfikuje faktury, ale nie jest systemem do zarządzania zwrotami, reklamacjami, pracą magazynu czy refundami. Z faktury korygującej można odczytać, jaki dokument został skorygowany i jakie dane zostały zmienione, ale sam KSeF nie potwierdzi, że klient faktycznie wysłał określony produkt, magazyn go przyjął, reklamacja została rozpatrzona w konkretny sposób albo klientowi zwrócono środki. Nie przechowuje również dla sprzedawcy pełnego kontekstu operacyjnego, takiego jak numer RMA, wynik kontroli towaru, przebieg komunikacji z klientem czy status realizacji refundu. Te informacje powstają w procesach firmy i to po jej stronie pozostaje stworzenie spójnej historii pozwalającej połączyć zdarzenie biznesowe z dokumentem wystawionym później w KSeF.

To rozróżnienie jest ważne także dlatego, że faktura korygująca i dowód zdarzenia gospodarczego pełnią inne funkcje. Korekta pokazuje podatkowy i dokumentowy efekt zmiany, natomiast dane z procesu wyjaśniają jej przyczynę i przebieg. Jeżeli przykładowo firma wystawia korektę w związku z częściowym zwrotem zamówienia, powinna być w stanie ustalić, jaki produkt został zwrócony, jaki skutek tego zdarzenia zaakceptowano, jaka wartość faktycznie przypadała na tę pozycję oraz jak obliczono zmianę uwzględnioną na korekcie. Przy kilku przypadkach miesięcznie można taką historię odtworzyć na podstawie wiadomości i ręcznych notatek. Przy tysiącach operacji dokumentacja musi stać się elementem architektury danych, ponieważ bez niej firma może posiadać prawidłowo wystawioną korektę, ale mieć trudność z szybkim wyjaśnieniem, jakie zdarzenie doprowadziło do jej powstania.

Zwroty i reklamacje a VAT — kiedy ująć korektę in minus?

Korekta in minus pojawia się wtedy, gdy po pierwotnym rozliczeniu dochodzi do zdarzenia powodującego zmniejszenie podstawy opodatkowania lub wykazanego podatku, na przykład w związku ze zwrotem towaru albo późniejszą obniżką ceny. Od 2026 roku sposób ustalenia okresu, w którym sprzedawca ujmuje taką korektę, jest silniej powiązany z formą oraz sposobem wystawienia dokumentu. W przypadku faktury korygującej w postaci faktury ustrukturyzowanej zastosowanie ma szczególna reguła związana z okresem jej wystawienia, natomiast dla dokumentów wystawianych poza tym standardowym trybem obowiązują odrębne zasady. Z perspektywy e-commerce oznacza to, że system nie powinien opierać księgowania każdej korekty wyłącznie na dacie przyjęcia zwrotu przez magazyn, dacie refundu ani na prostym rozróżnieniu „KSeF: tak lub nie”. Powinien rozpoznawać rodzaj dokumentu, sposób i tryb jego wystawienia, status w KSeF oraz regułę podatkową właściwą dla danego przypadku.

Dlaczego moment wystawienia korekty ma znaczenie?

W przypadku obniżenia podstawy opodatkowania udokumentowanego fakturą korygującą w postaci faktury ustrukturyzowanej sprzedawca co do zasady dokonuje obniżenia za okres rozliczeniowy, w którym wystawił tę fakturę korygującą, z uwzględnieniem zasad przewidzianych dla szczególnych sytuacji. Oznacza to, że wystawienie korekty nie jest jedynie technicznym etapem zamykającym proces zwrotu. Jednocześnie nie należy wyprowadzać z tego wniosku, że każdy status operacyjny wystarczy do automatycznego stworzenia dokumentu. Automatyczne wystawienie korekty nie powinno następować przed ustaleniem, że rzeczywiście wystąpiła podstawa do obniżenia podstawy opodatkowania oraz że można prawidłowo określić zakres korekty. Dopiero wtedy wiadomo, czy zmiana dotyczy całej faktury, jednej pozycji, części ilości, ceny czy innego elementu transakcji.

Dla korekt, które nie podlegają tej szczególnej regule dotyczącej faktury ustrukturyzowanej, moment rozliczenia może wynikać z innych zasad. Nie należy utożsamiać ich ze starym mechanizmem wymagającym klasycznego „potwierdzenia odbioru” faktury korygującej przez nabywcę. W modelu obowiązującym przed szczególnymi rozwiązaniami KSeF znaczenie miało między innymi uzgodnienie z nabywcą warunków obniżenia podstawy opodatkowania, ich spełnienie oraz posiadanie odpowiedniej dokumentacji. Po wejściu nowych regulacji dochodzą dodatkowe zasady związane z formą i trybem wystawienia faktury. Dlatego silnik księgowy powinien ustalać okres VAT na podstawie konkretnego przypadku, a nie stosować jednej daty do wszystkich korekt występujących w sprzedaży internetowej.

Co zmienia faktura ustrukturyzowana w KSeF?

Dla faktury korygującej w postaci faktury ustrukturyzowanej szczególna reguła KSeF upraszcza ustalenie okresu obniżenia podstawy opodatkowania po stronie sprzedawcy. Nie oznacza to jednak, że samo techniczne wystawienie korekty tworzy materialną podstawę do obniżenia ceny albo wartości sprzedaży. Zdarzenie uzasadniające korektę musi rzeczywiście wystąpić, a przedsiębiorca powinien potrafić prawidłowo ustalić jego zakres. KSeF przyjmuje dokument i nadaje mu określony status, ale nie sprawdza za sklep, czy klient faktycznie zwrócił jedną sztukę, czy rabat został rzeczywiście przyznany ani czy reklamacja zakończyła się obniżeniem ceny. Odpowiedzialność za powiązanie faktury z rzeczywistym przebiegiem transakcji pozostaje po stronie przedsiębiorcy.

Ma to bezpośrednie znaczenie dla architektury automatyzacji. System sprzedażowy powinien najpierw zidentyfikować zdarzenie, ustalić właściwą fakturę i pozycję, uwzględnić rabaty oraz wcześniejsze korekty, a następnie określić prawidłowy skutek finansowy. Dopiero później może powstać faktura korygująca. Szczególne tryby, takie jak offline24, niedostępność czy awaria KSeF, wymagają dodatkowego rozróżnienia, ponieważ sposób ustalenia właściwego momentu rozliczenia może zależeć od zasad przewidzianych dla konkretnego trybu wystawienia i późniejszego przekazania dokumentu. Nie należy przy tym stosować jednej reguły do wszystkich trybów szczególnych ani zakładać, że późniejsze przesłanie dokumentu do KSeF zawsze automatycznie wyznacza okres korekty VAT.

W e-commerce znaczenie ma również rozróżnienie sprzedaży biznesowej i konsumenckiej. Faktury wystawiane konsumentom są wyłączone z obowiązku wystawiania w KSeF, choć sprzedawca może wystawiać je w systemie dobrowolnie. Firma obsługująca jednocześnie B2B i B2C może więc mieć w jednym procesie zwrotowym dokumenty podlegające różnym ścieżkom fakturowania. To kolejny powód, dla którego samo pole „KSeF: tak lub nie” nie wystarcza do prawidłowego określenia sposobu obsługi korekty. System powinien znać charakter transakcji, sposób wystawienia dokumentu pierwotnego, formę korekty, tryb jej wystawienia oraz aktualny status w KSeF.

Dlaczego korektę warto uruchamiać dopiero po osiągnięciu właściwego statusu zwrotu?

Największe ryzyko w automatycznej obsłudze zwrotów pojawia się wtedy, gdy firma wybiera trigger zbyt wcześnie w procesie. Status „klient zgłosił zwrot” informuje jedynie o zamiarze. „Przesyłka nadana” potwierdza, że towar jest w drodze. Nawet „paczka odebrana przez magazyn” nie zawsze mówi jeszcze, czy wewnątrz znajduje się właściwy produkt, jaka ilość faktycznie wróciła i jaki ostatecznie będzie ekonomiczny skutek sprawy. Jeżeli którykolwiek z tych statusów automatycznie wygeneruje fakturę korygującą, może się okazać, że dokument powstał, zanim firma ustaliła, czy rzeczywiście wystąpiła podstawa korekty i jaka powinna być jej wartość. Przy ustrukturyzowanej korekcie in minus jest to szczególnie istotne, ponieważ jej wystawienie ma znaczenie dla okresu rozliczenia po stronie sprzedawcy.

Właściwy trigger powinien więc oznaczać osiągnięcie stanu, w którym firma zna podatkowy i finansowy skutek zdarzenia. W jednym modelu może to nastąpić po zaakceptowaniu zwrotu i ustaleniu jego wartości, w innym po wydaniu decyzji o obniżeniu ceny w ramach reklamacji. Nie chodzi o narzucenie każdemu sklepowi identycznego statusu procesowego, lecz o to, aby wystawienie dokumentu następowało dopiero po ustaleniu materialnej podstawy korekty i jej prawidłowego zakresu. Dopiero wtedy system powinien przygotować fakturę korygującą, zastosować zasady odpowiednie dla jej formy i trybu wystawienia, przekazać dokument do KSeF, jeśli jest to wymagane, oraz zapisać rezultat przetwarzania. Tak ustawiona automatyzacja nie próbuje zastąpić reguł podatkowych statusem magazynowym, lecz wykorzystuje dane operacyjne jako jeden z elementów prowadzących do prawidłowej decyzji dokumentowej.

B2B, B2C i sprzedaż przez zewnętrzne kanały — nie wszystkie zwroty obsługuje się tak samo

W e-commerce podobny zwrot może prowadzić do różnych ścieżek dokumentowych w zależności od tego, kto kupił towar, w jakim modelu została zawarta transakcja i kto formalnie występuje jako sprzedawca. Z perspektywy magazynu dwa przypadki mogą wyglądać identycznie: paczka wraca, produkt zostaje przyjęty, a klient otrzymuje pieniądze. Z perspektywy fakturowania różnica może być jednak zasadnicza. Inaczej wygląda sprzedaż na rzecz przedsiębiorcy objęta obowiązkiem KSeF, inaczej sprzedaż konsumencka, a jeszcze inaczej transakcja realizowana przez zewnętrzny kanał sprzedaży. Dlatego status nabywcy, sposób wystawienia faktury oraz rola poszczególnych uczestników transakcji powinny być ustalone już na poziomie zamówienia, a nie dopiero wtedy, gdy księgowość otrzyma informację o zwrocie.

Zwroty w sprzedaży B2B

W krajowej sprzedaży B2B faktury objęte obowiązkiem KSeF są co do zasady wystawiane w systemie, dlatego również późniejszy proces korekty musi uwzględniać dokument znajdujący się w KSeF. Dla średniego e-commerce oznacza to przede wszystkim konieczność zachowania relacji między zamówieniem firmowym, własnym numerem faktury oraz numerem KSeF otrzymanym po jej przyjęciu przez system. Jeżeli klient biznesowy zwraca część zamówienia, otrzymuje późniejszą obniżkę ceny albo występuje inne zdarzenie wymagające zmiany faktury, system powinien odnaleźć właściwy dokument źródłowy i przygotować korektę zgodnie z rzeczywistym zakresem zmiany. W przypadku faktury pierwotnej wystawionej w KSeF jej numer KSeF służy również do prawidłowej identyfikacji dokumentu korygowanego, dlatego nie powinien pozostawać informacją przechowywaną wyłącznie w systemie księgowym.

Nie oznacza to jednak, że samo oznaczenie klienta jako „firma” wystarcza do automatycznego zastosowania jednej standardowej ścieżki. W praktyce trzeba uwzględnić zakres ustawowego obowiązku KSeF, możliwe wyłączenia oraz charakter konkretnej transakcji, zwłaszcza przy sprzedaży transgranicznej. Dla procesu zwrotowego najważniejsze jest więc ustalenie statusu faktury pierwotnej: czy została wystawiona w KSeF, jaki otrzymała numer i jakie wcześniejsze korekty są już z nią związane. Dzięki temu zwrot klienta B2B nie jest traktowany jako odrębne zdarzenie magazynowe, lecz jako kolejny etap tej samej historii sprzedaży. Jest to szczególnie ważne przy stałych kontrahentach, którzy składają wiele zamówień i mogą mieć równolegle otwarte zwroty, reklamacje, rabaty oraz kilka korekt odnoszących się do wcześniejszych dokumentów.

Zwroty w sprzedaży B2C

W przypadku konsumentów sytuacja wygląda inaczej, ponieważ faktury wystawiane osobom fizycznym nieprowadzącym działalności gospodarczej są wyłączone z obowiązku wystawiania w KSeF. Sprzedawca może wystawiać faktury B2C w systemie dobrowolnie, ale nie oznacza to, że każda faktura konsumencka i każdy związany z nią zwrot muszą przechodzić przez KSeF. Dla sklepu internetowego ma to duże znaczenie, ponieważ właśnie sprzedaż B2C często odpowiada za największą liczbę zamówień i zwrotów. System nie powinien więc automatycznie zakładać, że każdy zaakceptowany zwrot prowadzi do wystawienia korekty w KSeF. Najpierw trzeba ustalić, czy dla tej konkretnej transakcji została wystawiona faktura, a następnie czy powstała ona w KSeF dobrowolnie, czy poza systemem.

Jeżeli faktura B2C została dobrowolnie wystawiona w KSeF, przy wystawianiu jej korekty należy traktować ją jako fakturę pierwotną znajdującą się w systemie i prawidłowo wskazać jej dane identyfikacyjne, w tym numer KSeF. Jeżeli natomiast faktura konsumencka powstała poza KSeF, nie będzie miała takiego numeru i proces korekty powinien uwzględniać ten stan. Z punktu widzenia automatyzacji najlepiej więc nie budować dwóch zupełnie niezależnych procesów zwrotowych dla B2B i B2C. Wspólny może być przebieg operacyjny obejmujący zgłoszenie, przyjęcie i weryfikację zwrotu, natomiast warstwa dokumentowa powinna na podstawie statusu nabywcy i sposobu wystawienia dokumentu pierwotnego wybierać właściwą ścieżkę fakturowania i rozliczenia.

Kto powinien wystawić korektę przy sprzedaży przez zewnętrzny kanał?

Sam fakt, że klient kupił produkt przez zewnętrzny kanał sprzedaży, nie przesądza jeszcze o tym, kto odpowiada za fakturę i jej korektę. Punktem wyjścia powinno być ustalenie, kto jest sprzedawcą w danej transakcji oraz w czyim imieniu została wystawiona faktura pierwotna. W jednym modelu zewnętrzny kanał jedynie pośredniczy w pozyskaniu zamówienia, obsłudze płatności lub komunikacji, podczas gdy sprzedawcą wobec klienta pozostaje e-commerce. W innym układzie rola operatora może być szersza. Możliwy jest też model, w którym dokument jest technicznie generowany przez podmiot zewnętrzny, ale wystawiany w imieniu i na rzecz właściwego sprzedawcy. Nie można więc ustalać odpowiedzialności za korektę tylko na podstawie tego, w czyim panelu pojawiło się zamówienie, kto przyjął płatność albo kto technicznie zwrócił pieniądze klientowi.

Przy sprzedaży transgranicznej potrzebna jest jeszcze większa ostrożność, ponieważ w określonych modelach VAT operator platformy może być traktowany jako podmiot dokonujący dostawy. W takim przypadku ustalenie, kto jest sprzedawcą dla celów podatkowych, nie powinno opierać się wyłącznie na handlowym regulaminie kanału czy sposobie prezentacji oferty klientowi. Dla firmy planującej ekspansję oznacza to konieczność opisania modelu fakturowania osobno dla każdego kanału i rynku. System powinien wiedzieć, kto jest sprzedawcą, kto wystawia dokument, gdzie zapisany jest numer faktury oraz — gdy dokument znajduje się w KSeF — gdzie przechowywany jest jego numer KSeF. Dopiero po ustaleniu tych ról można bezpiecznie zdecydować, kto i w jakim modelu powinien wystawić późniejszą korektę.

Czy przy dużej liczbie zwrotów można wystawiać korekty zbiorcze?

Przy kilkuset zwrotach dziennie pokusa jest oczywista: zamiast wystawiać setki oddzielnych dokumentów, połączyć je w jeden i w ten sposób uprościć proces. Trzeba jednak rozróżnić dwie kwestie. Czym innym jest możliwość objęcia jedną fakturą korygującą więcej niż jednej wcześniejszej faktury, a czym innym szczególna uproszczona zbiorcza korekta przewidziana dla określonych opustów lub obniżek ceny. Nie powinno się więc używać pojęcia „korekta zbiorcza” tak, jakby oznaczało ono jeden uniwersalny mechanizm pozwalający połączyć dowolną liczbę dokumentów. Zakres danych i warunki zastosowania zależą od tego, jaki rodzaj korekty powstaje i czego dokładnie dotyczy.

Do czego faktycznie służy korekta zbiorcza?

Jedną sytuacją jest zwykła faktura korygująca odnosząca się do więcej niż jednej konkretnej faktury pierwotnej. W takim przypadku kluczowe pozostaje prawidłowe zidentyfikowanie dokumentów, których dotyczy zmiana, oraz ustalenie zakresu korekty dla każdej z nich. Osobnym rozwiązaniem jest szczególna uproszczona korekta zbiorcza przewidziana przy opuście lub obniżce ceny odnoszącej się do sprzedaży dla jednego odbiorcy w określonym okresie. Jej zasady nie powinny być automatycznie przenoszone na każdy przypadek dokumentu obejmującego wiele wcześniejszych faktur. W praktyce oznacza to, że system przygotowujący korekty musi rozpoznawać rodzaj zdarzenia, zamiast stosować jeden wspólny szablon do wszystkich sytuacji oznaczonych wewnętrznie jako „zbiorcze”.

Szczególna uproszczona korekta zbiorcza znajduje typowe zastosowanie wtedy, gdy jeden kontrahent otrzymuje po zakończeniu okresu rozliczeniowego opust lub obniżkę ceny dotyczącą szerszego zakresu sprzedaży. Taki dokument może korzystać z uproszczeń przewidzianych dla tego konkretnego przypadku, dlatego nie należy bezwarunkowo zakładać, że każda korekta obejmująca wiele faktur musi zawierać dokładnie ten sam zestaw danych identyfikacyjnych dla każdego dokumentu źródłowego. Z kolei przy zwykłej korekcie odnoszącej się do kilku konkretnych faktur ich prawidłowe powiązanie pozostaje kluczowe. Dla e-commerce praktyczny wniosek jest prosty: termin „zbiorcza” nie powinien być używany jako skrót techniczny, lecz musi odpowiadać rzeczywistemu rodzajowi korekty.

Dlaczego nie warto używać jej jako skrótu dla setek niezależnych zwrotów konsumenckich?

Setka zwrotów przetworzonych tego samego dnia nie staje się jednym zdarzeniem gospodarczym tylko dlatego, że firma obsługuje je w jednym procesie technicznym. Każdy klient ma własne zamówienie, własną relację ze sprzedawcą i może zwracać inny produkt, w innym terminie oraz na podstawie innego dokumentu. Nie można więc stworzyć jednej faktury korygującej obejmującej zwroty wielu różnych nabywców tylko dlatego, że system przetwarza je w jednej partii. Faktura pozostaje związana z określoną relacją sprzedawca–nabywca, a techniczny batch nie tworzy jednego zdarzenia podatkowego.

W typowym modelu masowych zwrotów wielu różnych klientów będą to więc odrębne dokumenty przypisane do właściwych nabywców i faktur. Techniczne przetwarzanie ich w jednej partii nie zmienia ich w jedną zbiorczą fakturę korygującą. System może w ciągu kilku minut wygenerować setki korekt, przeprowadzić ich walidację i przekazać je do dalszej obsługi bez ręcznej pracy księgowości, ale nadal zachowuje oddzielne relacje dokumentowe dla poszczególnych transakcji. Masowe przetwarzanie nie oznacza korekty zbiorczej. Skalę najlepiej rozwiązywać poprzez automatyzację wielu prawidłowych dokumentów, a nie przez sztuczne łączenie niezależnych zwrotów w jeden zapis.

Kiedy korekta zbiorcza może mieć sens?

Najbardziej czytelnym przykładem jest relacja B2B, w której jeden kontrahent dokonuje regularnych zakupów przez dłuższy okres, a później otrzymuje rabat zależny od wartości lub wolumenu współpracy. Firma może na przykład uzgodnić, że po przekroczeniu określonego poziomu zakupów w kwartale klient otrzyma dodatkowe 3% obniżki dotyczącej sprzedaży z tego okresu. W takiej sytuacji szczególna uproszczona korekta zbiorcza przewidziana w ustawie może być właściwym narzędziem do udokumentowania okresowego opustu lub obniżki ceny dla jednego odbiorcy. To zupełnie inny przypadek niż setki niezależnych zwrotów konsumenckich, nawet jeśli oba procesy technicznie obejmują dużą liczbę dokumentów.

Dla rozwijającego się e-commerce ważne jest więc rozdzielenie automatyzacji operacyjnej od konstrukcji dokumentu podatkowego. Tysiące standardowych zwrotów mogą być przetwarzane automatycznie jako duża partia odrębnych spraw, natomiast rabat okresowy dla jednego kontrahenta B2B może zostać udokumentowany w sposób zbiorczy, jeśli spełnia warunki przewidziane dla takiego rozwiązania. W ten sposób forma korekty wynika z charakteru zdarzenia gospodarczego i relacji z konkretnym nabywcą, a nie z ograniczeń technicznych systemu czy chęci zmniejszenia liczby dokumentów za wszelką cenę.

Co się stanie, jeśli nie uporządkujesz procesu korekt przed skalowaniem KSeF?

Przy niewielkiej liczbie zwrotów wiele błędów można jeszcze wychwycić ręcznie. Księgowa zauważy, że korekta dotyczy innej faktury, pracownik obsługi klienta przypomni sobie, że klient zwracał tylko jeden z trzech produktów, a brakujący numer dokumentu da się odnaleźć po numerze zamówienia. Ten model przestaje być bezpieczny, gdy firma zaczyna przetwarzać setki lub tysiące takich zdarzeń miesięcznie. Problemem nie jest wtedy pojedyncza pomyłka, lecz możliwość jej powtarzania przez proces, który działa automatycznie. Jeśli błędnie skonfigurowana reguła zostanie zastosowana do całej kolejki zwrotów, system może w krótkim czasie wygenerować dużą liczbę dokumentów wymagających późniejszej analizy, korekty i ręcznej interwencji. Im większy wolumen sprzedaży i liczba kanałów, tym kosztowniejsze staje się naprawianie takich błędów po fakcie.

Korekta może zostać wystawiona do niewłaściwej faktury

Pierwszym ryzykiem jest brak jednoznacznego powiązania pomiędzy zamówieniem, zwrotem i dokumentem sprzedaży. Jeśli pracownik lub system identyfikuje fakturę wyłącznie na podstawie danych klienta, nazwy produktu albo przybliżonej daty sprzedaży, przy większej liczbie transakcji rośnie prawdopodobieństwo przypisania zwrotu do niewłaściwego dokumentu. Problem jest jeszcze większy w przypadku stałych klientów B2B, którzy składają wiele zamówień w krótkim czasie, oraz przy sprzedaży przez kilka kanałów wykorzystujących różne identyfikatory. Sama zgodność danych nabywcy nie wystarcza wtedy do stwierdzenia, że odnaleziona faktura rzeczywiście dokumentuje zwracany produkt. System powinien przechodzić przez trwałe powiązania danych, a nie próbować dopasowywać dokument na podstawie najbardziej prawdopodobnego wyniku.

Błędne przypisanie jest szczególnie niebezpieczne, ponieważ może początkowo pozostać niewidoczne. Korekta może przejść techniczną walidację, zostać przyjęta przez KSeF i otrzymać numer, mimo że biznesowo odnosi się do niewłaściwej sprzedaży. Numer KSeF identyfikuje konkretny dokument, ale nie potwierdza, że przedsiębiorca wybrał właściwą fakturę dla danego zwrotu. To musi zagwarantować system sprzedażowy, księgowy lub fakturujący. Jeżeli faktura pierwotna została wystawiona w KSeF, jej numer KSeF powinien więc stanowić część szerszego łańcucha prowadzącego od zamówienia i konkretnej pozycji do zwrotu oraz korekty. Bez takiego powiązania firma może posiadać formalnie przetworzone dokumenty, których późniejsze biznesowe wyjaśnienie będzie wymagało czasochłonnego odtwarzania historii.

Możesz skorygować całą fakturę zamiast jednej pozycji

Częściowe zwroty są jednym z miejsc, w których brak danych na poziomie pozycji szybko zaczyna generować poważne problemy. Jeżeli klient kupił pięć produktów, ale zwraca tylko jeden z nich, korekta powinna odzwierciedlać zmianę dotyczącą właśnie tej części transakcji. System, który zna jedynie numer zamówienia i informację „zwrot zaakceptowany”, nie ma wystarczających danych, żeby bezpiecznie ustalić zakres korekty. Przy źle zaprojektowanej automatyzacji może potraktować zamówienie jako jedną całość i zmniejszyć wartości znacznie bardziej, niż wynika to z rzeczywistego zwrotu. Ryzyko rośnie, gdy na fakturze znajdują się produkty z różnymi stawkami VAT, rabaty koszykowe, kilka sztuk tego samego towaru albo wcześniejsze korekty dotyczące części sprzedaży.

Dlatego przy dużej skali nie wystarczy wiedzieć, że dana faktura „ma zwrot”. Trzeba wiedzieć, która pozycja uległa zmianie, w jakiej ilości, jaka wartość była do niej faktycznie przypisana i jak wygląda stan transakcji po wcześniejszych korektach. Szczególnie niebezpieczne jest obliczanie zwrotu na podstawie ceny katalogowej zamiast wartości po rabacie albo używanie kwoty refundu jako jedynego źródła danych do dokumentu podatkowego. System powinien zachowywać stan pierwotny, pełną historię zmian i aktualny stan wynikowy, tak aby kolejna korekta była liczona w kontekście całej wcześniejszej historii. W małym sklepie pracownik może zauważyć niezgodność przed wystawieniem dokumentu. W procesie automatycznym błąd w logice może zostać zastosowany do całej grupy zamówień, zanim ktokolwiek zobaczy jego konsekwencje.

Korekta może powstać, zanim zwrot faktycznie zostanie zaakceptowany

Kolejnym problemem jest uruchomienie procesu zbyt wcześnie. Zgłoszenie zwrotu, wygenerowanie etykiety, nadanie przesyłki czy nawet jej dostarczenie do magazynu nie muszą jeszcze oznaczać, że wystąpiła podstawa do dokonania korekty i że jej zakres jest znany. W paczce może znajdować się inny produkt, liczba zwróconych sztuk może różnić się od deklarowanej, a reklamacja może zakończyć się wymianą zamiast obniżeniem ceny. Jeżeli system generuje fakturę korygującą już przy pierwszym statusie logistycznym, firma może tworzyć dokumenty przed ustaleniem rzeczywistego skutku gospodarczego zdarzenia. Późniejsze odwracanie takich operacji zwiększa liczbę dokumentów i komplikuje historię sprzedaży.

Bezpieczniejsza automatyzacja powinna oddzielać zdarzenie operacyjne od decyzji dokumentowej. System może automatycznie rejestrować zgłoszenie, odbiór paczki i wynik kontroli produktu, ale faktura korygująca powinna powstać dopiero wtedy, gdy firma ustali, że istnieje rzeczywista podstawa korekty oraz potrafi prawidłowo określić jej zakres. Przy korektach ustrukturyzowanych ma to dodatkowe znaczenie z punktu widzenia rozliczenia VAT, dlatego trigger nie powinien być przypadkowym statusem magazynowym. Im większa skala, tym bardziej opłaca się formalnie zdefiniować moment przejścia od „obsługujemy zwrot” do „mamy wystarczające dane i podstawę do przygotowania korekty”.

Dokument może utknąć jako „wysłany”, mimo że KSeF go odrzucił

W systemie obsługującym duży wolumen bardzo niebezpieczny jest model, w którym wysłanie XML kończy proces. Przekazanie dokumentu do KSeF nie oznacza jeszcze, że został on pozytywnie przetworzony. Dokument może znajdować się w przetwarzaniu albo zostać odrzucony, a wtedy nie otrzyma numeru KSeF i należy usunąć przyczynę błędu oraz ponowić właściwą operację. Jeżeli wewnętrzny system oznaczy taką korektę jako zakończoną już w chwili wysyłki, pracownicy mogą nie zauważyć, że dokument nie został skutecznie przyjęty przez KSeF. Przy pojedynczych fakturach taki błąd można jeszcze wychwycić ręcznie. Przy tysiącach operacji niewidoczna kolejka odrzuconych dokumentów może szybko stać się poważnym problemem operacyjnym.

Techniczny proces obsługi dokumentu w integracji z KSeF powinien zostać uznany za zakończony dopiero po odebraniu i zapisaniu wyniku jego przetwarzania. Nie oznacza to utożsamienia momentu otrzymania numeru KSeF z datą wystawienia faktury, którą ustala się według zasad właściwych dla danego trybu. Wewnętrzny system może rozróżniać przykładowo dokument przygotowany, wysłany, znajdujący się w przetwarzaniu, przyjęty i odrzucony, przy czym nazwy i szczegółowość takich statusów są elementem architektury firmy, a nie narzuconym ustawowo katalogiem. Najważniejsze jest to, aby przyjęty dokument został powiązany z otrzymanym numerem KSeF, a odrzucenie automatycznie uruchamiało ścieżkę naprawczą lub kolejkę wyjątków.

Księgowość może stracić możliwość szybkiego odtworzenia historii transakcji

Gdy informacje o sprzedaży, płatności, zwrocie, magazynie i fakturach znajdują się w oddzielnych systemach, każda z tych aplikacji może zawierać poprawny fragment historii, a mimo to firma nie będzie w stanie szybko zobaczyć całości. W jednym miejscu znajduje się zamówienie, w drugim informacja o przyjęciu zwrotu, w trzecim refund, a księgowość posiada fakturę i korektę. Jeżeli nie ma wspólnych identyfikatorów, wyjaśnienie jednej sprawy wymaga przechodzenia między systemami i ręcznego dopasowywania rekordów. Przy zwykłej obsłudze klienta oznacza to stratę czasu, ale podczas zamknięcia miesiąca, kontroli albo wyjaśniania rozbieżności koszt takiego modelu staje się znacznie większy.

Docelowo firma powinna móc odtworzyć historię w obu kierunkach. Od zamówienia powinna dotrzeć do zwrotu, pozycji, faktury, korekty i refundu, a od konkretnej korekty wrócić do faktury, produktu, zgłoszenia zwrotu lub reklamacji i decyzji, która spowodowała zmianę. Jeśli dokumenty zostały wystawione w KSeF, w historii należy uwzględnić także ich numery KSeF i wyniki przetwarzania. Jednocześnie nie wystarczy przechowywać wyłącznie aktualnego stanu transakcji. Z punktu widzenia kontroli i audytowalności potrzebna jest również historia kolejnych zmian. Nie chodzi przy tym o to, aby wszystkie dane fizycznie znajdowały się w jednej aplikacji, lecz o to, aby można było odtworzyć cały przebieg bez polegania na wiedzy konkretnego pracownika.

Przy większej skali błędy zaczną się multiplikować

Przy dwudziestu zwrotach miesięcznie nawet niedoskonały proces może sprawiać wrażenie wystarczającego. Kilka brakujących powiązań da się uzupełnić ręcznie, błędną wartość poprawić, a jeden odrzucony dokument szybko znaleźć. Przy kilku tysiącach zwrotów miesięcznie ten sam odsetek problemów oznacza już dziesiątki lub setki przypadków wymagających interwencji. Co więcej, wraz ze skalą pojawiają się nowe kombinacje zdarzeń: kilka zwrotów do jednej faktury, zwrot po wcześniejszym rabacie, reklamacja po częściowym zwrocie, transakcje z zewnętrznych kanałów albo dokumenty wystawione w różnych trybach. Ręczna obsługa zaczyna wtedy rosnąć nie tylko wraz z liczbą zamówień, ale także wraz ze złożonością wyjątków.

Największe zagrożenie pojawia się jednak wtedy, gdy błąd zostanie wpisany w samą automatyzację. Źle przypisany trigger, nieprawidłowa metoda rozdzielania rabatu albo reguła zakładająca, że każda faktura posiada numer KSeF, może działać konsekwentnie i szybko, ale produkować nieprawidłowe wyniki przy każdym kolejnym pasującym przypadku. Dodatkowym ryzykiem jest wielokrotne przetworzenie tego samego zdarzenia. Powtórzony komunikat o zaakceptowanym zwrocie albo ponowienie operacji po błędzie komunikacji nie powinny prowadzić do wystawienia drugiej korekty dotyczącej tego samego zdarzenia. System musi więc potrafić rozpoznać, że dana operacja została już obsłużona. Problemem nie jest jedna błędna korekta. Problemem jest proces, który potrafi automatycznie wyprodukować ten sam błąd setki razy, zanim firma zorientuje się, że źródłem problemu nie był pojedynczy pracownik, lecz sama logika systemu.

Jak powinien wyglądać docelowy proces zwrotu zintegrowany z KSeF?

Docelowy proces powinien prowadzić od zdarzenia zgłoszonego przez klienta do dokumentu dopiero po przejściu przez kolejne punkty kontroli. W uproszczeniu może wyglądać następująco:

• Klient zgłasza zwrot zwrot otrzymuje własny identyfikator system przypisuje zamówienie i konkretną pozycję zwrot lub reklamacja przechodzi właściwą weryfikację firma ustala rzeczywisty skutek finansowy i podatkowy spełniony zostaje zdefiniowany trigger korekty system odnajduje właściwą fakturę oraz, jeżeli została wystawiona w KSeF, jej numer KSeF oblicza zakres zmiany z uwzględnieniem rabatów i wcześniejszych korekt generuje odpowiednią fakturę korygującą przekazuje ją do KSeF, gdy dana ścieżka tego wymaga kontroluje wynik przetwarzania zapisuje numer KSeF przyjętej korekty albo kieruje problem do kolejki wyjątków.

Najważniejszą cechą takiego procesu jest to, że żaden etap nie wymaga zgadywania. Zwrot ma własny identyfikator, pozycja jest przypisana do konkretnej sprzedaży, faktura jest odnajdywana na podstawie trwałej relacji, a wartości korekty wynikają z historii transakcji. System zachowuje dane pierwotne, wcześniejsze zmiany oraz aktualny stan po wszystkich korektach. Jeżeli którejś informacji brakuje albo dane są sprzeczne, proces zatrzymuje się przed wygenerowaniem dokumentu. Powinien być również odporny na ponowne przetworzenie tego samego zdarzenia, tak aby duplikat komunikatu, ponowiona próba po timeoutcie lub ponowne uruchomienie zadania nie tworzyły drugiej korekty do tego samego zwrotu. Dzięki temu automatyzacja nie polega na usunięciu człowieka za wszelką cenę, lecz na ograniczeniu jego udziału do przypadków, których nie można bezpiecznie rozstrzygnąć według ustalonych reguł.

Równie istotne jest domknięcie procesu po stronie KSeF. Samo wygenerowanie XML i rozpoczęcie wysyłki nie może oznaczać zakończenia technicznej obsługi dokumentu. System powinien odebrać wynik przetwarzania, połączyć otrzymany numer KSeF z konkretną korektą i udostępnić tę informację w historii zamówienia. Jeżeli dokument zostanie odrzucony, przypadek powinien automatycznie przejść do ponownego przetworzenia lub kontroli. Jeżeli faktura pierwotna została wystawiona poza KSeF, proces nie powinien oczekiwać numeru, którego prawidłowo nie ma. Jeżeli natomiast faktura pierwotna została wystawiona w trybie, w którym jest później przesyłana do KSeF, system musi również kontrolować zależność pomiędzy dokumentami — w przypadkach wymagających numeru KSeF faktury pierwotnej korekta nie może zostać wysłana przed prawidłowym przetworzeniem dokumentu źródłowego. Dopiero takie podejście pozwala skalować zwroty bez sytuacji, w której wraz z rosnącą sprzedażą proporcjonalnie rośnie również liczba ręcznych poprawek.

Checklista: czy Twój e-commerce jest gotowy na masową obsługę korekt w KSeF?

Przed uruchomieniem automatycznej obsługi dużej liczby korekt warto sprawdzić nie tylko, czy system potrafi wygenerować fakturę zgodną z właściwą strukturą logiczną KSeF, ale przede wszystkim czy dysponuje danymi potrzebnymi do podjęcia prawidłowej decyzji. Jeżeli na kilka poniższych pytań odpowiedź brzmi „nie”, problem prawdopodobnie znajduje się wcześniej niż na etapie samej komunikacji z KSeF.

• Czy każdy zwrot lub reklamacja otrzymuje własny, trwały identyfikator?
• Czy potrafisz jednoznacznie przypisać zwrot do konkretnego zamówienia i konkretnej pozycji?
• Czy dla faktur wystawionych w KSeF system zapisuje numer KSeF faktury pierwotnej?
• Czy masz jasno określone zdarzenie i reguły, po których spełnieniu może powstać korekta?
• Czy standardowe pełne i częściowe zwroty mogą przejść przez proces bez ręcznego szukania danych?
• Czy nietypowe lub niejednoznaczne przypadki są automatycznie zatrzymywane i kierowane do osobnej obsługi?
• Czy po wysłaniu dokumentu sprawdzasz wynik jego przetwarzania w KSeF, zamiast kończyć proces na statusie „wysłano”?
• Czy przechowujesz dokumentację pozwalającą odtworzyć przebieg zwrotu lub reklamacji?
• Czy proces rozróżnia sprzedaż B2B, B2C oraz faktury wystawione w KSeF i poza nim?
• Czy możesz przejść od zamówienia przez zwrot i fakturę do korekty, a następnie od korekty wrócić do zdarzenia, które ją spowodowało?
• Czy system zachowuje stan pierwotny transakcji, historię korekt i aktualny stan po wszystkich zmianach?
• Czy ponowne przetworzenie tego samego zdarzenia jest zabezpieczone przed utworzeniem drugiej, identycznej korekty?

Im większy wolumen sprzedaży, tym bardziej ta checklista staje się pytaniem o odporność całego procesu, a nie wyłącznie o gotowość księgowości. System może poprawnie komunikować się z KSeF, a jednocześnie generować błędne korekty, jeśli wcześniej nie potrafi ustalić właściwej pozycji, zastosowanego rabatu albo rodzaju transakcji. Gotowość do masowej obsługi oznacza więc, że standardowy przypadek przechodzi automatycznie od danych źródłowych do prawidłowego dokumentu, natomiast każda niejednoznaczność jest świadomie zatrzymywana przed wystawieniem korekty.

Najczęstsze pytania o KSeF, zwroty i reklamacje

Czy fakturę w KSeF można anulować po zwrocie towaru?

Jeżeli faktura została przyjęta przez KSeF i otrzymała numer KSeF, nie można jej później usunąć ani anulować w taki sposób, jakby nigdy nie została wystawiona. Zwrot produktu nie usuwa dokumentu pierwotnego z historii transakcji. Jeżeli zdarzenie powoduje konieczność zmiany danych wykazanych na fakturze, stosuje się odpowiednią fakturę korygującą. Może ona zmniejszać wartości wynikające ze zwrotu części lub całości sprzedaży albo korygować inne dane, zależnie od rzeczywistej przyczyny zmiany. Trzeba odróżnić tę sytuację od pliku wysłanego do KSeF, który został odrzucony i nie otrzymał numeru KSeF. W takim przypadku nie ma przyjętej faktury, którą należałoby anulować lub korygować. Należy usunąć przyczynę odrzucenia i ponownie przesłać prawidłowy dokument.

Czy każdy zwrot wymaga faktury korygującej?

Nie. Najpierw trzeba ustalić, czy dana sprzedaż została udokumentowana fakturą oraz czy zwrot rzeczywiście powoduje zmianę danych wynikających z tego dokumentu. W e-commerce B2C nie każda transakcja prowadzi do wystawienia faktury, dlatego nie można przyjąć prostej zasady „każdy zwrot równa się faktura korygująca”. Jeżeli jednak zwrot powoduje zmianę danych wykazanych na wystawionej fakturze, należy ocenić obowiązek wystawienia odpowiedniej faktury korygującej. Inaczej może wyglądać reklamacja zakończona wymianą wadliwego produktu na sprawny egzemplarz bez zmiany ceny i innych danych wymagających korekty. Kluczowe jest zatem ustalenie rzeczywistego skutku zdarzenia, a nie automatyczne generowanie korekty na podstawie samego statusu „zwrot”.

Jak skorygować częściowy zwrot zamówienia w KSeF?

Przy częściowym zwrocie korekta powinna odpowiadać faktycznemu zakresowi zmiany. Jeśli klient kupił kilka produktów, ale zwrócił tylko jeden, nie należy automatycznie zerować całej faktury. System powinien odnaleźć właściwą fakturę, zidentyfikować zwróconą pozycję lub część ilości, ustalić jej rzeczywistą wartość po uwzględnieniu rabatów i innych warunków sprzedaży, a następnie obliczyć zmianę podstawy opodatkowania i VAT, jeżeli korekta wpływa na te wartości. Jeżeli faktura pierwotna została wystawiona w KSeF, korekta powinna prawidłowo identyfikować dokument źródłowy, w tym poprzez jego numer KSeF. Przy kolejnych częściowych zwrotach trzeba również uwzględniać wcześniejsze korekty, zachowując jednocześnie pierwotny stan transakcji i pełną historię zmian.

Czy reklamacja zawsze wymaga korekty faktury?

Nie. Samo zgłoszenie reklamacji ani nawet jej uznanie nie oznaczają automatycznie, że dane na fakturze muszą zostać zmienione. Reklamacja może zakończyć się na przykład wymianą wadliwego produktu na sprawny egzemplarz, bez zmiany ceny, ilości ekonomicznie sprzedanych towarów czy pozostałych danych wymagających korekty. W takim przypadku faktura korygująca może nie być potrzebna. Inaczej wygląda sytuacja, gdy reklamacja prowadzi do obniżenia ceny, zwrotu części należności albo całkowitego rozliczenia danej części sprzedaży w inny sposób wpływający na fakturę. Wtedy trzeba ocenić skutek dla dokumentu pierwotnego i odpowiednio go skorygować. Dlatego triggerem dla korekty nie powinien być status „reklamacja uznana” sam w sobie, lecz ustalenie, jaki rzeczywisty skutek finansowy i podatkowy wynika z podjętej decyzji.

Kiedy przy zwrocie wystawić korektę do zera?

Korekta zmniejszająca wartości do zera może być właściwa, gdy po wystawieniu faktury wystąpiło zdarzenie powodujące konieczność skorygowania całej udokumentowanej nią wartości sprzedaży, na przykład w związku z pełnym zwrotem objętych nią towarów. Nie każdy zwrot oznacza jednak wyzerowanie całego dokumentu. Jeżeli klient zwraca tylko jedną z kilku pozycji albo część ilości, korekta powinna odpowiadać wyłącznie rzeczywistemu zakresowi zmiany. Szczególnym przypadkiem jest faktura wystawiona na błędnego nabywcę, gdy wskazany NIP identyfikuje inny podmiot niż rzeczywisty klient. W takiej sytuacji dokument wystawiony na niewłaściwego nabywcę koryguje się do zera, a następnie wystawia nową prawidłową fakturę pierwotną dla właściwego podmiotu. Nie należy traktować tej procedury jako sposobu poprawiania każdej drobnej literówki w danych klienta.

Czy można wystawiać zbiorcze korekty dla wielu zwrotów?

Nie należy traktować korekty zbiorczej jako sposobu na połączenie setek niezależnych zwrotów różnych klientów w jeden dokument. To, że system przetwarza wiele zwrotów w tym samym czasie, nie zmienia ich w jedną transakcję ani jedną relację sprzedawca–nabywca. W typowym modelu masowych zwrotów różnych klientów powstaną więc dokumenty przypisane do właściwych nabywców i faktur, choć technicznie mogą być generowane, walidowane i wysyłane jako jedna duża partia operacyjna. Jednocześnie przepisy przewidują możliwość korekt odnoszących się do więcej niż jednej faktury oraz szczególne rozwiązanie zbiorcze dotyczące między innymi okresowych opustów lub obniżek ceny dla jednego odbiorcy. Dlatego masowe przetwarzanie nie oznacza korekty zbiorczej, a możliwość zastosowania jednego dokumentu trzeba oceniać na podstawie charakteru konkretnej korekty.

Co zrobić, jeśli KSeF odrzuci fakturę lub korektę?

Jeżeli dokument nie przejdzie weryfikacji KSeF i zostanie odrzucony, system nie nada mu numeru KSeF. W takim przypadku trzeba zidentyfikować przyczynę odrzucenia, poprawić dane lub strukturę dokumentu i dopiero wtedy zdecydować o dalszej obsłudze. Nie wystawia się kolejnej faktury korygującej tylko po to, aby poprawić odrzucony plik, ponieważ dokument, który nie został przyjęty, nie stał się fakturą wystawioną w KSeF. Z tego powodu integracja nie powinna kończyć procesu w chwili wysłania dokumentu. Musi odebrać i zapisać wynik przetwarzania, a w razie odrzucenia automatycznie skierować przypadek do odpowiedniej ścieżki naprawczej lub kolejki wyjątków. Nie każdy błąd powinien powodować automatyczną ponowną wysyłkę, szczególnie jeżeli problem dotyczy nieprawidłowych danych biznesowych. Otrzymanie numeru KSeF jest potwierdzeniem przyjęcia dokumentu przez system, ale nie należy utożsamiać daty jego nadania z datą wystawienia faktury, którą ustala się zgodnie z zasadami właściwymi dla danego trybu.

Czy korekty faktur B2C również trafiają do KSeF?

Faktury B2C pozostają poza obowiązkowym KSeF, choć przedsiębiorca może wystawiać je w systemie dobrowolnie. Dlatego przy zwrocie konsumenckim najpierw trzeba ustalić, czy faktura w ogóle została wystawiona, a następnie w jaki sposób powstał dokument pierwotny. System powinien rozpoznawać sposób jego wystawienia oraz zastosować do korekty zasady właściwe dla konkretnego przypadku, zamiast zakładać, że każdy zwrot konsumencki wymaga dokumentu w KSeF. Jest to szczególnie istotne w dużych sklepach, w których obok faktur B2B objętych obowiązkiem KSeF występują faktury konsumenckie wystawione dobrowolnie w systemie oraz dokumenty B2C pozostające poza nim. Jedna reguła automatyczna zastosowana do wszystkich zwrotów konsumenckich byłaby więc zbyt dużym uproszczeniem.

Podsumowanie — przy dużej skali liczy się proces, nie samo wystawienie korekty

Przy kilku zwrotach miesięcznie firma może jeszcze traktować korektę jako pojedyncze zadanie księgowe. Przy tysiącach zamówień takie podejście szybko przestaje działać. Prawidłowa faktura korygująca jest bowiem końcem znacznie dłuższego łańcucha. Wcześniej klient musi zgłosić zwrot lub reklamację, firma musi rozpoznać zamówienie i właściwą pozycję, zweryfikować zdarzenie, ustalić jego rzeczywisty skutek, odtworzyć wartości po rabatach i wcześniejszych zmianach, odnaleźć odpowiedni dokument źródłowy oraz zastosować właściwą ścieżkę dla B2B, B2C i konkretnego sposobu wystawienia faktury. Dopiero wtedy można bezpiecznie wygenerować korektę i, jeżeli powinna znaleźć się w KSeF, przekazać ją do systemu oraz skontrolować wynik przetwarzania.

Dlatego KSeF jest ostatnim elementem łańcucha, a nie systemem zarządzającym całym zwrotem. Jakość korekt zależy przede wszystkim od danych i decyzji powstających wcześniej w sprzedaży, magazynie, obsłudze reklamacji, płatnościach i księgowości. Im większy e-commerce, tym mniej warto polegać na ręcznym odnajdywaniu dokumentów i wiedzy pojedynczych pracowników, a bardziej na trwałych identyfikatorach, jasno określonych triggerach, historii zmian, kolejce wyjątków i kontroli statusów. Firma przygotowująca ekspansję powinna potraktować wdrożenie KSeF nie tylko jako zmianę sposobu wystawiania i przesyłania faktur, lecz także jako okazję do uporządkowania procesów podatkowych, które wraz ze wzrostem sprzedaży będą musiały obsługiwać znacznie większy wolumen.

Jeżeli w Twoim e-commerce sprzedaż, zwroty i korekty przechodzą przez kilka systemów albo rozwój na nowe rynki zwiększa liczbę wyjątków podatkowych, warto uporządkować tę architekturę przed dalszym skalowaniem. amavat wspiera firmy e-commerce w porządkowaniu procesów VAT i KSeF związanych ze sprzedażą krajową oraz ekspansją, tak aby kwestie podatkowe były projektowane razem z procesem sprzedaży, a nie naprawiane dopiero wtedy, gdy rosnąca liczba transakcji zaczyna ujawniać jego słabe punkty.