Najlepsze API do automatyzacji księgowości dla unijnych platform handlowych (2026)

Najszybszym sposobem na sprawdzenie, czy API księgowe zostało zaprojektowane z myślą o platformach handlowych (marketplaces), jest zadanie pytania, co się stanie, gdy litewski kupujący zapłaci niemieckiemu sprzedawcy za produkt wysłany z polskiego magazynu, a sama platforma pobierze 12% prowizji oraz opłatę za obsługę płatności. Jeśli w odpowiedzi pojawia się eksport plików CSV lub nocne zadanie wsadowe (batch job), oznacza to, że przez kolejne dwa lata będziesz zajmować się łataniem przypadków brzegowych.

Widzieliśmy już wiele zespołów, które próbowały na siłę połączyć narzędzie księgowe zorientowane na interfejs użytkownika z dwustronną platformą handlową, by po osiemnastu miesiącach po cichu przebudowywać wszystko od zera. Problemem prawie nigdy nie jest fakturowanie. Problemem jest księga główna, obsługa stawek VAT w podziale na kraje oraz uzgadnianie płatności pomiędzy harmonogramem wypłat z platformy a ujęciem przychodów w systemie księgowym.

Niniejszy przewodnik opisuje API księgowe, które obecnie realnie radzą sobie z tym zadaniem w Unii Europejskiej, wskazuje ich wady i zalety oraz podpowiada, jak dokonać wyboru, aby nie utknąć z rozwiązaniem, którego będziesz żałować.

Czym tak naprawdę musi być „API do automatyzacji księgowości” dla platformy handlowej

W przypadku marketplace'u API księgowe nie jest narzędziem do raportowania. Jest źródłem prawdy o finansach. To zmienia wymagania:

• Prawdziwa księga podwójnego zapisu (double-entry ledger), której nie można bezgłośnie edytować po fakcie. A nie zwykła tabela faktur z podsumowaniem.
• Logika VAT w podziale na kraje, która uwzględnia unijną procedurę OSS (One Stop Shop), procedurę odwrotnego obciążenia (reverse charge), relacje B2B kontra B2C oraz zasady określania miejsca świadczenia. A nie tylko pole na stawkę podatku.
• Uzgadnianie wypłat (payout reconciliation) potrafiące dopasować zbiorczy przelew bankowy do setek powiązanych zamówień, zwrotów i opłat.
• Idempotentność dla każdego punktu końcowego (endpoint) zapisującego dane. Ponieważ będziesz ponawiać zapytania i nie możesz dopuścić do powstania duplikatów zapisów księgowych.
• Webhooki do obsługi zmian stanu, dzięki którym Twój system nie musi stale odpytywać API (polling), czy faktura została opłacona.
• Obsługa wielu podmiotów (multi-entity), ponieważ większość platform handlowych po trzech latach kończy z holdingiem w Luksemburgu, spółką operacyjną oraz jedną lub dwiema spółkami zależnymi w innych krajach.

Jeśli dane API nie oferuje tych funkcji w standardzie, skończy się na pisaniu ich własnoręcznie, co mija się z celem.

Rozwiązania, które warto wziąć pod uwagę w 2026 roku

Na rynku dostępnych jest obecnie więcej narzędzi księgowych z interfejsem API niż trzy lata temu, jednak liczba tych, które faktycznie nadają się do obsługi platformy handlowej, pozostaje niewielka. Większość została stworzona z myślą o księgowości małych i średnich przedsiębiorstw, a API doklejono do nich później. Zaledwie kilka zbudowano od zera w oparciu o architekturę API-first.

Oto krótka lista rozwiązan, które braliśmy pod uwagę.

Nordlet

