Automatyzacja księgowości w biurze rachunkowym 2026: po KSeF

U typowego klienta SMB około 70–85% strumienia faktur sprzedażowych i kosztowych wpada teraz strukturalnie przez KSeF, a pozostałe 15–30% — w zależności od profilu klienta — nadal trafia do manualnej obróbki. KSeF Phase 2 obowiązuje od 1 kwietnia 2026 r. dla wszystkich czynnych podatników VAT, więc w połowie maja biuro rachunkowe jest około sześciu tygodni w nowej rzeczywistości: strukturalne faktury pobierają się do głównego pakietu (Comarch ERP Optima, Symfonia, wFirma, iFirma, enova365) jednym ruchem, a księgowy nie wprowadza ich ręcznie. Reszta wymaga osobnego workflowu.

Te 15–30% jest właściwym przedmiotem decyzji, jakie podejmują dziś właściciele biur. Rok 2026 jest aktywnie marketingowany przez vendorów pakietów jako moment przeglądu stacku narzędziowego, ale przy bliższym spojrzeniu prawdziwa kwestia w automatyzacji księgowości biura rachunkowego 2026 nie dotyczy wymiany podstawowego pakietu — dojrzałe systemy działają na klientach od lat i koszt migracji rzadko zwraca się księgowo. Decyzja dotyczy obsługi tych pozostałych dokumentów, których KSeF nie strukturyzuje, a szablonowy OCR głównego pakietu nie domyka.

Co konkretnie pozostaje manualne po Phase 2:

• faktury zagraniczne PDF od dostawców spoza KSeF, w różnych językach i walutach;
• paragony fiskalne z NIP w wersji papierowej, które pozostają poza KSeF do 31 grudnia 2026 r.;
• faktury korygujące z odręcznymi adnotacjami od księgowego klienta albo samego klienta;
• dokumenty wystawiane w trybie offline24, fizycznie obecne w obiegu klienta zanim trafią do KSeF;
• archiwa sprzed cyfryzacji klienta — teczki, które biuro księguje wstecz po przejęciu obsługi;
• dowody zakupu od niepodatników VAT: rachunki uproszczone, faktury RR od rolników, dokumenty od fundacji i stowarzyszeń;
• faktury z niestandardową strukturą wewnętrzną, w których struktura pól KSeF rozwiązuje tylko nagłówek, nie układ pozycji.

Zakres i daty wprowadzania KSeF są ustalone publicznie: zgodnie z harmonogramem wdrożenia KSeF opublikowanym przez Ministerstwo Finansów, Krajowy System e-Faktur (KSeF) stał się obowiązkowy dla największych przedsiębiorców (sprzedaż powyżej 200 mln zł w 2024 r.) od 1 lutego 2026 r., a dla pozostałych przedsiębiorców od 1 kwietnia 2026 r. Faza obejmująca mikropodatników i faktury uproszczone wchodzi z dniem 1 stycznia 2027 r. Pełny zakres regulacyjny dla czytelnika, który chce szczegółów poza zakresem tego artykułu, znajduje się w opracowaniu opisującym pełen harmonogram i zakres obowiązkowego KSeF 2026.

Wniosek operacyjny jest prosty: biuro rachunkowe w 2026 r. nie zarobi na wymianie głównego pakietu — zarobi na uporządkowanej obsłudze tych 15–30% strumienia, które wypadają poza szablon.

---

Dokumenty odstające od szablonów: konkretne kategorie strumienia, którego pakiet nie domyka

Kategorie wymienione poniżej nie są wadą konkretnego pakietu księgowego. Są trwałym strumieniem nieustrukturyzowanym, którego KSeF z definicji nie obejmuje albo obejmuje tylko częściowo, a szablonowy OCR głównego pakietu nie obsługuje, bo nie ma na czym uczyć szablonu powtarzalnego dostawcy. To są właśnie dokumenty odstające od szablonu w biurze rachunkowym — kategoria operacyjna, a nie braki implementacyjne konkretnego vendora.

Faktury zagraniczne PDF. Dostawcy spoza polskiego systemu wystawiają w różnych językach (DE, EN, FR, IT, hiszpański, czeski) i różnych walutach (EUR, USD, GBP, CHF). Amazon Business, AWS, faktura hotelowa z 25 pozycjami per noc, faktura niemieckiego dostawcy z polem Steuernummer zamiast NIP, faktura francuska z numerem TVA, faktura ze Szwajcarii w CHF z pozycjami w trzech kolumnach językowych. Każdy dostawca to własny układ; biuro obsługujące kilku importerów albo klientów kupujących usługi SaaS w obcych walutach widzi po kilkadziesiąt różnych formatów miesięcznie.

