Što definira API nepromjenjive dvojnog knjigovodstva

Glavnu knjigu (ledger) na nekoj internetskoj platformi (marketplace) ne određuje to pohranjuje li kretanja novca. Većina sustava to radi. Određuje ju ono što se dogodi kada pružatelj plaćanja pošalje isti webhook dvaput, kada povrat novca stigne nakon što je prodavatelj već isplaćen ili kada revizor upita kako je saldo prodavatelja dosegnuo trenutni iznos. Ti trenuci otkrivaju imate li nepromjenjivu glavnu knjigu s dvojnim knjigovodstvom ili promjenjivo polje s optimističnim nazivom.

Kratak odgovor za platformsku aplikaciju jest sljedeći: API nepromjenjive glavne knjige s dvojnim knjigovodstvom bilježi svaki financijski značajan događaj kao uravnoteženu transakciju dnevnika (journal transaction), knjiži ju atomski, nikada ju ne prepisuje te vam omogućuje da izvodite salda, usklađujete podatke s vanjskim sustavima i programski izvozite povijest. Sve ostalo detalji su koji se nadovezuju na tu osnovu.

Uravnotežene stavke dnevnika, a ne polje tekućeg salda

Najjasniji test jest način na koji API prikazuje saldo prodavatelja. Ako je saldo broj koji vaša aplikacija izravno povećava, to nije glavna knjiga s dvojnim knjigovodstvom. Ako je saldo izvedeni prikaz proknjiženih stavki dnevnika, možda jest.

Svaka transakcija mora sadržavati jednaka dugovanja i potraživanja. Kada kupac plati 100 € za narudžbu na kojoj platforma uzima proviziju od 15 €, glavna knjiga bilježi dugovnu stranu prijelaznog računa u iznosu od 100 €, uz potražnu stranu obveza prema prodavatelju od 85 € i potražnu stranu prihoda od provizije od 15 €. Te dvije strane uvijek daju isti zbroj. To strukturno pravilo hvata veliku skupinu pogrešaka prije nego što uopće dospiju do izvještaja.

Transakcija dnevnika trebala bi minimalno prikazivati:

• Jedinstven, nepromjenjiv ID transakcije
• Stavke duguje i potražuje, svaka s računom, iznosom i valutom
• Datum valute i vremensku oznaku knjiženja
• Vrstu poslovnog događaja (prodaja, povrat, isplata, povrat sredstava od strane izdavatelja kartice)
• Ključ idempotentnosti (idempotency key)
• Izvornu referencu na narudžbu, plaćanje ili događaj pružatelja usluge
• Status (na čekanju, proknjiženo, stornirano)
• Uslugu ili vjerodajnicu koja ju je stvorila

Dostupna sredstva prodavatelja tada postaju upit nad tim stavkama, a ne vrijednost koju je netko ažurirao u kodu aplikacije. To je važno jer izravno izmijenjeni saldo gubi razlog za svako kretanje. Model platforme Nordlet tretira glavnu knjigu s dvojnim knjigovodstvom kao mjerodavnu putanju pisanja: svaki dokument knjiži uravnotežene stavke dnevnika, a sama baza podataka odbija one koje nisu uravnotežene. To je ispravna zadana postavka za sve koji ugrađuju računovodstvo u neku platformsku aplikaciju.

Knjiženje isključivo dodavanjem uz kompenzirajuće korekcije

Pojam „nepromjenjiv” (immutable) trebao bi značiti da se proknjiženi dnevnik ne može uređivati na licu mjesta. Pogreške se ispravljaju prema naprijed, a ne brisanjem. Unos s pogrešnom provizijom dobiva storno koji poništava izvornik, a zatim ispravljeni unos koji bilježi željeni rezultat. Oba unosa upućuju na izvornik, a povijest revizije pokazuje tko je pokrenuo promjenu i kada.

