Faktury kosztowe PDF do CSV: Optima, Symfonia, Subiekt

Aby zaimportować faktury kosztowe z PDF do Comarch Optima, Symfonii lub Subiekta nexo, najpierw trzeba wyciągnąć wspólny zestaw pól: dane sprzedawcy, NIP, numer faktury, daty, kwoty netto, VAT i brutto według stawek, walutę, termin płatności oraz opis księgowy. Dopiero potem te same dane mapuje się do formatu akceptowanego przez konkretny system: CSV lub Excel w ścieżkach dla Optimy, strukturę importu CSV w Symfonii albo EDI++/EPP i warstwę integracyjną w ekosystemie InsERT.

To ważne rozróżnienie, bo zapytanie o faktury kosztowe PDF do CSV zwykle nie oznacza jednego uniwersalnego pliku, który każdy program księgowy przyjmie bez pytań. CSV jest często formatem roboczym: wygodnym arkuszem pośrednim, w którym biuro rachunkowe kontroluje dane przed importem, konwersją albo księgowaniem.

Praktyczny proces wygląda tak:

Etap	Co powstaje	Co trzeba sprawdzić
PDF, skan lub załącznik od klienta	dokument źródłowy	czy faktura jest kompletna i czy nie jest już w KSeF
Ekstrakcja danych	tabela pól faktury	NIP, numer faktury, daty, stawki VAT, waluta, termin płatności
Kontrola biura	arkusz roboczy	duplikaty, kontrahent, kwoty według stawek, korekty, waluta
Mapowanie do systemu	plik lub rekordy importu	układ wymagany przez Optimę, Symfonię albo Subiekta
Import i weryfikacja	dokument w rejestrze VAT zakupu	okres VAT, opis księgowy, konto lub kategoria, status płatności

Invoice Data Extraction pasuje do pierwszej części tej pracy: biuro może wgrać PDF-y lub skany, opisać w promptcie wymagane pola i pobrać wynik jako Excel, CSV albo JSON. To nie zastępuje formatu importu w Optimie, Symfonii czy Subiekcie. Daje jednak uporządkowany, powtarzalny materiał wejściowy, z którego można przygotować plik pod konkretny importer, konwerter lub własną integrację.

KSeF zmienia część obiegu krajowych faktur, ale nie usuwa potrzeby takiego procesu. W biurach nadal zostają faktury zagraniczne, stare PDF-y, skany, dokumenty od klientów w okresie przejściowym, załączniki i koszty, które nie przychodzą jako gotowy, poprawnie obsłużony dokument strukturalny. Dla takich przypadków przewaga nie polega na samym OCR. Polega na tym, że raz ustalony schemat pól można konsekwentnie przekształcać pod kilka polskich systemów księgowych.

Uniwersalny schemat pól dla faktury kosztowej

Najpierw warto zbudować schemat, który nie jest jeszcze podporządkowany żadnemu programowi księgowemu. Taki arkusz roboczy powinien odpowiadać na pytanie: czy z faktury wyciągnięto wszystko, czego biuro potrzebuje do rejestru VAT zakupu, KPiR albo księgi handlowej?

Podstawowy zakres pól można podzielić na kilka grup:

Grupa danych	Pola, które zwykle warto wyciągnąć
Kontrahent	nazwa sprzedawcy, NIP lub zagraniczny numer identyfikacyjny, adres, kraj
Dokument	numer faktury, typ dokumentu, numer korekty, numer KSeF, źródło pliku
Daty	data wystawienia, data sprzedaży lub wykonania usługi, data wpływu, termin płatności
VAT	kwoty netto, VAT i brutto osobno dla stawek 23%, 8%, 5%, 0%, zw. i NP
Płatność	waluta, kwota do zapłaty, rachunek bankowy, metoda płatności, termin
Księgowanie	opis kosztu, kategoria, konto, MPK, uwagi do pozycji
Kontrola	flaga duplikatu, brak NIP, niezgodność sum, pole wymagające ręcznego sprawdzenia

Najczęstszy błąd przy projektowaniu importu polega na wyciąganiu tylko sumy brutto z nagłówka faktury. To wystarcza do prostego raportu, ale nie wystarcza do księgowania. Rejestr VAT zakupu potrzebuje rozbicia według stawek, a biuro często potrzebuje też informacji, czy koszt ma trafić na jedno konto, kilka kategorii albo osobne pozycje analityczne.

