Wbudowana księgowość: Zbudować czy kupić dla platform handlowych (marketplaces)

Lista wymagań, model kosztów z określonymi założeniami oraz warunki, w których każda z odpowiedzi jest poprawna.

Każda platforma handlowa (marketplace) w końcu tworzy własną księgę główną (ledger). Jedynym pytaniem pozostaje to, czy powstanie ona świadomie, jako system z odpowiednimi mechanizmami kontrolnymi, czy przypadkowo, jako kolumna balance w bazie danych, do której zapisują dane trzy niezależne usługi, a której nikt tak naprawdę nie ufa.

Ten artykuł pomoże podjąć tę decyzję z pełną świadomością. Omawiamy w nim zakres faktycznych prac, metodę uczciwego szacowania kosztów oraz konkretne warunki, w których budowa własnego rozwiązania ma sens, ponieważ czasami faktycznie jest to właściwy wybór.

Co w tym kontekście oznacza „wbudowana księgowość” (embedded accounting)

Wbudowana księgowość oznacza, że rejestry księgowe znajdują się bezpośrednio w Twoim produkcie, a nie w zewnętrznym programie uruchamianym w osobnym oknie. Twoje oprogramowanie zapisuje wpisy w momencie wystąpienia zdarzeń, użytkownicy widzą to, co prezentuje im interfejs, a pod koniec miesiąca nikt nie eksportuje arkuszy kalkulacyjnych dla księgowego.

W przypadku platformy handlowej obejmuje to co najmniej: otrzymane płatności od kupujących, kwoty należne sprzedawcom, naliczone prowizje, opłaty za przetwarzanie płatności, podatek VAT od prowizji i od transakcji podstawowej, zwroty środków, obciążenia zwrotne (chargebacks), rezerwy, wypłaty oraz uzgadnianie tych wszystkich pozycji z rachunkiem bankowym lub operatorem płatności.

Co tak naprawdę budujesz, decydując się na rozwój własnego rozwiązania

Sama księga główna to tylko niewielka część całego przedsięwzięcia. Zespoły programistyczne regularnie ograniczają szacunki do pierwszego punktu na liście, by dopiero później odkryć resztę.

Komponent	Czego dotyczy
Dziennik i konta	Zbilansowane zapisy, plan kont, typy kont, bilans otwarcia
Niezmienność danych (immutability)	Pamięć tylko do dopisywania (append-only), przepływ korekt i cofnięć, brak edycji w miejscu
Kontrola okresów	Zamknięcie okresu, blokowanie, odrzucanie spóźnionych wpisów, kontrolowane ponowne otwarcie z rejestrem audytu
Idempotencja	Klucze, przechowywanie wcześniejszych odpowiedzi, wykrywanie kolizji przy zmienionych danych
Obsługa kwot pieniężnych	Aritmetyka dokładna (dziesiętna lub na najmniejszych jednostkach waluty), kody walut, kursy walutowe i ich źródło, konta zaokrągleń
Silnik VAT	Stawki dla poszczególnych krajów z datami ważności, miejsce świadczenia, procedura odwrotnego obciążenia (reverse charge), zasady podatnika ułatwiającego dostawę (deemed supplier), zwolnienia
Weryfikacja identyfikatorów VAT	Sprawdzanie w oficjalnych rejestrach, buforowanie (caching), znaczniki czasu, identyfikator żądania, kolejka ręcznej weryfikacji w przypadku błędów
Dokumenty	Faktury, noty korygujące, ciągłość numeracji w ramach serii i roku, generowanie plików PDF, doręczanie
Faktury elektroniczne (e-invoicing)	Ustrukturyzowane formaty, takie jak EN 16931 UBL, oraz krajowe formaty lokalne tam, gdzie są wymagane
Pobieranie wyciągów bankowych	Import wyciągów lub połączenie z bankiem za zgodą użytkownika (consented bank connection), deduplikacja już zaimportowanych transakcji
Uzgadnianie (reconciliation)	Reguły dopasowywania, punktacja, dopasowania częściowe, wyjątki do rozstrzygnięcia przez człowieka
Wypłaty (payouts)	Generowanie plików płatności, paczki wypłat, dopasowywanie wypłat z powrotem do leżących u ich podstaw pozycji
Raportowanie	Zestawienie obrotów i sald (trial balance), bilans, rachunek zysków i strat, przepływy pieniężne, podsumowania VAT, wiekowanie należności
Rejestry podatkowe i deklaracje	Wszystko, czego wymagają poszczególne kraje, w formacie akceptowanym przez urząd
Audyt	Podmiot, akcja, encja oraz sama zmiana, z możliwością zapytań dla każdej modyfikacji
Retencja i eksport	Dziesięcioletni okres przechowywania danych dla procedury OSS, pełny eksport danych, archiwum spełniające wymogi prawne

Mniej więcej dwa z tych szesnastu punktów to elementy, które zespoły mają przed oczami, gdy mówią: „zbudujemy sobie księgę główną”.

