Koszty integracji księgowych: jeden projekt na każdego dostawcę

Szacunki wskazują na okres od trzech tygodni do dwunastu miesięcy dla każdego systemu księgowego, a wykonana praca nie przenosi się z jednego dostawcy na drugiego. Oto konkretne liczby, ich źródła oraz alternatywne rozwiązanie.

Platforma, która łączy się z systemami księgowymi swoich klientów, buduje osobną integrację dla każdego dostawcy. Publikowane szacunki dla pojedynczej integracji wynoszą od trzech do czterech tygodni w przypadku pierwszego działającego połączenia z QuickBooks do sześciu, a nawet dwunastu miesięcy dla NetSuite. Co ciekawe, każda odnaleziona przez nas wycena pochodzi od firmy, która sprzedaje narzędzie pozwalające tego uniknąć. Wykonana praca nie przenosi się na inne systemy: QuickBooks, Xero, NetSuite oraz Microsoft Dynamics 365 Business Central mają własne metody logowania, czas życia tokenów, składnię zapytań, limity (rate limits), opłaty oraz harmonogramy wycofywania funkcji. Sześciu dostawców oznacza więc sześć projektów i sześć budżetów na utrzymanie.

W tym artykule zebraliśmy opublikowane dane wraz z ich źródłami, pokazujemy różnice między dostawcami oraz wyjaśniamy inne wyjście: prowadzenie księgowości bezpośrednio we własnym produkcie za pomocą jednego interfejsu API księgowego, co pozwala zbudować jedną integrację zamiast osobnej dla każdego dostawcy.

Ile czasu zajmuje jedna integracja księgowego API

Nikt nie publikuje neutralnego badania dotyczącego czasu potrzebnego na zbudowanie integracji. Poniższe liczby pochodzą od firm sprzedających ujednolicone interfejsy API (unified APIs), mają więc interes w tym, aby zadanie wyglądało na skomplikowane. Niemniej są to najbardziej konkretne dostępne dane, które stają się spójne, gdy odróżni się „pierwszą działającą wersję” od wersji produkcyjnej.

Źródło	Co twierzą	Ich motywacja
Apideck (2026)	QuickBooks: „kompetentny inżynier może przygotować działające rozwiązanie w trzy do czterech tygodni”. Utrzymanie ponad 35 łączników wymaga „co najmniej jednego inżyniera oddelegowanego wyłącznie do utrzymania integracji”.	Sprzedaje ujednolicone API
Rutter (kwiecień 2026)	„Trzy miesiące pracy inżynierskiej na jedną platformę”, co Rutter określa jako konserwatywny szacunek. W przypadku NetSuite „harmonogram wydłuża się do sześciu, a nawet dwunastu miesięcy”. Jeden z klientów oszacował czas dla QuickBooks na dwóch inżynierów przez kilka miesięcy, a zajęło to „co najmniej trzy miesiące z wieloma iteracjami”.	Sprzedaje ujednolicone API
Merge	150 godzin na zbudowanie jednej integracji i 300 godzin rocznie na jej utrzymanie, przy założeniu pensji na poziomie 150 000 USD. Merge szacuje koszty na „50 000 do 150 000 USD rocznie”.	Sprzedaje ujednolicone API

W tych danych dwie rzeczy są ważniejsze niż same sumy.

Po pierwsze, przepaść między trzema tygodniami a trzema miesiącami to różnica między wersją demonstracyjną a środowiskiem produkcyjnym. Połączenie, które tworzy fakturę, zaczyna działać szybko. Połączenie, które radzi sobie z wygasaniem tokenów, zduplikowanymi webhookami, limitami zapytań, częściowymi awariami oraz klientem, który ponownie łączy inny plik firmy, pochłania pozostałą część czasu. Nasz przewodnik poświęcony integracji chmurowego API księgowego z platformą SaaS opisuje te prace krok po kroku.

Po drugie, w modelu Merge koszty utrzymania przewyższają koszt samej budowy: 300 godzin rocznie wobec 150 godzin jednorazowo. Ten koszt powtarza się co roku dla każdego wspieranego dostawcy.

