Faktura z KSeF bez protokołu, WZ i umowy – jak automatycznie połączyć komplet dokumentów w DMS?

Faktura trafia z KSeF do systemu finansowo-księgowego niemal automatycznie. Problem zaczyna się chwilę później, gdy księgowość potrzebuje odpowiedzi na prostsze z pozoru pytanie: gdzie jest dokument, który potwierdza, że tę fakturę rzeczywiście można zapłacić?

WZ może znajdować się w ERP. Protokół odbioru – w e-mailu kierownika projektu. Umowa – w folderze działu prawnego. Zamówienie – w systemie zakupowym. Zdjęcia wykonanej pracy – na SharePoint albo w telefonie pracownika terenowego. Sama faktura jest natomiast w KSeF.

KSeF tego problemu nie rozwiązuje, bo jego rolą jest przede wszystkim obsługa faktur ustrukturyzowanych, a nie budowanie pełnej dokumentacji gospodarczej transakcji. Od 1 lutego 2026 r. faktury w KSeF korzystają ze struktury FA(3), a odbieranie faktur przez podmioty objęte systemem stało się obowiązkowe już od tej daty. Obowiązek wystawiania wdrażano etapami: od 1 lutego 2026 r. dla największych podatników i od 1 kwietnia 2026 r. dla pozostałych, z czasowym wyjątkiem dla najmniejszych podmiotów spełniających ustawowy limit.

To oznacza zmianę problemu, a nie jego zniknięcie. Firma nie musi już polować na PDF faktury wysłany na niewłaściwą skrzynkę, ale nadal musi ustalić, do jakiego zamówienia, dostawy, protokołu i umowy należy faktura pobrana z KSeF. Rozsądny model nie polega więc na stworzeniu kolejnego archiwum faktur. Potrzebna jest teczka transakcji, czyli obiekt w DMS łączący dokumenty z kilku systemów wokół jednego zdarzenia gospodarczego.

KSeF dostarcza fakturę. Nie dostarcza całej historii transakcji

Najważniejsze rozróżnienie jest techniczne: faktura z KSeF i dokumentacja potwierdzająca wykonanie transakcji to dwa różne zbiory informacji.

Faktura ustrukturyzowana ma postać XML zgodnego ze strukturą FA(3). Może zawierać między innymi dane stron, pozycje, kwoty, informacje o płatności, transporcie czy dane dodatkowe. FA(3) przewiduje również element załącznika, ale nie należy z tego wyciągać wniosku, że KSeF automatycznie stanie się repozytorium umów, protokołów odbioru i WZ dla każdej transakcji. Korzystanie z załącznika wymaga spełnienia określonych warunków, a sam mechanizm nie zastępuje firmowego procesu zarządzania dokumentacją.

W praktyce trzeba założyć, że dokumenty nadal będą przychodziły wieloma kanałami:

• faktura – przez KSeF,

• zamówienie – z ERP lub systemu zakupowego,

• WZ – z magazynu lub systemu logistycznego,

• protokół odbioru – z DMS, systemu projektowego albo e-maila,

• umowa i aneksy – z repozytorium umów,

• korespondencja dotycząca reklamacji lub zmiany zakresu – z poczty elektronicznej,

• zdjęcia i dokumentacja wykonawcza – z systemu serwisowego, aplikacji mobilnej albo repozytorium plików.

Dobrym przykładem jest zakup 120 sztuk wyposażenia magazynowego. Zamówienie PO/2026/418 opiewa na 84 000 zł netto. Dostawca realizuje je w trzech transportach: 40, 50 i 30 sztuk. Powstają trzy dokumenty WZ. Następnie wystawiane są dwie faktury – pierwsza za dwa pierwsze transporty, druga za trzeci.

Nie ma tutaj relacji jedna faktura = jedno WZ = jedno zamówienie. Jedno zamówienie łączy się z trzema WZ i dwiema fakturami. System zbudowany na założeniu relacji 1:1 zacznie albo odrzucać poprawne dokumenty, albo tworzyć duplikaty „teczek”.

Dlatego teczka transakcji powinna pozwalać na relacje jeden-do-wielu i wiele-do-wielu. Jej głównym identyfikatorem może być numer zamówienia, numer kontraktu, numer projektu, zlecenie serwisowe albo inny identyfikator stosowany konsekwentnie w organizacji. Numer faktury czy numer KSeF są wtedy ważnymi atrybutami dokumentu, ale nie muszą być kluczem całej sprawy.