Uczciwe szacowanie kosztów

Wszystkie liczby zależą od specyfiki zespołu, dlatego poniższe podejście należy traktować jako metodę, a nie gotową wycenę. Weź powyższe komponenty, przypisz każdemu z nich rozmiar w tygodniach pracy inżyniera, opierając się na dynamice własnego zespołu, a następnie zastosuj trzy korekty, które zazwyczaj są pomijane w szacunkach.

Korekta pierwsza: komponenty związane ze zgodnością z przepisami (compliance) nie są jednorazowym zadaniem. Stawki się zmieniają, progi się zmieniają, formaty się zmieniają, a unijny pakiet VAT w erze cyfrowej (ViDA) wprowadza obowiązki powiązane z konkretnymi datami: zmiany w OSS i IOSS od 1 stycznia 2027 r., rozszerzone zasady dotyczące platform od 1 lipca 2028 r. oraz transgraniczne fakturowanie elektroniczne i raportowanie od 1 lipca 2030 r. Samodzielna budowa oznacza, że przejmujesz pełną odpowiedzialność za każdą z tych migracji.

Korekta druga: praca nad poprawnością trwa dłużej niż tworzenie nowych funkcji. Pierwsza wersja obsługuje ścieżkę idealną (happy path). Długi ogon to zwroty po wypłacie, zwroty częściowe, obciążenia zwrotne docierające tygodnie później, zaokrąglenia walutowe, zduplikowane webhooki oraz pliki rozliczeniowe, które nie zgadzają się z Twoimi rejestrami. To właśnie w tym obszarze topnieją harmonogramy projektów.

Korekta trzecia: księgowy to interesariusz, a nie recenzent. Księgi, pod którymi profesjonalny księgowy nie podpisze się, nie są skończone, a opinie te docierają zazwyczaj późno w cyklu rozwoju projektu.

Przydatny test racjonalności: oszacuj koszt najmniejszej wiarygodnej wersji systemu – księgi głównej, korekt, blokowania okresów, idempotencji, obsługi kwot, podatku VAT w jednym kraju, faktur, importu bankowego, uzgadniania oraz podstawowego zestawu raportów – i porównaj go z rocznym kosztem usługi rozliczanej subskrypcyjnie lub liczbowo. Plany cenowe Nordlet opublikowane w cenniku zaczynają się od 10 EUR miesięcznie (z wliczonym pakietem 3000 żądań) i sięgają 300 EUR miesięcznie dla 200 000 żądań. Jeśli budowa kosztuje ułamek rocznego wynagrodzenia jednego inżyniera, to poważny argument przemawiający za jej podjęciem. Jeśli kosztuje odpowiednik wieloletniej pracy zespołu inżynierskiego plus koszty stałego utrzymania, rachunek ekonomiczny przestaje się bilansować, a dysproporcja ta rośnie z każdym rokiem wraz ze zmianami przepisów.

Kiedy budowa własnego rozwiązania jest faktycznie właściwym krokiem

Trzy przypadki, wszystkie realne.

Twoja księga główna to Twój produkt. Jeśli budujesz platformę płatniczą, produkt bankowy lub portfel cyfrowy, w którym zachowanie salda w warunkach współbieżności (concurrency) stanowi czynnik wyróżniający na rynku, księga główna jest kluczowym elementem i powinna być Twoja. Warto jednak rozważyć gotowe produkty infrastrukturalne zamiast budowy od zera i trzymać księgowość finansowo-podatkową osobno.

Twój model biznesowy nie pasuje do żadnego systemu księgowego. Niektóre platformy handlowe posiadają nietypowe struktury rozliczeń: wielostronne podziały z warunkowym zwalnianiem środków, eskrow z etapowymi kamieniami milowymi, złożone polityki rezerw. Jeśli żaden produkt rynkowy tego nie odzwierciedla, a obejścia są gorsze niż budowa, wówczas należy budować.

Twoja skali transakcyjna czyni model opomiarowany nieopłacalnym. Przy skrajnie wysokiej liczbie transakcji model oparty na cenie za każde żądanie przestaje być atrakcyjny. Warto jednak przeliczyć to na realnych danych przed wyciągnięciem pochopnych wniosków, ponieważ pojęcie „skrajnie wysoki” oznacza tu wolumeny przekraczające to, co osiąga większość platform.

Kiedy zakup jest właściwym wyborem

Zakup wygrywa w sytuacjach, gdy księgowość jest koniecznością, a nie wyróżnikiem rynkowym – co stanowi zdecydowaną większość przypadków. Nikt nie wybiera Twojego marketplace'u dlatego, że wpisy w dzienniku księgowym są eleganckie. Klienci zauważają system dopiero wtedy, gdy księgi są błędne.

