Jak biuro rachunkowe pracuje na danych z systemów klientów
Biuro rachunkowe rzadko ma bezpośredni dostęp do systemu ERP klienta. Zazwyczaj pracuje na tym, co zostanie mu przekazane: plikach JPK, eksportach CSV/XLSX, wydrukach PDF lub paczkach dokumentów elektronicznych. Dlatego raporty dla biura rachunkowego i dobrze przygotowany eksport danych z ERP do księgowości stają się dla księgowego jedynym źródłem prawdy o zdarzeniach gospodarczych.
Księgowy patrzy na dane inaczej niż użytkownicy ERP. Dla użytkownika kluczowe są procesy (wystawienie faktury, wydanie towaru z magazynu, wysyłka zamówienia). Dla księgowego liczy się datowanie, prawidłowa klasyfikacja podatkowa, kompletność dokumentów i możliwość ich prześledzenia w razie kontroli. Jeśli ERP generuje dane niepełne, niespójne lub w różnych formatach, biuro rachunkowe musi nadrabiać ręcznie, co podnosi koszt obsługi i zwiększa ryzyko błędów.
Większość programów księgowych ma funkcje importu danych z zewnętrznych systemów. Jednak ich użycie wymaga stałego, powtarzalnego standardu eksportu – tych samych kolumn, nazw pól, kodów VAT i typów dokumentów. Bez tego księgowy szybko rezygnuje z automatyzacji i wraca do ręcznego księgowania, co niweluje sens integracji ERP z programem księgowym.
Dlaczego eksporty są ważniejsze niż sam podgląd w ERP
Zdarza się, że klient oferuje księgowemu dostęp do ERP w trybie tylko do odczytu. Brzmi wygodnie, ale w praktyce raporty dla biura rachunkowego i pliki eksportowe nadal są konieczne. Powody są proste:
Odpowiedzialność i ślad audytowy – biuro rachunkowe musi mieć możliwość wykazania, na podstawie jakich danych zaksięgowano podatek. Dostęp do ERP tego nie zapewnia; zapewnia go dopiero plik, który można zarchiwizować (JPK, CSV, PDF).
Archiwizacja – dokumenty źródłowe i eksporty z ERP przechowuje się latami, czasem dłużej niż obowiązkowy okres podatkowy. Dostęp do ERP może się skończyć po rozwiązaniu umowy, ale pliki księgowy musi nadal mieć.
Powtarzalność – stały format eksportu danych z ERP do księgowości pozwala zbudować szablony importu, schematy dekretacji, reguły automatycznego księgowania. Bez tego każda zmiana w ERP burzy pracę w biurze rachunkowym.
Kontrola kontroli – w razie korekt i sporów z urzędem skarbowym łatwiej jest wrócić do konkretnego pliku eksportowego z danego miesiąca niż odtwarzać stan danych z ERP sprzed kilku lat.
Dlatego nawet jeśli biuro loguje się do ERP, w praktyce bazuje na dedykowanych eksportach: rejestrach VAT, obrotach magazynowych, rozrachunkach, wyciągach bankowych. To na nich opiera księgi i deklaracje.
Raport do zarządu a eksport dla księgowego – dwie różne rzeczywistości
Wielu właścicieli firm myli raportowanie zarządcze z raportami dla księgowości. Menedżer chce widzieć marżę, sprzedaż wg handlowców, analizę ABC asortymentu, obroty w kanałach sprzedaży. Księgowy potrzebuje czegoś innego: poprawnego podziału na konta, rejestrów VAT, dat księgowych, walut i kursów, stanów rozrachunków. Raport, który świetnie wygląda w Excelu dla zarządu, może być bezużyteczny jako eksport do programu księgowego.
Dla zarządu kluczowa jest interpretacja, agregacja i estetyka. Dla księgowości – techniczna kompletność i zgodność z przepisami. Dlatego:
Raport sprzedaży dla zarządu może agregować dane miesięcznie, księgowy zwykle potrzebuje każdej faktury osobno.
Raport marżowy może pomijać korekty lub dokumenty wewnętrzne, a dla księgowości to często kluczowe zapisy.
Raport zarządczy może mieć własne kategorie kosztów, niezwiązane z planem kont księgowych.
Dobry praktyk rozdziela te dwie funkcje. Tworzy osobne eksporty z ERP bez braków dla księgowego i osobne raporty menedżerskie, bazujące na tych samych danych, ale inaczej ułożone.
Jak złej jakości dane z ERP podnoszą koszt obsługi w biurze
Każda luka w eksporcie danych z ERP do księgowości wraca w postaci dodatkowych pytań, maili i telefonów. Typowy scenariusz:
brakuje kilku faktur sprzedaży z końca miesiąca,
część dokumentów ma puste NIP-y lub błędne stawki VAT,
brak powiązania płatności z fakturami,
korekty wystawione po dacie eksportu nie są ujęte w przekazanym pliku.
Każde takie zdarzenie to dodatkowa praca. Biuro rachunkowe albo dolicza to do faktury, albo pracuje poniżej opłacalności i w dłuższej perspektywie szuka „mniej problematycznych” klientów. Z punktu widzenia firmy klienta oznacza to:
wyższe koszty księgowości,
wyższe ryzyko błędów (dopłaty do podatków, odsetki, kary),
gorszą współpracę i dłuższe terminy zamknięcia miesiąca.
Ułożone, kompletne i powtarzalne raporty dla biura rachunkowego działają odwrotnie – skracają czas zamknięcia, stabilizują koszty i minimalizują ryzyko korekt.
Jakie dane księgowy naprawdę potrzebuje z ERP
Minimum danych dla pełnej księgowości
Dla pełnej księgowości księgowy potrzebuje przede wszystkim kompletu dokumentów za dany okres. W praktyce oznacza to co najmniej:
Dokumenty zakupu – faktury od dostawców, korekty, faktury za media, koszty ogólne, faktury importowe (WNT, import usług, import towarów z poza UE).
Dokumenty magazynowe – WZ, PZ, RW, PW, MM, inwentaryzacje; potrzebne do ustalenia kosztu własnego sprzedaży i stanów magazynowych.
Wyciągi bankowe – ruchy na rachunkach, płatności klientów, przelewy do dostawców, opłaty bankowe, prowizje.
Raporty kasowe, KP/KW – dokumenty kasowe, jeśli firma obraca gotówką.
Wiele firm skupia się tylko na fakturach sprzedaży i zakupu, zapominając o magazynie i rozrachunkach. To błąd, bo bez tych danych księgowy nie ustali realnego wyniku finansowego ani poprawnych stanów należności i zobowiązań.
Poziom szczegółowości: nagłówki dokumentów a pozycje
Eksport z ERP można przygotować na dwóch poziomach: nagłówków dokumentów i pozycji. Nie zawsze potrzebne jest wszystko. Świadome podejście oszczędza pracy po obu stronach.
Przykładowe zasady:
Tylko nagłówki dokumentów – wystarczą tam, gdzie liczy się wyłącznie kwota i stawka VAT, a analityka towarowa nie jest księgowo wymagana. Dobre dla prostych usług, abonamentów, najmu czy małej sprzedaży B2B.
Nagłówki + sumy VAT – wystarczają w większości standardowych eksportów rejestrów VAT sprzedaży i zakupu, o ile ERP generuje prawidłowe agregaty po stawkach.
Pozycje dokumentów – konieczne przy rozbudowanej analityce: księgowanie kosztów wg MPK, projektów, centrów kosztów; rozliczanie marży na poziomie asortymentu; e-commerce z tysiącami pozycji.
Jeśli biuro rachunkowe importuje dane bezpośrednio do systemu księgowego, warto wspólnie ustalić wymagany poziom szczegółowości. Często sensowne jest rozwiązanie hybrydowe: rejestry VAT po nagłówkach, za to raport magazynowy lub analityka sprzedaży już po pozycjach.
Dane dodatkowe: kontrahenci, kursy walut, płatności
Poza samymi dokumentami księgowy potrzebuje danych pomocniczych, bez których import się nie uda albo będzie wymagał ręcznego uzupełniania. Kluczowe elementy:
Kartoteki kontrahentów – nazwa, NIP, adres, kraj, status podatnika VAT, ewentualnie numer rachunku bankowego. Bez tego system księgowy nie przypisze dokumentów do właściwych podmiotów.
Kursy walut – szczególnie przy transakcjach w EUR, USD i innych walutach. Księgowy musi wiedzieć, jaki kurs zastosowano (NBP z konkretnej daty, kurs kontraktowy itd.).
Formy i terminy płatności – przelew, gotówka, karta, pobranie. To wpływa na kontrolę rozrachunków i cash flow.
Rejestry VAT – przypisanie dokumentów do odpowiednich rejestrów sprzedaży i zakupu (krajowe, unijne, eksportowe, odwrotne obciążenie).
Brak tych danych oznacza, że księgowy będzie ręcznie zakładał kontrahentów, ustalał kursy i poprawiał parametry podatkowe. To spowalnia pracę i zwiększa ryzyko pomyłek. Dlatego struktura plików JPK i CSV powinna z góry zakładać przekazanie kompletnych kartotek i parametrów.
Różne branże, różne potrzeby eksportów
Rodzaj działalności mocno wpływa na konstrukcję eksportów z ERP.
Usługi – zazwyczaj mniej dokumentów magazynowych, za to większy nacisk na rozliczanie czasu pracy, projektów i MPK. Eksporty muszą dobrze przenosić opisy i oznaczenia projektów, żeby księgowość mogła prowadzić analitykę kosztów.
Handel – dużo dokumentów sprzedaży i zakupu, rozbudowany magazyn, korekty ilościowe. Tu kluczowe są eksporty operacji magazynowych i właściwe powiązanie kosztu własnego sprzedaży z przychodami. Często potrzebne są odrębne raporty dla sprzedaży detalicznej (raporty z kas fiskalnych) i hurtowej.
Produkcja – dochodzą zlecenia produkcyjne, rozchody materiałów, przyjęcia wyrobów gotowych, półprodukty. Eksporty muszą odzwierciedlać strukturę kosztów (materiały, robocizna, koszty pośrednie) i sposób rozliczania produkcji w czasie.
E-commerce – bardzo dużo pojedynczych transakcji, często mikrosprzedaż, integracje z marketplace’ami i operatorami płatności. Tu sensowne są raporty zbiorcze (np. raporty dzienne sprzedaży i prowizji) zamiast pojedynczych paragonów w eksporcie do księgowości, o ile taki model zaakceptuje biuro rachunkowe.
Ustalenie standardu wymiany z biurem rachunkowym
Wybór formatu plików do eksportu danych
Podstawą stabilnej współpracy jest jasny standard wymiany. Trzeba ustalić, w jakich formatach będą przekazywane raporty dla biura rachunkowego i jakie importy obsługuje program księgowy. Najczęstsze warianty:
JPK (Jednolity Plik Kontrolny) – formalny, narzucony przez prawo standard struktury danych. Część biur wykorzystuje go jako bazę do księgowania, jednak JPK jest tworzony głównie z myślą o kontroli skarbowej, a nie o wygodzie księgowego.
XML – pliki strukturalne, często dedykowane pod konkretny program księgowy; dobrze nadają się do pełnej automatyzacji importu.
CSV – prosty format tekstowy, łatwy do generowania z ERP i dalszego przetwarzania w Excelu lub programie księgowym.
XLSX – plik Excela, wygodny do ręcznej kontroli i poprawek; część systemów księgowych potrafi importować dane bezpośrednio z arkuszy.
Ważne, aby integracja ERP z programem księgowym bazowała na jednym, stabilnym formacie dla danego typu danych (np. CSV dla rejestrów VAT, XML dla wyciągów bankowych). Zmienianie formatu co kilka miesięcy zabija automatyzację.
Słownik pojęć i mapowanie nazw pól
ERP i program księgowy często używają innych nazw dla tych samych pojęć. W jednym systemie mamy „Typ dokumentu = FS”, w innym „FD sprz.”, w jeszcze innym „FV_SPRZ”. Dla człowieka to oczywiste, ale dla automatu importującego – już nie.
Pomaga prosty słownik pojęć, który pokazuje, jak pola z ERP odpowiadają polom w księgowości. Taki dokument może wyglądać jak tabela robocza:
Przykładowy słownik i zasady jego utrzymania
Prosty arkusz w Excelu lub w firmowym Wiki wystarczy, żeby ucywilizować komunikację między ERP a księgowością. Kluczowe, żeby był aktualny i dostępny dla osób konfigurujących eksporty, wdrożeniowców i księgowego.
Praktyczny szkielet takiego słownika może wyglądać tak:
Nazwa pola w ERP – np. DocType, CustomerVATNo, PostingDate.
Nazwa pola w programie księgowym – np. RodzajDok, NIP, DataKsiegowania.
Opis biznesowy – „rodzaj dokumentu sprzedaży/zakupu”, „NIP nabywcy”, „data ujęcia w księgach”.
Przykładowe wartości – „FS, KFS, PA”, „PL1234567890”, „2024-01-31”.
Reguły walidacji – wymagane/niewymagane, format (np. 10 znaków, tylko cyfry), zakres dat.
Taki słownik przydaje się szczególnie wtedy, gdy:
zmienia się biuro rachunkowe lub program księgowy,
do projektu dołącza nowa osoba od strony IT lub księgowości,
pojawiają się nowe typy dokumentów (np. faktury pro-forma, nowe rodzaje korekt).
Bez słownika każda zmiana kończy się serią telefonów „co mieliście na myśli w tym polu?”. Ze słownikiem da się to załatwić jednym mailem z aktualizacją.
Harmonogram przekazywania raportów
Nawet najlepszy format plików nie pomoże, jeśli dane są wysyłane chaotycznie. Księgowość musi wiedzieć, kiedy może zamknąć miesiąc i że po tym terminie nie wyskoczą kolejne „spóźnione” faktury.
Przydaje się prosty harmonogram ustalony z góry. Wystarczy uzgodnić:
termin eksportu danych miesięcznych – np. do 5. dnia następnego miesiąca,
osobę odpowiedzialną za przygotowanie plików po stronie firmy,
zakres „zamykanego” okresu – np. komplet dokumentów sprzedaży, zakupu, magazynu i wyciągów do ostatniego dnia miesiąca.
W praktyce dobrze sprawdza się sztywna zasada: po wysłaniu „zamknięcia miesiąca” każda nowa faktura z wsteczną datą wymaga pisemnej akceptacji i informacyjnej korekty do biura. Dzięki temu zespół księgowy nie wraca w kółko do już zaksięgowanych miesięcy.
Tryb roboczy i tryb produkcyjny
Przed startem regularnych eksportów warto wprowadzić rozróżnienie na „tryb roboczy” i „tryb produkcyjny”. Pozwala to uniknąć nerwowych korekt na żywych danych.
Eksporty testowe (robocze) – na wydzielonym okresie (np. jeden miesiąc z poprzedniego roku), służą do dopracowania formatu, mapowań i walidacji. Tu wolno „kombinować”, zmieniać strukturę, dopisywać pola.
Eksporty produkcyjne – po akceptacji biura struktura jest zamrożona; zmiany odbywają się w kontrolowany sposób (np. przez zmianę wersji pliku: v1, v2).
Dobra praktyka: krótkie, wspólne spotkanie online raz na kwartał, na którym omawia się ewentualne problemy z eksportami i listę planowanych zmian. Lepiej wprowadzać korekty świadomie niż „z dnia na dzień”, gdy księgowy nagle nie może wczytać pliku.
Źródło: Pexels | Autor: RDNE Stock project
Konfiguracja ERP pod poprawne eksporty księgowe
Struktura kont i słowniki księgowe
Żeby eksporty nie wymagały ręcznego „podpinania” każdego dokumentu w księgowości, ERP musi znać podstawowe zasady dekretacji. Nie chodzi o pełne księgowanie w ERP, ale o spójne słowniki.
Minimalny zestaw konfiguracji:
Typy dokumentów – FS, FZ, KFS, KFZ, WNT, WDT, dokumenty magazynowe; każdy z jasnym znaczeniem i przypisaniem do rejestrów VAT.
Grupy towarowo-usługowe – powiązane z kontami przychodów i kosztów (np. „Towary handlowe”, „Usługi serwisowe”, „Abonamenty”).
Grupy kontrahentów – krajowi, unijni, pozaunijni, podmioty powiązane; pomocne przy klasyfikacji VAT i raportowaniu.
Kody VAT – jasno zdefiniowane, z przypisaniem do stawek i typów transakcji (np. 23% kraj, 0% WDT, NP – poza zakresem).
Bez tych słowników eksport zamienia się w surową listę dokumentów, z którą księgowy i tak będzie miał dużo ręcznej pracy. Dobrze skonfigurowane słowniki pozwalają programowi księgowemu automatycznie proponować konta księgowe i rejestry.
Parametry podatkowe i rejestry VAT
ERP powinien odzwierciedlać realne scenariusze podatkowe firmy. Błędy pojawiają się, gdy wszyscy korzystają z jednego „uniwersalnego” kodu VAT 23% albo księgują sprzedaż unijną jak krajową.
Przydatne kroki porządkowe:
zdefiniowanie osobnych rejestrów VAT dla sprzedaży i zakupu krajowego, unijnego, eksportu i transakcji odwrotnego obciążenia,
powiązanie kodów VAT z odpowiednimi rejestrami, tak aby użytkownik nie musiał o tym pamiętać przy każdej fakturze,
konfiguracja domyślnych stawek VAT na kartotekach towarów i usług – ogranicza ryzyko pomyłek operatorów.
Przykład z praktyki: firma handlowa sprzedaje zarówno krajowo, jak i do UE. Zamiast dwóch osobnych stawek (23% PL, 0% WDT) wszyscy wystawiają faktury z 23%, a potem proszą księgowego o „przeksięgowanie”. Przy małej skali jakoś to działa, przy większej kończy się zbiorczą korektą i tłumaczeniami wobec urzędu.
Ustawienia walutowe i kursy
Transakcje walutowe to kolejne źródło problemów w eksportach. Księgowy musi wiedzieć nie tylko, w jakiej walucie wystawiono dokument, ale też jaki kurs zastosowano przy przeliczeniu.
Kilka praktycznych ustawień w ERP:
obowiązkowe pole waluty dokumentu dla faktur w innych walutach niż PLN,
automatyczne pobieranie kursów z NBP (lub innego źródła) wraz z datą kursu,
przechowywanie w dokumencie zarówno wartości w walucie, jak i po przeliczeniu na PLN,
osobny słownik sposobów przeliczania (kurs z dnia poprzedzającego, kurs kontraktowy).
W eksporcie dane walutowe powinny pojawiać się jawnie: waluta, kwota w walucie, kurs, kwota w PLN, data kursu. Brak któregokolwiek z tych elementów powoduje zgadywanie po stronie księgowości.
Uprawnienia i odpowiedzialność za dane
Nawet najlepsza konfiguracja nie przetrwa długo, jeśli każdy użytkownik ERP może zmieniać słowniki, stawki czy domyślne konta. Konieczne jest rozdzielenie ról.
W praktyce przydaje się podział na:
administratorów słowników – zwykle osoba z działu finansów lub controlling,
operatorów sprzedaży/zakupu – mogą korzystać z kartotek, ale nie zmieniają parametrów podatkowych,
opiekuna integracji – odpowiada za poprawność konfiguracji eksportów i kontakt z biurem rachunkowym.
Dodatkowo dobrze działa prosta zasada: zmiany w słownikach VAT, rejestrach i kontach są konsultowane z księgowym przed wdrożeniem, a nie po fakcie, gdy coś już nie przeszło w imporcie.
Przygotowanie danych przed eksportem – porządek w dokumentach
Checklisty przedeksportowe
Stały zestaw czynności „przed wysyłką do księgowości” oszczędza po obu stronach dużo energii. Może mieć formę krótkiej checklisty do odhaczenia raz w miesiącu.
Przykładowa lista kontroli:
wszystkie faktury sprzedaży i zakupu za dany miesiąc zostały zafinalizowane/zaksięgowane w ERP,
nie ma dokumentów w statusie „szkic”, „roboczy”, jeśli dotyczą zamykanego okresu,
uzgodniono salda magazynu (brak ujemnych stanów, wykonane korekty ilościowe),
dla wszystkich dokumentów zagranicznych uzupełniono waluty i kursy,
wydrukowano lub wygenerowano raport obrotów na kontach rozrachunkowych i zgodność z rejestrem płatności.
Taka checklista może wisieć nad biurkiem osoby odpowiedzialnej za eksport albo być elementem zamknięcia miesiąca w systemie obiegu dokumentów.
Uzupełnianie braków w kartotekach kontrahentów
Niedbałe kartoteki kontrahentów to klasyczne źródło błędów w JPK i eksportach. Brakuje NIP-ów, krajów, form prawnych. Księgowy widzi potem „Nabywca: Jan” zamiast pełnych danych.
Żeby ograniczyć ten problem, można wdrożyć kilka prostych reguł:
ustawić wymagalność NIP dla kontrahentów firmowych (B2B),
wymagać oznaczenia kodu kraju przy NIP-ach zagranicznych,
dodać walidację formatu NIP dla Polski (10 cyfr) i podstawową kontrolę dla VAT UE (np. poprzez VIES podczas zakładania kartoteki),
okresowo (np. raz na kwartał) przeglądać listę kontrahentów z nieuzupełnionymi kluczowymi polami.
Dobrym nawykiem jest też blokowanie możliwości wystawienia faktury bez podstawowych danych. Lepiej, żeby handlowiec poświęcił dwie minuty na uzupełnienie kartoteki niż żeby księgowość później ratowała temat na korektach.
Kontrola spójności dokumentów i płatności
Eksport sprzedaży i zakupu bez powiązania z płatnościami ogranicza możliwości księgowego w zakresie rozrachunków. Przy większej skali robi się z tego spory bałagan.
Przed eksportem warto wykonać krótką kontrolę:
czy wszystkie płatności mają przypisane dokumenty źródłowe (faktury, rachunki),
czy nie występują płatności „bez faktury” w okresie, który jest zamykany (np. przelew z błędnym numerem),
czy w systemie nie ma podwójnych płatności do tej samej faktury,
czy stan rozrachunków w ERP zgadza się z planowanym eksportem (prosty raport sald).
Jeżeli ERP nie obsługuje powiązania płatności z fakturami, warto przynajmniej eksportować numer dokumentu i opis operacji z wyciągu. Księgowy szybciej dopasuje przelewy po stronie programu księgowego.
Obsługa korekt i dokumentów „spóźnionych”
Korekty wystawione po dacie eksportu to częste źródło nieporozumień. Jedna strona zakłada, że księgowy je widzi, druga – że zostaną ujęte „następnym razem”. Potem pojawiają się różnice między raportami z ERP a księgą główną.
Dobrze zdefiniować proste zasady:
korekty do dokumentów z zamkniętego miesiąca zawsze trafiają do osobnego pliku (np. „Korekty_poprzednie_okresy.csv”),
przy każdej korekcie eksportowane jest powiązanie z dokumentem pierwotnym (numer, data, identyfikator w ERP),
dla korekt „technicznych” (np. oczywista literówka, zmiana opisu) ustala się z księgowym, czy w ogóle wymagają ujęcia w księgach.
W większych firmach sprawdza się dodatkowo raport „zmian po eksporcie” – lista dokumentów zmodyfikowanych lub wystawionych z datą historyczną po wysłaniu plików do biura rachunkowego.
Typy eksportów z ERP i ich zastosowanie w księgowości
Eksport rejestrów VAT sprzedaży i zakupu
To podstawowy typ eksportu, który większość biur wykorzystuje jako bazę do księgowania. Kluczowe jest, żeby struktura pliku odwzorowywała wymagania JPK, ale jednocześnie była czytelna dla programu księgowego.
Najczęściej w takim eksporcie znajdują się pola:
numer dokumentu, daty: wystawienia i sprzedaży/zakupu,
dane kontrahenta: nazwa, NIP, kraj,
wartość netto i VAT w podziale na stawki,
typ transakcji (krajowa, WDT, WNT, eksport, import usług),
oznaczenie rejestru VAT i ewentualne dodatkowe znaczniki (np. oznaczenia GTU, procedur).
Jeśli ERP potrafi generować JPK_V7, często da się na jego bazie przygotować uproszczony CSV, który biuro wczyta szybciej niż pełny plik JPK.
Eksport dokumentów magazynowych (PZ, WZ, MM, RW)
W wielu firmach księgowość nie może oprzeć się wyłącznie na rejestrach VAT. Musi widzieć, jak dokumenty magazynowe wpływają na koszty własne sprzedaży i stany zapasów. Jeżeli ERP obsługuje gospodarkę magazynową, eksport tych danych znacznie ułatwia życie obu stronom.
W typowym eksporcie magazynowym przydają się pola:
typ dokumentu (PZ, WZ, PW, RW, MM),
numer dokumentu i data operacji,
magazyn źródłowy i docelowy (przy przesunięciach),
kod towaru/usługi, nazwa, jednostka miary,
ilość, cena ewidencyjna, wartość pozycji,
schemat lub propozycja kont księgowych (np. magazyn → koszt własny sprzedaży).
Warto uzgodnić, czy biuro księguje dokumenty magazynowe „po pozycjach”, czy wystarczy dla nich zagregowanie do poziomu dokumentu lub nawet dziennego zbioru. Przy dużej liczbie pozycji drobnych (sklepy, e‑commerce) poziom agregacji ma ogromny wpływ na czas importu.
Przykład z praktyki: hurtownia generowała jednego dnia kilkaset dokumentów WZ po kilkadziesiąt pozycji. Biuro rachunkowe nie miało technicznej możliwości wczytywać wszystkiego po wierszach. Uzgodniono więc eksport zbiorczych pozycji „Sprzedaż towarów – magazyn A – dzień X” z ERP, a szczegóły zostały w systemie magazynowym jako dowód pomocniczy.
Eksport rozrachunków i płatności
Sama sprzedaż i zakupy to za mało, jeśli biuro ma prowadzić realną kontrolę należności i zobowiązań. Dlatego przydaje się oddzielny eksport rozrachunków, najczęściej w układzie: faktura – płatność – saldo.
Przy konstrukcji takiego eksportu dobrze uwzględnić co najmniej:
identyfikator i numer faktury w ERP,
identyfikator kontrahenta (taki sam jak w eksporcie sprzedaży/zakupu),
termin płatności i formę płatności,
datę zapłaty i kwotę rozliczoną,
ewentualne różnice kursowe lub dopłaty/zwroty częściowe,
aktualne saldo dokumentu (pozostało do zapłaty).
Dobrym podejściem jest standaryzacja klucza rozrachunków: numer faktury + identyfikator kontrahenta + data wystawienia. Ten sam klucz powinien pojawiać się w plikach: sprzedaży, płatności i ewentualnie w eksporcie not odsetkowych.
Jeżeli ERP ma moduł bankowy, opłaca się generować eksport bezpośrednio z wyciągów bankowych: z numerami rachunków, opisami przelewów i identyfikatorem płatności. Biuro dzięki temu szybciej powiąże płatności z fakturami, zwłaszcza w przypadku klientów detalicznych, którzy nie wpisują numeru faktury w tytule przelewu.
Eksport planu kont i słowników pomocniczych
Większość problemów przy imporcie danych wynika z rozjazdu słowników: inne konta, inne kody VAT, inne oznaczenia kontrahentów. Żeby tego uniknąć, opłaca się zbudować stały eksport konfiguracji, a nie tylko dokumentów.
Taki plik zwykle obejmuje:
plan kont z pełnymi numerami i nazwami,
listę rejestrów VAT z oznaczeniem typów (sprzedaż/zakup, kraj/UE itd.),
słownik magazynów i centrów kosztów, jeśli są używane.
Dobrym pomysłem jest wysłanie takiego pliku do biura przy starcie współpracy i przy każdej większej zmianie konfiguracji ERP. Księgowy może wtedy powiązać kody z własnymi słownikami w programie księgowym i uniknąć tłumaczenia kolejnego pliku „ręcznie”.
Eksport raportów pomocniczych (obroty, analityka, centra kosztów)
Oprócz klasycznych eksportów dokumentów biuro często potrzebuje dodatkowych raportów, które nie zawsze wczytuje do programu, ale używa jako wsparcia analitycznego. Chodzi o różnego typu zestawienia obrotów, kosztów czy przychodów.
Najbardziej użyteczne bywają:
zestawienia sprzedaży według grup towarowych lub kanałów (np. sklep internetowy, hurt, detale),
raporty kosztów według centrów kosztów lub projektów,
analizy rotacji magazynu (wartość i ilość obrotów na kluczowych indeksach),
raporty rozrachunków przeterminowanych.
Warto, aby struktura tych raportów była stała z miesiąca na miesiąc. Biuro może wtedy zautomatyzować ich obróbkę w swoim Excelu lub narzędziach BI, zamiast każdorazowo dopasowywać kolumny.
Eksport do plików JPK jako źródło danych
Jeżeli ERP poprawnie generuje JPK_V7 czy JPK_MAG, z takich plików da się wyciągnąć bardzo dużo informacji do księgowości finansowej. Nie każde biuro chce jednak importować pełny JPK do swojego programu – często wystarczy uproszczona wersja.
Rozsądne podejście:
na etapie ustaleń z biurem zidentyfikować, które pola JPK są mu rzeczywiście potrzebne do importu,
przygotować „płaski” eksport CSV/XLS, który odzwierciedla wybrane pola JPK w prostym układzie tabelarycznym,
dodać kolumny techniczne ułatwiające mapowanie (ID dokumentu w ERP, typ rejestru, znacznik korekty).
Takie rozwiązanie łączy dwie korzyści: po pierwsze, dane są zgodne z logiką JPK (a więc kompletne podatkowo), po drugie – biuro nie jest zmuszone do pracy na skomplikowanym XML-u, tylko dostaje proste tabelaryczne zestawienie.
Eksport danych kadrowo‑płacowych
Jeśli biuro prowadzi również kadry i płace, przydaje się dobrze przemyślany eksport z modułu kadrowego ERP lub odrębnego systemu HR. Tu wiele błędów wynika z niekompletnej identyfikacji pracowników i braku rozbicia składników wynagrodzeń.
W praktycznym eksporcie finansowym z części płacowej warto uwzględnić:
identyfikator pracownika i jego podstawowe dane (imię, nazwisko, PESEL – jeśli nie ma przeszkód RODO),
miesiąc rozliczeniowy i datę wypłaty,
podział wynagrodzenia na główne składniki (podstawa, premie, nadgodziny, dodatki),
składki ZUS pracownika i pracodawcy,
zaliczkę na PIT i inne potrącenia,
klucz do centrum kosztów lub projektu, jeśli koszty wynagrodzeń są dzielone.
Tu mapowanie musi być dobrze uzgodnione z księgowym: każdy składnik płacowy powinien mieć przypisane konto (lub grupę kont) po stronie planu kont. Dzięki temu biuro może zaksięgować listę płac automatycznie, zamiast ręcznie przepisywać dane z PDF‑ów.
Mapowanie danych: jak przełożyć strukturę ERP na potrzeby księgowego
Identyfikatory techniczne jako spoiwo między systemami
Klasyczną pułapką jest opieranie się wyłącznie na numerach dokumentów czy nazwach kontrahentów. Z czasem pojawiają się duplikaty, zmiany nazw, inne schematy numeracji. Żeby powiązać dane z ERP z zapisami w programie księgowym, wygodniej używać stabilnych identyfikatorów technicznych.
Praktyczne zasady:
każdy dokument w eksporcie ma własny, niezmienny ID z ERP,
każdy kontrahent ma ID, które jest stałe nawet po zmianie nazwy czy formy prawnej,
te same ID pojawiają się we wszystkich typach eksportów: sprzedaży, zakupów, płatności, magazynu.
Dzięki temu księgowy może np. łatwo wykryć, że dokument o ID 123 już raz był importowany, więc powtórny import to błąd lub korekta.
Mapowanie kont księgowych
Najważniejszy etap mapowania to przełożenie logiki ERP na konta, którymi operuje biuro. Jeżeli firma prowadzi własną ewidencję zarządczą, plan kont w ERP może różnić się od planu kont w programie księgowym. Wtedy powstaje potrzeba dwustopniowego mapowania.
Dobrą praktyką jest wprowadzanie w ERP dodatkowego pola:
konto księgowe biura – odrębnego od konta zarządczego używanego wewnętrznie,
ewentualnie grupy kont, jeśli biuro chce księgować bardziej agregacyjnie.
W mniejszych wdrożeniach wystarczy, że na poziomie kartoteki towaru, usługi, kontrahenta czy dokumentu zdefiniowane są konta „księgowe”, uzupełnione wspólnie z biurem. W bardziej złożonych systemach tworzy się tabelę mapowań: konto ERP → konto programu księgowego. Tabelę tę najlepiej trzymać w jednym miejscu i eksportować razem ze słownikami.
Mapowanie stawek i rejestrów VAT
Różne systemy inaczej nazywają i grupują stawki VAT. Jeden ma kody „A, B, C”, drugi „23, 8, zw”. Żeby uniknąć błędów, wystarczy jedna wspólna tabela powiązań. Bez niej każda zmiana stawki kończy się zgadywaniem podczas importu.
Przy tworzeniu takiej tabeli przydaje się prosty układ:
kod VAT w ERP,
opis stawki (np. 23% kraj, 0% WDT, zw. zdrowotna),
Jeśli biuro wymaga dodatkowych oznaczeń (np. GTU, procedury szczególne), do tabeli można dodać kolejne kolumny. Później ERP na podstawie tego słownika ustawia poprawne flagi w eksporcie, zamiast liczyć na pamięć użytkowników.
Mapowanie kontrahentów i grup odbiorców
Kiedy firma ma setki lub tysiące kontrahentów, powiązanie ich między ERP a programem księgowym staje się wyzwaniem. Nazwy mogą się różnić, mogą dojść przejęcia, zmiany form prawnych. Kluczem jest konsekwentne używanie jednego identyfikatora z ERP jako nadrzędnego.
Praktyczna ścieżka:
eksport aktualnej listy kontrahentów z ERP z numerem NIP, nazwą, krajem i ID technicznym,
zaimportowanie tej listy do programu księgowego lub przynajmniej stworzenie słownika powiązań,
uzgodnienie, że wszelkie nowe kartoteki powstają najpierw w ERP, a dopiero potem w księgowości.
Jeżeli firma pracuje z dużymi sieciami, grupami kapitałowymi czy marketplace’ami, przydaje się dodatkowe mapowanie na „grupy kontrahentów” (np. „Sieć X”, „Marketplace Y”). Księgowy może wtedy łatwiej analizować sprzedaż i rozrachunki na poziomie grup, nawet jeśli w ERP istnieje dziesiątki podmiotów szczegółowych.
Mapowanie centrów kosztów i projektów
Gdy zarząd oczekuje raportowania w układzie projektów lub centrów kosztów, a biuro rachunkowe prowadzi klasyczną księgowość finansową, pojawia się pytanie, gdzie przypisywać te informacje. Najprościej – już w ERP, na poziomie dokumentu lub pozycji.
Sprawdzony model:
w ERP definiuje się słownik centrów kosztów i projektów z krótkimi, jednoznacznymi kodami,
te same kody są wykorzystywane w programie księgowym jako analityka do kont kosztowych,
każda faktura kosztowa w ERP ma obowiązkowe pole „centrum kosztów” lub „projekt”.
W eksporcie pojawia się wtedy dodatkowa kolumna z kodem centrum/projektu. Biuro księguje dokumenty na odpowiednie konta, a analityka kosztowa pozostaje spójna między systemami. Bez takiego mapowania kończy się na ręcznym rozbijaniu faktur w księdze, często już bez zgodności z tym, jak dokument był traktowany operacyjnie w ERP.
Radzenie sobie z elementami „nieprzekładalnymi”
Nie wszystko, co istnieje w ERP, da się sensownie odzwierciedlić w programie księgowym biura. Dotyczy to np. bardzo szczegółowych cech towarów, rozbudowanych drzew struktur produktów czy procesów produkcyjnych. Ważne, aby jasno rozgraniczyć, co jest elementem zarządczym, a co księgowym.
Praktyczne podejście:
razem z księgowym przejść po głównych modułach ERP i zaznaczyć pola „konieczne do eksportu” oraz „tylko na potrzeby zarządcze”,
dla elementów, których nie da się bezpośrednio zmapować (np. kilkustopniowe zlecenia produkcyjne), przygotować uproszczony eksport na poziomie efektu finansowego (koszt produkcji, rozchód magazynowy),
gdy czegoś nie da się wprost odwzorować w księgach, zachować to w ERP jako dokumentację pomocniczą, a do księgowości przekazywać tylko niezbędne agregaty.
Takie podejście mocno ogranicza przypadki, w których biuro dostaje plik „przeładowany” danymi, ale bez jasnej informacji, co z czym powiązać i które pola w ogóle brać pod uwagę przy księgowaniu.
Najczęściej zadawane pytania (FAQ)
Jakie dane muszą znaleźć się w eksporcie z ERP dla biura rachunkowego?
Minimum to kompletne dokumenty sprzedaży i zakupu za dany okres, z poprawnymi datami (wystawienia, sprzedaży, księgową), stawkami VAT, kwotami netto/brutto, walutą i kontrahentem (nazwa, NIP, kraj). Do tego dochodzą podstawowe dane o płatnościach: forma płatności, termin, ewentualnie numer wyciągu lub raportu kasowego.
Przy pełnej księgowości dochodzą dodatkowo: dokumenty magazynowe (WZ, PZ, RW, PW, MM, inwentaryzacje) oraz dane o rozrachunkach – powiązania faktur z płatnościami, salda należności i zobowiązań. Bez tych informacji księgowy nie ustali realnego wyniku finansowego ani nie zamknie poprawnie miesiąca.
Jaki format eksportu z ERP jest najlepszy dla księgowości: CSV, XLSX czy PDF?
Dla automatycznego importu do programu księgowego najlepsze są pliki strukturalne: CSV lub XLSX. Kluczowa jest tu powtarzalność: te same kolumny, nazwy pól, kolejność i kody VAT przy każdym eksporcie. Na takich plikach można zbudować stałe schematy importu i ograniczyć ręczne poprawki.
PDF sprawdza się tylko jako materiał pomocniczy lub archiwalny (np. rejestr VAT, podgląd dokumentów). Na pliku PDF nie zautomatyzujesz księgowania – księgowy musi przepisywać dane ręcznie, co podnosi koszt obsługi i zwiększa ryzyko błędów.
Dlaczego biuro rachunkowe potrzebuje eksportów z ERP, skoro ma dostęp tylko do odczytu?
Dostęp „read only” do ERP ułatwia weryfikację, ale nie zastąpi eksportów. Księgowy musi mieć plik, który można zarchiwizować i pokazać przy ewentualnej kontroli – to on jest dowodem, na podstawie czego zaksięgowano podatek za konkretny miesiąc.
Eksport zapewnia też powtarzalność: ten sam układ danych co miesiąc, możliwość odtworzenia stanu na dany dzień oraz porównania wersji po korektach. Dostęp do ERP może się skończyć po zakończeniu współpracy, a pliki z eksportami i tak muszą być dostępne przez lata.
Czym różni się raport zarządczy od eksportu danych dla księgowości?
Raport zarządczy jest pod decyzje biznesowe: pokazuje marżę, wyniki handlowców, sprzedaż wg kanałów, często w formie zagregowanej (miesiące, kategorie produktów, grupy klientów). Taki raport może pomijać korekty, dokumenty wewnętrzne czy szczegóły podatkowe.
Eksport dla księgowości musi być technicznie kompletny: każda faktura osobno, poprawna klasyfikacja VAT, daty księgowe, waluty i kursy, powiązanie z rozrachunkami oraz zgodność z planem kont. Raport, który „ładnie wygląda” w Excelu dla zarządu, bez tych danych często jest bezużyteczny dla programu księgowego.
Jakie błędy w eksporcie z ERP najczęściej generują dodatkową pracę w biurze rachunkowym?
W praktyce najwięcej problemów powodują: niekompletne zakresy (brak faktur z końcówki miesiąca), brakujące lub błędne NIP-y, złe stawki VAT, brak korekt w eksporcie oraz brak powiązania płatności z fakturami. Każdy taki brak to telefony, maile i ręczne dopisywanie danych.
Częstym błędem jest też zmienianie struktury pliku „po cichu” – usunięcie lub zmiana nazwy kolumny, inny format daty, nowe typy dokumentów bez uzgodnienia. To zwykle wywraca wcześniej skonfigurowane schematy importu i wymaga od księgowego budowania ich od zera.
Czy zawsze trzeba eksportować pozycje dokumentów, czy wystarczą nagłówki faktur?
Przy prostych działalnościach (usługi, abonamenty, najem) często wystarczą same nagłówki faktur: kontrahent, daty, kwoty, stawki VAT, forma płatności. W wielu systemach księgowych rejestry VAT działają właśnie na poziomie nagłówków, z sumami VAT po stawkach.
Poziom pozycji jest potrzebny, gdy firma prowadzi rozbudowaną analitykę: MPK, projekty, centra kosztów, analizy marży na poziomie towaru, e-commerce z tysiącami linii. Dobrym kompromisem bywa model: rejestry VAT po nagłówkach, a osobny raport magazynowy lub sprzedażowy już po pozycjach dla potrzeb analiz i rozliczeń.
Jak ustalić z biurem rachunkowym standard eksportu z ERP, żeby uniknąć problemów?
Najlepiej zrobić krótką, techniczną checklistę wspólnie z księgowym. Powinna obejmować: zakres dokumentów (sprzedaż, zakup, magazyn, wyciągi, kasa), poziom szczegółowości (nagłówki vs pozycje), wymagane kolumny (daty, kwoty, VAT, waluty, kontrahenci), kody VAT i typy dokumentów oraz format pliku (CSV/XLSX) i sposób nazewnictwa.
Dobrym krokiem jest też testowy eksport za 1 miesiąc i próba importu po stronie biura rachunkowego. Po takim „pilocie” zwykle wychodzą wszystkie braki i niejasności, które można poprawić, zanim wejdzie się w stały, comiesięczny rytm wysyłki danych.
Co warto zapamiętać
Biuro rachunkowe zwykle nie pracuje bezpośrednio w ERP klienta, więc eksporty (JPK, CSV/XLSX, PDF) stają się jedynym źródłem prawdy o zdarzeniach gospodarczych i muszą być kompletne oraz spójne.
Stały, niezmienny format eksportu (te same kolumny, nazwy pól, kody VAT, typy dokumentów) jest warunkiem sensownej automatyzacji importu do programów księgowych; bez tego księgowi wracają do ręcznego księgowania.
Dostęp „tylko do odczytu” do ERP nie zastępuje plików eksportowych, bo księgowy potrzebuje namaczanego śladu audytowego, materiału do archiwizacji oraz powtarzalnych plików, do których można wrócić po latach lub przy kontroli.
Raporty zarządcze i raporty księgowe to dwa różne produkty: zarząd potrzebuje agregacji, marż i estetyki, a księgowość – danych szczegółowych, technicznych i zgodnych z przepisami; jeden raport rzadko sensownie obsługuje oba cele.
Braki i błędy w eksporcie (brak faktur, puste NIP-y, złe stawki VAT, niepowiązane płatności, pominięte korekty) generują lawinę pytań, wydłużają zamknięcie miesiąca, podnoszą cenę obsługi i ryzyko błędów podatkowych.
Ułożone, powtarzalne eksporty z ERP skracają czas pracy biura rachunkowego, stabilizują koszt księgowości, a przy okazji poprawiają relację z biurem – księgowy mniej „gasi pożary”, więcej czasu ma na merytoryczne wsparcie.
Źródła
Ustawa z dnia 29 września 1994 r. o rachunkowości. Sejm Rzeczypospolitej Polskiej (1994) – Podstawowe wymogi ewidencji, dowodów księgowych, archiwizacji danych
Ustawa z dnia 11 marca 2004 r. o podatku od towarów i usług. Sejm Rzeczypospolitej Polskiej (2004) – Zasady VAT, rejestry sprzedaży i zakupu, korekty, obowiązek podatkowy
Rozporządzenie w sprawie prowadzenia podatkowej księgi przychodów i rozchodów. Minister Finansów – Wymogi ewidencji uproszczonej, dokumenty źródłowe, kompletność zapisów
Jednolity Plik Kontrolny JPK_VAT – struktury logiczne i objaśnienia. Ministerstwo Finansów – Zakres danych w JPK, pola obowiązkowe, standard wymiany danych z ERP
Krajowy Standard Rachunkowości nr 7: Zmiany zasad rachunkowości, korekty błędów. Komitet Standardów Rachunkowości – Korekty zapisów, znaczenie kompletności danych dla sprawozdań
Międzynarodowy Standard Rachunkowości 1 – Prezentacja sprawozdań finansowych. Rada Międzynarodowych Standardów Rachunkowości – Wymogi rzetelności, kompletności i porównywalności informacji finansowych