Szczególnie istotny jest numer KSeF. Ministerstwo Finansów jednoznacznie wskazuje, że numer ten jest nadawany przez system po przyjęciu e-faktury i nie jest elementem oryginalnego pliku XML faktury. Jest między innymi zwracany w UPO.

To ma praktyczną konsekwencję dla DMS. Po pobraniu faktury nie należy modyfikować źródłowego XML tylko po to, aby „dopisać” do niego numer KSeF. Lepszy model to:

• zachowanie oryginalnego XML bez zmian,

• zapisanie numeru KSeF w metadanych rekordu dokumentu,

• zachowanie informacji o dacie pobrania i źródle,

• opcjonalne przechowanie UPO lub danych potwierdzających obsługę dokumentu,

• wygenerowanie wizualizacji faktury jako osobnego pliku, jeżeli jest potrzebna użytkownikom.

Dzięki temu firma może później udowodnić, który plik rzeczywiście otrzymała z KSeF, zamiast dysponować lokalnie zmodyfikowaną kopią.

Kiedy takie rozdzielenie ma największe znaczenie? Przy audytach, sporach z kontrahentem, kontroli integralności dokumentów oraz integracji kilku systemów. Jeśli natomiast firma przechowuje jedynie wizualizację faktury i traktuje ją jako podstawowy dokument, szybko pojawia się problem z ustaleniem, co dokładnie pochodziło z KSeF, a co zostało wygenerowane później przez własne oprogramowanie.

Automatyczne łączenie dokumentów działa dopiero wtedy, gdy systemy mówią tym samym identyfikatorem

Najczęstszy błąd projektowy polega na założeniu, że DMS „sam rozpozna”, która faktura należy do którego zamówienia. Może próbować. Nie powinien jednak zgadywać tam, gdzie wynik uruchamia płatność.

Automatyczne powiązanie wymaga integracji źródeł i wspólnych identyfikatorów transakcji. Im wcześniej identyfikator pojawia się w procesie, tym mniej heurystyki trzeba stosować później.

Najmocniejszymi kluczami są zwykle:

1. numer zamówienia zakupu,

2. numer umowy lub kontraktu,

3. numer zlecenia albo projektu,

4. identyfikator dostawy lub przyjęcia magazynowego,

5. identyfikator kontrahenta, np. NIP, połączony z dodatkowymi warunkami,

6. numer faktury dostawcy,

7. numer KSeF jako jednoznaczny identyfikator konkretnej faktury już po jej przyjęciu przez system.

Sam NIP dostawcy jest za słabym kluczem. Firma może dostać tego samego dnia od jednego kontrahenta dziesięć faktur dotyczących różnych projektów. Kwota również nie wystarczy – powtarzalne wartości są normalne, szczególnie przy abonamentach, najmach, usługach serwisowych czy dostawach cyklicznych.

Dobry algorytm działa warstwowo. Najpierw sprawdza identyfikatory jednoznaczne. Dopiero gdy ich brakuje, uruchamia reguły pomocnicze.

Przykład: do DMS trafia faktura na 24 600 zł brutto od dostawcy o określonym NIP. W danych faktury znajduje się numer zamówienia PO/2026/817. ERP zna to zamówienie i wskazuje trzy przyjęcia magazynowe. DMS może więc automatycznie dołączyć fakturę do istniejącej teczki PO/2026/817, pobrać powiązane dokumenty WZ i skierować zestaw do kontroli merytorycznej.

Jeżeli numeru zamówienia nie ma, system może sprawdzić jednocześnie:

• NIP kontrahenta,

• kwotę i walutę,

• przedział dat,

• numery WZ wpisane na fakturze,

• pozycje towarowe,

• projekt lub MPK,

• numer umowy,

• historyczne relacje pomiędzy dokumentami.

Tu potrzebny jest jednak próg pewności, a nie automatyczne zatwierdzanie każdego najlepszego dopasowania. Jeśli na przykład system znajduje jedno zamówienie zgodne pod względem numeru, NIP i pozycji – powiązanie można wykonać bez udziału człowieka. Jeśli pasują trzy otwarte zamówienia tego samego dostawcy, dokument powinien trafić do kolejki wyjątków.

Sensowny model rozdziela trzy wyniki:

• dopasowanie jednoznaczne – powiązanie automatyczne,

• dopasowanie prawdopodobne – propozycja przedstawiona użytkownikowi,

• brak wiarygodnego dopasowania – ręczne wskazanie transakcji.

To ważniejsze niż próba osiągnięcia 100 proc. automatyzacji. Fałszywe połączenie faktury z niewłaściwym protokołem odbioru jest bardziej niebezpieczne niż pozostawienie dokumentu na kilka minut w kolejce do weryfikacji.

