Od kilku dni temat Krajowego Systemu e-Faktur (KSeF) przestał być dla nas wyłącznie projektem wdrożeniowym realizowanym u klientów. Teraz pracujemy na nim również u siebie – wystawiamy faktury, wysyłamy je do KSeF i sprawdzamy cały proces w praktyce.

Choć obowiązek korzystania z KSeF dla naszej firmy – podobnie jak dla wielu klientów pracujących na SAP Business One – zaczyna się 1 kwietnia, zdecydowaliśmy się uruchomić proces wysyłki faktur już teraz.

Chcieliśmy sprawdzić wszystko w praktyce: od uwierzytelnienia, przez nadawanie uprawnień, po realny obieg dokumentów.

Obowiązek korzystania z KSeF wchodzi dla nas 1 kwietnia. Wiele firm planuje rozpocząć wysyłkę faktur do KSeF właśnie tego dnia. My podjęliśmy inną decyzję – rozpoczęliśmy wdrożenie wcześniej.

Dlaczego?

Nasze podejście jest proste: wdrożenie KSeF to nie tylko integracja techniczna, ale zmiana procesu w firmie. Lepiej przejść ją wcześniej i spokojnie – zanim stanie się obowiązkiem.

Po kilku dniach pracy możemy powiedzieć jedno: wystawianie faktur w SAP Business One praktycznie nie zmieniło się dla użytkownika.

Różnica polega na tym, że po zapisaniu faktura musi zostać wysłana do Krajowego Systemu e-Faktur, dlatego czas generowania dokumentu nieznacznie się wydłużył – czekamy na potwierdzenie jej przyjęcia w KSeF. Średnio trwa to ok. 3–4 sekundy na fakturę – tyle zajmuje nawiązanie połączenia i przekazanie danych.

Sam proces uwierzytelnienia dokumentu oraz pobrania numeru KSeF trwa od kilku do kilkunastu minut, ale odbywa się w tle. Nie blokuje pracy użytkownika ani systemu. Możemy normalnie wystawiać kolejne dokumenty i pracować dalej.

Niewątpliwą zaletą jest wyeliminowanie powtarzalnych czynności: nie musimy już drukować faktur, generować plików PDF ani wysyłać ich pocztą czy mailem. W efekcie czas od wystawienia do doręczenia dokumentu uległ radykalnemu skróceniu.

Wszystkie wystawiane przez nas faktury trafiają bezpośrednio do KSeF, skąd kontrahenci muszą je pobrać. Wiemy jednak, że nie każdy ma jeszcze nawyk regularnego zaglądania do systemu, dlatego wprowadziliśmy automatyczne powiadomienia mailowe. W momencie wysyłki dokumentu do KSeF klient natychmiast otrzymuje wiadomość z bezpośrednim linkiem oraz kompletem danych – numerem faktury, NIP-em i kwotą brutto. Pozwala to na szybki odbiór dokumentu bez zbędnych utrudnień.

Dużo uwagi poświęciliśmy opisom pozycji. Przez lata wypracowaliśmy własny wzorzec faktury i sposób prezentowania istotnych informacji, które ułatwiają naszym klientom późniejsze rozliczenia – takich jak odniesienie do umowy, numeru zamówienia czy wskazanie okresu, którego dotyczy usługa. Te elementy są istotne przy księgowaniu i weryfikacji dokumentów, dlatego przed uruchomieniem KSeF upewniliśmy się, że są one poprawnie odwzorowane w strukturze faktury i będą czytelne po jej wysłaniu do systemu.

W SAP Business One w momencie wystawiania faktury jest ona najpierw weryfikowana pod kątem zgodności z wymaganiami KSeF. Jeśli dane są poprawne, dokument zostaje dodany do systemu, a w tle następuje jego automatyczna wysyłka do KSeF.

W praktyce oznacza to, że nie ma sytuacji, w której faktura istnieje już w ERP, ma nadany numer i została zaksięgowana, a dopiero później okazuje się, że nie przeszła walidacji po stronie KSeF.