Zakup jest również słusznym wyborem, gdy Twoje obowiązki obejmują wiele krajów. Krajowe przepisy VAT, przechowywanie dowodów oraz obowiązkowe fakturowanie elektroniczne generują stałe zapotrzebowanie na prace utrzymaniowe, a dostawca oprogramowania rozkłada te koszty na wszystkich swoich klientów. Nordlet dostarcza unijny VAT dla poszczególnych krajów wraz z walidacją VIES, obliczaniem deklaracji OSS i iOSS, rejestrami i.SAF oraz formatem EN 16931 UBL dla sieci Peppol jako integralną część produktu, a nie jako projekt wymagający planowania w harmonogramie.

Ścieżka środková, którą wybiera większość zespołów

Praktyczna odpowiedź zazwyczaj nie leży w skrajnościach. Brzmi ona następująco: kup księgę główną, zbuduj przepływ pracy (workflow).

Backend księgowy odpowiada za wpisy, traktowanie podatkowe, dokumenty, zamknięcie okresu oraz ścieżkę audytu. Twój produkt odpowiada za wszystko, co widzą użytkownicy, oraz za wszelkie reguły biznesowe specyficzne dla Twojego marketplace'u: moment uwalniania środków, zasady tworzenia rezerw, obsługę sporów czy wygląd panelu sprzedawcy. Wywołujesz API księgowe w momentach, w których dochodzi do zaangażowania środków, zachowując dla siebie te elementy, które faktycznie stanowią o Twojej unikalności.

Taka granica podziału znosi zmiany znacznie lepiej niż alternatywne podejścia. Pojawienie się nowego kraju oznacza dodanie konfiguracji, a nie nowy projekt. Nowa polityka wypłat to Twój kod, a nie prośba o funkcję do dostawcy.

Co należy ustalić przed podjęciem ostatecznej decyzji

Czy Twoja księga główna to wyróżnik (differentiator), czy obowiązek? Bądź szczerzy – w większości przypadków to obowiązek.
W ilu krajach działasz i czego wymaga każdy z nich? Tylko stawek podatkowych, deklaracji, rejestrów czy pełnej wysyłki plików.
Jak wygląda u Ciebie obsługa korekt? Zwroty po wypłacie oraz spóźnione obciążenia zwrotne to sytuacje, które obnażają słaby projekt systemu.
Kto podpisuje księgi? Zaangażuj tę osobę przed ustaleniem projektu systemu, a nie po fakcie.
Jaki jest plan dziesięcioletniej retencji danych? Zapisy w ramach procedury OSS muszą być przechowywane przez dziesięć lat od końca roku, w którym miały miejsce transakcje, a archiwum to system, a nie zwykła kopia zapasowa.
Jak będzie wyglądać ewentualna migracja za trzy lata? W obu kierunkach. Przygotuj testowy eksport już pierwszego dnia i dbaj o to, aby zawsze działał.

FAQ

Jak długo trwa zbudowanie księgi głównej dla platformy handlowej?

Pierwszą wersję potrafiącą publikować zbilansowane zapisy można uruchomić w ciągu kilku tygodni. Wersja obsługująca zwroty po wypłacie, spóźnione obciążenia zwrotne, wielowalutowe zaokrąglenia, zduplikowane webhooki operatorów, zamknięcie okresu oraz audyt akceptowany przez księgowego powstaje znacznie dłużej, a prace konserwacyjne nie kończą się nigdy. Szacuj czas na podstawie drugiego wariantu, ponieważ to właśnie oznacza środowisko produkcyjne (production).

Czy możemy zacząć od kolumny `balance` i zmigrować dane później?

Możesz, i robi to wiele firm, ale zaplanuj tę migrację jako zadanie trudniejsze niż pierwotna budowa. Odtworzenie historii z modyfikowalnego salda jest możliwe tylko wtedy, gdy zachowano każde zdarzenie, które to saldo zmieniło – co w praktyce oznacza, że w zasadzie miałeś już księgę główną.

Czy wbudowane API księgowe zastępuje dział finansowy?

Nie. Eliminuje ono ręczne zapisywanie i uzgadnianie danych. Ktoś nadal musi zamknąć miesiąc, przejrzeć wyjątki, podjąć decyzje uznaniowe i wysłać deklaracje.

Co z RODO (GDPR), jeśli księga główna jest niezmienna (immutable)?

Przechowuj fakty finansowe i pseudonimizowane odniesienia w niezmiennych rejestrach, a dane osobowe w osobnym systemie z własnymi procedurami retencji i usuwania danych. Niezmienność dotyczy zdarzenia finansowego, a nie każdego powiązanego z nim atrybutu.

Czy oprogramowanie księgowe o otwartym kodzie źródłowym (open-source) stanowi alternatywną ścieżkę środka?

To realna opcja, która zmienia strukturę kosztów, zamiast je eliminuje: przejmujesz na siebie hosting, aktualizacje, lokalizację krajową oraz wdrażanie zmian w przepisach. Przelicz te koszty przed uznaniem oszczędności na licencji za pełny obraz sytuacji.