Paragony fiskalne z NIP w wersji papierowej. Pozostają poza KSeF do 31 grudnia 2026 r. — klient wystawia, klient płaci, papier wraca do biura w kopercie albo w fotce z telefonu. Jakość bywa zmienna: paragon na papierze termicznym może być wyblakły po dwóch tygodniach w teczce, foto z telefonu robione w sklepie pod kątem łapie cień na środku, czasem brakuje rogu z numerem. Mechanika tej kategorii — od fizycznego paragonu do księgowego dokumentu kosztowego — jest opisana w omówieniu, w którym znajdują się zasady paragonów z NIP i faktur do paragonu do końca 2026 r.. Po stronie nabywcy każdy taki paragon trzeba wpisać odrębnie do rejestru zakupów, co praktycznie pokazuje workflow eksportu paragonów z NIP do importowalnego Excela dla JPK_V7 i PKPiR.

Faktury korygujące z odręcznymi adnotacjami. Księgowy klienta — albo nawet sam klient — dopisuje na fakturze numer dokumentu pierwotnego, korektę kwoty, opis przyczyny korekty, czasem dodatkową datę. Szablon OCR nie wie, gdzie szukać tej adnotacji; nie była częścią trenowanego formatu dostawcy.

Archiwa sprzed cyfryzacji klienta. Biuro przejmuje klienta z teczką papierową — trzeba zaewidencjonować rok albo dwa lata wstecz, żeby zamknąć księgowo poprzednie okresy. Dokumenty są skanami zmiennej jakości, w niespójnych formatach, od kilkunastu różnych dostawców, których klient w międzyczasie zmienił. Każdy szablon trzeba by trenować od zera dla pojedynczego, jednorazowego przejścia.

Dowody zakupu od niepodatników VAT. Rachunki uproszczone od freelancerów, faktury RR od rolników ryczałtowych, paragony bez NIP używane jako dowód księgowy w przypadku małych kwot, dokumenty od fundacji i stowarzyszeń. Strukturalnie poza KSeF, bo wystawca nie jest podatnikiem VAT.

Dokumenty z trybu offline24. Wystawione w trybie awaryjnym KSeF (gdy system nie odpowiada), czekające na potwierdzenie ze strony Ministerstwa, ale fizycznie obecne w obiegu klienta jako PDF i podlegające księgowaniu w czasie rzeczywistym po stronie odbiorcy.

Faktury z niestandardową strukturą wewnętrzną. Faktury hotelowe (linia per noc plus opłaty serwisowe plus miejski podatek noclegowy), telekomunikacyjne (szczegółowy billing minut, pakietów, danych w roamingu), faktury za usługi prawne (godziny × stawka × opis sprawy plus refaktury kosztów sądowych), faktury leasingowe z harmonogramem rat na 36 miesięcy. KSeF strukturyzuje takie dokumenty na poziomie nagłówka, ale wewnętrzny układ pozycji wciąż wymaga interpretacji przy księgowaniu — szczególnie gdy klient chce widzieć rozbicie kosztu w analizie zarządczej.

Skala razem jest zauważalna. Biuro obsługujące 100 klientów, w którym średnio każdy klient generuje około 20 takich dokumentów miesięcznie, ma w skali biura 2000 dokumentów odstających od szablonu w jednym miesiącu.

Dlaczego OCR-szablon głównego pakietu zawodzi na tych dokumentach

Szablonowy OCR — niezależnie od tego, czy to Comarch OCR w Optimie, SaldeoSMART zintegrowane z biurowym workflowem, Symfonia eBiuro czy wbudowany moduł wFirmy — działa według dobrze zdefiniowanej mechaniki. Na podstawie pierwszych kilku dokumentów od konkretnego dostawcy narzędzie uczy się powtarzalnego układu: gdzie na stronie znajduje się numer faktury, gdzie kwota netto, gdzie stawka i kwota VAT, jak wygląda tabela z pozycjami, czy jest stopka z numerem konta bankowego. Po nauczeniu się tego układu narzędzie odczytuje pola z każdej kolejnej faktury tego samego dostawcy z bardzo wysoką dokładnością. To jest OCR po szablonie w biurze rachunkowym, jak to nazywa branża, i właśnie dlatego sprawdza się na powtarzalnym strumieniu kosztowym — dostawcy mediów, telekomy, leasing, regularni kontrahenci handlowi.