Dlaczego druga integracja kosztuje tyle samo co pierwsza

Gdyby dostawcy udostępniali ten sam interfejs, druga integracja w większości wykorzystywałaby kod z pierwszej. Tak jednak nie jest. Poniższa tabela porównuje cztery popularne systemy.

	QuickBooks Online	Xero	NetSuite	Business Central
Logowanie	OAuth 2.0	OAuth 2.0	OAuth 2.0; uwierzytelnianie oparte na tokenach (token-based authentication) zostaje zamknięte dla nowych integracji od wersji 2027.1	Tylko Microsoft Entra ID OAuth
Czas życia tokenu dostępu	1 godzina	30 minut	60 minut	Określony przez Entra ID
Token odświeżania (refresh token)	Ruchome 100 dni, maksymalnie pięć lat	Ruchome 60 dni	7 dni	Określony przez Entra ID
Styl zapytań	Podobny do SQL `SELECT … FROM Invoice`, brak `OR`, brak złączeń (joins)	REST z parametrem `where`	SuiteQL (SQL) przez REST, plus SOAP do 2028 roku	OData v4
Limity zapytań (rate limits)	500 zapytań na minutę i 10 na sekundę na firmę	60 na minutę, 5000 dziennie i 5 współbieżnych na firmę	Od 5 do 20 zapytań współbieżnych na konto, zależnie od poziomu usługi	6000 zapytań na 5 minut i 5 współbieżnych na użytkownika
Dodatkowa opłata za API	App Partner Program: darmowy próg, następnie od 300 USD do 4500 USD miesięcznie	Plany aplikacji od darmowych do 1445 AUD miesięcznie	Nie stwierdzono; dodatkowa współbieżność sprzedawana jest jako licencje SuiteCloud Plus	Nie stwierdzono

Źródła: FAQ autoryzacji Intuit, Limity i dławienie Intuit, Przewodnik po programie App Partner Program Intuit, Przewodnik po OAuth 2.0 w Xero, Limity API Xero, Cennik Xero, Tokeny OAuth 2.0 w NetSuite, Uwierzytelnianie oparte na tokenach w NetSuite, Limity operacyjne Business Central.

Tokeny wygasają w czterech różnych cyklach

Integracja musi odświeżać tokeny każdego dostawcy przed ich wygaśnięciem i każdorazowo zapisywać nowy token odświeżania – w przeciwnym razie klient będzie musiał ponownie nawiązywać połączenie. Harmonogramy te różnią się aż czternastokrotnie: token odświeżania w NetSuite ważny jest przez siedem dni, a w QuickBooks przez 100 dni. QuickBooks wprowadza dodatkowy sztywny limit: tokeny odświeżania są ważne maksymalnie przez pięć lat, co oznacza, że długo działające połączenia zaczną wygasać w określonym terminie bez względu na intensywność użytkowania. Każdy harmonogram wymaga własnego zadania odświeżania, własnej obsługi błędów oraz własnego komunikatu wyświetlającego klientowi prośbę o ponowne połączenie.

Każdy dostawca ma własny język zapytań

Pobieranie danych to obszar, w którym kod rozchodzi się najbardziej. QuickBooks akceptuje ograniczony dialekt SQL bez operatora OR oraz bez złączeń, zwracając maksymalnie 1000 rekordów na stronę. Xero filtruje dane za pomocą wyrażenia where w adresie URL i zaleca proste testy równości w przypadku dużych organizacji. NetSuite korzysta ze SuiteQL, czyli pełnego dialektu SQL wysyłanego do własnego punktu końcowego. Business Central stosuje filtry OData. Zapytanie znajdujące nieopłacone faktury dla jednego klienta wymaga napisania czterech różnych fragmentów kodu, z których każdy ma własną paginację i specyficzne przypadki brzegowe.

Każdy dostawca ogranicza ruch w inny sposób