Mieliśmy przypadek, w którym faktura została odrzucona z powodów technicznych już na etapie dodawania dokumentu do SAP . Efekt był prosty: dokument nie został dodany do bazy danych, a zlecenie sprzedaży pozostało otwarte. Po korekcie danych (w tym przypadku zbyt długiego opisu) faktura została dodana do SAP, a mechanizm wysyłający nie miał już problemu z dodaniem jej do KSeF.

Warto doprecyzować jedną rzecz: jeśli KSeF jest niedostępny z przyczyn technicznych, możliwe jest wystawienie faktury zgodnie z obowiązującymi przepisami i jej późniejsze przekazanie do systemu w wymaganym terminie. Taki scenariusz jest przewidziany w regulacjach na wypadek awarii po stronie systemu państwowego.

Podsumowując, możemy rozróżnić dwa scenariusze błędu:

W niektórych modelach systemowych najpierw wystawia się fakturę w ERP, a dopiero później wysyła ją do KSeF. W takim podejściu może pojawić się rozbieżność między tym, co widnieje w systemie księgowym, a tym, co zostało formalnie zarejestrowane w KSeF. W przypadku SAP Business One podejście jest bardziej restrykcyjne, ale spójne: faktura istnieje wtedy, gdy została skutecznie zarejestrowana w KSeF.

Sprzedaż to jedno, ale równie ważne są faktury zakupowe, które wystawiają nam dostawcy.

W Altab korzystamy ze SPUMY, dzięki czemu wszystkie faktury z Krajowego Systemu e-Faktur są pobierane w jedno miejsce i automatycznie trafiają do naszego obiegu dokumentów. W praktyce jako pierwsze widzą je sekretariat lub księgowość i to oni rozpoczynają dalszą obsługę dokumentu.

To duże ułatwienie – nie przeszukujemy maili ani wielu skrzynek. Dokumenty trafiają centralnie do systemu i od razu mogą zostać przekazane dalej.

Największe wyzwanie pojawia się w momencie identyfikacji faktury. Dokument jest w systemie, ale nie zawsze od razu wiadomo, kto dokonał zakupu i czego dokładnie dotyczy wydatek.

W praktyce wygląda to tak: pracownik kupuje usługę lub towar, dostawca wystawia fakturę i wysyła ją bezpośrednio do KSeF. Do obiegu trafia więc dokument bez dodatkowego kontekstu. W efekcie to sekretariat lub księgowość muszą ustalić, czyj to dokument i z jakim zakupem jest związany.

Aby uprościć ten proces, w SPUMIE planujemy uruchomić dwie funkcje: „Awizuj fakturę” oraz „Czyj to dokument?”

W praktyce dużym wyzwaniem okazuje się jakość opisów na fakturach od dostawców.

Często w treści pozycji brakuje odniesienia do zamówienia, umowy czy projektu. Pojawiają się ogólne sformułowania typu „usługa”, „transport”, „materiały” czy „robocizna”, bez wskazania, czego dokładnie dotyczą.

Przykład z życia: firma otrzymuje fakturę z pozycją „Usługa transportowa – marzec”. Nie ma informacji, czy chodzi o dostawę do konkretnego klienta, przewóz między magazynami czy transport związany z realizacją określonego zamówienia. Dokument trafia do systemu, ale księgowość musi ustalić, do jakiego kosztu lub kontraktu go przypisać.KSeF przyspiesza przepływ dokumentów, ale nie rozwiązuje problemu jakości danych. To właśnie precyzyjny opis decyduje o tym, czy fakturę można sprawnie zaksięgować, rozliczyć lub powiązać z konkretną realizacją.

Nasze pierwsze doświadczenia pokazują jedno: KSeF nie jest trudny technicznie, pod warunkiem że system został odpowiednio przygotowany. Integracja z SAP Business One działa stabilnie, wysyłka dokumentów przebiega sprawnie, a sam proces wystawiania faktur dla użytkownika zmienił się minimalnie.

Prawdziwa zmiana dotyczy organizacji pracy i jakości danych.

To właśnie te elementy decydują o tym, czy KSeF będzie usprawnieniem, czy dodatkowym źródłem pytań w firmie.