Różnica między nagłówkiem a pozycjami jest szczególnie ważna przy fakturach z mieszaną stawką VAT. Jedna faktura może mieć materiały biurowe na 23%, usługę transportową na 8% i element zwolniony z VAT. W arkuszu roboczym można przechowywać zarówno sumy według stawek, jak i linie faktury, ale nie każdy importer przyjmie oba poziomy danych w tej samej postaci. Dlatego ekstrakcja danych z faktur do CSV powinna dawać stabilny, kontrolowalny zestaw kolumn, a dopiero później osobne eksporty dla Optimy, Symfonii i Subiekta.

W Invoice Data Extraction taki układ można opisać promptem: na przykład poprosić o kolumny netto 23%, VAT 23%, brutto 23%, netto 8%, VAT 8%, brutto 8%, walutę, termin płatności, NIP sprzedawcy i komentarz do pól niepewnych. Wynik może zostać pobrany jako Excel, CSV lub JSON. To nadal arkusz przygotowawczy, nie gwarancja, że system księgowy przyjmie plik bez mapowania, ale biuro zyskuje jeden powtarzalny etap przed platformowymi różnicami.

Do schematu trzeba dodać przypadki, które nie mieszczą się w prostym przykładzie: faktury korygujące z wartościami ujemnymi, waluty obce wymagające kursu, dokumenty bez polskiego NIP, faktury z rachunkiem bankowym innym niż oczekiwany i pozycje, które księgowo trzeba rozdzielić na kilka kont. Jeśli te pola nie zostaną wyciągnięte na początku, wrócą jako ręczne poprawki po imporcie.

Optima, Symfonia i Subiekt nie chcą tego samego pliku

Comarch Optima, Symfonia i Subiekt nexo mogą obsłużyć ten sam dokument księgowy, ale nie oczekują tego samego układu danych. Dlatego biuro, które chce obsłużyć import faktur z PDF do Optimy, Symfonii i Subiekta nexo, powinno rozdzielić dwa pojęcia: wspólny arkusz ekstrakcji oraz docelowy format importu.

System	Praktyczna ścieżka wejścia	Co zwykle trzeba dopasować	Gdzie zostaje kontrola ręczna
Comarch Optima	CSV lub Excel przez importer, dodatek albo narzędzie wdrożeniowe do rejestru VAT zakupu	typ dokumentu, kontrahent, numer, daty, stawki VAT, kategoria, opis, pozycje	nowy kontrahent, powtórzony numer, rozbicie VAT, waluta, okres VAT
Symfonia	własna struktura importu CSV, a nie zwykła tabela faktur	wiersze dokumentu, zapisów, zakupów i VAT, pliki kontrahentów, nagłówki, pola puste	kompletność danych kontrahenta, poprawność rekordu VAT, daty, konta, brakujące pola
Subiekt nexo	EDI++/EPP, e-Faktura/KSeF, Sfera lub konwerter z pliku pośredniego	struktura dokumentu dla ekosystemu InsERT, synchronizacja kartotek, pozycje, asortyment lub opis	decyzja, czy tworzyć dokument, jak dopasować kontrahenta i jak potraktować pozycje

W przypadku Optimy "Comarch Optima import rejestru zakupu VAT CSV" najczęściej oznacza import przez konkretne narzędzie lub dodatek, a nie jeden oficjalny plik, który wygląda identycznie w każdym biurze. Istotne są typ dokumentu, numer, daty, NIP, wartości według stawek VAT, kategoria i opis. Przy fakturach wielopozycyjnych importer może wymagać osobnych wierszy albo powtarzania numeru dokumentu dla kolejnych pozycji, więc arkusz musi być przygotowany zgodnie z narzędziem, które faktycznie wykona import. Ten sam obszar warto odróżnić od szerszego tematu, jakim jest skanowanie faktur w Comarch ERP Optima po KSeF, bo tutaj problemem nie jest tylko pozyskanie obrazu dokumentu, lecz przygotowanie danych do rejestru.

Symfonia jest bardziej formalna w samym kształcie importu. "Symfonia import faktur zakupowych CSV" nie powinno być rozumiane jako prosty arkusz, w którym jeden wiersz równa się jednej fakturze. Dokumentacja Symfonii opisuje strukturę z różnymi typami wierszy, między innymi dla dokumentu, zapisu, zakupu i VAT. Dla biura oznacza to, że neutralny CSV z ekstrakcji jest dopiero materiałem wejściowym. Trzeba go przekształcić do struktury, w której program rozpozna dokument, zapis księgowy i rozbicie podatku.