Granica modelu szablonowego jest jednak strukturalna, nie implementacyjna. Gdy szablon spotyka dokument różniący się od trenowanego formatu, nie ma dokąd sięgnąć. Faktura Amazon Business w EUR z polem VAT ID zamiast NIP nie pasuje do szablonu, bo szablon nie wie, że VAT ID to odpowiednik NIP-u dla kontrahenta z UE. Skan paragonu fiskalnego z papieru termicznego, w którym połowa znaków jest wyblakła, nie pasuje, bo szablon zakładał czytelny układ pól. Faktura hotelowa z 25 wierszami per noc nie pasuje, bo szablon trenował się na fakturze hotelowej z jedną pozycją zbiorczą. Archiwalna faktura z 2018 r. od dostawcy, którego klient od tamtej pory zmienił, nie pasuje, bo szablonu dla tego dostawcy nigdy nie wytrenowano — i nie ma sensu uczyć go teraz, dla jednorazowej obsługi archiwum.

W praktyce w takich sytuacjach narzędzie zachowuje się na dwa sposoby. Albo świadomie wycofuje się z ekstrakcji i kieruje dokument do trybu pełnego ręcznego review (księgowy widzi pusty albo częściowo wypełniony formularz, sam wypisuje pola), albo — co jest bardziej zdradliwe — wypełnia pola wartościami pobranymi z najbliższego rozpoznanego szablonu, które nie pasują do tego konkretnego dokumentu. Druga ścieżka wymaga osobnej walidacji, bo błąd może wejść w księgi nierozpoznany.

Vendorzy nie ukrywają tego mechanizmu — wymienia się go wprost w dokumentacji produktowej. wFirma w pomocy własnego systemu pisze, że jej OCR obsługuje faktury zakupu wystawione w języku polskim w formacie PDF, PNG lub JPG, ale funkcja ta nie dotyczy faktur zagranicznych (obcojęzycznych oraz walutowych), faktur korygujących oraz faktur zaliczkowych. To dokładnie te kategorie, które rozpoznaliśmy w poprzedniej sekcji jako "odstające". Scanye z kolei pozycjonuje się dziś jako narzędzie łączące dokumenty z KSeF i te spoza — sygnał, że nawet vendorzy KSeF-OCR przyjęli, że dokumenty spoza KSeF to osobna kategoria wymagająca innego podejścia. Analiza tego samego problemu od strony konkretnego pakietu — jak Comarch ERP Optima OCR radzi sobie po KSeF z fakturami zagranicznymi — pokazuje tę granicę szczegółowo na przykładzie pakietu, którego używa najwięcej polskich biur.

Trzeba postawić to wyraźnie: model szablonowy nie jest słaby. Jest precyzyjny w swojej domenie. Działa świetnie na powtarzalnym strumieniu (czyli na większości strumienia większości klientów biura) i właśnie dlatego pozostaje sensownym wyborem dla głównego pakietu. Granica wynika z definicji modelu — szablon żyje z powtarzalności, więc tam, gdzie powtarzalności nie ma, model się kończy. Pytanie nie brzmi, czy szablon głównego pakietu wymienić na coś innego. Brzmi, czym wypełnić obszar, którego szablon z założenia nie domyka.

---

Prompt-driven ekstrakcja: model alternatywny, gdy szablon nie pasuje

Alternatywa wobec szablonu to inny model uczenia w ogóle. Zamiast trenować narzędzie pod konkretnego dostawcę i konkretny układ strony, użytkownik opisuje zadanie w języku naturalnym — co ma zostać wyekstrahowane i jak ma wyglądać wynik. Jeden prompt, niezależnie od tego, kto i w jakim języku wystawił dokument:

"Wyciągnij z każdego dokumentu nazwę sprzedawcy, NIP albo VAT ID, datę, numer, kwoty netto, VAT i brutto, walutę, opis pozycji w skrócie. Każdy dokument = osobny wiersz."

