Łączenie PrestaShop z programem księgowym: Xero, QuickBooks i inne

Ostatnia aktualizacja: czerwiec 2026. Zasady OSS aktualne dla unijnych przepisów obowiązujących po 2021 roku; ścieżki w panelu administracyjnym zweryfikowane dla PrestaShop 1.7, 8.x i 9.x. Zawsze potwierdź sposób rozliczania podatków z własnym księgowym.

To rozróżnienie decyduje o tym, jak bolesne będzie zamknięcie miesiąca: PrestaShop to system, który przyjmuje pieniądze, a program księgowy to system, który musi wyjaśnić te pieniądze przed urzędem skarbowym. To nie jest ta sama praca. Sklep zapisuje zamówienie z klientem, przewoźnikiem, metodą płatności i koszykiem produktów. Księgowy potrzebuje kolejno numerowanej faktury, konta przychodów, kodu podatkowego oraz noty korygującej dla każdego zwrotu, w formacie, który zgadza się co do centa. Połączenie tych dwóch światów polega na przetłumaczeniu jednego modelu na drugi. Jeśli zrobisz to dobrze, księgi zamkną się same; jeśli źle, będziesz ręcznie uzgadniać VAT o 23:00 ostatniego dnia kwartału.

Ten poradnik dotyczy konkretnie podłączenia PrestaShop do programu księgowego, Xero, QuickBooks i podobnych narzędzi, tak aby zamówienia zamieniały się w poprawne, audytowalne faktury bez przepisywania danych. Nie chodzi tu o łączenie PrestaShop z pełnym systemem ERP do obsługi stanów magazynowych i zakupów (to inny problem o innym kształcie, zobacz łączenie PrestaShop z systemem ERP oraz, w kontekście pytania „kiedy go potrzebuję”, kiedy Twój sklep wyrasta z pracy ręcznej). Tutaj zakres jest księgowy: faktury, podatki, zwroty, prowizje i liczby, pod którymi podpisuje się Twój księgowy.

Co naprawdę musi przepływać z PrestaShop do ksiąg

Zanim wybierzesz narzędzie, ustal jasno, jakie dane ma przenosić połączenie. PrestaShop już generuje większość z nich. Zadaniem integracji jest przypisanie każdego elementu do właściwego miejsca w planie kont, a nie odtwarzanie go od zera. Istotne obiekty znajdują się w dobrze zdefiniowanych tabelach PrestaShop, a znajomość ich nazw od razu pokazuje, co integracja odczytuje:

• Faktura, nie zamówienie. Zamówienie PrestaShop (ps_orders) nie jest jeszcze dokumentem księgowym. Faktura to osobny obiekt (OrderInvoice / ps_order_invoice) generowany, gdy zamówienie osiąga status fakturowania, i ma własny numer. Księgi interesuje faktura. Synchronizuj zamówienia bez faktury, a utworzysz przychód, który prawnie jeszcze nie istnieje.
• Podatek rozbity według stawek. PrestaShop przechowuje podatek na poziomie pozycji i faktury (ps_order_detail_tax, ps_order_invoice_tax). Jedno zamówienie może obejmować dwie lub trzy różne stawki VAT, towary ze stawką podstawową, towary ze stawką obniżoną, wysyłkę ze stawką 0%. Integracja musi zachować ten podział, a nie tylko pojedynczą sumę.
• Zwroty i anulowania jako noty korygujące. Zwrot w PrestaShop to korekta (OrderSlip / ps_order_slip) z własnym kolejnym numerem. W programie księgowym musi trafić jako nota korygująca do pierwotnej faktury, nie jako ujemna sprzedaż i nigdy jako ciche usunięcie.
• Płatność kontra faktura. To, co klient zapłacił (ps_order_payment), i to, co zafakturowano, to dwa różne zdarzenia. Oznaczenie faktury jako „opłaconej” w księgach powinno wynikać z rekordu płatności, aby gotówka i przychody uzgadniały się osobno.
• Prowizje bramek i wysyłka. Stripe i PayPal pobierają swoją część, zanim pieniądze trafią na konto; przychód z wysyłki (to, co zapłacił klient) i koszt wysyłki (to, co zapłaciłeś przewoźnikowi) to dwie różne pozycje. Nic z tego nie jest widoczne w naiwnym schemacie synchronizacji „suma zamówienia → przychód”.

