KSeF i automatyzacja faktur: pipeline, którego naprawdę potrzebuje twój dział finansowy

Co KSeF naprawdę zmienia w codziennej pracy działu finansowego

Zacznij od procesu, który umiera. Przez lata wyglądał tak samo po obu stronach. Faktura przychodzi jako PDF na czyjąś skrzynkę, człowiek ją czyta i albo przepisuje do ERP, albo pozwala OCR-owi zgadywać pola. Dział zobowiązań porównuje ją wzrokiem z zamówieniem, księgowa dekretuje ją na konto, i faktura zostaje zaksięgowana. Po stronie sprzedaży ERP generuje PDF i wysyła mailem, a wszyscy liczą, że klient go dostał.

Przy KSeF to PDF przestaje być fakturą. Faktura sprzedażowa to teraz ustrukturyzowany XML zbudowany według schemy FA(3), wysłany do KSeF przez jego API. KSeF waliduje dokument i albo go odrzuca, albo przyjmuje i nadaje mu numer KSeF. To ten numer, a nie mail, jest dowodem, że faktura istnieje w sensie prawnym. Odbiór też jest obowiązkowy: od 1 lutego 2026 każda firma musi umieć przyjmować faktury przez KSeF, więc faktury od twoich polskich dostawców przychodzą teraz jako XML FA(3), który pobierasz z systemu, a nie jako załączniki do przejrzenia wzrokiem.

I tu jest część, którą poradniki pomijają. KSeF to warstwa transportu i rejestru, nie silnik księgowy. Oddaje ci czysty, zgodny ze schemą XML i numer. Nie dopasuje faktury do twojego zamówienia i nie zadekretuje jej ani nie zaksięguje. Cała ta praca uzgodnieniowa dalej jest twoja, tyle że teraz zaczyna się od danych strukturalnych, a nie od skanu. Krok oglądania PDF-a znika dla polskich kontrahentów, a dekretacja i dopasowanie nie. Zespoły, które założyły, że KSeF to automatyzacja, odkrywają, że automatyzacja, której naprawdę potrzebują, siedzi po obu stronach KSeF, i wciąż trzeba ją zbudować.

Docelowy pipeline, krok po kroku

Potraktuj to jako dwa pipeline'y, które spotykają się w KSeF, z jedną bramką dla człowieka pośrodku. Najpierw sprzedaż, bo to tam błąd najszybciej staje się problemem prawnym.

System fakturujący produkuje dane faktury. Krok mapowania zamienia te dane w XML FA(3), i to kod deterministyczny, bo każde pole ma w schemie dokładnie jedno miejsce, a mapowanie chcesz zrobić dobrze raz, a nie w przybliżeniu za każdym razem. Potem walidujesz XML lokalnie względem XSD FA(3), na własnej granicy, zanim w ogóle zadzwonisz do KSeF. Dopiero wtedy wysyłasz. KSeF odpowiada przyjęciem i numerem albo odrzuceniem i błędem, a twój kod zapisuje numer przy dokumencie w ERP albo kieruje błąd do człowieka.

Przy bramce walidacji lokalnej warto się zatrzymać, bo pipeline, który o zepsutym wyniku dowiaduje się dopiero z odrzucenia przez KSeF, wykłada się na koniec miesiąca pod obciążeniem. W systemie Figma-to-code, który budowaliśmy w zupełnie innej domenie, tani strukturalny check nigdy nie wystarczał sam z siebie; bramką, która naprawdę trzymała, była pętla walidacji renderująca wynik od nowa i porównująca go ze źródłem, i wyłapywała rozjazdy w około 15% klatek, które kod poprawny strukturalnie ukrywał. Ten sam instynkt działa tutaj. Sprawdź swoją robotę, zanim ją oddasz, a nie po fakcie.

Odbiór idzie w drugą stronę. Zaplanowane zadanie odpytuje KSeF o nowe faktury, parsuje każdy XML FA(3) do własnego kanonicznego rekordu i deduplikuje, żeby ten sam dokument nie wszedł dwa razy. Reguły dopasowują go do zamówienia i przyjęcia towaru. Potem przychodzi dekretacja: przypisanie konta i MPK, a do tego ujęcia VAT. Wszystko, co dopasowuje się czysto i dekretuje z pewnością, płynie prosto do księgowania. Reszta zatrzymuje się na bramce.