Ten sam prompt obsługuje fakturę z niemieckiego AWS, polski paragon fiskalny ze skanera, hotelową fakturę z Włoch z 25 pozycjami per noc, korektę z odręcznym dopiskiem na marginesie. Działa, bo opisuje, co ekstrahować, a nie gdzie szukać. Model językowy rozumie kontekst pól bez konfiguracji per dostawca: rozpoznaje Steuernummer jako odpowiednik NIP-u dla kontrahenta niemieckiego, Total incl. VAT jako kwotę brutto, TVA jako VAT po francusku, kwotę w EUR jako walutę dokumentu, znak "−" przed kwotą jako korektę in minus. Tego nie da się załatwić listą reguł — żadna lista nie obejmie wszystkich wariantów językowych i strukturalnych, jakie pojawiają się w praktyce biura obsługującego klientów z miksem polski/zagranica. Dlatego mówimy o elastycznym narzędziu OCR dla biura rachunkowego — elastycznym w sensie operacyjnym, nie marketingowym.

Zakres tej elastyczności jest konkretny i sprawdzalny. Biuro rachunkowe może zastosować elastyczną ekstrakcję danych z faktur w sposób, który łączy w jednej partii dokumenty bardzo różnego pochodzenia: natywne PDF od dostawców SaaS, skany dobrej jakości z dokumentów archiwalnych, skany gorszej jakości z paragonów termicznych, fotografie z telefonu robione przez klienta po zakupach. W jednej partii mogą siedzieć dokumenty w polskim, niemieckim, angielskim, francuskim, włoskim, czeskim, hiszpańskim — modele językowe nie potrzebują osobnego wariantu na każdy język źródła. Niestandardowe struktury (faktura hotelowa z wielopozycyjnym rozliczeniem, faktura telekomunikacyjna ze szczegółowym billingiem, faktura korygująca z odręczną adnotacją) są przedmiotem normalnego promptu, a nie wyjątkiem wymagającym osobnego szablonu.

W praktyce to oznacza zupełnie inny układ workflowu. Zamiast konfigurować szablon dla każdego nowego dostawcy i czekać, aż narzędzie się go nauczy, księgowy w naszym elastycznym narzędziu ekstrakcji danych z faktur i innych dokumentów księgowych wgrywa partię dokumentów — może być ich dziesięć, może być kilka tysięcy — pisze prompt po polsku albo po angielsku, otrzymuje plik Excel, CSV lub JSON z danymi w kolumnach, których potrzebował. Nie ma kreatora konfiguracji, nie ma fazy uczenia szablonu, nie ma osobnego wariantu dla każdego dostawcy. Pojedyncze pole promptu, plik na wyjściu — ta sama interakcja, którą księgowy zna z ChatGPT czy Claude, z tą różnicą, że tutaj system jest zaprojektowany pod batch processing dokumentów księgowych, a nie pod rozmowę. Jedna partia może objąć do 6000 plików w sesji, pojedynczy PDF do 5000 stron — to mieści w sobie cały miesięczny strumień odstających dokumentów typowego biura.

To rozróżnienie warto trzymać: różnica względem szablonu nie jest "lepszy OCR". Różnica jest w samym modelu uczenia. Szablon żyje z powtarzalności struktury; prompt-driven ekstrakcja żyje ze zrozumienia kontekstu pól, więc tam, gdzie powtarzalności nie ma, jeden działa, a drugi z definicji nie. Stąd rola tego narzędzia w stacku biura jest dobrze zdefiniowana — nie zastępuje szablonowego OCR głównego pakietu, tylko obsługuje kategorię dokumentów, której tamten ze swojej natury nie obejmuje.

---

Rachunek dla biura ze 100 klientami: ile czasu i pieniędzy oszczędza side-tool

Wracam do skali z sekcji o kategoriach: biuro ze 100 klientami, każdy generujący średnio około 20 dokumentów odstających od szablonu miesięcznie, w sumie 2000 dokumentów w skali biura w jednym miesiącu. To liczba realistyczna dla biura obsługującego mieszankę klientów importujących z UE, klientów z papierowym strumieniem paragonów i klientów przejmowanych z archiwami; biura wąsko specjalizowane (np. wyłącznie krajowe usługi B2B z regularnymi dostawcami) będą miały tę liczbę niższą, biura z silnym strumieniem e-commerce i importu — wyższą.

Manualne wprowadzanie jednego takiego dokumentu zajmuje 3–4 minuty pracy księgowej. Te 3–4 minuty rozkładają się na otwarcie skanu albo PDF, odczytanie pól (data, nazwa sprzedawcy, NIP albo VAT ID, kwoty netto i brutto, stawka VAT, opis przedmiotu zakupu, waluta), wpisanie do ewidencji w głównym pakiecie, walidację formy (przeliczenie kursu dla walutowych, sprawdzenie NIP-u dla większych kwot, klasyfikacja kosztu). Mnożąc przez 2000 dokumentów, biuro spędza 100–130 godzin pracy księgowej miesięcznie tylko na tej kategorii — czyli ekwiwalent jednej osoby zaangażowanej w pełnym wymiarze przez 60–80% miesiąca w samo wprowadzanie danych z dokumentów odstających od szablonu.

