Integracja KSeF z ERP — dlaczego natywna obsługa nie wystarcza?
Od 1 kwietnia 2026 r. Krajowy System e-Faktur (KSeF) jest obowiązkowy dla wszystkich przedsiębiorców. Większość dostawców systemów ERP mówi: „mamy integrację z KSeF" — i technicznie to prawda. Faktury lecą, system przyjmuje, numer KSeF jest nadany. Problem pojawia się dopiero gdy faktura wraca odrzucona przez sieć handlową. Albo gdy factor nie może dopasować jej do zamówienia w EDI. Albo gdy instytucja publiczna domaga się numeru umowy, którego na fakturze nie ma.
Przyczyna jest zawsze ta sama: schemat FA(3) ma 355 pól, a ERP obsługuje kilkadziesiąt obowiązkowych. Reszta — pola opcjonalne wymagane przez kontrahentów — pozostaje pusta.
355 pól w schemacie FA(3). ERP wypełnia ~40.
Schemat FA(3) dzieli pola na trzy kategorie:
- Obowiązkowe (~30–40 pól) — wymagane zawsze, bez nich KSeF odrzuci plik XML. Producenci ERP implementują je bez wyjątku.
- Opcjonalne warunkowe (~80–100 pól) — wymagane gdy zachodzi określony warunek prawny (np. mechanizm podzielonej płatności, WDT, OSS). Częściowo obsługiwane przez ERP.
- Fakultatywne (~200+ pól) — nie wymagane przez prawo, ale wymagane przez konkretnych kontrahentów: sieci handlowe, factorów, instytucje publiczne. Natywna implementacja ERP ich nie obsługuje.
Faktura zatwierdzona przez KSeF to faktura poprawna technicznie. Ale faktura poprawna technicznie ≠ faktura zaakceptowana przez system odbiorcy. KSeF sprawdza zgodność XML ze schematem. Odbiorca sprawdza czy faktura zawiera jego wymagane pola biznesowe.
Trzy scenariusze w których natywna obsługa KSeF w ERP nie wystarcza
1. Dostawy do sieci handlowych
Sieci handlowe takie jak Kaufland, OBI, Castorama, Leroy Merlin, Brico Dépôt, Merkury Market, Terg SA (Media Expert) czy Grupa PSB prowadzą rozliczenia przez systemy EDI. Każda dostawa ma numer zamówienia zakupowego (PO), każde miejsce dostawy identyfikowane jest kodem GLN.
Gdy faktura trafia do KSeF bez numeru PO i kodu GLN zgodnego z danymi EDI sieci — system sieci nie potrafi automatycznie dopasować faktury do zamówienia. Faktura ląduje w kolejce ręcznej weryfikacji albo wraca odrzucona. Dział handlowy dzwoni do IT, IT do producenta ERP, producent mówi że to „konfiguracja wdrożeniowa". Tymczasem płatność stoi.
Dane których brakuje to m.in. numer zamówienia zakupowego (PO), kod GLN miejsca dostawy w elemencie Podmiot3 oraz indeks towaru z systemu sieci. Wszystkie te pola mają swoje miejsce w schemacie FA(3) — natywna implementacja ERP ich nie wypełnia.
2. Faktoring — Podmiot3 z kodem GLN factora
Jeśli faktury objęte są umową factoringową, factor musi być wskazany w dokumencie KSeF jako dodatkowy podmiot w elemencie Podmiot3 z odpowiednią rolą i kodem GLN. Każda firma factoringowa ma własny kod GLN.
Natywna obsługa KSeF w Subiekt GT i Navireo nie umożliwia dynamicznego wypełnienia wielu wystąpień Podmiot3 z kodem GLN factora przypisanym per kontrahent. Bez tego pola factor nie może automatycznie zidentyfikować faktur objętych cesją, co blokuje wypłatę finansowania.
3. Instytucje publiczne i spółki Skarbu Państwa
Spółki energetyczne (np. PGE), jednostki samorządu terytorialnego i inne instytucje publiczne wymagają na fakturze danych których prawo VAT nie narzuca, ale ich wewnętrzne procedury — tak. Numer umowy lub kontraktu, symbol centrum kosztów (MPK), identyfikator jednostki organizacyjnej. Wszystkie te dane mają swoje miejsca w polach fakultatywnych FA(3).
Dlaczego producenci ERP nie obsługują tych pól?
Producent ERP implementuje FA(3) zgodnie z przepisami prawa podatkowego — pola obowiązkowe i najczęstsze przypadki warunkowe. Specyficzne wymagania Kaufland, factora czy PGE to konfiguracja wdrożeniowa, nie standardowa funkcja produktu. Żaden producent ERP nie jest w stanie wbudować w produkt wymagań każdej sieci handlowej w Polsce.
Firma która chce wypełniać pola opcjonalne FA(3) ma trzy opcje:
- Modyfikacja u producenta ERP lub partnera — tygodnie oczekiwania, kilkaset złotych za każde pole. Gdy sieć zmieni wymagania, cykl się powtarza.
- Ręczna edycja XML przed wysyłką — niewykonalne przy kilkudziesięciu fakturach dziennie.
- Zewnętrzne narzędzie do mapowania pełnego schematu FA(3) — jedna konfiguracja per kontrahent, gotowe szablony dla sieci handlowych, niezależność od producenta ERP.
Rozwiązanie: KSeF Mapper
KSeF Mapper to aplikacja desktopowa do wizualnego mapowania wszystkich 355 pól schematu FA(3) z dowolnej bazy ERP opartej o Microsoft SQL Server. Łączy się bezpośrednio z Subiekt GT (przez Sferę InsERT), Navireo lub dowolną bazą MS SQL — bez eksportów CSV i bez pośredników.
Konfigurację mapowania zapisujesz per NIP kontrahenta — system automatycznie dobierze właściwy profil przy każdej wysyłce. Gotowe szablony dostępne dla: Kaufland, OBI, Castorama, Brico Dépôt, Leroy Merlin, Terg SA (Media Expert), Merkury Market, Grupy PSB, PGE i innych.
Pełny cykl w jednej aplikacji: mapowanie pól → generowanie XML FA(3) → walidacja offline → podpis certyfikatem → wysyłka do KSeF → pobranie UPO. Zero opłat za ilość wysłanych dokumentów — w przeciwieństwie do natywnej obsługi KSeF w InsERT, która wymaga InsPunktów (0,11–0,50 zł za każdą wysłaną i odebraną e-Fakturę).
Szczegółowe porównanie natywnej obsługi KSeF w ERP z KSeF Mapper oraz opis problemu pól opcjonalnych: Integracja KSeF z ERP — dlaczego natywna obsługa nie wystarcza?
Dla kogo?
- Dostawcy sieci handlowych wymagających pól opcjonalnych FA(3) (GLN, numery PO, Podmiot3)
- Firmy korzystające z factoringu — factor musi być wskazany w Podmiot3 z kodem GLN
- Partnerzy InsERT wdrażający Subiekt GT i Navireo u klientów obsługujących sieci EDI
- Firmy z własnym ERP opartym o MS SQL potrzebujące pełnego mapowania FA(3) bez budowania integracji od zera
Cennik, gotowe schematy mapowania i szczegóły techniczne: omnisync.pl/ksef-mapper. Katalog gotowych szablonów FA(3) per sieć handlowa: omnisync.pl/schematy-ksef.
