Kaj je API za dvostavno knjigovodstvo za tržnice?
API za dvostavno knjigovodstvo beleži pretok denarja na tržnici kot usklajene, nespremenljive knjižbe, da vedno veste, komu in zakaj ste nekaj dolžni.
Tržnica je lahko videti povsem zdrava v tabeli naročil (orders), hkrati pa so njeni finančni podatki popolnoma napačni. V naročilu piše „plačano“. Na nadzorni plošči prodajalca jeviden dobroimetje. Vendar pa nobena vrstica v tej tabeli ne dokazuje, koliko gotovine ima platforma dejansko pri sebi, koliko je dolžna posameznemu prodajalcu, kolikšen del plačila predstavlja prihodke iz naslova provizij ali kolikšen davek na dodano vrednost je treba plačati. API za dvostavno knjigovodstvo obstaja prav zato, da te finančne posledice beleži pravilno, in sicer eno usklajeno transakcijo naenkrat.
Povedano preprosto: API za dvostavno knjigovodstvo je programirljiv računovodski sistem. Vaša aplikacija mu pošlje finančni dogodek, kot je zajeto plačilo ali odobren izplačilo, glavna knjiga pa ta dogodek zabeleži kot dnevniško knjižbo z enakimi bremeni in dobroimetji na ustreznih kontih. Knjiga ne premika denarja. Beleži resnico o denarju, ki se je premaknil drugje.
Kaj v tem kontekstu pomeni „dvostavno knjigovodstvo“
Glavna knjiga je zapis o spremembah na kontih in ne tabela, v kateri je shranjeno samo zadnje stanje. Delujoča glavna knjigovodska evidenca temelji na treh povezanih konceptih:
- konto: poimenovan finančni položaj, na primer terjatve do ponudnika plačilnih storitev, obveznosti do prodajalcev, prihodki od provizij ali obveznosti za DDV.
- transakcija (dnevniška knjižba): en sam atomarni finančni dogodek, ki vsebuje več usklajenih vrstic.
- knjižba (postavka): posamezna vrstica bremenitve ali dobrega v tej transakciji.
Invarianta, ki drži skupaj celotno zasnovo, je preprosta: vsota vseh bremenitev mora biti enaka vsoti vseh dobroimetij, in sicer za vsako transakcijo in valuto. API-ji glavne knjige običajno zavrnejo neusklajen zapis, preden ta sploh pride do hrambe. Dokumentacija podjetja Modern Treasury opredeljuje transakcijo v glavni knjigi kot dogodek, ki vključuje dva ali več kontov z vsaj enim bremenom in enim dobroimetjem enakih skupnih zneskov, knjiženo transakcijo pa obravnava kot nespremenljivo.
Dvostavno knjigovodstvo ne pomeni nujno natanko dveh vrstic. Posamezna prodaja na tržnici pogosto zahteva eno bremenitev in več dobroimetij. To je tisti del, ki ga ljudje najpogosteje napačno razumejo.
Zakaj tržnice potrebujejo glavno knjigo in ne le tabele plačil
Tržnica vzdržuje več finančnih odnosov hkrati. Kupec plača. Ponudnik plačilnih storitev izvede poravnavo. Platforma morda začasno upravlja sredstva. Prodajalec si prisluži svoj delež. Platforma obdrži provizijo. Nastane obveznost za davek. Morda se zadrži rezerva. Pozneje izplačilo premakne denar izven sistema, vračila kupnin ali ugovori plačil (chargeback) pa del tega obrnejo.
Tabela plačil (payments) vam lahko pove komercialni status naročila. Vendar pa vam ne more zanesljivo povedati:
- kolikšne so terjatve do ponudnika plačilnih storitev ali gotovina,
- koliko je dolžno posameznemu prodajalcu,
- kolikšen prihodek pripada platformi,
- koliko DDV-ja je treba plačati in v kateri državi,
- kaj je rezervirano za primere vračil ali sporov,
- ali je izplačilo zmanjšalo pravilno obveznost do prodajalca,
- ali se poravnave ponudnika plačilnih storitev ujemajo s tistim, kar je platforma pričakovala.
Nordletov vodnik po API-jih za dvostavno knjigovodstvo za računovodstvo na tržnicah postavlja jasno mejo: tabele aplikacij opisujejo stanje izdelkov, medtem ko glavna knjiga beleži finančne posledice tega stanja. Izpostavlja tudi misel, ki jo je vredno ponoviti, in sicer da so poročila ponudnikov plačilnih storitev vhodi za usklajevanje in ne popolne dvostavne knjige.
Primer praktične prodaje na tržnici
Predpostavimo, da kupec plača 100 EUR, prodajalec je upravičen do 85 EUR, provizija platforme pa znaša 15 EUR. Zaradi preglednosti zanemarimo DDV in provizije ponudnika plačilnih storitev.
| Konto | V breme | V dobro | Razlog |
|---|---|---|---|
| Terjatve do ponudnika plačilnih storitev | 100 EUR | Ponudnik je platformi dolžan zajeto plačilo | |
| Obveznosti do prodajalcev | 85 EUR | Platforma je dolžna prodajalcu | |
| Prihodki od provizij | 15 EUR | Platforma si je prislužila provizijo | |
| Skupaj | 100 EUR | 100 EUR | Usklajeno |
Pomembna klasifikacija tukaj je, da je znesek 85 EUR, ki je dolžan prodajalcu, obveznost in ne prihodek platforme. V skladu z opredelitvenim okvirom IFRS je obveznost sedanja obveznost prenosa gospodarskega viri. Tržnica ne sme celotnih prihodkov od prodaje prodajalca prikazati kot lastni prihodek samo zato, ker je kupec plačal prek nje. Ne glede na to, ali nastopate kot posrednik, principal ali domnevni dobavitelj, se obravnava spremeni, vendar mehanizem glavne knjige ostane nespremenjen.
Ko prodajalec izpolni pogoje za izplačilo, se ne pripozna nov prihodek. Poravnate obveznost:
| Konto | V breme | V dobro |
|---|---|---|
| Obveznosti do prodajalcev | 85 EUR | |
| Denarna sredstva na banki ali prehodni račun izplačil | 85 EUR | |
| Skupaj | 85 EUR | 85 EUR |
Če ponudnik plačilnih storitev pred poravnavo odtegne provizijo v višini 3 EUR, se denarni tok spremeni v dnevniško knjižbo s tremi vrsticami: 97 EUR na bančno gotovino, 3 EUR v stroške obdelave plačil, 100 EUR v breme terjatev do ponudnika plačilnih storitev. Vsaka sprememba položaja ima svoj izvor in cilj.
Kako deluje API, korak za korakom
1. Vaša aplikacija zazna poslovni dogodek. Plačilo je zajeto, naročilo izpolnjeno, izplačilo odobreno, izdano vračilo kupnine, odprt ugovor plačila, poravnava je prispela. Vaša baza podatkov še vedno upravlja operativno stanje. Glavna knjiga pa beleži denarni učinek.
2. Pošljete strukturiran zahtevek. Običajno vsebuje vrsto dogodka, znesek in valuto, ID naročila ali plačila, identifikatorje kupca in prodajalca, provizijo, davčne podatke, vključene konte, datume veljavnosti in knjiženja, ključ za enkratnost izvedbe (idempotency key) ter metapodatke, ki se povezujejo nazaj s podatki o ponudniku plačilnih storitev in izdelkih. Nordletov primer javnega API-ja prikazuje konceptualni zahtevek za prodajo z ID-jem prodajalca, vrsto prodaje, zneskom, valuto ter državo in stopnjo DDV-ja.
3. API izvede preverjanje veljavnosti. Preveri, ali so bremena in dobroimetja usklajena, ali konti obstajajo in omogočajo knjiženje, ali je valuta podprta, ali znesek uporablja natančno obdelavo manjših enot (minor-unit), ali ključ za enkratnost izvedbe ni bil ponovno uporabljen za drugačen rezultat, ali je obračunsko obdobje odprto in ali so prisotni zahtevani metapodatki. Neuspešno preverjanje za seboj ne pusti delnih dnevniških zapisov.
4. Knjiženje se izvede atomarno. Celotna transakcija se zapisuje kot enotna celota. Nikoli se ne sme zgoditi, da bi zabeležili bremenitev, medtem ko ustrezno dobroimetje propade. Pri tržnici bi lahko delna razdelitev ustvarila navidezno dobroimetje prodajalca brez ustrezne gotovine ali pa knjižila provizijo brez obveznosti do prodajalca.
5. Stanja in poročila izvirajo iz glavne knjige. Po knjiženju lahko berete stanja kontov, čakajoča in razpoložljiva stanja prodajalcev, bruto in neto bilanco, dejavnost v glavni knjigi, povzetke DDV-ja in zgodovino na pretekli dan. Dobroimetje prodajalca mora biti mogoče rekonstruirati iz knjižb in ne temeljiti na spremenljivem polju, ki mu slepo zaupate.
6. Spletni kljukci (webhooks) obveščajo vaš izdelek. Dogodki, kot so sale_invoice.paid, knjižena dnevniška knjižba, razpoložljivo izplačilo ali izjema pri usklajevanju, so vam posredovani. Obdelajte jih enkratno (idempotentno). Spletni kljukec je obvestilo in ne dovoljenje za ponovno uveljavitev finančnega dogodka. Konvencije API-ja podrobno obravnavajo obsege, ključe za enkratnost izvedbe, oblike napak in podpisovanje spletnih kljukcev.
Stanja dobroimetij prodajalcev niso le enaka eni sami številki
Večina tržnic zaide v težave, ker dobroimetje prodajalca obravnava kot en sam znesek. Denar mora biti razporejen v naslednja stanja:
| Stanje | Pomen |
|---|---|
| V teku (Pending) | Prodajalec je morda upravičen do sredstev, vendar pogoji za sprostitev še niso izpolnjeni |
| Na voljo (Available) | Primerno za izplačilo |
| Rezervirano (Reserved) | Zadržano za primere vračil, reklamacij ali sporov |
| Izplačano (Paid out) | Obveznost poravnana s prenosom |
| Negativno (Negative) | Vračila, ugovori plačil ali provizije presegajo razpoložljiva sredstva |
To odražajo tudi modeli ponudnikov plačilnih storitev. Ločeni tokovi bremenitev in prenosov pri storitvi Stripe omogočajo platformi, da obremeni lasten račun, nato pa del sredstev prenese na povezane račune, pri čemer provizije, vračila in ugovori bremenijo dobroimetje platforme. Tržnični model ponudnika Adyen loči uporabniške račune dobroimetja, na katerih so sredstva shranjena do izplačila, od odgovornega računa dobroimetja (liable balance account), ki lahko pokrije negativna stanja zaradi vračil ali ugovorov plačil. Ti podatki so uporabni vhodi v vašo glavno knjigo, niso pa vaš celoten računovodski model.
Izplačila in zaslužki prodajalcev se zgodijo ob različnih časih
Prodajalec lahko zasluži sredstva v ponedeljek, izplačilo pa prejme naslednji ponedeljek. V vmesnem času je naročilo izpolnjeno, zadržana je rezerva, sestavljen je sveženj izplačil, ponudnik plačilnih storitev izvede poravnavo z zmanjšanjem za provizije in prispe nakazilo na banko. Glavna knjiga mora ohraniti vsako posamezno stopnjo in ne prebrisati naročila s končnim stanjem „plačano“. To vam omogoča, da pojasnite časovne razlike med aktivnostjo naročil, upravičenostjo prodajalca, poravnavo, začetkom izplačila in prejemom sredstev na banko.
Vračila in ugovori plačil: obrnite knjižbe, ne prebrišite jih
Vračila kupnin in ugovori plačil (chargeback) so novi dogodki, povezani z izvirnim plačilom. V nespremenljivi glavni knjigi napake popravite s storno knjižbo, ki ji sledi pravilna knjižba, tako da izvirni dogodek ostane viden za revizijo. Modern Treasury obravnava knjižene transakcije kot nespremenljive in podpira ključe za enkratnost izvedbe (idempotency keys), s čimer preprečuje podvajanje predmetov ob ponovnih poskusih.
Vračilo kupnine običajno zmanjša gotovino ali terjatve do kupcev, obrne obveznost do prodajalca, lahko glede na politiko obrne del provizije, prilagodi davek in lahko porabi rezervo za vračila. Ugovor plačila zmanjša gotovino ali terjatve do ponudnika plačilnih storitev, lahko ponovno odpre znesek, ki ga dolguje prodajalec ali platforma, zabeleži strošek spora in provizijo ponudnika ter premakne sredstva prek rezervnega računa.
Usklajevanje: povezovanje glavne knjige z dejanskim denarjem
Glavna knjiga je lahko interno usklajena, hkrati pa so njeni podatki o zunanjem svetu napačni. Usklajevanje primerja interne evidence z zunanjimi dokazili: poročili o poravnavah ponudnikov plačilnih storitev, bančnimi izpiski, datotekami izplačil ter evidencami vračil in sporov.
Delujoča zanka je videti takole:
- Uvozite poravnavo ali bančni sveženj.
- Vsako vrstico povežite z naročilom, plačilom, vračilom, provizijo, izplačilom ali sporom.
- Primerjajte pričakovani bruto znesek, odbitke, rezerve in neto znesek.
- Potrjene premike knjižite v glavno knjigo.
- Neusklajene postavke pošljite na določen prehodni račun (suspense account).
- Raziščite izjeme.
- Zaklenite obdobje.
Gradivo o usklajevanju podjetja Nordlet opisuje prav to: uvoz svežnjev poravnav, ujemanje bremenitev in vračil ter usmerjanje neusklajenih prejemkov na prehodne račune namesto ugibanja o vsebini računa. Dve vrsti preverjanj sta ključni, pri čemer nobena ne nadomešča druge: preverjanje dvostavnega knjigovodstva sprašuje, ali je vsak dnevniški zapis usklajen, usklajevanje pa sprašuje, ali se ujema s ponudnikom plačilnih storitev, banko in poslovnim dogodkom.
Oblikovne podrobnosti, ki odločajo o vašem uspehu
Enkratnost izvedbe (Idempotency). Povežite ključ s stabilnim dogodkom, kot je payment_captured:pi_123. Ponovni poskus vrne prvotni rezultat in ne ustvari drugega dnevnika.
Atomarnost. Vse vrstice posameznega dogodka se knjižijo skupaj ali pa nobena.
Nespremenljivost in stornacije. Knjižena zgodovina ni zgolj popravljiva z običajnimi posodobitvami. Popravki ustvarjajo povezane knjižbe, ki ohranjajo prvotni znesek, datum, klasifikacijo, razlog in avtorja.
Natančen denar. Brez binarnih plavajočih vejic (floating point). Uporabite cele manjše enote ali natančne decimalke, eksplicitno valuto in deterministično pravilo za zaokroževanje pri delitvah. Če razdelite 100 EUR med prodajalce in provizije brez ustreznega pravila, bo osamljen cent porušil vaše ravnovesje.
Dejavni datum (effective date) proti datumu knjiženja (posting date). Čas, ko je kupec plačal, čas, ko si je prodajalec prislužil sredstva, čas, ko je banka izvedla poravnavo, in čas knjiženja so različni datumi. Njihovo enačenje naredi poročanje po obdobjih in časovno usklajevanje davkov nezanesljivo.
Večvalutnost. V breme in v dobro mora biti usklajeno znotraj posamezne valute. Pretvorba zahteva ekspliciten valutni dogodek s konti za provizijo, zaokroževanje ter morebitne tečajne dobičke ali izgube. Sprejemanje polja za valutu (currency) ne spremeni glavne knjige v menjalniški mehanizem.
Česa API glavne knjige ne bo storil namesto vas
Ne bo določil vašega kontnega načrta. Še vedno morate sami ugotoviti, ali nastopate kot principal ali posrednik, kdaj je provizija prislužena, katera stran nosi provizije ponudnika plačilnih storitev, kako vračila vplivajo na provizijo ter kako se obračunava in poroča DDV. Nordletovo priporočilo je, da najprej preslikate denarne tokove, pripravite osnutek kontnega načrta, ga daste v pregled računovodji, nato pa pred širitvijo implementirate en celoten tok od naročila prek izplačila do usklajevanja.
Ne bo reševal davčnih vprašanj. DDV je odvisen od lokacije kupca in prodajalca, vrste izdelka, statusa registracije in pravil o domnevnem dobavitelju; vodnik po EU DDV-ju določa, kaj mehanizem izračuna in kaj označi za človeški pregled. Področje pokrivanja DDV-ja podjetja Nordlet je osredotočeno na EU in EGP, zato se ne razširja na ameriški prometni davek ali latinskoameriško e-fakturiranje. Prav tako ne bo rešil operativnih dvomov, kot so vprašanja, ali se je obdobje za vračilo izteklo, ali je treba izplačilo blokirati ali ali je plačilo prevarantsko. To so vaše odločitve. Glavna knjiga beleži le njihov finančni rezultat.
Kje se umešča Nordlet
Nordlet je računovodski API, zgrajen za platforme in tržnice, z nespremenljivo glavno knjigo z dvostavnim knjigovodstvom, izplačili, obravnavo DDV-ja v EU, končnimi točkami REST (REST endpoints), tipiziranimi kompleti SDK in spletnimi kljukci, ki so dostopni prek ene same površine. Njegova izrazita značilnost je vgrajeno računovodstvo znotraj vašega lastnega izdelka in ne zunanji postopek zaključevanja nakupa. V času pisanja je izdelek v zgodnjem dostopu s peskovnikom za načrtovalce (sandbox for design partners), zato ga obravnavajte kotli odličen primer te kategorije ter pred odločitvijo preverite produkcijsko zrelost, delovni čas (uptime) in jurisdikcijsko pokrivanje za vaš primer.
Za razvijalce tržnic in platform je koristen miselni vz 모델 prehod med pretokom plačil in finančno resnico. Vaš ponudnik plačilnih storitev premika denar. API za dvostavno knjigovodstvo beleži, komu se kaj dolguje, kaj ste zaslužili, kakšne davke in rezerve nosite ter ali se zunanji svet ujema z vašimi poslovnimi knjigami.
FAQ
Ali je API za dvostavno knjigovodstvo isto kot ponudnik plačilnih storitev?
Ne. Ponudnik plačilnih storitev avtorizira, zajame, poravna in včasih izplača sredstva. API glavne knjige beleži računovodske posledice teh dogodkov. Večina tržnic uporablja oboje: ponudnika, kot sta Stripe ali Adyen, za pretok sredstev ter glavno knjigo za poslovne knjige.
Ali lahko preprosto uporabljam nadzorno ploščo svojega ponudnika plačilnih storitev kot glavno knjigo?
Lahko poskusite, vendar boste sčasoma padli na reviziji. Poročanje ponudnika prikazuje bremenitve, provizije, prenose in poravnave, vendar običajno ne odraža vaših celotnih obveznosti do prodajalcev, davčnih obveznosti, stroškov, ki niso povezani s ponudnikom, ali računovodskih popravkov. Obravnavajte ga kot vhodni podatek za usklajevanje.
Ali uravnotežena glavna knjiga pomeni, da so moje poslovne knjige pravilne?
Samo to, da vaše knjižbe izpolnjujejo pravilo bremena in dobrega. Popolnoma uravnotežena transakcija je lahko še vedno knjižena na napačen konto, napačnemu prodajalcu ali z napačno davčno obravnavo. Ravnovesje je nujno, vendar ni zadostno. Usklajevanje je tisto, ki ujame preostalo.
Če je glavna knjiga nespremenljiva, kako popravim napake?
Knjižite storno postavko in nato pravilno knjižbo. Prvotna ostane vidna, kar je tudi glavni namen. Nespremenljivost ščiti revizijsko sled, ne pa vas ujame v pasti vaših napak.
Ali me računovodski API samodejno naredi skladnega s predpisi?
Ne. Uveljavlja računovodsko strukturo in ustvarja uporabne zapise. Zakonska skladnost je še vedno odvisna od vaše jurisdikcije, pogodbene vloge, davčne obravnave, plačilnih predpisov, postopkov KYC in AML ter obveznosti poročanja.