Z prompt-driven ekstraktorem ten sam strumień wygląda inaczej. Księgowy wgrywa partię tysiąca dokumentów (np. wszystkie zagraniczne PDF zebrane przez biuro w danym tygodniu), pisze albo wybiera z biblioteki zapisany prompt, otrzymuje strukturalny arkusz Excel z gotowymi kolumnami. Praca, która zostaje po jego stronie, to review danych — sprawdzenie nazw dostawców i NIP-ów, weryfikacja kwot dla pozycji o wyższej wartości, korekta pojedynczych pól, gdzie model się zawahał — oraz import do głównego pakietu. Czas spada do 20–40 godzin miesięcznie na tę samą partię 2000 dokumentów. Oszczędność realna 60–90 godzin pracy księgowej w skali biura.

W przeliczeniu na strukturę biznesową biura: 80 godzin to pełne dwa tygodnie pracy księgowej w miesiącu. Brutto kosztu pracy księgowej w Polsce w 2026 r. zależy od regionu i doświadczenia, ale rząd wielkości 6000–10000 zł miesięcznie odzwierciedla realny zakres dla księgowej z 3–7 lat doświadczenia. Dwa tygodnie tej pensji to 3000–5000 zł zwolnionej zdolności miesięcznie. Koszt narzędzia po stronie biura mieści się typowo w przedziale kilkuset złotych miesięcznie — w modelu opartym na kredytach za przetworzone strony, bez subskrypcji per księgowy i bez minimalnej liczby miejsc, biuro płaci dokładnie za to, co przetworzyło. Saldo widać w pierwszym miesiącu, próg break-even jest osiągany jeszcze przed końcem pierwszego kwartału użycia.

Konkretnie liczbowy efekt operacyjny dla biura jest dwojaki. Po pierwsze — czas księgowej, która do tej pory wprowadzała te 100 godzin manualnie, można przeznaczyć na pracę o wyższej wartości: dekretację skomplikowanych transakcji, doradztwo klientom, weryfikację rozliczeń. Po drugie, i to jest punkt strategiczny — biuro może wziąć więcej klientów bez dorzucania kolejnej osoby do zespołu. Tradycyjną odpowiedzią na wzrost liczby klientów z 100 do 130 byłoby zatrudnienie dodatkowej księgowej; skalowanie biura rachunkowego bez zwiększania zespołu w roku 2026 polega na tym, że 30 nowych klientów mieści się w odzyskanym czasie istniejącego zespołu. To jest realna dźwignia w automatyzacji księgowości biura rachunkowego 2026.

Jedno zastrzeżenie warte powtórzenia: żadne narzędzie nie sprowadza 100–130 godzin tej pracy do zera. Realna redukcja czasu na tej kategorii to 60–70%, nie 100%. Review danych, korekta pojedynczych błędów, import, walidacja — to dalej praca człowieka. Vendor-pages, które obiecują automatyzację end-to-end bez tych zastrzeżeń, opisują marketingowy wycinek; rachunek przedstawiony powyżej jest tym, co biuro realnie zobaczy w drugim miesiącu użycia.

Hybrydowy workflow: jak osadzić elastyczną ekstrakcję obok Comarch Optima, Symfonii i wFirmy

Najczęstsza obawa właściciela biura przy wprowadzaniu nowego narzędzia jest praktyczna: "co to zrobi z moim workflowem". Odpowiedź w tym przypadku jest mechaniczna — side-tool produkuje plik Excel albo CSV, a ten plik wchodzi do głównego pakietu przez funkcję importu, której księgowy w biurze już używa, czasem od lat, do importu rejestrów zewnętrznych, danych z banku albo arkuszy klienta. Hybrydowy workflow biuro rachunkowe KSeF sprowadza się do dwóch równolegle działających ścieżek danych w tym samym pakiecie księgowym, nie do dwóch pakietów.

Konkretne ścieżki importu w głównych systemach, po nazwie funkcji:

• Comarch ERP Optima — import ewidencji VAT z pliku CSV/XLS, import dokumentów handlowych (faktury zakupu, sprzedaży) z arkusza.
• Symfonia / Symfonia eBiuro — import dokumentów handlowych z arkusza kalkulacyjnego, import rejestru VAT z pliku zewnętrznego.
• wFirma — import ewidencji KPiR oraz import ewidencji VAT z plików CSV.
• enova365 — standardowy import danych z plików tekstowych i CSV w module księgowym, mapowanie kolumn definiowane raz dla typu dokumentu.
• iFirma — import faktur zakupu i wydatków z plików CSV w panelu księgowego.

W każdym z tych pakietów funkcja importu jest dojrzała — księgowy raz konfiguruje mapowanie kolumn dla danego typu dokumentu, potem cyklicznie wgrywa kolejne pliki w tym samym układzie. Typowy zestaw kolumn idących z side-toola do importu: data wystawienia, numer dokumentu, nazwa sprzedawcy, NIP albo VAT ID, kwota netto, stawka VAT, kwota VAT, kwota brutto, opis pozycji, waluta (dla zagranicznych), kurs przeliczenia (jeśli pakiet go wymaga w pliku, a nie pobiera z własnej konfiguracji NBP). Side-tool może wyprodukować te kolumny dokładnie w takim nazwaniu i kolejności, jakiego wymaga import konkretnego pakietu — wystarczy raz opisać w promptcie ("Order columns as: Data, Numer, Sprzedawca, NIP, Netto, VAT_proc, VAT_kwota, Brutto, Waluta, Opis"), a wynik trafia prosto do importu. To jest import Excel CSV do głównego pakietu księgowego bez warstwy pośredniej; przy fakturach zakupowych najważniejsze mapowania opisuje osobno proces zamiany faktur kosztowych PDF na CSV dla Optimy, Symfonii i Subiekta.

Dla biura obsługującego mieszankę klientów polskich i zagranicznych daje to czystą strukturę pracy w obrębie tego samego pakietu. Polskie faktury kosztowe i sprzedażowe wpadają do Optimy (albo dowolnego pakietu z listy powyżej) przez KSeF, automatycznie, bez ręcznego dotyku księgowego. Zagraniczne PDF — które KSeF z definicji nie obsługuje, bo dostawca jest spoza systemu polskiego — wracają z side-toola jako Excel i idą do importu rejestru VAT w tym samym pakiecie. Księgowy obsługuje obie ścieżki w jednym interfejsie głównego pakietu; różni je tylko źródło danych, a nie miejsce, w którym ostatecznie wchodzą do ksiąg. Dodatkowy zysk operacyjny — biuro może raz zapisać prompt per klient (np. dla klienta importującego z Niemiec: prompt już z mapowaniem niemieckich pól na polskie i z stałą walutą EUR; dla klienta hotelarskiego: prompt z rozbiciem per noc) i używać go raz w miesiącu na całej partii dokumentów tego klienta. Biblioteka promptów w narzędziu zachowuje te zapisane konfiguracje pomiędzy sesjami.

Warto rozwiać jeden konkretny niepokój dla biur używających Comarch ERP Optima. Optima ma własny moduł OCR (Comarch OCR), który dla wielu biur pełni rolę szablonowego rozpoznawania faktur od regularnych dostawców polskojęzycznych. Side-tool prompt-driven nie wchodzi z nim w konflikt — działa na innej kategorii dokumentów. Comarch OCR uczy szablonów stałych polskich dostawców, gdzie ma sens i gdzie precyzja jest najwyższa. Side-tool obsługuje wszystko poza tym: zagranicę, archiwa, korekty z adnotacjami, niestandardowe struktury, dokumenty od niepodatników. Dwie technologie, dwa zakresy zastosowania, jeden pakiet księgowy na końcu workflowu.

Co side-tool obsługuje, a czego nigdy nie zastąpi w pakiecie księgowym

Zakres działania narzędzia uzupełniającego do Comarch Optima, SaldeoSMART i pozostałych pakietów warto zdefiniować dokładnie — żeby właściciel biura, który jest odpowiedzialny zawodowo za rozliczenia klientów, wiedział, czego się spodziewa i czego nie obiecuje. Side-tool produkuje strukturalny arkusz z danymi wyekstrahowanymi z dokumentów. To jest początek workflowu księgowego, nie jego całość.

Co konkretnie robi:

• Ekstrahuje dane z dokumentów odstających od szablonów — kategorii wymienionych w sekcji drugiej, w tym faktur zagranicznych, paragonów z NIP, korekt z adnotacjami, archiwów, dokumentów od niepodatników, offline24, niestandardowych struktur.
• Produkuje plik Excel, CSV lub JSON w kolumnach i formacie zdefiniowanym przez prompt, gotowy do importu w głównym pakiecie.
• Obsługuje dokumenty w wielu językach źródła (polski, niemiecki, angielski, francuski, włoski, hiszpański, czeski i kolejne), w wielu walutach, w formatach PDF natywnym, PDF skanowanym, JPG, PNG.
• Radzi sobie z dokumentami niższej jakości — wyblakłymi paragonami termicznymi, fotami z telefonu, skanami archiwalnymi — gdzie szablonowy OCR ma już problemy.

Czego nie robi i nie powinien robić:

• Nie zastępuje pakietu księgowego. Nie prowadzi ksiąg rachunkowych, nie generuje sprawozdań finansowych, nie integruje się z urzędem skarbowym — te obszary pozostają w Comarch ERP Optimie, Symfonii, wFirmie, enovie lub innym wybranym pakiecie.
• Nie składa JPK_V7 ani innych deklaracji. JPK powstaje w głównym pakiecie na podstawie zaimportowanych danych z rejestru VAT, a nie w narzędziu ekstrakcji.
• Nie waliduje NIP-u przeciw Białej Liście podatników VAT. Walidacja przeciw rejestrowi MF jest funkcją pakietu księgowego (Optima ma wbudowaną integrację z białą listą; Symfonia, wFirma analogicznie) albo osobnej integracji z API ministerialnym — szczegółowo opisujemy automatyzację weryfikacji rachunków dostawców na białej liście VAT i procedurę ZAW-NR w osobnym opracowaniu.
• Nie waliduje numerów VAT-EU kontrahentów zagranicznych przez VIES. To obowiązek pakietu albo osobnego procesu po stronie biura.
• Nie robi dekretacji ani klasyfikacji rodzaju kosztu — wyboru konta kosztowego, kodu GTU, kodu świadczenia, identyfikacji procedury szczególnej. To pozostaje decyzją księgowego na podstawie wiedzy o specyfice klienta i obowiązujących przepisach.
• Nie zarządza obiegiem dokumentów, akceptacjami, statusami płatności. To obszar głównego pakietu albo dedykowanego systemu DMS.

Każde "nie" w tej liście jest jednocześnie obszarem, w którym główny pakiet biura — Optima, Symfonia, wFirma, enova — zachowuje swoją rolę i swoją wartość. Side-tool nie konkuruje o te obszary. Działa na wąsko zdefiniowanym etapie workflowu: ekstrakcja danych z dokumentów odstających od szablonu, między momentem, w którym dokument fizycznie trafia do biura, a momentem, w którym dane z niego trafiają do importu w pakiecie. Brak konfliktu funkcjonalnego oznacza brak konieczności migracji, a to wprost przekłada się na ryzyko wdrożenia — narzędzia, które nie ruszają niczego w istniejącym stacku, da się testować na pojedynczym kliencie albo pojedynczej partii dokumentów i wycofać bez kosztu.

W realistycznym tygodniu pracy biura side-tool jest używany 30–60 minut tygodniowo przez księgowego obsługującego daną partię klientów. To czas potrzebny na wgranie zebranych dokumentów, uruchomienie ekstrakcji, review wyniku i pobranie pliku do importu. Narzędzie nie wymaga codziennej uwagi, nie wymaga osoby dedykowanej, nie wymaga osobnego ekranu otwartego cały dzień. Pozostaje w roli, którą sam definiuje — biuro rachunkowe z niestandardowymi dokumentami KSeF dostaje cichy, krótko używany etap workflowu, który robi jedną rzecz dobrze.

---

KSeF Phase 3 w styczniu 2027: dlaczego elastyczne narzędzie zostaje w stacku na stałe

Pytanie, które padnie u każdego właściciela biura rozważającego dziś nowe narzędzie ekstrakcji, brzmi: czy ono nie stanie się zbędne, gdy 1 stycznia 2027 r. ruszy Phase 3? Wtedy bowiem do KSeF wejdą mikropodatnicy, którzy w Phase 2 byli zwolnieni, oraz faktury uproszczone (paragony z NIP do 450 zł brutto), do końca 2026 r. pozostające poza systemem. Phase 3 to faktyczna zmiana w zakresie KSeF — i część strumienia "odstających" dokumentów rzeczywiście zniknie.