W Subiekcie nexo skrót "CSV" bywa jeszcze bardziej mylący. Ekosystem InsERT często pracuje z EDI++/EPP, e-Fakturą, KSeF albo integracją przez Sferę. Jeśli biuro zaczyna od PDF-a, może przygotować CSV jako etap kontrolny, ale docelowo potrzebuje konwertera, pliku EPP albo integracji, która zbuduje dokument w rozumieniu programu. Dla prostego rejestru kosztów to może być wystarczająco proste. Dla faktur z pozycjami, asortymentem lub powiązaniem z zamówieniem robi się to już zadanie integracyjne.

W każdym z trzech systemów powtarzają się te same ryzyka: błędnie dopasowany kontrahent, numer faktury uznany za duplikat, rozbite stawki VAT, waluta obca i data wpływu przypisana do złego okresu. Różni się tylko miejsce, w którym błąd wyjdzie na jaw: w arkuszu, w importerze, w konwerterze albo dopiero po utworzeniu dokumentu w rejestrze.

Przykład faktury z mieszanym VAT i trzema mapowaniami

Załóżmy, że biuro otrzymuje fakturę kosztową PDF od dostawcy:

Pole	Wartość z faktury
Sprzedawca	ABC Serwis Sp. z o.o.
NIP sprzedawcy	5250000000
Numer faktury	FV 18/05/2026
Data wystawienia	2026-05-15
Data sprzedaży	2026-05-14
Termin płatności	2026-05-29
Waluta	PLN
Pozycja 1	materiały biurowe, netto 1000,00 zł, VAT 23%, VAT 230,00 zł, brutto 1230,00 zł
Pozycja 2	usługa transportowa, netto 500,00 zł, VAT 8%, VAT 40,00 zł, brutto 540,00 zł
Razem	netto 1500,00 zł, VAT 270,00 zł, brutto 1770,00 zł

Neutralny wynik ekstrakcji do Excela albo CSV nie musi jeszcze przypominać importu do żadnego systemu. Może wyglądać tak:

invoice_number	supplier_nip	issue_date	sale_date	due_date	net_23	vat_23	gross_23	net_8	vat_8	gross_8	total_gross	description
FV 18/05/2026	5250000000	2026-05-15	2026-05-14	2026-05-29	1000,00	230,00	1230,00	500,00	40,00	540,00	1770,00	materiały biurowe i transport

Dla Optimy ten arkusz trzeba dopasować do importera rejestru VAT zakupu. Jeżeli narzędzie obsługuje pozycje, faktura może zostać rozbita na dwa wiersze z tym samym numerem dokumentu, ale inną stawką VAT i opisem. Jeżeli import działa na sumach według stawek, istotne będą osobne pola dla 23% i 8%, typ dokumentu, data wpływu, kategoria oraz rozpoznanie kontrahenta po NIP. Właściwa kolejność kolumn zależy od używanego importera, więc nie warto traktować neutralnego CSV jako gotowego pliku do Optimy.

Dla Symfonii punkt wyjścia jest podobny, ale format docelowy jest inny. Ta sama faktura może wymagać rekordu dokumentu, rekordu zapisu, rekordu zakupu i osobnych rekordów VAT dla stawek 23% oraz 8%. W praktyce oznacza to, że jedna linia z arkusza ekstrakcji może stać się kilkoma wierszami w pliku importowym. Jeżeli kontrahent nie istnieje w kartotece albo plik kontrahentów nie jest przygotowany, sam import dokumentu nie wystarczy.

Dla Subiekta nexo neutralny CSV zwykle jest punktem pośrednim do konwersji. Jeśli docelowy proces idzie przez EDI++/EPP, trzeba zbudować dokument w strukturze, którą InsERT rozumie jako fakturę zakupu. Jeżeli biuro używa Sfery lub innej integracji, CSV może zasilać logikę, która tworzy dokument i dopasowuje kontrahenta. Jeśli faktura ma pozycje powiązane z asortymentem, samo rozbicie VAT nie wystarczy, bo pojawia się pytanie, czy pozycje mają być opisowe, czy kartotekowe.

Ten przykład pokazuje najważniejszą zasadę: ekstrakcja faktury zakupu do Excela porządkuje fakty z dokumentu, ale import księgowy jest osobną decyzją projektową. Dobra tabela źródłowa powinna zachować wszystkie dane potrzebne do mapowania, nawet jeśli docelowy system nie użyje każdej kolumny wprost.

---

KSeF nie kończy importu z PDF i CSV

