Faktura wystawiona w offline24 nie powinna po późniejszym przesłaniu do KSeF wracać do DMS jako „nowy dokument”. To właśnie w tym miejscu najłatwiej stworzyć podwójny obieg: najpierw akceptowana jest faktura utworzona poza bieżącą sesją KSeF, a po nadaniu numeru KSeF integracja importuje ją ponownie i uruchamia drugi workflow. Efekt jest groźniejszy niż zwykły bałagan w archiwum. Użytkownik może zobaczyć dwie pozycje dotyczące tej samej sprzedaży, księgowość może próbować obsłużyć je niezależnie, a system traci wiarygodną historię tego, co naprawdę wydarzyło się z dokumentem.
Poprawny model jest odwrotny: faktura ma jedno wewnętrzne ID przez cały cykl życia, a zmieniają się wyłącznie jej statusy i metadane. Najpierw może istnieć jako XML wystawiony w trybie offline24, później otrzymuje informację o wysłaniu, następnie numer KSeF i UPO. Nie staje się przez to drugim dokumentem.
Trzeba przy tym pilnować terminologii. Offline24 nie oznacza „24 godzin na wysłanie”. Fakturę należy przesłać do KSeF niezwłocznie, najpóźniej w następnym dniu roboczym po dniu wystawienia. Jeżeli więc dokument powstanie w piątek, termin co do zasady przypadnie na poniedziałek, o ile nie jest to dzień wolny. Datą wystawienia pozostaje data wpisana w polu P_1 struktury FA(3).
Jedna faktura w DMS, nawet jeśli jej numer KSeF pojawi się później
Najbezpieczniejsza konstrukcja DMS opiera się na rozdzieleniu tożsamości dokumentu od jego statusu w KSeF. Numer KSeF nie powinien być głównym kluczem faktury, ponieważ w chwili wystawienia offline24 po prostu jeszcze go nie ma.
Minimalny rekord dokumentu powinien zawierać co najmniej:
- stałe wewnętrzne ID faktury nadawane w ERP, systemie sprzedażowym lub DMS,
- numer własny faktury z pola P_2,
- datę wystawienia z P_1,
- NIP sprzedawcy i dane nabywcy,
- oryginalny plik XML FA(3),
- informację o trybie wystawienia, np. offline24,
- status wysyłki do KSeF,
- wiarygodny identyfikator integracyjny lub techniczny, jeżeli architektura integracji go przewiduje,
- numer KSeF po jego nadaniu,
- UPO albo informację pozwalającą je jednoznacznie powiązać z dokumentem,
- historię zmian statusu i prób wysyłki.
Numer KSeF jest metadaną nadawaną później, a nie nową tożsamością dokumentu.
Załóżmy hipotetycznie, że 6 października spółka wystawia w offline24 fakturę sprzedażową i nadaje jej wewnętrzny identyfikator FV-INT-84521. DMS zapisuje XML i uruchamia zwykły proces kontroli: zgodność z zamówieniem, limit kredytowy, dekretację lub inną ścieżkę obowiązującą w organizacji. Dokument zostaje zaakceptowany. Później integracja przesyła ten sam XML do KSeF i otrzymuje numer KSeF.
Błędna integracja wykona w tym momencie import „nowej faktury z KSeF”. Prawidłowa najpierw próbuje ustalić, czy dokument już istnieje, a następnie aktualizuje istniejący rekord:
zaakceptowana / oczekuje na KSeF → przesłana → przyjęta przez KSeF.
Workflow akceptacyjny nie startuje drugi raz.
Tu potrzebna jest jednak ważna granica techniczna. Dopasowanie przed nadaniem numeru KSeF nie może opierać się wyłącznie na samym P_2 ani wyłącznie na samym NIP-ie. Numer własny faktury może powtarzać się w różnych spółkach, seriach, latach lub systemach źródłowych, a NIP identyfikuje podmiot, nie konkretny dokument.
Najpewniejsze mechanizmy to:
- trwały identyfikator integracyjny przekazywany między ERP, warstwą integracyjną i DMS,
- hash identycznego XML, jeżeli porównywany jest dokładnie ten sam dokument źródłowy,
- kontrolowany zestaw danych, np. P_2, P_1, NIP sprzedawcy, NIP nabywcy, kwota brutto, waluta i identyfikator spółki lub jednostki organizacyjnej,
- dodatkowy kontekst systemu źródłowego, serii numeracyjnej i podmiotu prawnego.
Hash XML jest bardzo mocnym kluczem, ale tylko wtedy, gdy porównujemy ten sam plik. Jeśli po drodze system technicznie przebuduje XML, zmieni kolejność elementów, formatowanie albo inne elementy wpływające na reprezentację pliku, hash nie musi pozostać identyczny. Dlatego w dużych grupach kapitałowych lepszy jest trwały identyfikator integracyjny nadany przed wysyłką, a hash pełni rolę dodatkowej kontroli.
Idempotentność powinna działać także przy kolejnych synchronizacjach. Jeżeli integracja pobierze tę samą fakturę z KSeF pięć razy, DMS ma pięć razy rozpoznać ten sam dokument, a nie utworzyć pięć rekordów.
Taki model ma sens wszędzie tam, gdzie firma dopuszcza offline24 albo inne tryby offline i jednocześnie używa DMS, ERP lub platformy workflow. Nie ma sensu budować osobnej „kartoteki faktur offline” i po uzyskaniu numeru KSeF przenosić dokumentu do drugiej kartoteki. To tworzy dwa źródła prawdy.
Najbardziej ryzykowny jest model, w którym kryterium unikalności stanowi wyłącznie numer KSeF. Przed wysyłką pole jest puste, więc system traktuje dokument jako tymczasowy. Po synchronizacji otrzymuje numer i uznaje go za nowy obiekt. To projekt integracji, który sam produkuje duplikaty.
Potwierdzenie transakcji, faktura i dwa kody QR to trzy różne przypadki
Drugie źródło duplikatów pojawia się na styku DMS i kanału przekazania dokumentu nabywcy. Nie każdy plik, który klient otrzymuje przed dosłaniem faktury do KSeF, jest fakturą.
Jeżeli nabywcą jest krajowy podatnik z NIP, który otrzymuje fakturę w KSeF, faktura wystawiona w offline24 trafia do niego poprzez KSeF. Zanim system nada jej numer KSeF, sprzedawca może przekazać nabywcy potwierdzenie transakcji.
Potwierdzenie transakcji nie jest fakturą. Zawiera ograniczony zestaw danych, w tym dane stron, numer faktury nadany przez podatnika, kwotę należności ogółem oraz wymagane elementy pozwalające powiązać je z właściwym dokumentem i zweryfikować wystawcę.
To rozróżnienie musi istnieć również w DMS. Potwierdzenie nie może dostać typu dokumentu „faktura sprzedażowa”, bo system zacznie traktować je jak drugi dokument księgowy.
Hipotetyczny scenariusz: kierowca firmowy odbiera towar w magazynie dostawcy, a faktura została właśnie wystawiona w offline24. Dostawca chce przekazać mu dokument od razu. Jeżeli nabywcą jest polska firma z NIP odbierająca faktury w KSeF, może otrzymać potwierdzenie transakcji, a właściwą fakturę otrzyma w KSeF po jej przesłaniu przez wystawcę. DMS nabywcy nie powinien księgować potwierdzenia jako faktury ani uruchamiać na jego podstawie standardowej akceptacji kosztu.
Inaczej wygląda sytuacja podmiotów wskazanych w art. 106gb ust. 4 ustawy o VAT, czyli przypadków, w których faktura jest otrzymywana poza KSeF. Jeżeli faktura jest im udostępniana poza systemem przed przesłaniem do KSeF, stosuje się zasady właściwe dla takiego udostępnienia, w tym wymagane oznaczenia QR.
I tu pojawia się częsty błąd wdrożeniowy: regułę „faktura offline ma dwa QR” wpisuje się do systemu jako zasadę dla wszystkich odbiorców. To nie jest poprawne uproszczenie. Dwa kody QR przed wysyłką dotyczą przewidzianych ustawą przypadków udostępniania faktury poza KSeF. Dla krajowego nabywcy z NIP, który odbierze fakturę w KSeF, wcześniejszy dokument może być potwierdzeniem transakcji, a nie drugą wersją faktury wręczaną „na wszelki wypadek”.
DMS powinien więc przed wygenerowaniem dokumentu dla odbiorcy rozstrzygnąć co najmniej trzy kwestie:
- czy nabywca otrzymuje fakturę w KSeF,
- czy należy do grupy objętej wyjątkiem przewidzianym w art. 106gb ust. 4,
- czy właściwa faktura ma już nadany numer KSeF.
Dopiero wynik tych warunków powinien decydować, czy generowana jest wizualizacja faktury, dokument z kodami QR czy potwierdzenie transakcji.
To rozwiązanie jest szczególnie potrzebne w firmach, które mają sprzedaż mieszaną: B2B krajowe, kontrahentów zagranicznych, klientów bez NIP i sprzedaż dla konsumentów. Przy jednolitym modelu sprzedaży reguły będą prostsze, ale nadal nie warto zaszywać ich na sztywno w szablonie PDF. Powinny wynikać ze statusu nabywcy i sposobu udostępnienia faktury.
Odrzucenie techniczne nie powinno uruchamiać nowej faktury ani nowej akceptacji
Najbardziej kosztowny błąd pojawia się wtedy, gdy KSeF odrzuca wysyłany plik. W wielu starszych integracjach status „odrzucony” jest interpretowany biznesowo: skoro wysyłka się nie powiodła, użytkownik tworzy dokument jeszcze raz. Przy fakturze wystawionej offline to zła logika.
Dla faktur offline odrzuconych przy próbie przesłania do KSeF przewidziano mechanizm korekty technicznej pliku XML, między innymi wtedy, gdy dokument nie spełnia wymagań struktury logicznej. Plik doprowadza się do zgodności i wysyła ponownie. Przy korekcie technicznej przekazywany jest również hash błędnego pliku.
Dla DMS oznacza to jedno: techniczne odrzucenie wysyłki powinno zmienić status tej samej faktury, np.:
zaakceptowana → wysłana do KSeF → odrzucona technicznie → wymaga naprawy XML → ponowiona wysyłka → przyjęta.
Nie powinien pojawić się drugi rekord ani drugi pełny workflow akceptacyjny.
Załóżmy hipotetycznie, że faktura o wartości 48 000 zł została zatwierdzona przez dyrektora sprzedaży. KSeF odrzuca XML, ponieważ plik nie spełnia technicznego wymogu struktury. Program poprawia strukturę bez zmiany ceny, kontrahenta, VAT ani zakresu świadczenia. Ponowne kierowanie dokumentu do dyrektora nie ma sensu biznesowego — dyrektor nie zatwierdza składni XML.
Inaczej będzie, jeżeli podczas analizy błędu okaże się, że trzeba zmienić dane merytoryczne: kwotę, stawkę VAT, nabywcę, pozycję towarową albo inne pole objęte kontrolą biznesową. Wtedy DMS powinien uruchomić adekwatny fragment kontroli ponownie. Nie zawsze oznacza to cały proces od początku.
Jeżeli zmieniła się wyłącznie klasyfikacja podatkowa, sens może mieć ponowna kontrola podatkowa bez powtarzania akceptacji handlowej. Jeśli natomiast wartość faktury zmienia się z 9 800 zł na 58 000 zł, a firma ma próg akceptacyjny 50 000 zł, potrzebna jest ponowna zgoda osoby z odpowiednim limitem.
To właśnie różnica między naprawą techniczną a zmianą biznesową powinna sterować workflow.
Trzeba także odróżnić trzy procedury, które od strony integracji mogą wyglądać podobnie, ale prawnie nie są tym samym:
- offline24 — może zostać wybrany przez podatnika; dokument trzeba przesłać niezwłocznie, najpóźniej następnego dnia roboczego po wystawieniu,
- tryb związany z niedostępnością KSeF — dotyczy okresu oficjalnie ogłoszonej niedostępności; termin dosłania wynika z reguł właściwych dla tego trybu,
- tryb awaryjny — stosowany po ogłoszeniu awarii KSeF i podlegający odrębnym zasadom oraz terminom.
Jeżeli już po wystawieniu faktury offline24, a przed jej przesłaniem, zostanie ogłoszona awaria KSeF, termin może zmienić się zgodnie z zasadami właściwymi dla awarii. DMS nie powinien więc mieć jednego twardego licznika „24 h”. Powinien przechowywać rodzaj procedury i wyliczać termin na podstawie daty wystawienia oraz aktualnego statusu KSeF.
Jeszcze inaczej należy traktować fakturę korygującą. To nie jest techniczna wersja pierwotnego pliku. Korekta jest oddzielnym dokumentem. Jeżeli dotyczy faktury pierwotnej wystawionej w offline24, faktura pierwotna powinna zostać prawidłowo przyjęta w KSeF i uzyskać numer KSeF, a korekta musi być obsłużona jako odrębny dokument powiązany z dokumentem pierwotnym.
W systemie warto więc ustanowić prostą granicę: ten sam sens ekonomiczny i naprawa techniczna — ten sam dokument; merytoryczna zmiana wymagająca faktury korygującej — nowy dokument powiązany z pierwotnym.
FAQ
Czy offline24 można stosować tylko wtedy, gdy nie działa internet?
Nie. Offline24 jest dostępny z wyboru podatnika i nie jest zarezerwowany wyłącznie na problemy techniczne.
Czy „offline24” daje dokładnie 24 godziny na przesłanie faktury do KSeF?
Nie. Graniczny termin to następny dzień roboczy po dniu wystawienia faktury. Nazwa trybu nie powinna być podstawą do ustawienia w DMS licznika 24 godzin.
Jaka jest data wystawienia faktury offline24?
Data wskazana przez wystawcę w polu P_1 struktury logicznej. Późniejsze przydzielenie numeru KSeF nie zmienia tej daty.
Czy numer KSeF należy zapisać bezpośrednio w oryginalnym XML faktury?
Nie. Numer KSeF jest nadawany po przyjęciu dokumentu przez system, dlatego w DMS powinien być przechowywany jako metadana powiązana z zachowanym dokumentem źródłowym.
Czy przed uzyskaniem numeru KSeF wystarczy dopasować dokument po P_2?
Nie. Sam P_2 nie daje wystarczającej pewności. Bezpieczniejsze jest użycie trwałego identyfikatora integracyjnego, hasha identycznego XML albo zestawu danych obejmującego m.in. P_2, P_1, NIP-y, kwotę, walutę oraz kontekst konkretnej spółki lub systemu źródłowego.
Czy potwierdzenie transakcji można skierować do zwykłego obiegu faktur kosztowych?
Nie. Potwierdzenie transakcji nie jest fakturą. Jeżeli system je przechwytuje, powinno mieć osobny typ dokumentu i nie może być księgowane jak faktura.
Czy każda faktura offline24 przed wysłaniem musi mieć dwa kody QR?
Nie. Zasady zależą od sposobu udostępnienia i statusu nabywcy. Nie wolno przenosić wymogu dwóch kodów QR na wszystkich odbiorców.
Czy techniczne odrzucenie przez KSeF oznacza konieczność wystawienia drugiej faktury?
Nie. Techniczna naprawa i ponowienie wysyłki powinny dotyczyć tego samego dokumentu.
Kiedy ponownie uruchomić akceptację?
Gdy zmiana dotyczy danych, które były przedmiotem decyzji biznesowej lub podatkowej. Naprawa składni XML nie uzasadnia pełnego ponowienia akceptacji. Zmiana kwoty, kontrahenta, VAT albo danych przekraczających firmowy próg akceptacyjny może już tego wymagać.
Pierwszym krokiem przy porządkowaniu obiegu nie powinno być dodawanie kolejnych statusów. Najpierw sprawdź, po czym DMS rozpoznaje tożsamość faktury. Jeżeli po synchronizacji z KSeF numer KSeF powoduje utworzenie nowego rekordu zamiast aktualizacji istniejącego dokumentu, usuń ten błąd przed wdrażaniem dalszych reguł.
W drugiej kolejności sprawdź mechanizm dopasowania dokumentu przed nadaniem numeru KSeF. Jeżeli opiera się wyłącznie na P_2 albo wyłącznie na NIP-ie, to nadal jest za słaby. Potrzebny jest trwały identyfikator integracyjny, hash identycznego XML albo kontrolowany zestaw danych uwzględniający również kontekst spółki i systemu źródłowego.
Dopiero później ustaw osobne statusy dla offline24, niedostępności i awarii oraz warunki ponownego uruchamiania kontroli. Bez stałego wewnętrznego ID i idempotentnego importu każdy bardziej rozbudowany workflow będzie tylko sprawniej produkował duplikaty.