W praktyce warto również egzekwować identyfikator już po stronie procesu zakupowego. Jeśli numer zamówienia powstaje w ERP, powinien być przekazany dostawcy i wymagany na kolejnych dokumentach. Bez tej dyscypliny firma próbuje później naprawiać problem organizacyjny OCR-em, analizą tekstu albo modelem AI.

Takie narzędzia są przydatne dla starych dokumentów, skanów i wyjątków, ale nie powinny zastępować dobrego klucza transakcyjnego. Rozpoznanie numeru zamówienia ze skanu jest pomocą. Umieszczenie poprawnego numeru w danych źródłowych jest regułą.

Teczka transakcji w DMS powinna sterować decyzją, a nie tylko przechowywać pliki

DMS w tym modelu nie jest katalogiem nazwanym „KSeF”. Ma być warstwą, która pokazuje użytkownikowi pełny kontekst zobowiązania przed jego akceptacją.

Trzeba przy tym zachować jedno zastrzeżenie: „teczka transakcji” nie jest automatycznie dostępna w każdym produkcie określanym jako DMS. To model procesu, który trzeba skonfigurować, a czasem zbudować przez integrację DMS z KSeF, ERP, pocztą, systemem zakupowym i repozytorium umów. Zakres możliwości zależy od konkretnego oprogramowania, API i architektury firmy.

Praktyczna teczka może zawierać na jednym ekranie:

Dane transakcji

• dostawca i NIP,

• numer zamówienia,

• numer umowy,

• projekt lub MPK,

• osoba odpowiedzialna,

• uzgodniony budżet.

Dokumenty

• XML faktury z KSeF,

• numer KSeF zapisany jako metadana,

• wizualizację faktury,

• zamówienie,

• jedno albo kilka WZ,

• protokół odbioru,

• umowę i aneksy,

• zdjęcia,

• korespondencję dotyczącą odstępstw.

Status kontroli

• zgodność z zamówieniem,

• zgodność ilościowa z przyjęciem,

• zgodność ceny,

• potwierdzenie wykonania usługi,

• zgłoszone reklamacje,

• akceptacja właściciela kosztu,

• status księgowy i płatniczy.

Wyobraźmy sobie firmę budowlaną odbierającą fakturę za etap instalacji elektrycznej. Faktura opiewa na 147 600 zł brutto i wskazuje kontrakt oraz etap prac. W DMS znajduje się umowa przewidująca płatność dopiero po podpisaniu protokołu odbioru. Kierownik budowy przesłał zdjęcia, ale protokół nadal ma status „do poprawy”.

Technicznie faktura została poprawnie odebrana z KSeF. Biznesowo nie powinna jeszcze przejść do płatności.

To jest zasadnicza różnica między archiwizacją faktury a obsługą transakcji. Automatyzacja nie ma jedynie powiedzieć „mam dokument”. Ma odpowiedzieć: „mam wymagany komplet dokumentów i spełnione warunki pozwalające przejść do następnego etapu”.

Dla dostawy materiałów reguła może wyglądać inaczej:

• faktura: obowiązkowa,

• zamówienie: obowiązkowe,

• WZ lub PZ: obowiązkowe,

• zgodność ilościowa: obowiązkowa,

• protokół: niewymagany,

• umowa: opcjonalna, jeżeli zakup odbywa się na podstawie pojedynczego zamówienia.

Dla usługi konsultingowej WZ nie ma sensu. Za to kluczowe może być zatwierdzenie timesheetu albo miesięcznego raportu.

Dla robót budowlanych brak protokołu częściowego może blokować płatność nawet wtedy, gdy kwota faktury dokładnie odpowiada harmonogramowi.

Dlatego nie należy budować jednego szablonu „komplet dokumentów” dla całej firmy. Kompletność zależy od typu transakcji, umowy i sposobu odbioru świadczenia.

Właściwy model to macierz reguł. Przykładowo:

• towary magazynowe – faktura + zamówienie + PZ/WZ,

• środki trwałe – faktura + zamówienie + dokument odbioru + dane środka trwałego,

• usługi cykliczne – faktura + umowa + potwierdzenie okresu świadczenia,

• usługi projektowe – faktura + zamówienie lub umowa + protokół,

• roboty budowlane – faktura + umowa + protokół + ewentualne załączniki rozliczeniowe.

Najbardziej irytująca część wdrożenia pojawia się przy wyjątkach. Dostawcy nie zawsze wpisują numer zamówienia w tym samym miejscu. Jedno WZ może obejmować pozycje później rozliczone na dwóch fakturach. Faktura zbiorcza może obejmować kilkanaście dostaw. Korekta może dotyczyć jedynie jednej pozycji z większej transakcji. Do tego dochodzą przedpłaty, faktury zaliczkowe i rozliczające.

