Što je API za dvojno knjigovodstvo za internetske tržnice (marketplaces)?
API za dvojno knjigovodstvo bilježi kretanje novca na internetskoj tržnici u obliku uravnoteženih, nepromjenjivih knjiženja kako biste uvijek znali tko kome i zašto duguje.
Internetska tržnica (marketplace) može izgledati financijski zdravo u tablici narudžbi (orders), a da pritom ima potpuno krive podatke o novcu. U narudžbi piše „plaćeno“. Na nadzornoj ploči prodavatelja vidljiv je saldo. Međutim, ništa u toj tablici ne dokazuje koliko gotovine platforma drži, koliko duguje pojedinom prodavatelju, koliki dio uplate predstavlja prihod od provizije ili koliki je PDV dospio za naplatu. API za dvojno knjigovodstvo (double-entry ledger API) služi upravo tome da ispravno zabilježi te financijske posljedice, i to jednu po jednu uravnoteženu transakciju.
Jednostavno rečeno: API za dvojno knjigovodstvo jest programabilni računovodstveni sustav. Vaša mu aplikacija šalje financijski događaj, poput naplaćene uplate ili odobrene isplate, a glavna knjiga (ledger) taj događaj zapisuje u obliku dnevnika s jednakim dugovnim i potražnim iznosima na imenovanim računima. Ona ne premješta novac. Ona bilježi istinu o novcu koji se premjestio negdje drugdje.
Što ovdje znači „dvojno knjigovodstvo“
Glavna knjiga je zapis o promjenama na računima, a ne tablica koja prikazuje samo posljednji saldo. Funkcionalna glavna knjiga temelji se na tri povezana pojma:
- Konto (account): imenovana financijska pozicija, poput potraživanja od procesora plaćanja, obveza prema prodavateljima, prihoda od provizija ili obveza za PDV.
- Transakcija (dnevnik / journal): jedan atomski financijski događaj koji sadrži više uravnoteženih stavki.
- Stavka (posting / entry): pojedinačna dugovna ili potražna linija unutar te transakcije.
Invarijanta koja povezuje cijeli dizajn jest jednostavna: ukupni dugovni iznosi jednaki su ukupnim potražnim iznosima, za svaku transakciju i svaku valutu. API-ji glavne knjige obično odbijaju neuravnotežen unos prije nego što on uopće dospije u pohranu. Dokumentacija platforme Modern Treasury definira transakciju u glavnoj knjizi kao transakciju koja uključuje dva ili više računa s najmanje jednim dugovnim i jednim potražnim iznosom jednakih zbrojeva, te knjiženu transakciju tretira kao nepromjenjivu (immutable).
Dvojno knjiženje ne znači nužno točno dva retka. Jedna prodaja na internetskoj tržnici često zahtijeva jedno dugovno i nekoliko potražnih knjiženja. Upravo je to dio koji ljudi najčešće pogrešno shvaćaju.
Zašto internetskim tržnicama treba glavna knjiga, a ne samo tablica plaćanja
Internetska tržnica u isto vrijeme održava nekoliko financijskih odnosa. Kupac plaća. Procesor izvršava namiru (settlement). Platforma možda privremeno upravlja sredstvima. Prodavatelj zarađuje svoj dio. Platforma zadržava proviziju. Porez dospijeva na naplatu. Može se zadržati i jamčevni polog (reserve). Kasnije isplata odlijeva novac, a povrati ili povrati sredstava (chargebacks) poništavaju dijelove tih iznosa.
Tablica plaćanja (payments) može vam reći kakav je komercijalni status narudžbe. No ona vam ne može pouzdano reći:
- koliko potraživanja od procesora ili gotovine postoji
- koliko se duguje pojedinom prodavatelju
- koliki prihod pripada platformi
- koliki je PDV plativ i u kojoj državi
- koliki je iznos rezerviran za povrate ili sporove
- je li isplata smanjila ispravnu obvezu prema prodavatelju
- odgovaraju li namire procesora onome što je platforma očekivala
Nordletov vodič kroz API-je dvojnog knjigovodstva za računovodstvo internetskih tržnica jasno povlači granicu: tablice u aplikaciji opisuju stanje proizvoda, dok glavna knjiga bilježi financijske posljedice tog stanja. Također ističe vrijednu napomenu da su izvješća procesora plaćanja ulazni podaci za usklađivanje, a ne potpune dvojne knjige.
Primjer prodaje na internetskoj tržnici
Pretpostavimo da kupac plaća 100 €, prodavatelju pripada 85 €, a provizija platforme iznosi 15 €. Radi jasnoće zanemarimo PDV i naknade procesora.
| Konto | Duguje | Potražuje | Razlog |
|---|---|---|---|
| Potraživanja od procesora plaćanja | 100 € | Procesor duguje platformi naplaćeni iznos | |
| Obveze prema prodavateljima | 85 € | Platforma duguje prodavatelju | |
| Prihod od provizija | 15 € | Platforma je zaradila proviziju | |
| Ukupno | 100 € | 100 € | Uravnoteženo |
Važna je klasifikacija prema kojoj iznos od 85 € koji se duguje prodavatelju predstavlja obvezu, a ne prihod platforme. Prema konceptualnom okviru MSFI-ja (IFRS), obveza je sadašnja obveza prijenosa ekonomskog resursa. Internetska tržnica ne bi trebala prikazivati cjelokupan prihod od prodaje prodavatelja kao vlastiti prihod samo zato što je kupac platio putem nje. Vaša uloga – bilo da nastupate kao posrednik (agent), principal ili smatrani dobavljač (deemed supplier) – mijenja postupanje, ali mehanizam glavne knjige ostaje isti.
Kada prodavatelj stekne pravo na isplatu, ne priznaje se nikakav novi prihod. Time se zatvara obveza:
| Konto | Duguje | Potražuje |
|---|---|---|
| Obveze prema prodavateljima | 85 € | |
| Novčana sredstva na banci ili prijelazni račun isplata | 85 € | |
| Ukupno | 85 € | 85 € |
Ako procesor prije namire naplati naknadu od 3 €, kretanje gotovine postaje trodijelni dnevnik: 97 € na bankovnu gotovinu, 3 € na trošak obrade, a 100 € se skida s potraživanja od procesora. Svaka promjena pozicije ima svoj izvor i odredište.
Kako API funkcionira, korak po korak
1. Vaša aplikacija detektira poslovni događaj. Naplaćena je uplata, ispunjena narudžba, odobrena isplata, izdan povrat, otvoren povrat sredstava (chargeback) ili je sjela namira. Vaša baza podataka i dalje upravlja operativnim stanjem. Glavna knjiga bilježi novčani učinak.
2. Šaljete strukturirani zahtjev. Obično sadrži vrstu događaja, iznos i valutu, ID narudžbe ili plaćanja, identifikatore kupca i prodavatelja, proviziju, porezne podatke, uključene konte, datume valute i knjiženja, ključ idempotencije (idempotency key) te metapodatke koji se vežu na zapise procesora i proizvoda. Nordletov primjer javnog API-ja prikazuje konceptualni zahtjev za prodaju s ID-jem prodavatelja, vrstom prodaje, iznosom, valutom te zemljom i stopom PDV-a.
3. API obavlja provjeru valjanosti. Provjerava jesu li dugovna i potražna strana uravnotežene, postoje li konta i može li se na njih knjižiti, je li valuta podržana, koristi li iznos precizno rukovanje manjim novčanim jedinicama (minor units), nije li ključ idempotencije ponovno iskorišten za drugačiji rezultat, je li razdoblje otvoreno i jesu li prisutni potrebni metapodaci. Neuspjela provjera ne ostavlja nikakve djelomične zapise u dnevniku.
4. Knjiži se atomski. Cijela se transakcija zapisuje kao jedna cjelina. Nikada se ne smije dogoditi da se zabilježi dugovna stavka, dok pripadajuća potražna strana ne uspije. Kod internetskih tržnica djelomično dijeljenje moglo bi stvoriti prividni saldo prodavatelja bez odgovarajuće gotovine ili uknjižiti proviziju bez obveze prema prodavatelju.
5. Salda i izvješća izvode se iz glavne knjige. Nakon knjiženja možete pročitati salda računa, pending i available salda prodavatelja, zaključnu bilancu (trial balance), promet glavne knjige, pregled PDV-a i povijesne podatke na određen datum u prošlosti. Saldo prodavatelja mora se moći rekonstruirati iz knjiženja, a ne oslanjati se na promjenjivo polje u bazi.
6. Webhookovi obavještavaju vaš proizvod. Događaji poput sale_invoice.paid, proknjiženi dnevnik, dostupna isplata ili iznimka pri usklađivanju šalju se vašem sustavu. Obradite ih idempotentno. Webhook je obavijest, a ne dozvola za ponovnu primjenu financijskog događaja. API konvencije detaljno pokrivaju raspone (scopes), ključeve idempotencije, oblike pogrešaka i potpisivanje webhookova.
Salda prodavatelja nisu jedinstven broj
Većina internetskih tržnica upada u probleme tretirajući saldo prodavatelja kao jednu znamenku. Novac bi se trebao nalaziti u različitim stanjima:
| Stanje | Značenje |
|---|---|
| Na čekanju (Pending) | Prodavatelj možda ima pravo na sredstva, ali uvjeti za isplatu nisu ispunjeni |
| Dostupno (Available) | Spremno za isplatu |
| Rezervirano (Reserved) | Zadržano za pokriće povrata, reklamacija ili sporova |
| Isplaćeno (Paid out) | Obveza podmireno prijenosom |
| Negativno (Negative) | Povrati, povrati sredstava ili naknade premašuju raspoloživa sredstva |
Modeli procesora odražavaju ovu podjelu. Stripeov tijek odvojenih terećenja i prijenosa (charges and transfers) omogućuje platformi da tereti vlastiti račun, a zatim prenosi dijelove povezanim računima, pri čemu naknade, povrati i povrati sredstava terete saldo platforme. Adyenov marketplace model razlikuje račune stanja korisnika (user balance accounts), koji drže sredstva do isplate, od računa zaduženog salda (liable balance account) koji može apsorbirati negativna stanja nastala uslijed povrata ili sporova. Oni su koristan ulazni podatak za vašu glavnu knjigu, ali nisu vaš cjeloviti računovodstveni model.
Isplate i zarade prodavatelja događaju se u različito vrijeme
Prodavatelj može ostvariti zaradu u ponedjeljak, a isplatu primiti idući ponedjeljak. Između tih točaka narudžba se ispunjava, zadržava se jamčevni polog, sastavlja se skupna isplata, procesor izvršava namiru umanjenu za naknade i pristiže bankovni polog. Glavna knjiga mora sačuvati svaku fazu umjesto da prepisuje narudžbu konačnim statusom „plaćeno“. Upravo vam to omogućuje da objasnite vremenske razlike između aktivnosti narudžbe, prava prodavatelja, namire, pokretanja isplate i primitka bankovne uplate.
Povrati i povrati sredstava (chargebacks): stornirajte, nemojte prepisivati
Povrati i povrati sredstava novi su događaji povezani s izvornim plaćanjem. U nepromjenjivoj glavnoj knjizi ispravke vršite stornirajućim knjiženjem praćenim ispravnim knjiženjem, čime izvorni zapis ostaje vidljiv radi revizije. Modern Treasury tretira proknjižene transakcije kao nepromjenjive i podržava ključeve idempotencije kako bi se spriječili dvostruki objekti prilikom ponovnih pokušaja (retry).
Povrat obično smanjuje gotovinu ili potraživanja od kupca, stornira obvezu prema prodavatelju, može ovisno o politici stornirati dio provizije, prilagođava porez i može iskoristiti rezervu za povrate. Povrat sredstava (chargeback) smanjuje gotovinu ili potraživanja od procesora, može ponovno otvoriti iznos koji prodavatelj ili platforma duguju, bilježi trošak spora i naknadu procesora te premješta sredstva kroz račun rezerve.
Usklađivanje (reconciliation): povezivanje glavne knjige sa stvarnim novcem
Glavna knjiga može biti unutrašnje uravnotežena, a da je pritom u krivu u odnosu na vanjski svijet. Usklađivanjem se uspoređuju interni zapisi s vanjskim dokazima: izvješćima o namiri procesora, bankovnim izvodima, datotekama isplata te zapisima o povratima i sporovima.
Funkcionalni postupak izgleda ovako:
- Uvoz namire ili bankovne serije.
- Uparivanje svake stavke s narudžbom, uplatom, povratom, naknadom, isplatom ili sporom.
- Usporedba očekivanog bruto iznosa, odbitaka, rezervi i neto iznosa.
- Knjiženje potvrđenih kretanja u glavnu knjigu.
- Slanje neuparenih stavki na imenovani privremeni račun (suspense account).
- Istraživanje iznimaka.
- Zaključivanje razdoblja.
Nordletovi materijali o usklađivanju opisuju upravo to: uvoz serija namire, uparivanje stavki naplate i povrata te usmjeravanje neuparenih primitaka na privremeni račun umjesto nagađanja o kojoj se fakturi radi. Dvije provjere imaju važnost, pri čemu jedna ne zamjenjuje drugu: provjera dvojnog knjigovodstva pita je li svaki dnevnik uravnotežen, dok usklađivanje pita slaže li se on s procesorom, bankom i poslovnim događajem.
Pojedinosti dizajna o kojima ovisi uspjeh
Idempotencija. Vežite ključ uz stabilan događaj, poput payment_captured:pi_123. Ponovni pokušaj vraća izvorni rezultat, a ne drugi dnevnik.
Atomnost. Sve stavke jednog događaja knjiže se zajedno ili se ne knjiži nijedna.
Nepromjenjivost i storniranja. Proknjiženi povijesni podaci ne mogu se uređivati uobičajenim ažuriranjima. Ispravci stvaraju povezane stavke koje čuvaju izvorni iznos, datum, klasifikaciju, razlog i autora.
Precizan novac. Nema binarnog pokretnog zareza (floating point). Koristite cjelobrojne manje jedinice ili točne decimale, eksplicitnu valutu i determinističko pravilo zaokruživanja za raspodjele. Ako dijelite 100 € na prodavatelje i naknade bez definiranog pravila, zalutali će cent narušiti vaš saldo.
Datumi valute i knjiženja. Trenutak kada je kupac platio, kada je prodavatelj zaradio, kada je banka obavila namiru i kada je stavka proknjižena različiti su datumi. Njihovo poistovjećivanje čini izvještavanje po razdobljima i vremensko usklađivanje poreza nepouzdanima.
Viševalutnost. Dugovna i potražna strana trebaju biti uravnotežene unutar valute. Konverzija zahtijeva eksplicitni događaj tečaja s računima za naknadu, zaokruživanje i eventualne tečajne dobitke ili gubitke. Prihvaćanje polja currency ne čini glavnu knjigu valutnim mehanizmom.
Što API glavne knjige neće učiniti umjesto vas
Neće umjesto vas odrediti vaš kontni plan. I dalje morate sami utvrditi jeste li principal ili posrednik, kada je provizija zarađena, koja stranka snosi naknade procesora, kako povrati utječu na proviziju te kako se PDV obračunava i prijavljuje. Nordletova vlastita preporuka jest da prvo mapirate novčane tijekove, izradite nacrt kontnog plana, zatražite od računovođe da ga pregleda, a zatim implementirate jedan cijeli tijek od narudžbe preko isplate i usklađivanja prije nego što krenete u širenje poslovanja.
Neće riješiti porezna pitanja. PDV ovisi o lokaciji kupca i prodavatelja, vrsti proizvoda, poreznom statusu i pravilima o smatranom dobavljaču; vodič za EU PDV navodi što mehanizam sam izvodi, a što označava kao potrebu za ljudskom provjerom. Nordletov obuhvat PDV-a usmjeren je na EU i EGP, stoga se ne proteže na porez na promet u SAD-u (sales tax) ni na e-fakturiranje u Latinskoj Americi. Također neće riješiti operativnu dvosmislenost: je li isteklo razdoblje za povrat, treba li blokirati isplatu ili je li plaćanje prijevarno. To su vaše odluke. Glavna knjiga bilježi njihov financijski rezultat.
Gdje se Nordlet uklapa
Nordlet je računovodstveni API stvoren za platforme i internetske tržnice, s nepromjenjivom glavnom knjigom dvojnog knjigovodstva, isplatama, obradom EU PDV-a, REST krajnjim točkama (endpoints), tipiziranim SDK-ovima i webhookovima dostupnim kroz jedno sučelje. Njegova prepoznatljiva značajka jest ugrađeno računovodstvo unutar vašeg vlastitog proizvoda umjesto korištenja naplate treće strane. U trenutku pisanja ovog teksta proizvod je u ranoj fazi dostupnosti (early access) uz sandbox za partnere u dizajnu, stoga ga promatrajte kao snažan primjer te kategorije te prije donošenja odluke o implementaciji procijenite njegovu produkcijsku zrelost, radno vrijeme sustava (uptime) i pokrivenost nadležnosti za vaš specifičan slučaj.
Za programere internetskih tržnica i platformi koristan mentalni model jest podjela između kretanja plaćanja i financijske istine. Vaš procesor premješta novac. API za dvojno knjigovodstvo bilježi tko kome što duguje, što ste zaradili, koje poreze i rezerve nosite te usklađuje li se vanjski svijet s vašim knjigama.
FAQ
Je li API za dvojno knjigovodstvo isto što i procesor plaćanja?
Ne. Procesor odobrava, naplaćuje, provodi namiru i ponekad isplaćuje sredstva. API glavne knjige bilježi računovodstvene posljedice tih događaja. Većina internetskih tržnica koristi oboje: procesor poput Stripea ili Adyena za kretanje novca, a glavnu knjigu za knjigovodstvo.
Mogu li jednostavno koristiti nadzornu ploču svog procesora kao glavnu knjigu?
Možete pokušati, ali s vremenom ćete pasti na reviziji. Izvješća procesora prikazuju terećenja, naknade, prijenose i namire, ali obično ne prikazuju vaše cjelokupne obveze prema prodavateljima, porezne obveze, troškove koji nisu vezani uz procesor ili računovodstvene ispravke. Smatrajte ih ulaznim podacima za usklađivanje.
Znači li uravnotežena glavna knjiga da su mi knjige ispravne?
Samo to da vaši unosi zadovoljavaju pravilo duguje-potražuje. Savršeno uravnotežena transakcija i dalje može biti proknjižena na krivi konto, krivom prodavatelju ili s krivim poreznim tretmanom. Uravnoteženost je nužan, ali ne i dovoljan uvjet. Usklađivanje je ono što hvata ostale pogreške.
Ako je glavna knjiga nepromjenjiva, kako ispravljam pogreške?
Knjižite stornirajuću stavku, a zatim ispravnu. Izvorni zapis ostaje vidljiv, što i jest njegova svrha. Nepromjenjivost štiti revizijski trag, a ne zarobljava vaše pogreške.
Čini li me računovodstveni API automatski usklađenim sa zakonima?
Ne. On provodi računovodstvenu strukturu i proizvodi uporabljive zapise. Pravna usklađenost i dalje ovisi o vašoj nadležnosti, ugovornoj ulozi, poreznom tretmanu, propisima o plaćanju, KYC i AML procesima te obvezama izvješćivanja.