QuickBooks i Xero zliczają zapytania na firmę w przeliczeniu na minutę. NetSuite zlicza zapytania współbieżne dla całego konta, co oznacza, że Twoja integracja dzieli pulę zasobów z każdą inną integracją uruchomioną przez klienta, a NetSuite odrzuca wywołania przekraczające limit. Business Central liczy zapytania na użytkownika w oknie pięciominutowym. Masowy import, który jest bezpieczny dla jednego dostawcy, u innego zostanie zdławiony (throttling), dlatego logikę dławienia i ponawiania prób trzeba pisać osobno dla każdego systemu.

Dostęp do API wiąże się z relacją handlową

Dwóch z czterech dostawców pobiera obecnie opłaty za dostęp do API w oparciu o wolumen. Program partnerski Intuit App Partner Program mierzy wywołania typu „CorePlus” (obejmujące większość operacji odczytu danych) i blokuje je po przekroczeniu darmowego limitu; płatne pakiety kosztują odpowiednio 300, 1700 oraz 4500 USD miesięcznie. Xero przeszło na płatne plany aplikacji 2 marca 2026 roku – od darmowego planu ograniczonego do 5 połączeń aż po 1445 AUD miesięcznie dla 10 000 połączeń. Koszt bieżący integracji zależy więc od tego, ilu Twoich klientów korzysta z danego dostawcy i jak dużo danych pobierasz.

Dostawcy zmieniają reguły gry według własnego harmonogramu

Działająca obecnie integracja wiąże się z listą zapowiedzianych już, obowiązkowych przebudowywania kodu:

NetSuite przestaje akceptować nowe integracje korzystające z uwierzytelniania opartego na tokenach począwszy od wersji 2027.1, a komunikat Oracle dotyczący SOAP wskazuje, że „wraz z wersją NetSuite 2028.2 wszystkie punkty końcowe zostaną wyłączone, a integracje oparte na SOAP przestaną działać” (komunikat NetSuite dotyczący SOAP).
Xero przypisuje szczegółowe zakresy uprawnień (permission scopes) aplikacjom tworzonym od marca 2026 roku, dając istniejącym aplikacjom czas na migrację do września 2027 roku (przegląd OAuth 2.0 w Xero).
QuickBooks wprowadza wspomniane wcześniej ograniczenie pięcioletniej ważności tokena odświeżania oraz wycofał starsze wersje pomocnicze API (minor versions), czyniąc wersję 75 wersją bazową.
Business Central w wersji online przestał akceptować klucze dostępu (uwierzytelnianie podstawowe) dla usług sieciowych już w 2022 roku; integracje musiały przejść na Entra ID OAuth (lista wycofanych funkcji Microsoftu).

Żadna z tych zmian nie wnosi nowych funkcji dla Twoich klientów. Każda oznacza czas inżynierski poświęcony wyłącznie na utrzymanie działania istniejącego połączenia, pomnożony przez liczbę wspieranych dostawców.

Kalkulacja dla sześciu integracji

Przyjmijmy szacunki Rutter wynoszące trzy miesiące pracy inżynierskiej na platformę oraz wyliczenia Merge mówiące o 300 godzinach utrzymania rocznie, i zastosujmy je do sześciu systemów księgowych:

	Jeden dostawca	Sześciu dostawców
Budowa	3 miesiące inżynierskie	18 miesięcy inżynierskich
Utrzymanie rocznie	300 godzin	1800 godzin, co odpowiada prawie jednemu pełnoetatowemu inżynierowi

Są to założenia samych dostawców, a nie nasze, przy czym sam NetSuite mógłby te wartości przekroczyć. Kluczowy jest tu ogólny obraz: koszty rosną wraz z liczbą dostawców, a nakład pracy na utrzymanie nigdy się nie kończy. Ujednolicone API skraca czas samej budowy, lecz w zamian uzależniasz się od tego, jak dobrze radzi sobie ono z zapisami i przypadkami brzegowymi u poszczególnych dostawców, płacąc za nie w modelu subskrypcyjnym za każde połączenie lub wywołanie. Nasz artykuł na temat wyboru między budową a zakupem gotowego rozwiązania szczegółowo omawia rzetelną kalkulację takich kosztów.