Co z tego wynika? Jeśli potrafisz nazwać tych pięć przepływów, możesz ocenić dowolny łącznik w pięć minut, po prostu pytasz, które z nich obsługuje, a które po cichu pomija.

Decyzja przed wyborem narzędzia: kto nadaje numer faktury?

To jedna decyzja, która kształtuje każdą integrację księgową, a większość poradników ją pomija. W niemal każdej jurysdykcji faktury sprzedaży i noty korygujące muszą być kolejne i unikalne, a w niektórych krajach sekwencja musi być bez luk albo każda luka musi być wyjaśnialna i audytowalna. Pytanie brzmi: który system jest źródłem prawdy dla tej numeracji.

Jeśli PrestaShop odpowiada za numerację, natywna sekwencja jest konfigurowalna, ale mało elastyczna, a niewyjaśniona luka (anulowana lub brakująca faktura, ręczna zmiana w bazie danych, nieudana migracja albo źle skonfigurowany reset sekwencji) to dokładnie ten rodzaj rzeczy, który audytor oznacza jako problem. Dwa nasze moduły powstały właśnie dla tego punktu kontroli: Invoice Number i Order Number pozwalają ustawić prefiks, wartość początkową i format, aby dokumenty PrestaShop trzymały bezlukową, roczną sekwencję numeracji oczekiwaną przez księgowego, zamiast walczyć z domyślnym zachowaniem rdzenia. Korzyść jest wąska, ale realna: dokument pobierany przez klienta i dokument księgowany przez księgowego mają ten sam, prawnie poprawny numer, więc uzgodnienie jest wyszukaniem, a nie dochodzeniem.

Xero

Xero to częsty wybór dla sklepów z Wielkiej Brytanii i Europy, i zasłużenie: dobrze udokumentowane API, natywna obsługa wielu walut oraz obsługa VAT, która sprawdza się w sprzedaży transgranicznej. W przypadku PrestaShop połączenie niemal zawsze jest pośrednie, usługa pośrednicząca albo dedykowany moduł odczytuje zafakturowane zamówienia i tworzy odpowiadające im faktury Xero, ponieważ Xero nie ma własnej natywnej wtyczki do PrestaShop.

Cztery rzeczy, które naprawdę decydują o poprawności połączenia z Xero:

• Mapowanie planu kont. Kategorie (albo produkty) z PrestaShop muszą mapować się na konta przychodów w Xero. Sklep sprzedający towary fizyczne i pliki cyfrowe zwykle chce mieć je na osobnych kontach, zdecyduj o mapowaniu przed pierwszą synchronizacją, bo przemapywanie po tysiącach faktur jest wyjątkowo niewdzięczne.
• Mapowanie stawek podatku. Reguła podatku w PrestaShop (Panel administracyjny → Międzynarodowe → Podatki → Reguły podatków) nie jest tym samym obiektem co stawka podatku w Xero. Każdą z nich mapujesz jawnie: PrestaShop „FR Standard 20%” do odpowiadającej jej stawki w Xero i tak dalej dla każdego kraju, do którego sprzedajesz. Pominiesz jedną, a sprzedaż z tego kraju zostanie zaksięgowana z błędnym podatkiem, albo bez podatku.
• Status płatności. Faktura powinna być oznaczona jako opłacona w Xero dopiero wtedy, gdy PrestaShop potwierdzi płatność. Opieraj to na opłaconym statusie zamówienia, nie na samym utworzeniu faktury, inaczej stan gotówki będzie zawyżony.
• Wiele walut. Jeśli sprzedajesz w GBP, EUR i USD, pozwól Xero odpowiadać za kursy wymiany i księguj faktury w walucie sprzedaży. Nie przeliczaj ich wcześniej w integracji, stracisz ślad audytowy pierwotnej kwoty w oryginalnej walucie.

Najczęstszy błąd przy Xero to synchronizowanie zbyt wielu danych. Zacznij od wyłącznie zafakturowanych i opłaconych zamówień. Zamówienia robocze, porzucone koszyki i oczekujące płatności nie mają czego szukać w księgach, dopóki pieniądze nie zmienią właściciela.

QuickBooks Online