Co się zmieni dla biura. Po pierwsze, spadnie wolumen papierowych paragonów z NIP, bo od stycznia 2027 r. będą wystawiane strukturalnie w KSeF. To jedna z większych kategorii sekcji drugiej, więc spadek jest zauważalny. Po drugie, faktury od mikrofirm, które klient biura kupuje (np. od jednoosobowych dostawców usług, którzy w Phase 2 zostali jeszcze poza systemem), zaczną wpadać do KSeF — kolejny segment papierowo-PDF-owy migruje do strukturalnego, a po stronie wystawców oznacza to osobny proces przygotowania do obowiązku KSeF dla JDG i mikrofirm.

Czego Phase 3 nie zmieni. To jest pełna lista i warto ją zobaczyć w jednym miejscu:

• Faktury zagraniczne PDF. KSeF z założenia obejmuje podatników rejestrowanych w Polsce. Niemiecki, francuski, amerykański dostawca nigdy nie będzie wystawiał w KSeF — wystawia w swoim systemie krajowym albo natywnie jako PDF. Dla biura obsługującego klientów importujących z UE i spoza UE ten strumień jest strukturalnie poza zasięgiem KSeF i Phase 3 niczego tu nie zmienia.
• Archiwa 2026 i wcześniejsze. Biura obrabiają dokumenty wstecz przez kolejne kwartały po Phase 3 — księgowanie z opóźnieniem, korekty deklaracji wstecz, kontrole skarbowe sięgające pięć lat w głąb, przejmowanie nowego klienta z teczką sprzed cyfryzacji. Archiwum nie znika z dnia na dzień.
• Dowody zakupu od niepodatników VAT. Rachunki od freelancerów rozliczających się ryczałtem, faktury RR od rolników ryczałtowych, dokumenty od fundacji i stowarzyszeń — wystawca nie jest podatnikiem VAT, więc nie wchodzi do KSeF z definicji. Phase 3 obejmuje mikropodatników VAT, nie wszystkie podmioty wystawiające dowody zakupu.
• Dokumenty z trybu offline24 i awaryjnego. Tryb offline pozostaje w obiegu jako mechanizm ciągłości — gdy KSeF nie odpowiada albo wystawca jest tymczasowo bez dostępu. Dokument fizycznie istnieje jako PDF zanim trafi do KSeF i biuro może go potrzebować zaksięgować szybciej, niż system go potwierdzi.
• Niestandardowe struktury wewnętrzne. KSeF strukturyzuje fakturę na poziomie pól nagłówka, ale wewnętrzny układ pozycji w skomplikowanych dokumentach (hotelowych z linią per noc, telekomunikacyjnych ze szczegółowym billingiem, leasingowych z harmonogramem rat 36-miesięcznym) wciąż wymaga interpretacji przy księgowaniu, jeśli klient chce widzieć rozbicie kosztu albo biuro chce dekretować precyzyjnie.

Konsekwencja jest spójna. Po Phase 3 strumień dokumentów odstających od szablonu w typowym biurze spadnie z 15–30% do 10–20% — mniej niż dziś, ale wciąż realnie. Dla biura ze 100 klientami, miksem polski/zagranica/archiwa, jest to dalej kilkaset do 1500 dokumentów miesięcznie. Próg, przy którym narzędzie się amortyzuje (60–90 godzin oszczędzonej pracy księgowej miesięcznie), jest osiągany w tej skali bez problemu również w 2027 r. Side-tool nie jest tymczasowym mostkiem na czas wdrożenia KSeF; jest trwałym elementem stacku biura obsługującego klientów z choć minimalnym zagranicznym albo archiwalnym strumieniem.

Dlatego w 2026 r. dźwignia w automatyzacji księgowości biura rachunkowego nie leży w zmianie głównego pakietu. Leży w uporządkowanej obsłudze tych 15–30% strumienia, których szablonowy OCR z definicji nie domyka. Prompt-driven ekstraktor obok dojrzałego stacku rozwiązuje konkretny ból, nie wymaga migracji, mieści się w godzinie pracy księgowego tygodniowo i amortyzuje się w pierwszym kwartale użycia. To również ścieżka do skalowania biura rachunkowego bez zwiększania zespołu, bo czas zwolniony z ręcznego wprowadzania danych jest dokładnie tym czasem, który potrzeba na obsługę dodatkowych klientów. To inwestycja, której wartość nie wygasa z kolejną fazą KSeF — i to jest decyzja, jaka realnie stoi dziś przed właścicielem biura.