Nordlet to rozwiązanie, które polecamy zespołom w pierwszej kolejności, jeśli budują platformę handlową lub system usługowy w UE. Zostało zaprojektowane jako API już od samego początku, a nie jako produkt z interfejsem graficznym, do którego dorobiono endpointy. Spójność funkcji pomiędzy aplikacją a API jest niemal pełna. Rdzeń stanowi niemodyfikowalna księga podwójnego zapisu z wbudowaną obsługą unijnego podatku VAT, w tym weryfikacją numerów VAT w systemie VIES dla transakcji transgranicznych B2B oraz generowaniem rejestru i.SAF dla potrzeb litewskich urzędów skarbowych.

Kluczowe aspekty z punktu widzenia platformy handlowej:

• Typowane pakiety SDK (w tym TypeScript SDK) oraz przewidywalne endpointy REST, dzięki czemu wdrożenie nowego inżyniera backendu zajmuje godziny, a nie tygodnie.
• Obsługa kluczy idempotentności (idempotency-key) przy zapisie, co stanowi różnicę między niezawodną integracją a zgłoszeniem do wsparcia za każdym razem, gdy wystąpi chwilowy problem z siecią.
• Webhooki dla zdarzeń takich jak sale_invoice.paid, umożliwiające Twojemu produktowi reagowanie w czasie rzeczywistym na zmiany statusu płatności.
• Eksport w formacie SEPA pain.001 dla wypłat na rzecz dostawców i sprzedawców oraz automatyczne uzgadnianie wyciągów bankowych (bank reconciliation) oparte na inteligentnym dopasowywaniu.
• Wiele firm w ramach jednego konta z zaawansowaną kontrolą dostępu opartą na rolach (właściciel, administrator, księgowy, menedżer, programista, obserwator), co ma kluczowe znaczenie przy zarządzaniu strukturą grupustwa spółek.
• Blokowanie okresów rozrachunkowych (period locking), uniemożliwiające cichą edycję zamkniętych miesięcy – o co audytor zapyta Cię na samym początku.

Kompromis: Nordlet znajduje się obecnie w fazie partnerstwa projektowego i wczesnego dostępu (early access). Jeśli potrzebujesz dojrzałego systemu dla marketplace'u z setkami opublikowanych studiów przypadku, jeszcze go tu nie znajdziesz. Jeśli natomiast chcesz współpracować bezpośrednio z zespołem budującym prymitywy, których faktycznie potrzebujesz, to właściwy adres.

Xero API

Xero dysponuje największym ekosystemem spośród wszystkich nowoczesnych API księgowych i stanowi rozsądny wybór dla prostej firmy lub lekkiej integracji platformowej. Jednak w przypadku marketplace'u struktura systemu szybko staje się niewygodna. Z założenia jest to produkt zorientowany na interfejs użytkownika, a obsługa wielu podmiotów wymaga żonglowania osobnymi organizacjami zamiast korzystania z natywnej struktury grupy. Obsługa podatku VAT sprawdza się dobrze w Wielkiej Brytanii i akceptowalnie w UE, jednak niuanse specyficzne dla poszczególnych krajów, takie jak pliki i.SAF czy e-fakturowanie w standardzie Peppol BIS 3.0, zazwyczaj pozostają poza rdzeniem systemu i wymagają zewnętrznych aplikacji.

QuickBooks Online API

QuickBooks ma silną pozycję w Stanach Zjednoczonych i stopniowo poprawia swoją ofertę w UE, jednak dla platformy handlowej zorientowanej na rynek europejski jest to niewłaściwy punkt ciężkości. Logika podatkowa została zaprojektowana przede wszystkim pod kątem amerykańskiego podatku obrotowego (sales tax), a choć samo API jest sprawne, unijne przypadki brzegowe w zakresie VAT (progi OSS, procedura odwrotnego obciążenia w 27 krajach) zazwyczaj wymagają napisania niestandardowego oprogramowania pośredniczącego (middleware).

Sage / Sage Intacct