QuickBooks Online jest popularny wśród sprzedawców z USA i bywa użyteczny także w części europejskich konfiguracji, z dojrzałym ekosystemem łączników, większość platform pośredniczących obsługuje go od ręki. To, czy rzeczywiście pasuje do europejskiego sklepu, zależy od lokalnych wymagań podatkowych i e-fakturowania, więc sprawdź je przed decyzją. Trudność dla sprzedawców transgranicznych polega na tym, że QuickBooks modeluje amerykański podatek od sprzedaży (zależny od miejsca dostawy, na poziomie stanu/hrabstwa) zupełnie inaczej niż VAT (UE). Jeśli sprzedajesz w obu modelach, integracja musi utworzyć właściwy wpis podatkowy na podstawie lokalizacji klienta, zamówienie z USA dostaje linię podatku od sprzedaży, zamówienie z UE dostaje linię VAT, i ta logika znajduje się w łączniku, nie w QuickBooks.

Praktyczna konfiguracja, która się opłaca:

• Używaj klas albo lokalizacji. Jeśli prowadzisz więcej niż jeden sklep PrestaShop (na przykład osobny sklep dla każdego kraju), klasy QuickBooks pozwalają utrzymać przychody każdego sklepu oddzielnie w rachunku zysków i strat bez tworzenia drugiego pliku QuickBooks.
• Przetwarzaj partiami, nie strumieniowo. Synchronizacja w czasie rzeczywistym brzmi atrakcyjnie; dzienna albo godzinowa paczka jest bardziej niezawodna i dużo łatwiejsza do debugowania, gdy jedna faktura się nie powiedzie. Lepiej znaleźć problem w partii 40 dokumentów niż śledzić go w żywym strumieniu.
• Ustal szczegółowość produktów. Czy każdy produkt PrestaShop ma stać się pozycją QuickBooks, czy agregujesz przychód według kategorii? Poziom produktu daje raportowanie produktowe i znacznie większą listę pozycji do utrzymania; poziom kategorii utrzymuje QuickBooks w lżejszej formie. Większość sklepów jest bardziej zadowolona z agregacji.
• Odwzoruj korekty jako noty korygujące. Korekta z PrestaShop powinna utworzyć notę korygującą w QuickBooks do pierwotnej faktury, ta sama kwota, to samo traktowanie podatku.

Inne platformy, i dlaczego decyduje Twój kraj

Xero i QuickBooks dominują w anglojęzycznych rozmowach, ale właściwym narzędziem zwykle jest to, którego oczekują lokalny księgowy i urząd skarbowy. Podejście do integracji zmienia się odpowiednio:

• Sage, od dawna obecny w Wielkiej Brytanii i Francji, popularny w większych firmach; sposób integracji zależy od konkretnego produktu Sage, od łączników API (Sage Business Cloud, Intacct) po usługi pośredniczące i zaplanowane eksporty.
• Datev, faktyczny standard w Niemczech, ponieważ większość niemieckich doradców podatkowych (Steuerberater) pracuje właśnie w nim. Rzadko chcą API; chcą eksportu zgodnego z Datev, który mogą zaimportować. Dla takich księgowych czysty proces CSV/eksportu jest lepszy niż dowolny łącznik działający w czasie rzeczywistym.
• Fakturownia / inFakt / wFirma, polskie platformy fakturowe i podatkowe. Polskie zasady numeracji i raportowania JPK są rygorystyczne, co sprawia, że opisana wyżej decyzja „kto jest właścicielem numeru faktury” ma tu szczególnie duże znaczenie.
• Fattura24 / Aruba, Włochy wymagają fakturowania elektronicznego (fatturazione elettronica) przez system wymiany SDI. Te platformy obsługują wysyłkę do SDI; zadaniem integracji PrestaShop jest przekazać im poprawnie ustrukturyzowaną fakturę, a nie komunikować się bezpośrednio z SDI.
• Narzędzia typu FreshBooks / Debitoor, prostsze fakturowanie dla mikrofirm i freelancerów, zwykle zasilane eksportem, a nie głęboką integracją.

Dla każdej platformy bez gotowego łącznika integracja niemal zawsze sprowadza się do ustrukturyzowanego eksportu, który program księgowy (albo księgowy) importuje według harmonogramu. To nie jest gorsze rozwiązanie. W procesie Datev albo Fattura24 jest dokładnie tym, czego oczekuje strona odbierająca.

Co faktycznie zawiera plik eksportu księgowego

Jeśli wybierasz ścieżkę eksportu (Datev, JPK, „po prostu wyślij mi CSV”), warto wiedzieć, jakich kolumn oczekuje strona odbierająca, bo czysty nagłówek to większość sukcesu. Import księgowego nie chce widoku zamówienia ze sklepu, chce wierszy na poziomie faktury z podatkiem rozbitym według stawek. Działający nagłówek CSV dla eksportu faktur sprzedaży wygląda tak:

invoice_number,invoice_date,order_reference,customer_name,customer_vat_number,country,currency,net_amount,tax_rate,tax_amount,gross_amount,payment_method,document_type
INV-2026-000412,2026-06-18,XKBKTSXPM,"ACME GmbH",DE811234567,DE,EUR,200.00,0.00,0.00,200.00,bankwire,invoice
INV-2026-000412,2026-06-18,XKBKTSXPM,"ACME GmbH",DE811234567,DE,EUR,50.00,19.00,9.50,59.50,bankwire,invoice
CN-2026-000031,2026-06-20,XKBKTSXPM,"ACME GmbH",DE811234567,DE,EUR,-50.00,19.00,-9.50,-59.50,bankwire,credit_note

Dwie rzeczy są tu ważne: każda stawka podatku dostaje własny wiersz (więc faktura z wieloma stawkami zajmuje kilka linii, które sumują się do wartości dokumentu), a zwrot pojawia się jako credit_note z ujemnymi kwotami powiązanymi z pierwotnym order_reference, nigdy jako usunięty albo edytowany wiersz faktury. Przed pierwszym uruchomieniem potwierdź z księgowym dokładne nazwy kolumn i format daty; Datev i JPK mają własne wymagane układy, ale kształt, jeden wiersz na stawkę, noty korygujące jako wartości ujemne, pozostaje stały.

Dwie drogi do ksiąg: natywny moduł kontra usługa pośrednicząca

Gdy wiesz już, co musi przepływać i kto odpowiada za numerację, istnieją dwie realistyczne metody faktycznego przenoszenia danych. Nie wykluczają się wzajemnie, wiele sklepów używa modułu do faktur i łącznika pośredniczącego dla konkretnej platformy, ale warto jasno zobaczyć kompromis.

Po stronie modułów nasz moduł Financial Revolution obsługuje generowanie faktur, numerację i eksport w formatach, które może przyjąć Twoja platforma księgowa. Gdy efektem ma być czysty plik według harmonogramu, przypadek Datev albo JPK, Invoice CSV List Exporter pobiera faktury oraz dane podatkowe według stawek, które importuje księgowy, a Orders CSV List Exporter obejmuje surową stronę zamówień, gdy tego oczekuje system odbierający. Praktyczny efekt: możesz uruchomić dokładny strumień danych księgowych z panelu administracyjnego, bez cyklicznego rachunku za usługę pośredniczącą i bez opuszczania serwera przez dane zamówień. Co często jest decydujące w procesie Datev albo JPK, gdzie księgowy chce po prostu czystego pliku według harmonogramu. (A jeśli ten harmonogram ma działać bez ręcznej obsługi, Cron Manager uruchamia i zapisuje cykliczny eksport, dzięki czemu pominięte uruchomienie jest widoczne, a nie ciche.)

Usługa pośrednicząca uzasadnia swoją subskrypcję wtedy, gdy chcesz konkretnie synchronizacji na żywo i bez ręcznej obsługi z Xero albo QuickBooks oraz cenisz wbudowane ponowienia, logowanie i wstępnie zmapowane łączniki. Jeśli powodem sięgania po Zapier albo Make jest szersza automatyzacja sklepu, a nie sama księga, to inny temat, mechanikę budowania takich procesów omawiamy w Zapier i Make dla PrestaShop, a podejście bez kodowania w automatyzacji procesów bez pisania kodu.

Transgraniczny VAT: część, która zmienia zadanie księgowe w prawne

Jeśli sprzedajesz przez granice w UE, VAT jest miejscem, w którym integracja księgowa przestaje być wygodą, a zaczyna być zgodnością z przepisami. PrestaShop zapisuje surowe fakty; księgi muszą je poprawnie zaraportować.