API bi trebao odbijati obične naredbe UPDATE i DELETE primijenjene na proknjižene računovodstvene podatke. Može vam dopustiti pridruživanje nefinancijskih metapodataka, poput reference na slučaj podrške, sve dok iznosi, računi i vremenske oznake ostaju netaknuti.

Korisno je odvojiti troje stvari koje ljudi često poistovjećuju:

• Operativna nepromjenjivost: korisnici aplikacije ne mogu mijenjati niti brisati proknjižene retke.
• Revizijska nepromjenjivost: sustav može dokazati da se povijest nije promijenila.
• Zakonsko čuvanje: evidencije se čuvaju onoliko dugo koliko to zahtijeva primjenjivi zakon.

Relacijska baza podataka koja podržava samo dodavanje (append-only), uz stroge dozvole, sigurnosne kopije i disciplinirane radne procese storniranja, pruža uistinu nepromjenjivu glavnu knjigu. Tehnologija blockchain ovdje nije uvjet, a za podatke europskog računovodstva obično uvodi probleme s privatnošću i ispravljanjem koji nadmašuju dodanu sigurnost od neovlaštenog mijenjanja.

Atomnost i idempotentnost

Događaj na platformi mora se proknjižiti atomski. Ili se potvrđuju sve stavke dnevnika ili nijedna. Bilježenje primitka od 100 €, uz propust bilježenja provizije od 15 €, daje neuravnotežen, obmanjujući rezultat koji netko kasnije mora raščišćavati. Nordlet to provodi ispod razine aplikacije: odgođeni okidač (trigger) u bazi podataka provjerava je li svako knjiženje uravnoteženo u trenutku potvrde, tako da se neuravnotežena transakcija uopće ne može potvrditi.

Idempotentnost je točka u kojoj se većina integracija tiho slomi. Platni sustavi ponavljaju radnje u slučaju mrežnih pogrešaka, a datoteke namire se ponovno šalju. Bez ključa idempotentnosti obuhvaćenog za određenog najamnika (tenant) ili račun, jedan ponovljeni zahtjev stvara dvostruko knjiženje. Ponovljeni zahtjev s istim ključem trebao bi vratiti izvornu transakciju, a ne drugu.

Ključ mora biti povezan s izvornim događajem, vrstom događaja, ID-jem događaja pružatelja usluge, pravnim subjektom i hash vrijednošću sadržaja zahtjeva. Ako isti ključ stigne s drugačijim iznosom ili valutom, API bi to trebao tretirati kao sukob i odbiti ga umjesto da tiho prihvati novi sadržaj. Tiho prihvaćanje način je na koji revizijski tragovi propadaju. Zaglavlje Idempotency-Key platforme Nordlet funkcionira na ovaj način: ponovljeni pokušaj s istim ključem i sadržajem ponavlja pohranjeni odgovor, dok se isti ključ s drukčijim sadržajem odbija s porukom idempotency_key_reuse. To je mala značajka s golemim učinkom na usklađivanje.

Računovodstvo podjele između više strana (split accounting)

Narudžba na platformi nije samo jedno kretanje sredstava. Jedna prodaja može obuhvatiti sredstva kupca, prihode prodavatelja, proviziju platforme, naknade za obradu plaćanja, PDV na proviziju, dostavu i rezerve. Glavnoj knjizi potrebne su strukture računa koje te elemente drže odvojenima umjesto da ih sažimaju u jedan neto iznos.

Postoji uobičajena pretpostavka protiv koje se vrijedi boriti: značajka isplate s podjelom (split payout) pružatelja plaćanja nije isto što i računovodstvo platforme. Podjela novca među primateljima usmjerava gotovinu. Time se ne dobiva potpuna, nepromjenjiva evidencija zarađene provizije, naplaćenog PDV-a, dugovanih povrata ili zadržanih rezervi. I dalje trebate vlastitu glavnu knjigu i i dalje ju morate uskladiti s pružateljem usluge.

Glavna knjiga platforme također bi trebala razlikovati više od jednog salda prodavatelja:

Stanje salda	Što predstavlja
Na čekanju (Pending)	Sredstva vezana uz događaj, ali još nisu podobna za isplatu
Dostupno (Available)	Sredstva koja prolaze pravila oslobađanja, rezervi, povrata i sporova
Zadržano / rezervirano (Held / reserved)	Iznosi zadržati za povrate sredstava (chargeback), povrate robe ili kontrole prijevara
Isplaćeno (Paid out)	Iznosi preneseni prodavatelju
Negativno / naplativo (Negative / recoverable)	Iznosi koje prodavatelj duguje nakon što povrati ili naknade premaše dostupna sredstva

Premještanje novca sa stanja na čekanju na dostupno stanje samo po sebi mora biti uravnotežena stavka dnevnika, a ne preimenovano polje.

Storniranja, povrati novca i negativna salda

Novčani tokovi na platformi kreću se u oba smjera, često izvan uobičajenog redoslijeda. Teški su slučajevi povrati novca nakon isplate i povrati sredstava od strane izdavatelja kartice koji stižu tjednima kasnije. Ozbiljna glavna knjiga definira što se događa kada raspoloživi saldo prodavatelja ne može pokriti povrat novca: stvaranje negativnog salda, premještanje iznosa na potraživanja od prodavatelja, posezanje za rezervom ili ograničavanje daljnjih isplata.

Svaki bi od tih događaja trebao upućivati na izvornu transakciju i očuvati ju. Glavna knjiga bilježi računovodstvenu posljedicu povrata novca. Ona ne određuje politiku povrata novca platforme niti njezinu pravnu odgovornost. Održavanje te granice jasnom sprječava mnoštvo zbunjujućih rasprava o dizajnu.

Valute i preciznost

Prekogranične platforme trebaju precizno rukovanje novcem. Iznosi bi trebali koristiti ISO 4217 oznake valuta i točan prikaz, bilo u obliku cjelobrojnih manjih novčanih jedinica ili decimalnih nizova fiksne preciznosti, a nikako u obliku pomičnog zareza (floats). Nema tihog zaokruživanja. Kada dođe do konverzije, glavna knjiga treba očuvati izvorni iznos, tečaj, izvor tečaja, vremensku oznaku i rezultirajući iznos, s razlikama zaokruživanja proknjiženim na definirani račun.

Jedna uravnotežena transakcija ne smije miješati valute bez izričitog mehanizma deviznog tečaja. Ako to učini, vaši se izvještaji neće slagati sa stvarnošću na načine koje je bolno pratiti na kraju mjeseca.

Usklađivanje s vanjskim sustavima

Interno uravnotežena glavna knjiga sama po sebi nije mjerodavna. Ona se mora slagati s vanjskim svijetom: transakcijama pružatelja plaćanja, naknadama pružatelja usluga, izvještajima o namiri, bankovnim izvodima, datotekama isplata i izvještajima o povratima sredstava.

Zreo API podržava uvezene vanjske događaje i stanja podudaranja kao što su usklađeno, djelomično usklađeno, neusklađeno, dvostruko, neusklađen iznos i zahtijeva pregled. Razlike u usklađivanju trebale bi stvarati izričite evidencije iznimaka ili računovodstvene stavke. One nikada ne smiju tiho prepisivati povijest glavne knjige. Pristup platforme Nordlet bankovnom usklađivanju i usklađivanju plaćanja temelji se na ovom načelu: uvezeni izvodi i izvezeni podaci iz sustava Stripe preskaču sve što je već uvezeno, prijedlozi plaćanja boduju se prema iznosu, referenci, drugoj ugovornoj strani i IBAN-u, usklađivanje jednim klikom rješava rutinske slučajeve, a iznimke se iznose na površinu umjesto da se apsorbiraju.

Granice u EU-u koje API treba poštovati i one koje ne može

Ovo je područje na kojem marketinške tvrdnje obično nadmašuju stvarnost. Glavna knjiga pomaže s obvezama u EU-u, ali sama po sebi ih ne ispunjava.