System, który nie przewiduje tych przypadków, wygląda dobrze podczas demonstracji, a zaczyna przeszkadzać po pierwszych tygodniach produkcyjnej pracy.

Dlatego automatyzację warto wdrażać w kolejności:

1. integracja z KSeF i zachowanie oryginalnego XML,

2. zapis numeru KSeF jako oddzielnej metadanej,

3. integracja z ERP i repozytorium zamówień,

4. zdefiniowanie głównego identyfikatora transakcji,

5. obsługa relacji 1 oraz N,

6. określenie wymaganego kompletu dokumentów dla poszczególnych typów zakupów,

7. automatyczne dopasowanie przypadków jednoznacznych,

8. kolejka wyjątków dla przypadków niejednoznacznych,

9. dopiero później wykorzystanie OCR lub AI do trudnych dokumentów bez stabilnych identyfikatorów.

Odwrócenie tej kolejności zwykle oznacza kosztowną automatyzację chaosu.

FAQ

Czy KSeF prześle razem z fakturą umowę, WZ albo protokół odbioru?
Nie należy tego zakładać. KSeF służy przede wszystkim do obsługi faktur ustrukturyzowanych. FA(3) przewiduje możliwość załącznika po spełnieniu wymaganych formalności, ale nie oznacza to automatycznego dostarczenia całej firmowej dokumentacji transakcji. Umowy, WZ, protokoły i korespondencję trzeba obsłużyć w procesie DMS oraz w systemach źródłowych.

Czy numer KSeF trzeba dopisać do pliku XML faktury?
Nie. Numer KSeF nadawany przez system nie jest elementem oryginalnego XML. W DMS najlepiej przechowywać XML w niezmienionej postaci, a numer KSeF zapisać jako metadane rekordu dokumentu.

Czy numer KSeF wystarczy do połączenia faktury z zamówieniem?
Nie. Numer KSeF jednoznacznie identyfikuje konkretną fakturę w KSeF, ale sam nie mówi, z którym zamówieniem, WZ czy protokołem należy ją połączyć. Potrzebny jest wspólny identyfikator biznesowy, np. numer zamówienia, umowy, projektu lub zlecenia.

Czy jedno zamówienie powinno odpowiadać jednej fakturze?
Nie. W rzeczywistych procesach jedno zamówienie może mieć kilka dostaw, kilka WZ i kilka faktur. Możliwa jest również faktura zbiorcza obejmująca wiele dostaw. DMS powinien obsługiwać relacje jeden-do-wielu i – tam, gdzie proces tego wymaga – wiele-do-wielu.

Czy DMS może automatycznie blokować fakturę bez protokołu?
Tak, jeżeli rozwiązanie zostało tak skonfigurowane i zintegrowane z odpowiednimi źródłami danych. Blokada powinna jednak wynikać z reguły dla konkretnego rodzaju transakcji. Protokołu nie ma sensu wymagać przy każdym zakupie – przy dostawie magazynowej ważniejsze może być PZ lub WZ.

Czy AI może zastąpić numery zamówień i inne identyfikatory?
Nie powinno. AI i OCR dobrze sprawdzają się jako mechanizm pomocniczy przy dokumentach nieustrukturyzowanych i wyjątkach. Jeżeli proces można oprzeć na jednoznacznym identyfikatorze przekazywanym pomiędzy ERP, kontrahentem i DMS, jest to rozwiązanie łatwiejsze do kontroli i mniej podatne na błędne dopasowania.

Co powinno być pierwszym krokiem przed wdrożeniem takiego obiegu?
Nie zaczynaj od wyboru algorytmu ani modułu AI. Najpierw weź kilkadziesiąt rzeczywistych faktur zakupowych z różnych kategorii i sprawdź, jaki identyfikator rzeczywiście łączy dziś fakturę z zamówieniem, dostawą, umową i odbiorem. Następnie policz przypadki, w których identyfikatora brakuje albo jest niespójny.

Jeśli numer zamówienia istnieje w ERP, ale nie trafia konsekwentnie na dokumenty dostawcy, to właśnie ten błąd należy usunąć jako pierwszy. Bez wspólnego identyfikatora DMS będzie jedynie coraz bardziej zaawansowanym narzędziem do zgadywania. Z dobrze zaprojektowanym identyfikatorem może natomiast automatycznie budować teczkę transakcji i kierować do człowieka przede wszystkim wyjątki.