Ta bramka to nośna decyzja w całym projekcie. Nie wybierasz między w pełni ręcznym a w pełni automatycznym. Wybierasz próg. Faktury, które dopasowują się czysto i dekretują w granicach tolerancji, księgują się same; wyjątki czekają na człowieka, każdy z powodem, dla którego się zatrzymał. Ustaw próg dobrze, a człowiek dotyka garstki faktur, które naprawdę wymagają osądu, zamiast przeklikiwać setki, które go nie wymagają.

Gdzie w automatyzacji KSeF zarabia AI, a gdzie wygrywa zwykły kod

Ten podział to miejsce, gdzie automatyzacja KSeF najczęściej idzie w złą stronę, w jedną z dwóch. Jeden zespół kieruje model językowy na całość, bo "AI", i pozwala mu generować XML, który jest w większości poprawny, czyli czasem niepoprawny. Drugi zespół ręcznie koduje rozmytą klasyfikację, którą model zrobiłby lepiej, i tonie w regułach. Uczciwa odpowiedź brzmi tak: automatyzacja faktur w KSeF to w większości kod deterministyczny z kilkoma dobrze dobranymi miejscami, w których model naprawdę zarabia na swoje utrzymanie. Właśnie ten uczciwy podział, a nie hasło "AI robi teraz faktury", odróżnia pipeline, któremu ufasz na koniec miesiąca, od takiego, który niańczysz.

Zwykłego, deterministycznego kodu używaj wszędzie tam, gdzie jest jedna poprawna odpowiedź i schema za nią. Budowa i parsowanie XML FA(3) to dokładnie to: sztywna struktura, w której "w większości dobrze" jest błędem, nie cechą. Walidacja XSD to przejście albo odrzucenie. Deduplikacja po numerze KSeF, wysyłka z idempotencją, ponawianie z backoffem gdy KSeF zwalnia, sprawdzenie stawki VAT: żadne z tych miejsc nie chce osądu modelu, chcą funkcji, która zachowuje się tak samo za każdym razem. Model językowy w którymkolwiek z nich dokłada koszt i opóźnienie, a do tego tryb awarii, którego wcześniej nie miałeś.

Model wprowadzaj tam, gdzie odpowiedź jest kwestią osądu, a ty masz historię, z której można się uczyć. Dekretacja to najczystszy przypadek: przypisanie pozycji z opisu tekstowego do właściwego konta i MPK to rozmyta klasyfikacja, a ponieważ FA(3) jest strukturalne, model klasyfikuje czyste pola, a nie papkę z OCR, co czyni go i łatwiejszym, i pewniejszym. Dopasowanie rozjechanych pozycji faktury do zamówień, gdy zmieniono nazwy SKU albo dostawa była częściowa, to kolejne miejsce, gdzie model proponuje to, czego silnik reguł nie potrafi. Podobnie flagowanie anomalii, dostawca fakturujący w walucie, której nigdy nie używa, albo kwota dziesięć razy większa niż zwykle, gdzie model to wyławia, a decyduje człowiek.

Jeszcze jedno miejsce uczciwie zasługuje na model: faktury, które w ogóle nie wchodzą do KSeF. Zagraniczny dostawca bez stałego miejsca prowadzenia działalności w Polsce jest zwolniony, więc dalej przysyła PDF-y, i tam OCR z ekstrakcją LLM wciąż robi realną robotę. Dwie rzeczy pilnuj przy tym z głową. Dane na fakturze to dane osobowe w rozumieniu RODO, nazwy kontrahentów, jednoosobowe działalności, NIP-y, więc gdzie działa model, ma znaczenie: procesuj je pod kontrolą, najlepiej u dostawcy z umową powierzenia, a nie wrzucaj bezrefleksyjnie do losowego zewnętrznego API. A bramka z człowiekiem, o której mowa wyżej, to nie tylko kontrola jakości, to też twój mechanizm nadzoru, który trzyma asystenta AI po właściwej stronie audytu i AI Act.

