Serdecznie zapraszamy do obejrzenia webinara, który odbył się 6 grudnia pt. „KSeF, czyli co nas czeka od 1 stycznia 2024”.
Wspólnie z naszymi partnerami – EY i SME Banking Club – przybliżyliśmy najważniejsze zagadnienia związane z systemem KSeF. Opowiedzieliśmy o czekających na Was wyzwaniach na poziomie procesów i o zmianach na poziomie technicznym, których mogą wymagać Wasze dotychczasowe systemy. Podpowiedzieliśmy jak dobrze wykorzystać czas, który nam jeszcze został do wdrożenia zmian.
Zapraszamy na retransmisję!
Transkrypcja:
Olena Gryniuk SME (OG): Jesteśmy life, więc zaczynamy nasz webinar. Dziękuję wszystkim za dołączenie. Nazywam się Olena Gryniuk, jestem dyrektorem regionu Europy Środkowo-Wschodniej w SME Banking Club i poprowadzę dzisiejszy webinar. Tematem naszej rozmowy jest KSeF. Webinar jest zaplanowany na 40 minut i jest nagrywany, więc po zakończeniu wyślemy wszystkim nagranie. Formatem dzisiejszego webinaru jest dyskusja, więc zachęcam Was serdecznie do zadawania pytań na czacie. Dla oglądających nas teraz na naszym kanale YouTube – zapraszam do rejestracji przez link podany w opisie transmisji. W taki sposób będziecie mogli uczestniczyć w dyskusji i zadawać pytania. No to przejdźmy do dzisiejszego tematu.
Bardzo dużo informacji i artykułów teraz widzimy w temacie KSeF, tak od firm konsultingowych, jak też od producentów oprogramowania, czy też czytając aktualności na stronie Ministerstwa Finansów o nowej wersji KSeF. Dzisiaj chcemy spojrzeć na kwestie związane z KSeF z różnych perspektyw. Na wszystkie pytania odpowiedzą dzisiejsi eksperci i głoście. Michał Drabikowski – Partner zarządzający, ekspert tematyki KSeF z firmy in4mates.
Michał Drabikowski in4mates (MD): Dzień dobry, miło mi.
OG: Dziękuję za dołączenie. Krzysztof Walasek, Partner zarządzający i ekspert architektury IT z firmy in4mates.
Krzysztof Walasek in4mates (KW): Dzień dobry.
OG: Wojciech Michalak, Senior Manager Tax Technology & Transformation z firmy doradczej EY Polska. Witam serdecznie.
Wojciech Michalak EY (WM): Dzień dobry.
OG: Michał, zacznijmy od pytania do Ciebie. Powiedz proszę na początek – jak jest z tym KSeF?
MD: Jak zwykle, kiedy wokół czegoś jest dużo szumu, zakrada się mnóstwo nieścisłości. Kiedy wpiszemy w wyszukiwarkę internetową hasło „e-faktura”, otrzymamy około miliona wyników. Gdy wpiszemy „KSeF” – już tylko 200 tysięcy. Natomiast dla „faktury ustrukturyzowanej” – jedynie 10 tysięcy. Tymczasem to ostatnie określenie najtrafniej określa rewolucję, która nas czeka w najbliższym czasie.
KW: „Faktura ustrukturyzowana” to jak „stół z powyłamywanymi nogami” – mówiąc to pomylimy się cztery razy. Może dlatego w przestrzeni informacyjnej stosujemy „KSeF”.
WM: Tak, chociaż myślę, że mówiąc o KSeF warto zacząć od samych przepisów. Przepisów, które zostały, tak naprawdę, opublikowane dopiero w zeszłym tygodniu i to dopiero jako draft. e-faktura – czym jest? To tak naprawdę obowiązek, który ma wejść w życie od 2024 r., który obejmie wszystkie podmioty posiadające siedzibę lub stałe miejsce prowadzenia działalności w Polsce. A zatem mogą to być także podmioty zagraniczne. Pewnym zaskoczeniem może być objęcie obowiązkiem wystawiania e-faktur także tych podatników, którzy stosują zwolnienia podmiotowe, czyli np. skromnych przedsiębiorców, czy świadczących usługi w odniesieniu do sprzedaży zwolnionej czy nieobjętej VAT-em. A zatem może być taka sytuacja, że także faktury, w których teoretycznie nie mamy wykazanego VAT-u, będą wystawiane także w KSeF.
I co to oznacza w praktyce? W praktyce to oznacza, że KSeF od 2024 r. stanie się głównym systemem do wystawiania, ale też otrzymywania faktur. Czyli system ten będzie obejmował zarówno faktury sprzedażowe, jak i zakupowe. Jako podatnicy będziemy wysyłać faktury do KSeF w postaci plików XML, KSeF zweryfikuje od strony technicznej dane, zaakceptuje, zwróci nam unikalną informację o numerze KSeF w ramach którego dostaniemy też potwierdzenie, że faktura została przez KSeF przeprocesowana. I to będzie dopiero nasza faktura. Zatem jest to ewidentnie wyzwanie. Wyzwanie, które będzie nieporównywalnie trudniejsze, nieporównywalnie szersze niż chociażby pliki JPK, które wprowadzaliśmy dwa lata temu. Z jednej strony dlatego, że teraz wszystkie podmioty będą tym objęte jednocześnie, a z drugiej strony to już nie będzie raportowanie miesięczne, tylko bieżące przetwarzanie.
KW: Dokładnie. Czyli sama integracja z KSeF, samo przesyłanie informacji do KSeF, to jest tylko kawałeczek całej pracy. Taka wisienka na torcie. To co nas czeka, to zmiany w procesach, zmiany w organizacji działania z fakturami i powiązane z tym modyfikacje w systemach, które muszą odzwierciedlać te zmiany. No i gdzieś też będzie musiała być wykonana sama integracja z KSeF .
OG: To omówimy sobie zatem kolejno ta obszary. Michał – powiedz na początek w jaki sposób faktura ustrukturyzowana będzie dystrybuowana pomiędzy wystawcą, KSeF i odbiorcą.
MD: Wystawca faktury zaczyna standardowo od wprowadzenia danych faktury. Potem cała sprawa już się komplikuje. Tak jak to Wojtek chwilę temu powiedział – dane będą musiały być na początek zapisane w strukturze XML i wysłane do KSeF.
Następnie wystawca faktury będzie musiał cyklicznie odpytywać KSeF o status przetwarzania tejże faktury. W końcu dowie się, że albo faktura została zaksięgowana i wtedy pozna unikalny numer KSeF, albo że faktura została odrzucona przez KSeF np. ze względu na niepoprawną strukturę przekazanego XML. Musimy pamiętać, że faktura odrzucona przez KSeF to faktura z prawnego punktu widzenia nieistniejąca, więc nadawca będzie musiał fakturę poprawić i wysłać ponownie. Dopiero gdy ostatecznie otrzyma numer KSeF, będzie mógł zaksięgować fakturę u siebie i przekazać stosowne dane do odbiorcy.
I tu mamy dwie możliwości. Jeśli odbiorca faktury nie wyrazi zgody na otrzymywanie faktur przy użyciu KSeF, co dotyczyć może w praktyce pewnie mniejszych podmiotów, to należy ją w całości, razem z numerem KSeF, przekazać w uzgodniony sposób – np. poprzez e-mail. Jeśli odbiorca wyrazi zgodę, wtedy wystarczy przekazać sam numer KSeF i konieczne załączniki. Odbiorca połączy to sobie z danymi pobranymi z KSeF i całość będzie mógł zaksięgować u siebie.
Ale to jeszcze nie koniec. Wystawca faktury powinien dodatkowo dla wysłanych faktur pobrać z KSeF UPO, czyli Urzędowe Potwierdzenie Odbioru. Jest to jedyny bezsporny dowód wystawienia faktur, potwierdzony cyfrowym podpisem przez Ministerstwo Finansów.
No i to by już było wszystko, jeżeli chodzi o wysokopoziomowy proces. Oczywiście jeszcze jest mnóstwo szczegółów technicznych i potencjalnych sytuacji awaryjnych, które też trzeba umieć jakoś obsłużyć.
OG: Wojtku, zatem pytanie do Ciebie – jak przedstawiony przez Michała proces wpływa na firmy, na przedsiębiorstwa? Jakie zmiany organizacyjne przedsiębiorstwa mają wprowadzić w związku z tym?
WM: Generalnie dostosowanie do KSeF, tak jak wspomnieliśmy,jest to dość szeroki proces, w ramach którego nie tylko będziemy zobowiązani do raportowania faktur, ale tak naprawdę wystawiania i ich odbioru z KSeF. Będzie to dość istotna zmiana, jeżeli chodzi o procesy. Jakiekolwiek odstępstwo od tych wymagań – czy technicznych wymagań schematu czy chociażby połączenia się z KSeF – będzie skutkowało odrzuceniem takiej faktury w KSeF. Więc już na samym początku naszego projektu powinniśmy przewidzieć i zapewnić takie działanie systemu i aplikacji, które pozwoli nam na generowanie faktur, które są w pełni zgodne z KSeF. Ale warto także przygotować się poprzez przegląd wszelkich procesów czy naszych polityk związanych z księgowaniem faktur.
Opierając się na naszych doświadczeniach projektowych, ale też na tych przepisach, które zostały w zeszłym tygodniu opublikowane, widzimy kilka takich obszarów zmian. W pierwszej kolejności chcę zwrócić uwagę na kwestię zapewnienia odpowiedniego procesu wystawiania e-faktur. Obecnie te procesy mogą być rozproszone. Gdy e-faktury wejdą w życie, to procesy te będą musiały być w pewien sposób scentralizowane, ponieważ będziemy musieli wysyłać faktury do KSeF, będziemy musieli z niego także potrafić odebrać numery KSeF. Wyjątkiem oczywiście może być, i to wynika z tych nowych przepisów, sytuacja, w której KSeF dozna awarii. Tutaj możemy fakturę wystawić poza KSeF, ale wciąż w formacie XML. Ale, i to pod groźbą kary, musimy taką fakturę w ciągu siedmiu dni do KSeF dostarczyć.
Druga kwestia, o której chciałbym powiedzieć, to gromadzenie numerów KSeF. Każda faktura, którą wysyłamy do KSeF, będzie miała nadany taki unikalny identyfikator. Jest to numer, po którym KSeF będzie taką fakturę identyfikować. Musimy umożliwić zbieranie tej informacji przez nasze systemy źródłowe, ponieważ ten numer KSeF będziemy musieli podać w momencie, w którym będziemy chcieli fakturę skorygować i to będzie element obligatoryjny. Chociaż tutaj Ministerstwo troszkę zmieniło podejście, ponieważ faktury wystawione poza KSeF, czyli zanim KSeF wszedł w życie, nadal będą mogły być wystawione i ten numer nie będzie wówczas potrzebny do zaraportowania.
Kolejny istotny temat, na który warto zwrócić uwagę, to potencjalna rozbieżność w dacie wystawienia dokumentu. W samym pliku XML dotyczącym e-faktur wskazujemy datę wystawienia faktury, niemniej tą datą wystawienia faktury jest data, w której faktura została w KSeF przeprocesowana. W niektórych przypadkach związanych np. z opóźnieniem komunikacji z systemem KSeF i naszym systemem, może zaistnieć rozbieżność między datą systemową a datą rzeczywistego wystawienia. Mniejszym problemem jest sytuacja, w której nie wpływa to na należności, czy na moment powstania obowiązku podatkowego. Wówczas możemy taką datę u nas w systemie po prostu skorygować, ale może być tutaj istotny problem w momencie, w którym wystawiamy faktury walutowe i wtedy nam się rozjeżdża należność.
KW: Przy czym na razie powiedziałeś o takich podstawowych rzeczach procesowych. Takich, które po prostu musimy spełnić. Natomiast to, co jeszcze jest przed nami, to jakoś ułatwić życie naszym pracownikom, którzy jako użytkownicy systemów będą w to wszystko zaangażowani.
WM: Tak, racja. Tutaj takim obszarem, który widzimy jako obszar do modyfikacji, to dostosowania procesów wizualizacji danych. Faktura tak jak wspomnieliśmy, będzie plikiem XML, który nie jest łatwy i oczywisty do rozczytywania przez człowieka. W związku z tym na pewno warto zapewnić sobie jakąś wizualizacje czy to w PDFie czy HTMLu, tak żeby nasi użytkownicy byli w stanie tę fakturę rozczytać i np. zaksięgować.
Warto też zaznaczyć pewną nowość, którą wprowadziły świeżo opublikowane przepisy. Mianowice zakładają one, że faktury zwizualizowane, czyli te które mamy w PDFie i chcielibyśmy je przedstawić naszym kontrahentom, powinny mieć oznaczenie, które pozwoli na weryfikację takiej faktury z KSeF. Tu najprawdopodobniej będzie chodziło o to, żeby na takich fakturach zaprezentować jakiś QR kod, który odniesie nas do KSeF.
W sumie jeszcze jedną rzecz bym powiedział odnośnie zmiany procedur. To właściwa dystrybucja pobranych e-faktur zakupowych. KSeF zwróci nam wszystkie faktury, które są wystawione na spółkę. W związku z czym – jeżeli korzystamy z więcej niż jednego systemu, to z jednej strony oczywiście dobrze jest móc je zwizualizować, żeby je odpowiednio zaksięgować, ale też przewidzieć takie procesy, które pozwolą nam na odpowiednie dopasowanie faktury do systemu.
Generalnie wydaje się, że KSeF ma nam ułatwić życie jako podatnikom i być może nawet ułatwi poprzez digitalizację czy centralizację wszystkich procesów, ale zanim dojdziemy do tego momentu, jest jednak sporo wyzwań i działań, które jako podatnicy, jako przedsiębiorcy będziemy musieli zrealizować.
MD: Ja bym jeszcze po stronie wyzwań chciał zaakcentować konieczność zmiany praktyk związanych z obiegiem faktur. Tak jak powiedziałeś, wystawienie faktury będzie miało ściśle kontrolowaną datę, ale – co ważne – będzie też nieodwracalne. Wszystkie ewentualne błędy będą musiały być poprawiane za pomocą faktur korygujących, ewentualnie not korygujących po stronie odbiorcy.
Dodatkowo faktury nie będą mogły liczyć zbyt wielu linii, ze względu na ograniczenie wielkości e-faktury do 1 MB. Wreszcie wystawienie faktur będzie trwało dłużej – ze względu na specyfikę KSeF, czas wystawienia pojedynczej e-faktury trzeba będzie liczyć w minutach. A to przykładowo oznacza dużo dłuższy czas obsługi klientów “przy okienku”, czy też potencjalne problemy wydajnościowe przy dużym wolumenie faktur wystawionych w krótkim czasie.
Ostatnie co warto zaakcentować, to konieczność identyfikacji i sprawnej obsługi błędów biznesowych jakie się mogą pojawić. Czyli np. odrzucenie e-faktury przez KSeF, czy problem duplikatów e-faktur w KSeF, które niestety mogą się pojawić. Ale o tym powiemy później, bo to są już szczegóły techniczne.
OG: Dobrze, to mamy nakreślone zmiany na poziomie procesów. Pozostaje kwestia zmian technicznych. Jak nowe podejście musi być odzwierciedlone w systemach informatycznych, które je wspierają?
KW: Zasadniczo można powiedzieć, że mamy tutaj dwie grupy systemów. Jedna grupa jest związana z fakturami sprzedaży, z fakturami wychodzącymi – czyli są to wszystkie systemy, które wystawiają faktury. W wielu przedsiębiorstwach takich systemów może być kilka, ze względów historycznych czy np. przez segmentację klientów. Tak po prostu jest, taka może być historia. Problemem jest to, że w tej chwili każdy z takich systemów musi dodatkowo fakturę przekazać do KSeF. Kiedyś on po prostu musiał dystrybuować ją do odbiorcy i przekazać do wewnętrznych systemów finansowo-księgowych, i to był koniec. A teraz dodatkowo trzeba obsługiwać cały proces z ustrukturyzowaną fakturą i jej przesłaniem do KSeF.
Z drugiej strony jest grupa systemów finansowo-księgowych, które rejestrują faktury zakupowe i tutaj zupełnie zmieniają się ich przepływy. Do tej pory jakoś to było zorganizowane, czy przez faktury elektronicznie czy przez OCR. Natomiast w tej chwili źródłem podstawowym musi być KSeF. I to oczywiście jest pewnego rodzaju wyzwanie, ale jednocześnie szansa. Mamy w KSeFie faktury ustrukturyzowane, czyli dostajemy do ręki pewne źródła danych. Przestaniemy mieć kłopoty z tym promilem faktur, które być może źle się „zOCRowały”, czy też gdzieś źle zostały przepisane.
Gdy się zastanowić jak do podejść do wymaganych zmian w systemach, to pewnie najłatwiej będą mieli ci, którzy mają u siebie jeden system finansowo-księgowy wystawiający faktury. Jak mają taki kombajn, to co powinni zrobić? Otóż powinni pójść do producenta, zapytać się „czy macie państwo takie podłączenie do KSeF?”. Najprawdopodobniej już mają lub będą mieli w najbliższym czasie, bo skoro to jest wymóg prawny, to takie systemy bez konektora do KSeF nie będą miały racji bytu.
Natomiast takie podejście nie zadziała wtedy, kiedy mamy mocno „zcustomizowany” system czy wręcz po prostu zrobiony „pod nas”.
OG: A jeśli w firmie istnieje jednak kilka systemów finansowo-księgowych?
KW: Z tego co ja wiem o specyfice podłączenia do KSeF, to tu zaczynają się problemy. Ale Michale, może Ty więcej tu opowiedz, bo nad tym tematem więcej pracowałeś.
MD: Rzeczywiście specyfika integracji z KSeF jest dość skomplikowana i to wynika z kilku przyczyn. Po pierwsze samo API KSeF jest niewystarczająco udokumentowane.
Po drugie jest bardzo skomplikowane technicznie. Przykładowo, wywołania usług nie są tam niezależne, lecz muszą być wykonywane w ustalonej kolejności w ramach sesji, którą musimy utrzymywać i która podlega pewnym ograniczeniom. Jeśli sesja zostanie z jakiegoś powodu przerwana, to status faktury w KSeF będziemy mogli poznać już tylko przeszukując wszystkie zarejestrowane tam faktury. Dodatkowo nie możemy zgubić identyfikatora sesji, bo tylko dzięki niemu będziemy mogli pobrać UPO. Robiąc to wszystko musimy zachować odpowiednie interwały czasowe między wywołaniami usług, a to ze względu na istniejące w KSeF ograniczenia na częstotliwość wywołań. Przykładowo dla konkretnej faktury możemy sprawdzać jej status tylko 20 razy na 10 min i to z tego między innymi wynika fakt, że dość długo musimy oczekiwać na informację o jej zarejestrowaniu. Inny przykład: zarejestrowane faktury możemy pobierać tylko 5 razy na godzinę.
Trzecim wyzwaniem są częste zmiany w API KSeF i pojawiające się od czasu do czasu błędy techniczne. I tu dochodzimy do bardzo istotnej właściwości KSeF – brakuje w nim mechanizmu zabezpieczenia przed powstawaniem duplikatów, tzn. jeśli fakturę wyślemy do KSeF dwa razy – na skutek awarii, albo niepewność dostarczenia – to efektywnie zarejestrowane zostaną dwie odrębne faktury, o dwóch różnych numerach KSeF. Jeśli będziemy świadomi powstania sytuacji błędnej, tzn. utworzenia duplikatu, to jeszcze nie jest tak źle – możemy jedną z faktur skorygować wystawiając stosowną fakturę korygującą. Gorzej, jeśli się nie zorientujemy, że powstał duplikat, bo wtedy cały czas obowiązuje nasze podwójne żądanie zapłaty i jesteśmy zobligowani zapłacić podwójny podatek.
KW: Jak tego słucham to mi włos się jeży na głowie. No bo kiedy mamy małą firmę, to damy sobie radę z problemem niejasnych statusów faktur, jakoś kłopoty z nimi „opędzimy” ręcznie. Natomiast jeżeli firma wystawia 10 milionów faktur rocznie, to jeżeli jakiś minimalny odsetek, np. promil tych faktur, jest z jakiegoś powodu kłopotliwych, bo gdzieś nastąpi jakieś zaburzenie komunikacji z KSeF, wówczas otrzymujemy 10 tysięcy wątpliwych przypadków. I teraz albo możemy posadzić armię ludzi, która te 10 tysięcy przypadków będzie ręcznie procesować – co nie brzmi jak dobry pomysł, albo możemy teoretycznie ponawiać w kółko wysyłanie tych niepewnych, no ale jak Michał mówił mamy tu do czynienia z groźbą duplikatu. Czy to jest „kwadratura koła”?
MD: Na szczęście nie jest aż tak źle. Istnieje sensowne rozwiązanie tego typu problemu, ale jest ono skomplikowane. Wymaga stworzenia automatycznych procesów, które będą wznawiać wysyłkę faktur, ale analizując cały kontekst sytuacji w taki sposób, żeby zapewnić ochronę przed duplikatami. Wymaga to między innymi zapamiętywania wszystkich wcześniej przesłanych komunikatów, wywoływania dodatkowych usług API KSeF, czy analizy pobieranych UPO.
KW: No dobrze, zatem wiedząc o potencjalnych problemach jakie są związane z integracją z KSeF, można teraz spróbować powiedzieć w jaki sposób podchodzić do tego problemu w skomplikowanych przypadkach. Kiedy nie mamy jednego systemu, lecz wiele, to wydaje się, że najsensowniejsze byłoby zrobienie do nich centralnego konektora. Takiego komponentu, który izolowałby wszystkie systemy od problemów związanych z niuansami komunikacji z KSeF. W nim byśmy raz a dobrze rozwiązali wszystkie problemy związane z tymi algorytmami połączenia, redukcją duplikatów, kwestią wydajności czy kwestią ograniczeń ilości pytań, które KSeFowi możemy zadawać. Tam byśmy to wszystko raz a dobrze zakodowali i systemy, które by się podłączały, zawsze by przez niego „przychodziły” przy komunikacji z KSeF. Wszystkie systemy wystawiające faktury by przekazywały informacje do takiego komponentu, a on by już zajmował się tym, żeby to do KSeF było dostarczone.
Taki komponent byłby też odpowiedzialny za komunikację w drugą stronę: przekazywanie faktur, które do nas przychodzą. Pobierałby je z KSeF i przekazywał do właściwych systemów wewnątrz firmy. Przy czym oczywiście konieczna byłaby integracja systemów z takim korektorem, natomiast ona byłaby dużo łatwiejsza niż opieranie się na API KSeF. Chociażby dlatego, że wiele systemów finansowo-księgowych ma integrację przez pliki jako mechanizm exportu i importu, natomiast API KSeF wymaga wywoływania usług. Tymczasem taki konektor może wykorzystywać różne interfejsy, w tym plikowe.
Kolejnym argumentem za takim centralnym korektorem jest chociażby to, że wszystkie techniczne, nie-biznesowe zmiany, które w przyszłości miałyby miejsce w KSeFie, można by obsłużyć w jednym miejscu, a dla wszystkich pozostałych systemów byłyby one przeźroczyste.
OG: Rozumiem, że opisałeś teraz Wasz autorski system obsługi e-faktor, czyli inVoice?
Bardzo fajna nazwa. Wiem, że macie takie rozwiązanie, które ogarnia KSeF.
KW: Tak, ale tylko częściowo go opisałem.
MD: Krzyś opisał połowę tego systemu, czyli tę część odpowiadającą za komunikację z KSeF. Druga część to repozytorium e-faktur, czyli taka ich replika z KSeF, czy też patrząc szerzej – z systemów organów państwowych. W inVoice do tego repozytorium mają dostęp uprawnione systemy za pośrednictwem API, no i oczywiście uprawnieni użytkownicy za pomocą interfejsu użytkownika. Ważne, że dostęp jest nieporównanie wygodniejszy i szybszy niż ten dostarczany przez KSeF. Bo przecież KSeF będzie przechowywał wszystkie faktury jakie tylko zostaną w Polsce wystawione, a zgodnie z przewidywaniami ustawodawcy ma być ich około 2,5 miliarda rocznie. Jeżeli więc nie chcemy czekać cierpliwie w kolejce do KSeF, to lepiej w dogodnej chwili pobrać z niego faktury do lokalnego repozytorium i potem operować już na tych lokalnych zasobach, dostępnych na bieżąco, zaindeksowanych w taki sposób jaki jest dla nas optymalny, z możliwością filtrowania po najróżniejszych, ważnych dla nas atrybutach.
KW: Patrząc na to okiem architekta IT: przechowując w naszym inVoice UPO, czy numery KSeF, uniezależniamy się od zasobu zewnętrznego jakim jest KSeF. W szczególności eliminujemy nawet potrzebę transferowania UPO do systemów finansowo-księgowych, bo to jest informacja istotna tylko przy sporach, a więc stosunkowo rzadko. Jednakże musi być ona dostępna w firmie, udostępniona grupie uprawnionych do tego osób.
Podobnie można rozważyć kwestię numerów KSeF. Jak się mocno zastanowić to można sobie wyobrazić, że numery KSeF też nie będą transferowane do systemów finansowo-księgowych czy systemów wystawiających faktury. Z technicznego punktu widzenia, one są przede wszystkim potrzebne przy wystawianiu korekt. A inVoice wystawiając korektę potrafi połączyć fakturę źródłową z nadanym jej numerem KSeF i transferując informacje o korekcie do KSeF wzbogacić ją właśnie o ten nadany numer.
MD: Przepraszam, że wchodzę w słowo. Na pewno jeszcze opowiemy o inVoice innym razem, ale dzisiaj głównym tematem niech pozostanie KSeF.
OG: Ile czasu potrzeba na wdrożenie wszystkich zmian związanych z fakturami ustrukturyzowanymi? Bo styczeń 2024 już tak dosłownie za rok – czy musimy się spieszyć?
WM: Ja może odpowiem. Z perspektywy projektów, które już rozpoczęliśmy widzimy, że to jest rzeczywiście ostatni dzwonek, żeby rozpocząć takie przygotowanie. W zależności od skomplikowania tych projektów, skomplikowania procesów, liczby systemów, danych, taki proces od momentu analizy do momentu wdrożenia może zająć od trzech do nawet kilkunastu miesięcy. Biorąc pod uwagę, że KSeF ma wejść jako obowiązkowy system od 1 stycznia 2024 roku, to tego czasu jest mało. Ale tak naprawdę, ile czasu będziemy potrzebować na wdrożenie się jako spółka, będzie wynikać dopiero z analizy, którą przeprowadzimy, a którą powinniśmy zrealizować jako pierwszy element całego procesu dostosowania do tego nowego obowiązku. Szacując potrzebny czas na wdrożenie, trzeba jeszcze pamiętać o ewentualnym dostosowaniu swoich systemów źródłowych, decyzji czy chcemy rozwijać jakieś narzędzie w swoich systemach czy właśnie korzystać z systemów, które ułatwią nam to zadanie i gdzieś obok naszych systemów zintegrują, dostarczą i odbiorą te dokumenty z KSeF.
Reasumując – biorąc pod uwagę ten termin 1 stycznia 2024 roku wydaje się, że powinniśmy już mieć zaplanowane te projekty. Warto też pamiętać o tym, aby zostawić sobie czas na przetestowanie naszych systemów pod kontem zgodności z KSeF. Warto, abyśmy czwarty kwartał 2023 roku zaplanowali już tylko na stabilizację i testowanie narzędzia.
KW: Ja może się pokuszę żeby to doprecyzować. Tylko odrobinę, bo w szczegółach to oczywiście – tak jak Wojtku mówiłeś – jest kwestią analizy. Natomiast spójrzmy na to z punktu widzenia tych rzeczy, które na dziś wiemy na pewno, że musimy zrobić.
Jeżeli mówimy o prostej sytuacji – czyli takiej, kiedy mamy jeden system, do którego uda nam się zakupić plugin do KSeF, to wydaje się, że cała procedura związana z zakupem, przetestowaniem, zainstalowaniem i wdrożeniem zajmie nam „niewyjęte” dwa-trzy miesiące.
Natomiast jeżeli mamy ich odpowiednio więcej, to nasze problemy się zdecydowanie zwielokrotniają. Możemy kombinować, możemy starać się upraszczać taką integrację kupując, czy też sami starając się stworzyć taki konektor do KSeF, ale w żadnym wypadku to nie będzie krótka praca.
OG: Michał, ile według Ciebie czasu zajęłoby stworzenie takiego rozwiązania od zera?
MD: To oczywiście zależy od wielu czynników, najprościej będzie mi odnieść się do własnych doświadczeń. Zbudowanie i przetestowanie funkcjonalne oraz wydajnościowe systemu inVoice zajęło nam prawie rok. Fakt, że system został stworzony bardzo ogólnie, tak żeby przy odpowiedniej konfiguracji móc adresować najróżniejsze potrzeby potencjalnych użytkowników. I fakt, że tworzyliśmy go nie mając jeszcze pełnej wiedzy o KSeF. Tych informacji jest coraz więcej, coraz bardziej stabilne jest API. Myślę, że mając naszą dzisiejszą wiedze o KSeF i ograniczając funkcjonalności tylko do tych potrzebnych konkretnej organizacji można by ten czas skrócić. Ale wciąż wydaje mi się, że liczyć trzeba jakieś pół roku.
OG: Wygląda więc na to, że taniej, bezpieczniej i szybciej jest skorzystać z gotowego rozwiązania. Tak?
KW: Jak zawsze! Jak zawsze, kiedy coś już jest gotowe, jest przetestowane i co ważne, używa tego wiele różnych organizacji. Wtedy nie tylko my jesteśmy tym testującym tylko razem z nami testują inni. Mamy produkt, który wiemy, że działa, a my nie męczymy się z jego błędami wieku dziecięcego.
Wiedząc to wszystko spróbujmy podsumować ten czas wdrożenia. Jest tak, że z jednej strony mamy zmiany procesowe: tak jak Wojtek mówił, dobrze jest sobie na to wygospodarować pół roku. Do tego mamy zmiany w naszych systemach. Powiedzmy że mamy trzy systemy u siebie w firmie, to ja bym powiedział, że na samą ich integrację trzeba w takim czy innym podejściu poświęcić jakieś dwa-trzy miesiące. Do tego dodatkowo wyprodukowanie konektora KSeF wymagać może poświęcenia pół roku, lub krócej jak go kupimy. Pewne rzeczy oczywiście można zrobić równolegle, ale nie wszystko. Czas nie jest z gumy, i jak wszystko się poukłada, to wydaje się, że ten styczeń 2024 jest naprawdę już blisko i nic tylko trzeba zakasać rękawy do pracy.
OG: Dobrze, naświetliliśmy kilka istotnych kwestii w kontekście faktur ustrukturyzowanych. Oczywiście jak zwykle diabeł tkwi w szczegółach, na które tutaj nie mamy już za dużo czasu i miejsca.