KSeF zmniejszy liczbę krajowych faktur, które biuro będzie odbierać jako zwykły PDF, ale nie zamknie całego tematu importu z plików. Według oficjalnego FAQ Ministerstwa Finansów o limicie 10 000 zł w KSeF obowiązek wystawiania faktur w systemie obejmuje firmy etapami od 1 lutego 2026 r. i 1 kwietnia 2026 r.; do 31 grudnia 2026 r. można jeszcze wystawiać faktury poza KSeF, jeśli miesięczna suma sprzedaży z VAT na takich fakturach nie przekroczy 10 000 zł. Dla najmniejszych klientów biura znaczenie mają też zasady KSeF dla JDG i mikrofirm, bo wpływają na to, które dokumenty nadal trzeba zbierać i porządkować poza systemem.

Dla biura rachunkowego to oznacza mieszany okres pracy, a nie czystą wymianę jednego procesu na drugi. Część dokumentów przyjdzie jako KSeF XML lub zostanie pobrana z systemu. Część nadal będzie PDF-em, skanem, załącznikiem mailowym, dokumentem zagranicznym albo starym plikiem z okresu sprzed pełnego wdrożenia. Do tego dochodzą koszty, które nie zachowują się jak standardowa krajowa faktura zakupowa.

Właśnie w takich wyjątkach zostaje miejsce na import faktur kosztowych z PDF do CSV. Zagraniczny dostawca może przysłać fakturę w swoim formacie. Klient może dosłać zaległy skan. W dokumentacji kosztowej mogą pojawić się załączniki, zestawienia, potwierdzenia, rachunki albo faktury uproszczone. Wtedy biuro nadal potrzebuje kontrolowanego arkusza danych, nawet jeśli dla krajowych faktur ustrukturyzowanych wybierze natywną ścieżkę KSeF.

Ten sam problem dotyczy dokumentów sąsiednich wobec faktur zakupowych. Jeżeli w obiegu klienta pojawiają się paragony z NIP do Excela i JPK_V7, biuro nadal musi zdecydować, jakie dane trafią do arkusza, jak zostaną opisane i kiedy wymagają kontroli przed ujęciem w KPiR albo rejestrze. KSeF nie porządkuje automatycznie wszystkich takich przypadków.

Szersze planowanie procesów po 2026 r. powinno więc rozdzielać dwie warstwy: obsługę dokumentów strukturalnych oraz obsługę wyjątków, PDF-ów i plików roboczych. To jest jeden z powodów, dla których automatyzacja księgowości w biurze rachunkowym po KSeF nie polega wyłącznie na podłączeniu do KSeF. Biuro nadal potrzebuje procedury dla dokumentów, które przychodzą bokiem albo wymagają ręcznej kwalifikacji kosztu.

Kontrole przed importem, które oszczędzają najwięcej poprawek

Największe oszczędności nie biorą się z samego wygenerowania CSV. Biorą się z tego, że błędy zostają złapane przed importem, a nie po utworzeniu dokumentów w rejestrze VAT zakupu. W biurze rachunkowym warto traktować arkusz ekstrakcji jak etap kontroli, nie tylko jak techniczny eksport.

Pierwsza kontrola to kontrahent. NIP powinien prowadzić do właściwej kartoteki, ale w praktyce pojawiają się literówki, zagraniczne numery identyfikacyjne, skrócone nazwy sprzedawców, brak prefiksu kraju albo faktury od podmiotów, których jeszcze nie ma w systemie. Jeżeli importer tworzy nowego kontrahenta automatycznie, błąd w nazwie może zostać utrwalony. Jeżeli wymaga istniejącej kartoteki, import zatrzyma się na dokumencie, który księgowa i tak musi sprawdzić ręcznie.

Druga kontrola to numer faktury. Ten sam numer może oznaczać duplikat, ale w niektórych układach importu powtórzony numer dokumentu służy do zapisania kolejnej pozycji tej samej faktury. Dlatego przed automatycznym odrzuceniem trzeba sprawdzić kontekst: NIP sprzedawcy, datę, kwotę brutto i liczbę wierszy. Prosta flaga "numer już istnieje" jest przydatna, ale nie powinna sama decydować o księgowaniu.

Trzecia kontrola dotyczy dat. Data wystawienia, data sprzedaży, data wpływu i okres VAT mogą być różne, a system importu może oczekiwać jednej z nich w konkretnym polu. Błąd na tym etapie jest cichy: dokument przejdzie import, ale trafi do złego okresu. To szczególnie ryzykowne przy fakturach otrzymanych po zamknięciu miesiąca i przy korektach.