Tryby awarii, które projektujesz od pierwszego dnia

Demo obsługuje ścieżkę szczęśliwą. Produkcja to przypadki brzegowe, a przy KSeF przypadki brzegowe mają ciężar prawny, więc projektujesz je od początku, a nie łatasz po pierwszym złym zamknięciu miesiąca.

Najpierw odrzucenia schemy. KSeF odrzuca niepoprawny XML, a odrzucona faktura sprzedażowa, której nikt nie zauważył, to faktura niewystawiona, luka zgodności i dziura w cashflow naraz. Waliduj lokalnie, żeby większość odrzuceń w ogóle nie nastąpiła, a gdy KSeF i tak powie nie, podnieś to do człowieka z dokładnym błędem w załączeniu. Cicha awaria to jedyny wynik, na który tu nie możesz sobie pozwolić.

Potem duplikaty. Ta sama faktura może trafić do twojego systemu więcej niż raz: ponowne odpytanie, ponowna wysyłka, faktura z trybu offline, która dochodzi dwa razy po powrocie łączności. Deduplikujesz po numerze KSeF i traktujesz wysyłkę jako idempotentną. To problem exactly-once, i ma ten sam kształt co w pipelinie feedu w czasie rzeczywistym, gdzie jedno ogłoszenie mogło przyjść na nakładających się oknach i wciąż musiało zostać dostarczone dokładnie raz. Ponawianie z backoffem przy przejściowych błędach KSeF mieszka w tej samej warstwie.

Dalej niewygodne faktury. Korekty (faktura korygująca), dokumenty wielowalutowe, zwolnieni zagraniczni dostawcy, którzy dalej przysyłają PDF-y, faktury z załącznikiem, bo FA(3) dodało dla niego węzeł: każda to osobna gałąź, którą wypisujesz przed startem, bo to one zatrzymują partię w najgorszym momencie. Tryb offline ma własny zegar. Tryb offline24 pozwala wystawić fakturę bez żywego połączenia, ale masz czas do końca następnego dnia roboczego, żeby wysłać dokument do KSeF, a dłuższe okno obowiązuje tylko podczas ogłoszonej awarii KSeF. Ten termin się monitoruje, a nie liczy na to, że sam się utrzyma.

Awaria, która gryzie po cichu, to rozjazd mapowania. Twój ERP zmienia pole, twoje mapowanie FA(3) dalej produkuje XML poprawny, ale semantycznie zły, i przechodzi kontrolę schemy, żeby wyłożyć się na audycie miesiące później. Poprawny-ale-zły jest groźniejszy niż niepoprawny, bo niepoprawny zostaje odrzucony, a zły zostaje przyjęty. Obroną jest sprawdzenie w obie strony na poziomie znaczenia, nie tylko struktury: zbuduj XML, sparsuj go z powrotem do rekordu i porównaj to z tym, co chciałeś wysłać, zanim zobaczy to KSeF, a nie zanim zobaczy to twoja księgowa.

Checklista gotowości, którą przejdziesz w tym tygodniu

Własny setup możesz sprawdzić pod obciążeniem bez zatrudniania kogokolwiek. Przejdź te siedem punktów i bądź szczery, na które odpowiadasz systemem, a na które pamięcią konkretnej osoby.

Jeśli na wszystkie siedem odpowiadasz systemem, jesteś w dobrym miejscu i potrzebujesz głównie monitoringu. Jeśli trzy czy cztery to wciąż "ktoś pamięta, żeby sprawdzić", masz swoją listę do zbudowania, w kolejności priorytetów. A aktualne terminy, progi i wersje schemy to jedyna rzecz, którą warto przeczytać u źródła, zanim zaklepiesz kod, bo KSeF przesuwał swoje daty nieraz: oficjalny harmonogram na podatki.gov.pl jest punktem odniesienia. A jeśli wolisz, żeby ktoś zmapował tę listę na twój ERP i stack razem z tobą, robimy takie rzeczy w ramach bezpłatnego audytu.

FAQ