Rozpoczęcie pracy przed 1 kwietnia dało nam spokój, czas na dopracowanie szczegółów i możliwość sprawdzenia wszystkiego w realnych warunkach. Dziś możemy dzielić się tym doświadczeniem z naszymi klientami pracującymi na SAP Business One, którzy rozpoczynają obowiązkową wysyłkę faktur od 1 kwietnia.

Po pierwszych doświadczeniach z KSeF chcemy podzielić się kilkoma praktycznymi wskazówkami:

Jeszcze kilka lat temu decyzja o wdrożeniu ERP sprowadzała się do jednego pytania: „Jaki system wybrać?”. Miał on „obsłużyć wszystko”, być możliwie kompletny i wystarczyć firmie na wiele lat. W praktyce często oznaczało to kompromisy, kosztowne dostosowania i rosnącą frustrację użytkowników.

W 2026 roku to podejście wyraźnie się zmienia. Biznes działa szybciej, kanałów sprzedaży jest więcej, a wyspecjalizowane narzędzia rozwijają się znacznie szybciej niż klasyczne systemy transakcyjne. Coraz trudniej oczekiwać, że jeden system będzie najlepszym rozwiązaniem dla wszystkich procesów i ról w firmie.

Dlatego coraz więcej organizacji przestaje myśleć o ERP jako o „systemie do wszystkiego”, a zaczyna traktować go jako fundament większej całości. W centrum pozostaje stabilny core, a wokół niego powstaje ekosystem wyspecjalizowanych aplikacji, integracji i usług.

Poniżej pięć kluczowych trendów, które w 2026 roku definiują sposób, w jaki firmy projektują i rozwijają swoje środowiska ERP.

Współczesny ERP coraz rzadziej działa w pojedynkę.
Nie dlatego, że brakuje mu funkcji, ale dlatego, że rosnąca specjalizacja narzędzi i standaryzacja integracji sprawiają, że pojedynczy system przestaje być najlepszym rozwiązaniem we wszystkich obszarach.

Firmy przestają traktować ERP jako system „docelowy”. Coraz częściej jest on core’em ekosystemu IT – stabilnym fundamentem, do którego można łatwo podłączać kolejne technologie, np. gdy organizacja się rozwija, wchodzi na nowe rynki lub musi dostosować się do zmian narzucanych przez rynek i oczekiwania klientów. lub sięga po AI.

W praktyce wygląda to tak:

To właśnie ta zmiana – od jednego ERP do ekosystemu IT – definiuje jeden z kluczowych trendów w 2026 roku i sprawia, że o wartości ERP coraz częściej decydują jego otwartość, elastyczność i gotowość do integracji, a nie liczba wbudowanych funkcji.

Rola systemu ERP w firmach wyraźnie się zmienia. Coraz rzadziej jest to jedno narzędzie, w którym realizuje się wszystkie zadania, a coraz częściej stabilne zaplecze operacyjne, działające w tle całego ekosystemu IT.

W 2026 roku firmy oczekują od ERP przede wszystkim niezawodności. Ma on utrzymywać spójność danych, kontrolować przebieg procesów i egzekwować reguły biznesowe – tak, aby kluczowe obszary firmy działały w sposób przewidywalny i uporządkowany.

Front-end dla konkretnych ról i zadań coraz częściej przejmują wyspecjalizowane narzędzia lub dedykowane interfejsy, dopasowane do kontekstu pracy użytkowników. To one stają się miejscem codziennej pracy magazynierów, pracowników produkcji czy sprzedawców, podczas gdy ERP w tle pilnuje reguł biznesowych i spójności procesów.

Przykłady:

Mimo że operacje odbywają się w różnych narzędziach, ERP pozostaje centralnym punktem spójności danych i procesów. Informacje z tych aplikacji trafiają do ERP w ustandaryzowanej formie, zgodnie z ustalonymi regułami biznesowymi.

To właśnie dlatego rola ERP w takiej architekturze jest kluczowa. Na niestabilnym ERP nie da się zbudować sensownego ekosystemu – jeśli fundament jest słaby, każda kolejna integracja zamiast porządkować procesy, tylko powiększa chaos.