• OSS (One-Stop Shop). Od lipca 2021 roku sklep z UE może rozliczać VAT dla wszystkich państw członkowskich w jednej deklaracji OSS, ale tylko wtedy, gdy Twoje rekordy wiedzą, stawka którego kraju została zastosowana do każdej sprzedaży. PrestaShop już zapisuje kraj docelowy i zastosowaną regułę podatku na fakturze; integracja musi przenieść ten wymiar kraju do ksiąg, inaczej deklaracja OSS staje się zgadywaniem.
• Odwrotne obciążenie B2B. Sprzedajesz firmie z ważnym unijnym numerem VAT i nie naliczasz VAT, nabywca rozlicza go sam. Oznacza to, że integracja musi zaksięgować sprzedaż jako odwrotne obciążenie, a nie sprzedaż z zerowym VAT, bo dla urzędu skarbowego to różne rzeczy. Warunkiem jest walidacja numeru w momencie zamówienia; nasz Automatic EU VAT Checker sprawdza numery VAT w VIES w czasie rzeczywistym, dzięki czemu zamówienie jest poprawnie oznaczone, zanim trafi do ksiąg.
• Eksport poza UE. Sprzedaż poza UE zwykle ma stawkę 0%, ale nadal musi pojawić się w księgach jako eksport, obecna, nie niewidoczna.

Zasada praktyczna: uporządkuj transgraniczny VAT zanim zwiększysz wolumen. Błędne mapowanie podatku to drobna irytacja przy 30 zamówieniach miesięcznie i pięciocyfrowa korekta przy 3000.

Pułapki, które gryzą każdą integrację księgową

Niezależnie od wybranego narzędzia, powtarza się kilka tych samych błędów. Zaprojektowanie ochrony przed nimi od początku jest tańsze niż odkrycie ich na koniec roku:

• Zduplikowane faktury. Klasyk. Synchronizacja uruchomiona dwa razy albo ponowiona po przekroczeniu limitu czasu może zaksięgować tę samą fakturę dwukrotnie. Rozwiązaniem jest klucz idempotencji, prawie zawsze ID zamówienia albo faktury z PrestaShop, dzięki któremu strona księgowa rozpoznaje powtórkę i ją pomija.
• Rozjazd zaokrągleń. PrestaShop i program księgowy mogą inaczej zaokrąglać podatek: według pozycji albo według sumy. Różnica jednego centa na jednym zamówieniu to szum; przy tysiącach zamówień zamienia się w uzgodnienie, które nigdy do końca się nie bilansuje. Ustal zasadę zaokrągleń raz i spraw, aby oba systemy ją stosowały (tryb i typ zaokrągleń w PrestaShop znajdują się w Parametry sklepu → Ogólne).
• Niezgodność walut. Klient płaci w GBP, księgi prowadzisz w EUR, wpis potrzebuje zarówno kwoty w oryginalnej walucie, jak i kwoty przeliczonej po właściwym kursie, inaczej raportowanie walut obcych jest fikcją.
• Zapomniane prowizje bramek. Procent pobierany przez operatora płatności nie jest rabatem od przychodu, jest kosztem. Zapisuj sprzedaż brutto i prowizję osobno, inaczej marże będą wyglądały lepiej niż w rzeczywistości, a saldo bankowe się nie uzgodni.
• Zwroty, które znikają. Najczęstsze miejsce, w którym psuje się proces ręczny, to zwroty. Jeśli korekty nie przepływają automatycznie do not korygujących, przychody są systematycznie zawyżane. Zautomatyzuj tę ścieżkę jako pierwszą, nie ostatnią.

Rozsądne wdrożenie według wielkości sklepu

Nie potrzebujesz najbardziej zaawansowanego procesu. Potrzebujesz takiego, który jest dokładny, niezawodny i oszczędza więcej czasu, niż kosztuje jego obsługa. Dopasuj wysiłek do wolumenu:

• Poniżej ~50 faktur miesięcznie: tygodniowy eksport (CSV / w stylu Datev), który importuje księgowy, naprawdę wystarczy. Nie komplikuj na siłę.
• ~50–500 miesięcznie: dzienna automatyczna synchronizacja albo zaplanowany eksport, z automatycznymi zwrotami i alertem o błędzie, aby znaleźć przerwane uruchomienie tego samego dnia, a nie przy zamknięciu miesiąca.
• 500+ miesięcznie: integracja prawie w czasie rzeczywistym z idempotencją, logami i monitoringiem, to wolumen, przy którym cichy duplikat albo pominięta nota korygująca kosztuje wystarczająco dużo, by uzasadnić pracę inżynierską.