Zintegruj raz: prowadź księgowość w swoim produkcie

Model oparty na łącznikach zakłada, że księgi każdego klienta znajdują się w systemie wybranym przez niego samego, a Twoja platforma jedynie kopiuje do niego dane. Istnieje jednak drugi model: Twoja platforma prowadzi księgi we własnym zakresie za pośrednictwem jednego interfejsu API księgowego i prezentuje je we własnym interfejsie użytkownika. Do tego właśnie służy Nordlet. Do zbudowania jest tylko jedna integracja, niezależnie od tego, jakiego oprogramowania księgowego klienci używali wcześniej.

Tak wygląda ta pojedyncza integracja w Nordlet:

Jednolita struktura żądań. Każda operacja ma postać POST /v1/{module}/{resource}/{action}. Każda akcja list przyjmuje to samo ciało żądania zawierające filtry, sortowanie i paginację, a każdy błąd korzysta z tej samej koperty. Kod napisanego dla jednego punktu końcowego działa w ten sam sposób dla pozostałych. Zobacz konwencje API.
Klucze API zamiast tokenów odświeżania. Klucz należy do jednej firmy, posiada ustalone zakresy uprawnień, może mieć zdefiniowaną datę wygaśnięcia i zostać unieważniony. Nie trzeba obracać ani przechowywać tokenów odświeżania.
Bezpieczne ponawianie prób. Każda zmiana akceptuje nagłówek Idempotency-Key. Powtórzenie żądania z tym samym kluczem zwraca zapisaną odpowiedź zamiast tworzyć drugą fakturę.
Podpisane webhooki z ponawianiem prób. Zdarzenia są zapisywane w tej samej transakcji bazy danych co zmiana, podpisywane algorytmem HMAC-SHA256, a próby ich dostarczenia są ponawiane przez około 24 godziny.
Jednolity, opublikowany limit zapytań. 300 zapytań na minutę dla jednego klucza API, raportowanych w nagłówkach x-ratelimit-*.
Wtyczki SDK z typowaniem w dziewięciu językach, generowane z jednej specyfikacji OpenAPI. Zobacz SDK.
Nielimitowane firmy testowe (sandbox) w ramach jednego konta do celów testowania integracji.
Jeden cennik. Plany rozliczane są na podstawie liczby wywołań, zaczynając od 10 EUR miesięcznie za 3000 zapytań. Zobacz cennik.

Księga główna oparta na podwójnym zapisie, faktury, rozliczanie płatności bankowych, deklaracje VAT oraz raporty są dostępne przez to samo API, dzięki czemu integracja obejmuje samą księgowość, a nie jej kopię. Strona funkcji przedstawia listę dostępnych możliwości, a artykuł czym jest API księgowe wyjaśnia ten model bardziej szczegółowo.

Klienci, którzy posiadają już księgi w innych systemach

Dwie funkcje zastępują łączniki dla poszczególnych dostawców, które platforma musiałaby budować dla takich klientów:

Migracja danych. Plan kont partnera, salda otwarcia lub pełna historia dziennika, otwarte faktury, środki trwałe oraz stany magazynowe są importowane jednym wywołaniem. Zobacz migrację z innego systemu.
Pliki dla księgowego. Jeśli księgowy klienta pracuje we własnym oprogramowaniu, Nordlet eksportuje księgę w formatach odczytywanych przez te systemy: jako paczkę księgowań DATEV (POST /v1/reports/datev) dla niemieckich księgowych oraz plik SIE 4 (POST /v1/reports/sie) dla szwedzkich. Eksport pliku nie wymaga logowania, odświeżania tokenów ani ponoszenia opłat za wywołania u dostawcy oprogramowania księgowego.

Kiedy łączniki nadal są właściwym rozwiązaniem

Prowadzenie księgowości bezpośrednio w produkcie nie jest odpowiednim wyborem dla każdej platformy:

Jeśli działy finansowe Twoich klientów wymagają, aby ich dotychczasowy system księgowy pozostał systemem źródłowym, potrzebujesz łączników do tego systemu, zbudowanych bezpośrednio lub poprzez ujednolicone API.
Jeśli musisz jedynie przesać kilka dokumentów do ksiąg klienta, takich jak jedna faktura na zamówienie, pojedyncze bezpośrednie połączenie z dostawcą, z którego korzysta większość Twoich klientów, może okazać się wystarczające.
Jeśli większość Twoich klientów korzysta z jednego dostawcy, pojedyncza bezpośrednia integracja oznacza jeden projekt, a nie sześć.

Argument przemawiający za jednorazową integracją ma zastosowanie wtedy, gdy Twoja platforma musi obsługiwać księgowość swoich użytkowników, a nie ją odzwierciedlać: giełdy i platformy marketplace wypłacające środki sprzedawcom, platformy wystawiające faktury w imieniu użytkowników oraz produkty SaaS, w których księgowość stanowi część samego produktu. Przed wybraniem którejkolwiek ścieżki warto zapoznać się z naszym planem testów przedprodukcyjnych dla API księgowego, który wskazuje, co należy przetestować.

FAQ

Ile czasu zajmuje zbudowanie integracji z QuickBooks?

Apideck szacuje czas potrzebny jednemu kompetentnemu inżynierowi na trzy do czterech tygodni dla pierwszej działającej wersji. Jeden z klientów Rutter oszacował potrzebny nakład na dwóch inżynierów przez kilka miesięcy, co ostatecznie zajęło co najmniej trzy miesiące z wieloma iteracjami. Prace produkcyjne – odświeżanie tokenów, ponawianie prób, limity zapytań, ponowne łączenie i uzgadnianie danych – stanowią różnicę między tymi wartościami.

Ile czasu zajmuje integracja z NetSuite?

Rutter określa czas potrzebny na integrację z NetSuite na od sześciu do dwunastu miesięcy. NetSuite wprowadza limity współbieżności dla całego konta, siedmiodniowe tokeny odświeżania, SuiteQL obok SOAP oraz zapowiedziane zmiany: brak nowych integracji opartych na uwierzytelnianiu tokenowym od wersji 2027.1 oraz wyłączenie punktów końcowych SOAP w wersji 2028.2.

Czy ujednolicone API księgowe eliminuje prace związane z wieloma dostawcami?

Zmniejsza narzut związany z budową, ponieważ jeden interfejs obsługuje kilku dostawców. Nie eliminuje jednak różnic między nimi: operacje zapisu, pola niestandardowe i przypadki brzegowe są często wspierane nierównomiernie, a koszt ujednoliconego API dolicza się do opłat pobieranych bezpośrednio przez dostawców. Kompromisy te zostały omówione w naszym przewodniku po integracjach SaaS.

Ile kosztuje dostęp do API QuickBooks i Xero?

Program partnerski Intuit App Partner Program oferuje darmowy poziom Builder oraz płatne pakiety za 300, 1700 i 4500 USD miesięcznie, przy czym odczyty danych powyżej wliczonego limitu są dodatkowo mierzone. Plany aplikacji Xero, obowiązujące od 2 marca 2026 roku, kosztują od zera (dla 5 połączeń) do 1445 AUD miesięcznie (dla 10 000 połączeń), a większe plany są wyceniane indywidualnie na zapytanie.

Czy Nordlet może zastąpić integracje z systemami księgowymi moich klientów?

Gdy Twoja platforma prowadzi księgi swoich użytkowników – tak: budujesz jedną integrację z API Nordlet zamiast osobnej dla każdego dostawcy księgowości. Dotychczasowe księgi są importowane jednym wywołaniem, a księgowi korzystający z oprogramowania kompatybilnego z DATEV lub SIE otrzymują pliki eksportu. Nordlet nie synchronizuje danych do QuickBooks, Xero, NetSuite ani Business Central; jeśli te systemy muszą pozostać systemami źródłowymi, nadal potrzebujesz dedykowanych łączników.