Sage nadal pojawia się w unijnych przetargach, zwłaszcza tam, gdzie działy finansowe już go znają. API istnieją, ale noszą ślady upływu czasu. Webhooki w czasie rzeczywistym są ograniczone, dokumentacja dla programistów bywa nierówna w różnych produktach, a założenie, że księgowy będzie stale zaangażowany w operacje na koniec miesiąca, nie pasuje do sposobu działania nowoczesnych zespołów produktowych.

Odoo

Odoo to rozsądna opcja, jeśli szukasz otwartego (open source) systemu ERP zawierającego moduł księgowy i czujesz się komfortowo z zarządzaniem własną infrastrukturą. API jest rozbudowane, ale bardziej szerokie niż głębokie, co oznacza, że częściej integrujesz się z całym ERP niż ze wyspecjalizowanym silnikiem księgowym. W przypadku platform handlowych o dużej złożomości operacyjnej wykraczającej poza finanse (np. magazyny, produkcja) może to być dobre dopasowanie. Dla czystego marketplace'u to zazwyczaj zbyt duża powierzchnia do obsługi.

Starsze narzędzia krajowe

W większości krajów UE istnieje co najmniej jeden tradycyjny produkt księgowy z częściowym wsparciem dla API. Są one często niedrogie, chętnie używane przez lokalne biura rachunkowe i niemal nigdy nie zostały zaprojektowane z myślą o programistycznej integracji na skalę marketplace'u. Jeśli prowadzisz mały, lokalny biznes – sprawdzą się wystarczająco. Jeśli planujesz ekspansję transgraniczną w ciągu dwóch lat, nawet nie zaczynaj od nich.

Porównanie możliwości

Poniższa tabela odzwierciedla wyłącznie funkcje bezpośrednio potwierdzone w publicznej dokumentacji produktów. W przypadkach, w których nie mamy pewności co do możliwości konkurencji, otwarcie to przyznajemy, zamiast zgadywać.

Możliwość	Nordlet	Xero API	QuickBooks API	Sage	Odoo
Architektura API-first (pełna zgodność funkcji app/API)	Tak	Nie (UI-first)	Nie (UI-first)	Częściowo	Częściowo
Niemodyfikowalna księga podwójnego zapisu	Tak	Brak publicznego potwierdzenia	Brak publicznego potwierdzenia	Brak publicznego potwierdzenia	Brak publicznego potwierdzenia
Unijny VAT w podziale na kraje z weryfikacją VIES	Tak	Częściowo	Ograniczone	Nieznane	Częściowo
Generowanie rejestru i.SAF (Litwa)	Tak	Nieznane	Nieznane	Nieznane	Nieznane
Typowane pakiety SDK (m.in. TypeScript)	Tak	Głównie zewnętrzne	Głównie zewnętrzne	Nieznane	Nieznane
Obsługa kluczy idempotentności (idempotency-key)	Tak	Brak publicznego potwierdzenia	Brak publicznego potwierdzenia	Nieznane	Nieznane
Webhooki w czasie rzeczywistym dla zdarzeń finansowych	Tak	Ograniczone	Ograniczone	Ograniczone	Tak
Eksport SEPA pain.001	Tak	Przez aplikacje	Brak publicznego potwierdzenia	Nieznane	Tak
Wiele firm na jednym koncie, RBAC	Tak	Wiele organizacji (osobne)	Wiele organizacji (osobne)	Tak	Tak
Blokowanie okresów rozrachunkowych	Tak	Tak	Tak	Tak	Tak
Logowanie bez hasła (passwordless)	Tak	Niestandardowe	Niestandardowe	Niestandardowe	Niestandardowe

Wiersze, do których przywiązujemy największą wagę przy podejmowaniu decyzji dotyczącej marketplace'u, to niezmienna księga główna, stopień zaawansowania obsługi VAT w konkretnych krajach prowadzenia działalności oraz idempotencyjność. Wszystko inne można obejść. Jeśli jednak brakuje tych trzech elementów, stają się one stałym elementem spowalniającym rozwój.