I niezależnie od wielkości: porozmawiaj z księgowym, zanim zaczniesz budować. Zapytaj, jakiego planu kont używać, jakich kodów podatkowych oczekuje, jaki format eksportu faktycznie importuje i czy numerację faktur ma prowadzić PrestaShop, czy jego własny system. Następnie uruchom nowy proces równolegle z dotychczasowym przez pełny miesiąc i uzgodnij oba wyniki, zanim wyłączysz ręczną rezerwę. Celem nie jest sprytna integracja. Tylko koniec kwartału, w którym księgi są już zamknięte, bo każde zamówienie, zwrot i linia podatkowa zostały poprawnie przetłumaczone za pierwszym razem.

Najczęściej zadawane pytania

Czy numer faktury powinien pochodzić z PrestaShop, czy z programu księgowego?

Wybierz jeden system jako rejestr źródłowy i konsekwentnie się go trzymaj. Jeśli wystawiasz faktury widoczne dla klienta w momencie zamówienia, a sklep jest Twoim głównym rejestrem sprzedaży, PrestaShop powinien odpowiadać za numerację, ale wtedy musisz ściśle kontrolować prefiks, format i sekwencję, aby była bez luk i odporna na kontrolę (do tego służą Invoice Number i Order Number). Jeśli księgowy wymaga wystawiania wszystkich dokumentów prawnych ze swojego systemu, pozwól mu je numerować i traktuj ID zamówienia PrestaShop jako metadane, oraz wyłącz PDF dla klienta, żeby oba dokumenty ze sobą nie kolidowały.

Jak zwroty powinny trafiać do programu księgowego?

Jako noty korygujące, nigdy jako usunięte albo edytowane faktury. Korekta z PrestaShop (OrderSlip / ps_order_slip) mapuje się na notę korygującą w Xero albo QuickBooks do pierwotnej faktury, ta sama kwota, to samo traktowanie podatku, wartości ujemne. Zautomatyzuj tę ścieżkę jako pierwszą, bo ręczny proces zwrotów jest najczęstszym powodem zawyżania przychodów w księgach.

Czy potrzebuję płatnej subskrypcji usługi pośredniczącej, czy mogę po prostu eksportować plik?

Dla księgowego pracującego na eksportach, Datev w Niemczech, JPK w Polsce albo kogokolwiek, kto mówi „po prostu wyślij mi CSV”, zaplanowany eksport jest dokładnie tym, czego chce, a moduł taki jak Invoice CSV List Exporter robi to bez opłaty cyklicznej i bez opuszczania serwera przez dane zamówień. Usługa pośrednicząca (Synder, A2X) uzasadnia subskrypcję wtedy, gdy konkretnie chcesz synchronizacji API na żywo i bez ręcznej obsługi z Xero albo QuickBooks, z ponowieniami i logowaniem po stronie usługi.

Jak uniknąć podwójnego księgowania faktur, gdy synchronizacja jest ponawiana?

Użyj klucza idempotencji, prawie zawsze ID zamówienia albo faktury z PrestaShop, aby strona księgowa rozpoznawała powtórkę i ją pomijała. Bez niego każda synchronizacja uruchomiona dwa razy albo ponowiona po przekroczeniu limitu czasu może zaksięgować tę samą fakturę ponownie, a dowiesz się o tym dopiero przy uzgodnieniu. To jednolinijkowa decyzja projektowa, która zapobiega najczęstszemu błędowi integracji księgowej.

Transgraniczny VAT wygląda źle w księgach, gdzie zwykle powstaje problem?

Prawie zawsze w mapowaniu stawek podatku albo w brakującym wymiarze kraju. PrestaShop zapisuje kraj docelowy i zastosowaną regułę podatku na fakturze, ale integracja musi przenieść ten kraj do ksiąg na potrzeby raportowania OSS, księgować sprzedaż B2B dla ważnych unijnych numerów VAT jako odwrotne obciążenie (nie jako zerowy VAT) oraz traktować sprzedaż poza UE jako eksport ze stawką 0%, zamiast ją pomijać. Waliduj numery VAT w momencie zamówienia (Automatic EU VAT Checker sprawdza je w VIES), aby każde zamówienie było poprawnie oznaczone, zanim trafi do księgi.

Powiązane artykuły

• Kiedy Twój sklep wyrasta z pracy ręcznej. Decyzja, czy integracja księgowa jest pierwszym krokiem, którego potrzebujesz
• Łączenie PrestaShop z systemem ERP, część magazynowo-zakupowa, inna niż księga
• Zapier i Make dla PrestaShop, gdy powodem integracji jest szersza automatyzacja sklepu, a nie księga