PDV. Glavna knjiga treba očuvati porezno relevantne dimenzije: nadležnost, stopu, poreznu kategoriju i način na koji je stopa utvrđena. Treba razlikovati prodaju prodavatelja kupcu od provizije platforme te odvojiti PDV na naknade od iznosa koji samo prolaze. Nordlet upravlja izračunima PDV-a po zemljama, VIES provizijama i generiranjem i.SAF registara, zajedno sa scenarijima OSS-a i IOSS-a s kojima se susreću europske platforme. Glavnu knjigu tretirajte kao dokaz i porezni mehanizam, a ne kao porezni savjet.

DAC7. Pravila izvještavanja za platforme zahtijevaju pouzdane veze između identiteta prodavatelja, nadležnosti, ukupnih iznosa transakcija, naknada, povrata i isplata. Uravnotežena glavna knjiga daje dokaz o transakciji. Ona ne određuje je li prodavatelj obveznik izvještavanja i ne zamjenjuje postupak utvrđivanja identiteta klijenta (KYC), uvođenja u sustav (onboarding) ili radni proces izvještavanja. Računovodstvo transakcija i regulatorno izvještavanje držite odvojenima.

PSD2 i čuvanje sredstava. Bilježenje kretanja novca nije isto što i biti licencirana platna usluga ili čuvati sredstva. Glavna knjiga treba učiniti tok novca i uključene strane izričitima. Ona sama po sebi ne može osigurati odobrenje za pružanje platnih usluga niti dokazati da se gotovina drži na određenom računu. To ostaje pitanje vaše regulatorne uloge i vašeg pružatelja platnih usluga (PSP).

GDPR. Nepromjenjivost stvara stvarnu napetost s načelima zaštite podataka. Najsigurnija arhitektura čuva novčane činjenice u nepromjenjivoj jezgri, a osobne podatke izvan nje. U stavkama dnevnika koristite stabilne pseudonimizirane reference prodavatelja i kupaca. Pohranite promjenjive osobne podatke u zaseban sustav s kontroliranim pristupom, vlastitim radnim procesom čuvanja i brisanja. „Nepromjenjivost” nije dozvola za zauvijek čuvanje svakog sadržaja plaćanja.

Kontrolni popis za ocjenu API-ja glavne knjige

Oznake značajki jeftine su. Umjesto toga provjerite ponašanje u testnom okruženju (sandbox). Pokrenite ove scenarije i provjerite dokaze:

• Proknjižite narudžbu od 100 € podijeljenu između prodavatelja i platforme te potvrdite uravnoteženi dnevnik s izričitim računima.
• Pošaljite isti zahtjev dvaput i potvrdite jednu transakciju bez dupliciranja.
• Pokušajte urediti proknjiženi unos i potvrdite da je odbijen ili ograničen na nefinancijske metapodatke.
• Ispravite pogrešnu proviziju i potvrdite povezani storno uz ispravljeni unos.
• Izvršite djelomični povrat novca nakon isplate i potvrdite povrat koji se može pratiti uz potraživanje od prodavatelja ili negativan saldo gdje je to potrebno.
• Ponovno pokrenite webhook pružatelja usluge i potvrdite otkrivanje dvostrukih unosa.
• Obradite namiru u više valuta i potvrdite pojedinosti deviznog tečaja i računovodstvo konverzije.
• Upitajte saldo prodavatelja na kraju razdoblja i potvrdite ponovljiv rezultat s dokumentiranim presjekom.
• Uvezite namiru pružatelja usluge i potvrdite usklađivanje sa statusom iznimke koji ostavlja povijest netaknutom.
• Izveozite jednomjesečnu aktivnost i potvrdite potpuni, stranični, ponovljivi izvadak.

Najjači su dokazi dokumentacija uz ponovljiv test. Riječi poput „u stvarnom vremenu”, „spremno za reviziju” i „nepromjenjiv” ne znače ništa bez podatkovnog modela, semantike pogrešaka i ponašanja pri čuvanju podataka koji stoje iza njih.