Czwarta grupa to kwoty i VAT. Arkusz powinien wykazywać oddzielnie stawki 23%, 8%, 5%, 0%, zw. i NP oraz sumy kontrolne. Korekty z wartościami ujemnymi muszą być opisane tak, aby importer nie potraktował ich jak zwykłych pozycji dodatnich. Zaokrąglenia trzeba porównywać na poziomie stawek, nie tylko całej faktury, bo różnica kilku groszy w rozbiciu VAT potrafi zablokować import albo wymusić ręczną edycję.

Waluty obce wymagają osobnej uwagi. Samo wyciągnięcie kwoty EUR albo USD nie wystarcza, jeśli proces księgowy wymaga kursu, daty kursu, kwoty w PLN i decyzji, czy kurs ma zostać pobrany przez system, czy wpisany w pliku. Rachunek bankowy też nie jest zwykłą informacją opisową. Może służyć do kontroli płatności, ale nie powinien bezrefleksyjnie przesądzać o księgowaniu faktury.

W Symfonii i podobnych ścieżkach importu dochodzi jeszcze techniczna kompletność pól. Jeśli dokumentacja wymaga pól pustych albo placeholderów takich jak PUSTY, brak takiej wartości może mieć znaczenie strukturalne. To nie jest problem rozpoznawania tekstu z PDF-a, tylko zgodności pliku z parserem importu.

Invoice Data Extraction może pomóc na etapie arkusza kontrolnego, bo prompt może obejmować nie tylko pola księgowe, ale też dodatkowe kolumny typu "brak NIP", "suma VAT nie zgadza się z pozycjami", "możliwy duplikat" albo "pole wymaga sprawdzenia", jeśli taka informacja wynika z dokumentu i instrukcji użytkownika. Trzeba jednak zachować granicę: narzędzie przygotowuje dane w Excelu, CSV lub JSON, a nie księguje dokumentów w Optimie, Symfonii ani Subiekcie.

Jak wybrać docelową ścieżkę dla biura rachunkowego

Wybór ścieżki nie powinien zaczynać się od pytania, czy da się zrobić CSV. Lepsze pytanie brzmi: ile dokumentów będzie przechodzić przez proces, ile systemów trzeba obsłużyć i jak dużo kontroli biuro chce zachować przed importem.

Przy małej skali wystarczy często prosty arkusz kontrolny. Biuro wyciąga dane z PDF-ów, sprawdza NIP, numer, daty i VAT, a potem importuje dokumenty przez dostępny dodatek albo przepisuje wyjątki ręcznie. Taki model ma sens, gdy dokumentów jest niewiele, faktury są powtarzalne, a koszt wdrożenia konwertera byłby większy niż zysk z automatyzacji.

Przy wielu klientach i kilku systemach warto oddzielić stały etap ekstrakcji od zmiennych eksportów. Ten sam schemat wejściowy może zasilać osobne mapowania: jedno dla Optimy, drugie dla Symfonii, trzecie dla Subiekta nexo. Dzięki temu biuro nie projektuje procesu od nowa dla każdego klienta. Zmienia się warstwa eksportu, ale kontrola pól źródłowych pozostaje ta sama.

Przy dużej skali, powtarzalnych strumieniach faktur albo złożonych dokumentach zwykły CSV bywa za słaby jako format docelowy. Wtedy właściwszą warstwą może być importer, konwerter, EDI++/EPP, KSeF XML, Sfera, API albo inna integracja, która tworzy dokument w systemie zgodnie z jego regułami. To szczególnie ważne, gdy faktury mają wiele pozycji, waluty obce, powiązania z kartoteką asortymentową albo wymagają rozbudowanej dekretacji.

Invoice Data Extraction może pełnić rolę wspólnego pierwszego etapu: zamienić faktury na strukturę Excel, CSV lub JSON według promptu opisującego pola potrzebne biuru. Taki wynik można potem mapować inaczej dla Optimy, inaczej dla Symfonii i inaczej dla Subiekta. Nie jest to natywna integracja z tymi systemami, ale porządkuje najbardziej powtarzalną część pracy: wydobycie danych z dokumentu źródłowego.

Najtrwalszy proces powstaje wtedy, gdy biuro nie myli ekstrakcji z importem. Ekstrakcja odpowiada za wierne i kompletne dane z faktury. Import odpowiada za zgodność z konkretnym systemem księgowym. Gdy te warstwy są rozdzielone, łatwiej zmienić konwerter, dodać kolejny program lub obsłużyć wyjątki bez przebudowy całego obiegu faktur kosztowych.