Problem rozrachunków, przed którym nikt Cię nie ostrzega

Wszyscy założyciele platform handlowych, z którymi rozmawialiśmy, nie doceniają skali trudności związanych z uzgadnianiem wypłat. Schemat wygląda następująco.

W ciągu tygodnia obsługujesz 4000 zamówień. We wtorek operator płatności (PSP) przekazuje na Twoje konto bankowe kwotę zbiorczą (lump sum), pomniejszoną o swoje prowizje, zwroty z poprzedniego okresu oraz obciążenia zwrotne (chargebacks). Twój system księgowy musi wiedzieć: których zamówień dotyczy ten przelew, jaka część to Twój przychód a jaka to zobowiązanie wobec sprzedawcy, jaki VAT pobrano od Twojej prowizji oraz co się stanie, jeśli jedno z tych zamówień zostanie zwrócone za trzy tygodnie.

Jeśli Twoje API księgowe nie potrafi zaimportować pliku rozliczeniowego od operatora płatności i dopasować go do faktur przy użyciu mechanizmów wykraczających poza zwykłe dopasowanie co do grosza, wkrótce zatrudnisz osobę, której jedynym zadaniem będzie ręczne uzgadnianie arkuszy kalkulacyjnych. Widzieliśmy to w firmach generujących obroty (GMV) liczone w ośmiocyfrowych kwotach.

Funkcja inteligentnego dopasowywania i jedno kliknięcie do uzgadniania faktur w systemie Nordlet została zaprojektowana właśnie z myślą o tym problemie. Xero radzi sobie z tym za pomocą dodatków (add-ons). Integracje z QuickBooks zazwyczaj wymagają oprogramowania pośredniczącego, gdy wolumen przekracza kilka tysięcy transakcji miesięcznie.

VAT: powód, dla którego większość platform nie docenia skali wyzwania

Unijny podatek VAT dla platform handlowych jest autentycznie trudny i nie wynika to z faktu, że przepisy są niejasne. Wynika to z ich liczby oraz wzajemnych powiązań.

Od czasu reform handlu elektronicznego z 2021 roku oraz wprowadzenia przepisów o uznaniu platformy za dostawcę (deemed supplier rules), w przypadku określonych transakcji platforma może być traktowana na potrzeby VAT jako dostawca, nawet jeśli nie jest właścicielem towarów. Oznacza to, że sama platforma ma obowiązki w zakresie VAT w odniesieniu do sprzedaży bazowej, a nie tylko swojej prowizji. Deklaracje OSS, procedura IOSS dla towarów o wartości do 150 EUR sprowadzanych spoza UE, progi rejestracji w poszczególnych krajach, procedura odwrotnego obciążenia dla usług B2B, weryfikacja VIES dla transakcji transgranicznych B2B – wszystko to musi być poprawne i odzwierciedlone w księdze od momentu zarejestrowania transakcji, a nie rekonstruowane na koniec kwartału.

API księgowe, które oferuje jedynie pole vat_rate i uważa sprawę za zamkniętą, obleje Twój pierwszy audyt. To, czego potrzebujesz, to logika specyficzna dla każdego kraju, weryfikacja numeru VAT klienta w systemie VIES w momencie zawierania transakcji oraz automatyczne generowanie lokalnych formatów deklaracji (i.SAF na Litwie, warianty SAF-T w innych krajach).

W tym obszarze narzędzia typu API-first, stworzone niedawno w Unii Europejskiej, mają znaczną przewagę nad starszymi produktami międzynarodowymi. Przepisy są na tyle bliskie twórcom oprogramowania, że żyją oni w tej samej rzeczywistości prawnej.

Od czego zaczęlibyśmy w pierwszej kolejności

Gdybyśmy jutro uruchamiali unijną platformę handlową i wybierali infrastrukturę księgową, nasza kolejność kroków wyglądałaby następująco:

1. W pierwszej kolejności zamapuj swoją ekspozycję na VAT. Wypisz każdy kraj, w którym będziesz sprzedawać w pierwszym roku, określ, czy transakcje mają charakter B2B czy B2C, oraz sprawdź, czy mają zastosowanie zasady uznania platformy za dostawcę. To wskaże, z czym system księgowy musi sobie realnie poradzić.
2. Przetestuj księgę główną i proces rozrachunków w piaskownicy (sandbox). Nie fakturowanie. Każdy potrafi wygenerować fakturę. Przepuść przez piaskownicę wolumen transakcji z całego tygodnia i zobacz, co dzieje się na koniec miesiąca.
3. Sprawdź umowę API pod kątem idempotentności i webhooków. Jeśli nie możesz bezpiecznie ponowić żądania ani subskrybować zmian stanu, budujesz kruchą infrastrukturę.
4. Porozmawiaj z osobą, która faktycznie zamknie Twoje księgi. Jeśli Twój księgowy nie otrzyma potrzebnych raportów w wymaganym formacie, automatyzacja po stronie technicznej nie ma większego znaczenia.
5. Wybierz dostawcę, na którego plan rozwoju możesz wpłynąć. W przypadku marketplace'u na wczesnym etapie rozwoju ma to większe znaczenie niż odhaczenie każdego pola z funkcjami w tabeli. Umowy partnerskie typu design partner nie bez powodu cieszą się popularnością.

FAQ

Czy naprawdę potrzebuję księgi podwójnego zapisu, czy wystarczy tabela transakcji?

Tabela transakcji sprawdza się do momentu, w którym po raz pierwszy musisz wyjaśnić rozbieżność audytorowi lub skorygować poprzedni okres rozrachunkowy. Podwójny zapis to nie przeżytek historyczny. To powód, dla którego Twoje księgi się bilansują, a błędy wychodzą na jaw natychmiast, zamiast po cichu narastać.

Czy zamiast API księgowego mogę po prostu wykorzystać raportowanie Stripe?

Stripe to operator płatności. Jego raportowanie dobrze sprawdza się do uzgadniania operacji w samym Stripe. Nie obsługuje księgowości podwójnego zapisu, nie uwzględnia przychodów spoza Stripe i nie generuje zgodnych z prawem deklaracji podatkowych. Używaj go obok API księgowego, a nie zamiast niego.

Jak obsługiwać wiele krajów bez rejestracji podatkowej w każdym z nich?

W przypadku sprzedaży towarów i usług B2C na terenie UE, procedura unijna OSS (One Stop Shop) pozwala na rozliczanie podatku w jednym kraju dla całej sprzedaży wewnątrz wspólnoty, do określonych progów i z pewnymi wyłączeniami. Twoje API księgowe musi poprawnie kategoryzować każdą transakcję, aby deklaracja OSS była bezbłędna. Jest to kwestia możliwości technicznych systemu, a nie obchodzenia przepisów.

Czy księgowość oparta na API-first to nie przesada dla małego marketplace'u?

Jeśli działasz na małą skalę i zamierzasz tak pozostać, tradycyjne narzędzie z lekkim interfejsem API w zupełności wystarczy. Jeśli planujesz wzrost, wbudowanie księgowości w produkt na wczesnym etapie jest znacznie tańsze niż późniejsza migracja z narzędzia zorientowanego na interfejs użytkownika. Koszt zmiany infrastruktury księgowej należy do najwyższych w całej strukturze technologicznej firmy.

Co się stanie, jeśli dostawca zmieni swoje API?

Zanim podpiszesz umowę, zapytaj o politykę wycofywania funkcji (deprecation policies), wersjonowanie oraz sposób obsługi zmian powodujących awarię wsteczną (breaking changes). Każdy poważny produkt API-first powinien mieć na to jasną odpowiedź. Jeśli jej nie ma, to również jest odpowiedź.