KSeF Forum. KSeF jako projekt tax compliance realizowany przez zespół międzynarodowy

Wdrożenie KSeF w grupie kapitałowej to nie „kopiuj-wklej” z innego kraju. To projekt tax compliance na styku globalnego IT i lokalnych regulacji, gdzie decydują szczegóły: dwukierunkowa komunikacja (wystawianie i pobieranie faktur zakupowych), specyfika schemy FA (pola obligatoryjne, opcjonalne i fakultatywne – w polskim rozumieniu), tryby awaryjne/offline i lokalne obowiązki raportowe (numer KSeF w JPK). Prelegent pokazuje, jak zbudować wspólny język między centralą a polską spółką i jak uniknąć klasycznych porażek globalnych rolloutów.

Dwie perspektywy, jeden cel. Z poziomu grupy liczy się synergia, reużywalność komponentów i koszt. Z poziomu lokalnego – zgodność z polskimi przepisami i sprawność operacyjna. Dlatego zespół projektowy powinien być dwutorowy: PM globalny + PM lokalny, po stronie Polski: główna księgowa, tax manager/finance manager; po stronie grupy: IT Project Manager / właściciel architektury. Kluczowe są: jasny harmonogram z kamieniami milowymi, ustalone SLA (zwłaszcza na awarie KSeF) i reguły decyzyjne „kto za co odpowiada”.

Specyfika KSeF, której „global” nie domyśli się sam:

• Zakres komunikacji: nie tylko wysyłka XML, ale ciągłe pobieranie zakupów i metadanych (UPO, numer KSeF, daty), ich zapis w ERP i użycie w JPK/CIT/płatnościach.

• Mapa danych FA(3): lokalne mapowanie pól (w tym „adnotacje”, numery zamówień/PO, identyfikatory pracowników/podmiot trzeci). Najefektywniej przygotować mapę lokalnie i przekazać ją integratorowi.

• Tryby offline/awarie: zasady uruchamiania, kody QR, terminy dosyłki oraz procedury biznesowe (kto decyduje, jak informujemy kontrahentów, co księgujemy w międzyczasie).

• Testy lokalne: scenariusze „edge case” (korekty zbiorcze, zaliczki, eksport/WDT, wielooddziałowość, duże paczki, wydatki pracownicze). Testy muszą kończyć się raportem i listą poprawek do globalnego rozwiązania.

Antywzorce z projektów:

1. Globalny szablon ponad lokalny compliance – brak czasu na dostosowanie, „pudełkowa” faktura nie spełnia polskich wymogów.

2. Rozmyta odpowiedzialność (grupa–dostawca–lokalny zespół) i niejasne SLA – w awarii nikt nie reaguje w oknie prawnym.

3. Nadmierna reużywalność („mamy rozwiązanie z innego kraju”) – brak zrozumienia polskiej architektury KSeF i procesów dwukierunkowych.

Jak zrobić to dobrze?

• Ustal dwupoziomowe zarządzanie projektem i wspólny słownik (różnica „optional ≠ facultative”).

• Przygotuj lokalną mapę danych i „Definition of Done” na testy.

• Zapisz w umowie z integratorem SLA na incydenty KSeF (niedostępność/awaria) i ścieżkę zmian po testach.

• Zapewnij monitoring end-to-end (statusy, numery KSeF, przyczyny odrzuceń), zwrot metadanych do ERP oraz gotowość na pobieranie zakupów.

Wniosek: globalna standaryzacja jest cenna, ale sukces przynosi dopiero lokalne dowodzenie zgodnością i testy „na polskim gruncie”.