W architekturze IT, w której ERP pełni rolę core systemu, lista funkcji przestaje być kluczowym kryterium wyboru. Znacznie ważniejsze staje się pytanie: jak łatwo i w jakim standardzie ERP pozwala integrować kolejne aplikacje i technologie – dziś i w przyszłości.

W 2026 roku firmy coraz rzadziej budują integracje „szyte na miarę” pod pojedyncze scenariusze. Zamiast tego oczekują otwartych, dobrze udokumentowanych i stabilnych interfejsów API, które umożliwiają bezpieczne dołączanie kolejnych elementów ekosystemu bez ryzyka destabilizacji całości.

Standaryzacja dotyczy nie tylko samej wymiany danych, ale również:

Dzięki temu możliwa jest realna wymienialność elementów ekosystemu. System B2B, platforma e-commerce, WMS czy inne wyspecjalizowane aplikacje mogą się zmieniać wraz z rozwojem firmy, wejściem na nowe rynki czy zmieniającymi się trendami – bez konieczności przebudowy całego zaplecza ERP.

To istotna zmiana myślenia: ERP nie ma być systemem, który „potrafi wszystko”, ale systemem, który umożliwia bezpieczną integrację wyspecjalizowanych rozwiązań. Im lepsze i bardziej przewidywalne API, tym mniejsze uzależnienie od jednego dostawcy technologii i mniejsze ryzyko po stronie biznesu.

W praktyce oznacza to, że w 2026 roku o dojrzałości ERP decyduje nie liczba modułów, lecz jakość architektury integracyjnej. To ona pozwala budować ekosystem, który można rozwijać i modyfikować bez zatrzymywania operacji firmy.

Sztuczna inteligencja coraz częściej pojawia się w rozmowach o systemach ERP, ale w praktyce nie jest kolejnym modułem systemu. Tempo rozwoju modeli i narzędzi AI jest zbyt szybkie, aby zamykać je wewnątrz systemu transakcyjnego.

W 2026 roku AI funkcjonuje przede wszystkim jako zewnętrzne usługi i wyspecjalizowane narzędzia, które korzystają z danych ERP, ale nie są z nim trwale związane technologicznie. ERP dostarcza uporządkowane, wiarygodne dane i kontekst biznesowy, a AI wykonuje to, do czego została zaprojektowana: analizuje, porównuje, przewiduje i automatyzuje.

W praktyce oznacza to m.in.:

Kluczowe jest to, że AI korzysta z ERP, ale działa obok niego. Dziś może to być jedno narzędzie, a za rok zupełnie inne. Dlatego firmy wybierają ERP, który:

To kolejny argument za otwartą architekturą. ERP nie musi „mieć AI”, aby dobrze z nią współpracować. Musi natomiast być stabilnym core systemem, który nie zamyka danych i nie ogranicza rozwoju.

Jeszcze kilka lat temu wdrożenie ERP traktowano jak duży, jednorazowy projekt:
 wybieramy system, wdrażamy „jak najwięcej” i liczymy, że wystarczy na kolejne 8-10 lat.

W 2026 roku to podejście coraz częściej się nie sprawdza.

Firmy działają w zmiennym otoczeniu:
 pojawiają się nowe kanały sprzedaży, nowe regulacje, nowe oczekiwania klientów, nowe technologie. W takiej rzeczywistości zamknięty, sztywny projekt ERP szybko staje się hamulcem zamiast wsparciem.

Dlatego zamiast planować wdrożenie „na dekadę”, organizacje projektują architekturę IT, którą można rozwijać krok po kroku.

W praktyce oznacza to, że:

Dziś może to być automatyzacja obiegu dokumentów, za pół roku nowe kanały sprzedaży, a za rok analityka predykcyjna lub wsparcie AI.

Bez „rewolucji”, bez zatrzymywania biznesu, bez wymiany ERP. To podejście:

ERP przestaje być projektem z datą końcową. Staje się trwałym fundamentem, na którym architektura IT może ewoluować razem z biznesem.

Większość firm z sektora MŚP nadal wybiera ERP, kierując się listą funkcji potrzebnych „na dziś”. To naturalne podejście, ale w 2026 roku coraz częściej okazuje się niewystarczające. O powodzeniu wdrożenia nie decyduje już to, co system ma w standardzie, lecz to, jak łatwo pozwala łączyć się z zewnętrznym światem: innymi aplikacjami, danymi i nowymi technologiami.