Što bismo prvo provjerili

Kada bismo sutra procjenjivali API glavne knjige za neku platformu, započeli bismo s dvjema stvarima prije nego što pogledamo bilo što drugo. Kao prvo, dokazali bismo da se saldo prodavatelja izvodi iz stavki dnevnika, a ne iz promjenjivog polja, jer sve u nastavku o tome ovisi. Kao drugo, ponovno bismo pokrenuli isti webhook i potvrdili točno jedan računovodstveni rezultat. Ta nam dva testa govore više o kvaliteti temeljnog dizajna nego bilo koji popis značajki.

Nakon toga, razmatranja usmjerena na API važna su za brzinu kojom vaš tim isporučuje rješenja: tipizirani SDK-ovi, webhooks za događaje poput sale_invoice.paid, radno testno okruženje i zaključavanje razdoblja radi zaštite zatvorenih mjeseci. Nordlet je izgrađen oko ovog modela, s istim skupom značajki izloženim putem API-ja kao i putem aplikacije, što platformi omogućuje vođenje poslovnih knjiga spremnih za reviziju unutar vlastitog proizvoda umjesto naknadnog dodavanja naplate treće strane. Širu sliku o tome kako se takva glavna knjiga uklapa u arhitekturu platforme potražite u našem vodiču o API-jima glavne knjige s dvojnim knjigovodstvom za računovodstvo na internetskim platformama.

FAQ

Jamči li dvojno knjigovodstvo da je moje računovodstvo točno?

Ne. Glavna knjiga može biti savršeno uravnotežena dok se knjiži na krive račune, primjenjuje krivi tretman PDV-a ili pripisuje sredstva krivom prodavatelju. Ravnoteža je strukturna kontrola koja hvata aritmetičke pogreške i nedostajuće strane transakcije. Ona ne govori ništa o tome je li vaša poslovna logika ispravno preslikala događaj. Zbog toga je testiranje u testnom okruženju na stvarnim scenarijima važnije od same provjere ravnoteže.

Je li glavna knjiga pružatelja plaćanja dovoljna za platformu?

Obično ne. Pružatelj platnih usluga prati sredstva unutar vlastitog sustava, što je korisno za kretanje i isplatu. Vaša platforma i dalje treba vlastite evidencije za prihod od provizije, obveze prema prodavatelju, PDV na naknade, povrate, rezerve, sporove i upravljačko izvještavanje. Ta se dva sustava moraju uskladiti, a tretiranje pogleda pružatelja usluge kao vašeg računovodstva ostavlja praznine koje se pojavljuju u trenutku revizije.

Trebam li tehnologiju blockchain kako bih glavnu knjigu učinio nepromjenjivom?

Ne. Relacijska pohrana koja podržava samo dodavanje, uz stroge dozvole pisanja, kontrolirane radne procese ispravljanja, dnevnik revizije i pouzdane sigurnosne kopije, pruža vam operativnu i revizijsku nepromjenjivost. Tehnologija blockchain dodaje distribuiranu zaštitu od neovlaštenog mijenjanja, ali donosi poteškoće s privatnošću, performansama i ispravljanjem koje rade protiv zahtjeva europskog računovodstva i GDPR-a. Za većinu platformi ona rješava problem koji zapravo nemaju.

Može li nepromjenjiva glavna knjiga čuvati podatke zauvijek prema GDPR-u?

Zadržavanje računovodstvenih evidencija tijekom zakonski propisanog razdoblja je u redu. Neograničeno čuvanje potpunih osobnih podataka ili sadržaja plaćanja samo zato što je glavna knjiga nepromjenjiva nije u redu. Čuvajte novčane činjenice i pseudonimizirane reference u nepromjenjivoj jezgri, a osobne podatke držite u zasebnom sustavu s odgovarajućim radnim procesom čuvanja i brisanja. Nepromjenjivost se odnosi na financijski događaj, a ne na svaki dio podataka koji je s njim povezan.