Powyższe trendy pokazują, że ERP coraz rzadziej pełni rolę samodzielnego, „kompletnego” systemu. Znacznie częściej staje się stabilnym elementem większej architektury IT — zapleczem, które odpowiada za spójność danych, kontrolę procesów i egzekwowanie reguł biznesowych.

W praktyce oznacza to, że o przydatności ERP decyduje dziś przede wszystkim to, czy:

Firmy, które myślą o ERP w ten sposób, mogą rozwijać swoje środowisko krok po kroku — dodając nowe kanały sprzedaży, automatyzacje czy narzędzia analityczne wtedy, gdy pojawia się realna potrzeba biznesowa, bez konieczności wymiany systemu przy każdej zmianie.

ERP nie jest więc dziś projektem „do zamknięcia”. Jest stabilnym zapleczem, które powinno działać przewidywalnie, podczas gdy reszta architektury IT może się zmieniać wraz z rozwojem firmy.

PS. Jeśli interesuje Cię, jak taka architektura wygląda w praktyce — na przykładzie SAP Business One — w Bazie Wiedzy opisujemy konkretne scenariusze integracji, analityki i wykorzystania AI.

2 października w Budapeszcie odbyło się spotkanie szerokiej grupy partnerów SAP Business One z krajów Europy Środkowo-Wschodniej, by wspólnie omówić kierunki rozwoju, bieżące wyzwania i potrzeby klientów. Wydarzenie było okazją do wymiany doświadczeń w gronie ekspertów, wdrożeniowców i przedstawicieli SAP, a także do spojrzenia w przyszłość rozwiązania – w szczególności w kontekście modelu webowego, lokalizacji i adaptacji do specyfiki krajowej.

Jednym z głównych tematów omawianych podczas spotkania była strategia przeniesienia całego zakresu funkcjonalności SAP Business One do klienta webowego (Web Client) – co wpisuje się w docelowy kierunek uproszczonej obsługi, mobilności i pracy w nowoczesnym interfejsie. Road Mapa wskazuje, że SAP przygotowuje m.in. rozszerzoną obsługę analityki, raportowania, wzbogaconą integrację i dostęp do systemu przez przeglądarkę.

W kontekście regionu CEE (Europa Środkowo-Wschodnia) bardzo istotne okazały się zagadnienia związane z lokalnymi wymaganiami prawnymi i fiskalnymi. W Polsce do takich funkcjonalności należą m.in.: faktury zaliczkowe, faktury korygujące, integracja z systemem KSeF, pliki JPK oraz inne rozliczenia i elektroniczna dokumentacja. Na spotkaniu partnerzy wymieniali się doświadczeniami i potrzebami klientów właśnie w tym obszarze – podkreślając, że przyszłe wersje SAP B1 muszą uwzględniać specyfikę polskiego rynku, aby zapewnić zgodność i pełną funkcjonalność.

Partnerzy z różnych krajów opowiadali, jakie potrzeby zgłaszają ich klienci – zarówno w aspekcie technologicznym, jak i biznesowym. Wspólnym mianownikiem była potrzeba większej elastyczności systemu, lepszej obsługi mobilnej, łatwiejszej integracji z innymi rozwiązaniami oraz szybszej adaptacji lokalnych zmian legislacyjnych. Tego typu spotkania są doskonałą platformą, by SAP mógł bezpośrednio „usłyszeć” oczekiwania rynku i partnerów – co przekłada się na kierunki rozwoju oprogramowania.

Dla polskich firm (i partnerów wdrożeniowych) to spotkanie jest znaczące z kilku powodów:

Wydarzenie potwierdziło silną współpracę partnerów SAP Business One w regionie CEE oraz zaangażowanie w dalszy rozwój systemu. Spotkanie przyniosło konkretne ustalenia dotyczące ulepszeń, integracji i wspólnej wizji przyszłości platformy, skoncentrowanej na potrzebach użytkowników i nowoczesnych rozwiązaniach webowych. Dowiedz się więcej o perspektywach rozwoju systemu SAP Business One