Hvað einkennir óbreytanlegan tvíhliða bókhalds-API (immutable double-entry ledger API)

Bókhaldskerfi (ledger) fyrir markaðstorg einkennist ekki af því hvort það geymir peningafærslur - flest kerfi gera það. Það einkennist af því hvað gerist þegar greiðslumiðlari sendir sama vefskilaboðið (webhook) tvisvar, þegar endurgreiðsla berst eftir að seljanda he ऑलरेडी verið greitt út, eða þegar endurskoðandi spyr hvernig staða seljanda hafi náð núverandi tölu. Þau augnablik sýna hvort um er að ræða óbreytanlegan tvíhliða bókhalds-API (immutable double-entry ledger API) eða breytanlegan gagnareit með bjartsýnu nafni.

Fyrir markaðstorg (marketplace platform) er stutta svarið þetta: óbreytanlegur tvíhliða bókhalds-API skráir alla fjárhagslega mikilvæga atburði sem jafnaða færslu í dagbók (journal transaction), bókar hana á atómískan hátt (atomically), skrifar hana aldrei yfir og gerir þér kleift að leiða út stöður, afstemma við utanaðkomandi kerfi og flytja út ferilinn með sjálfvirkum hætti. Allt annað eru smáatriði sem hanga á þeim kjarna.

Jafnaðar dagbókarfærslur, ekki hlaupandi staðareitur

Skýrasta prófunin er hvernig API-ið birtir stöðu seljanda. Ef staðan er tala sem forritið þitt hækkar beint er um að ræða annað en tvíhliða bókhald. Ef staðan er afleidd sýn af bókuðum dagbókarlínum gæti það átt við.

Hver færsla æáb að bera jafnháar debet- og kreditfærslur. Þegar kaupandi greiðir 100 evrur fyrir pöntun þar sem markaðstorgið tekur 15 evra þóknun, skráir bókhaldskerfið að millireikningur (clearing account) er debetfærður um 100 evrur á móti skuld við seljanda (seller payable) sem er kreditfærð um 85 evrur og þóknunartekjum sem eru kreditfærðar um 15 evrur. Hvor tveggja hliðarnar passa alltaf saman í sömu tölu. Sú kerfisbundna regla grípur fjölda villna áður en þær ná inn í skýrslu.

Dagbókarfærsla ætti að sýna að lágmarki:

• Einstakt, óbreytanlegt færslunúmer (transaction ID)
• Debet- og kreditlínur, hver um sig með reikningi, fjárhæð og gjaldmiðli
• Gildisdag og bókunartímasetningu
• Viðskiptaatrog (sala, endurgreiðsla, útborgun, endurgreiðslukrafa / chargeback)
• Auðkenni fyrir sjálfsbætingu (idempotency key)
• Upprunatilvísun í pöntun, greiðslu eða atburð frá veitanda
• Stöðu (í bið, bókað, afturkallað)
• Þjónustuna eða skilríkin sem bjuggu færsluna til

Lausafé seljanda verður þá fyrirspurn gegn þessum línum, en ekki gildi sem einhver uppfærði í forritakóða. Þetta skiptir máli vegna þess að beint breytt staðsetning missir ástæðuna fyrir hverri hreyfingu. Líkan Nordlet meðhöndlar tvíhliða bókhald sem hinn rétta skrifveg: hvert skjal bókar jafnaðar dagbókarfærslur og gagnagrunnurinn sjálfur synjar um ójafnaðar færslur. Það er rétta sjálfgefna valkosturinn fyrir alla sem samþætta bókhald inn í markaðstorg.

Bókun eingöngu í viðbótartalningu (append-only) með jöfnunarleiðréttingum

„Óbreytanlegt“ ætti að þýða að ekki sé hægt að breyta bókaðri færslu á staðnum. Mistök eru leiðrétt áfram, ekki eyddu út. Röng þóknunarfærsla fær afturköllun sem dregur þá gömlu til baka, og síðan leiðrétta færslu sem skráir ætlaða niðurstöðu. Báðar vísar í hina upphaflegu og endurskoðunarslóðin sýnir hver hafi átt frumkvæði að breytingunni og hvenær.

API-ið ætti að hafna venjulegum UPDATE og DELETE aðgerðum á bókuðum bókhaldsfærslum. Það gæti leyft þér að tengja fjárhagslega óviðkomandi lýsigögn (metadata), svo sem tilvísun í stuðningsmál, svo fremi sem fjárhæðir, reikningar og tímasetningar haldist ósnertar.

Það hjálpar til við að aðgreina þrjá hluti sem fólk ruglar oft saman:

• Starfræn óbreytanleiki (operational immutability): notendur forritsins geta ekki breytt eða eytt bókuðum röðum.
• Endurskoðunaróbreytanleiki (audit immutability): kerfið getur sýnt fram á að sagan hafi ekki breyst.
• Lagaleg varðveisla: gögn eru geymd þann tíma sem gildandi lög krefjast.

Venslagagnagrunnur sem tekur aðeins við viðbótum (append-only relational database) með ströngum heimildum, afritum og aga ferlum við afturköllun skilar raunverulega óbreytanlegu bókhaldskerfi. Blokklínur (blockchain) eru ekki skilyrði hér, og fyrir evrópsk bókhaldsgögn valda þær venjulega vandamálum varðandi persónuvernd og leiðréttingar sem vega þyngra en það innbrotsskjöl sem þær bæta við.

Atómvirkni og sjálfsbæting (idempotency)

Atburður á markaðstorgi verður að bókast á atómískan hátt. Annað hvort ganga allar dagbókarlínur í gegn eða engin þeirra. Ef 100 evra móttaka er skráð en 15 evra þóknunin vantar verður til ójafnað, villandi niðurstaða sem einhver þarf að greiða úr síðar. Nordlet framfylgir þessu undir forritunarlaginu: seinkaður gagnagrunnsreiti (database trigger) athugar að hver færsla sé í jafnvægi á bókunarstundu, þannig að ójafnaðri færslu verður aldrei komið í gegn.

Sjálfsbæting (idempotency) er þar sem flestar samþættingar brotna hljóðlega. Greiðslukerfi reyna aftur við netbilanir og uppgjörsskrár eru keyrðar aftur. Án sjálfsbætingarlykils (idempotency key) sem bundinn er við leigjanda (tenant) eða reikning, býr ein endurtekin beiðni til tvítekið bókhald. Endurtekin beiðni með sama lykli ætti að skila hinni upphaflegu færslu, en ekki annarri til viðbótar.

Lykillinn ætti að tengjast upprunalegum atburði, tegund atburðar, atburðarnúmeri veitanda, lögaðila og hrislu (hash) af beiðnigögnum. Ef sami lykill berst með annarri fjárhæð eða gjaldmiðli ætti API-ið að líta á það sem árekstur og hafna því í stað þess að samþykkja nýju gögnin hljóðlega. Hljóðleg samþykkt er leiðin til þess að endurskoðunarslóðir rotni. Idempotency-Key hausinn hjá Nordlet virkar þannig: endurtekning með sama lykli og gögnum endurspilar geymdu svarinu, og sama lykli með öðrum gögnum er hafnað með idempotency_key_reuse. Það er lítill eiginleiki með gríðarleg áhrif á afstefmun.

Fjölaðila skiptibókhald (multi-party split accounting)

Pöntun á markaðstorgi er ekki ein hreyfing. Ein sala getur snert fjármuni kaupanda, tekjur seljanda, þóknun markaðstorgs, greiðslumiðlunargjöld, virðisaukaskatt á þóknun, sendingarkostnað og bindifjárhæðir (reserves). Bókhaldskerfið þarf reikningsskipulag sem heldur þessu aðskildu í stað þess að þjappa þessu saman í eina hreina tölu.

Það er algengur misskilningur sem ástæða er til að knýja gegn: „skiptaútborgun“ (split payout) greiðslumiðlunar er ekki það sama og bókhald markaðstorgs. Að skipta peningum á milli viðtakenda beinist að reiðufé. Það gefur þér ekki fullkomna, óbreytanlega skrá yfir áunnin þóknun, innheimtan VSK, endurgreiðslur sem skuldast eða bindifjárhæðir. Þ þarft samt þitt eigið bókhaldskerfi og þú þarft samt að afstemma það við veitandann.

Bókhaldskerfi markaðstorgs ætti einnig að greina á milli fleiri en einnar stöðu seljanda:

Stöðustaða (Balance state)	Hvað hún táknar
Í bið (Pending)	Fjármunir sem tengjast atburði en eiga ekki rétt á úttekt enn þá
Tiltækt (Available)	Fjármunir sem standast reglur um losun, bindifjárhæðir, endurgreiðslur og ágreining
Haldið / frátekið (Held / reserved)	Fjárhæðir sem haldið er eftir vegna endurgreiðslukrafna, skilavara eða svikavarna
Útborgað (Paid out)	Fjárhæðir sem færðar hafa verið til seljanda
Neikvætt / endurheimtanlegt (Negative / recoverable)	Fjárhæðir sem seljandi skuldar eftir að endurgreiðslur eða gjöld fara yfir tiltækt fé

Að flytja peninga úr biðstöðu í tiltæka stöðu ætti sjálft að vera jöfnuð dagbókarfærsla, ekki endurmerktur reitur.

Afturköllun, endurgreiðslur og neikvæðar stöður

Peningar á markaðstorgi flæða í báðar áttir, oft í röngum tímaröðum. Erfiðu tilvikin eru endurgreiðslur eftir útborgun og endurgreiðslukröfur (chargebacks) sem berast vikum síðar. Alvöru bókhaldskerfi skilgreinir hvað verður um þegar tiltæk staða seljanda getur ekki mætt endurgreiðslu: býr til neikvæða stöðu, flytur fjárhæðina yfir í kröfur á seljanda, gengur á bindifjárhæð eða takmarkar frekari útborgun.

Hver þessara atburða ætti að vísa í upphaflegu færsluna og varðveita hana. Bókhaldskerfið skráir fjárhagslegar afleiðingar endurgreiðslu. Það ákveður ekki endurgreiðslustefnu markaðstorgsins eða lagalega ábyrgð. Að halda þeim mörkum skýrum kemur í veg fyrir margar ruglingslegar hönnunarumræður.

Gjaldmiðlar og nákvæmni

Markaðstorg yfir landamæri þurfa skýra meðferð peninga. Fjárhæðir ættu að nota ISO 4217 gjaldmiðlakóða og nákvæma framsetningu, annað hvort heiltölueiningar í undireiningum (minor units) eða fastar tugabrotastrengja, aldrei fleytitölur (floats). Engar hljóðlegar afmyndanir. Þegar gjaldeyrisbreyting á sér stað ætti bókhaldskerfið að varðveita upphaflegu fjárhæðina, gengið, heimild gengisins, tímasetningu og niðurstöðufjárhæðina, þar sem sléttunarmunur (rounding differences) er bókaður á tilgreindan reikning.

Ein jöfnuð færsla ætti ekki að blanda saman gjaldmiðlum án skýrs gjaldeyriskerfis. Ef hún gerir það munu skýrslur þínar ósamræmast veruleikanum á þann hátt sem er sársaukafullt að rekja í lok mánaðar.

Afstemming við utanaðkomandi kerfi

Innanlands jafnað bókhaldskerfi er ekki eitt og sér fullnaðarsönnun. Það þarf að vera í samræmi við umheiminn: færslur greiðslumiðlara, gjöld veitunnar, uppgjörsskýrslur, bankayfirlit, útborgunarskrár og skýrslur um endurgreiðslukröfur.

Þroskaður API styður innflutta ytri atburði og samsvörunarstöður eins og passað (matched), að hluta passað (partially matched), ópassað (unmatched), tvítekið (duplicate), misræmi í fjárhæð (amount mismatch) og þarf skoðun (needs review). Mismunur í afstefmingu ætti að búa til skýr undantekningartilvik (exception records) eða bókhaldsfærslur. Þær ættu aldrei hljóðlega að skrifa sögu bókhaldsins upp á nýtt. Nálgun Nordlet við bankaafstemmingu og greiðslusamvinnu byggir á þessu: innflutt yfirlit og Stripe útflutningur sleppir öllu sem þegar hefur verið flutt inn, greiðslutillögum er gefin einkunn eftir fjárhæð, tilvísun, gagnaðila og IBAN, einskellismellssamsvörun (one-click matching) sér um venjuleg tilvik og undantekningar eru teknar fram í stað þess að gleypast.

Evrópsk mörk sem API ætti að virða, og þau sem það getur ekki

Þetta er þar sem markaðssetningin á það til að hlaupa fram úr raunveruleikanum. Bókhaldskerfi hjálpar til við skyldur í Evrópu, en það fullnægir þeim ekki eitt og sér.

VSK (VAT). Bókhaldskerfið ætti að varðveita skattalega mikilvæga þætti: lögsögu, skatthlutfall, skattaflokk og hvernig hlutfallið var ákveðið. Það ætti að aðgreina sölu seljanda til kaupanda frá þóknun markaðstorgsins, og aðgreina VSK af gjöldum frá fjármunum sem einfaldlega fara í gegn. Nordlet sér um VSK útreikninga eftir löndum, VIES staðfestingu og i.SAF skráagerð, ásamt OSS og IOSS sviðsmyndum sem markaðstorg í Evrópu lenda í. Líttu á bókhaldskerfið sem sönnun gögn og skattavél, en ekki sem skattaráðgjöf.

DAC7. Reglur um skýrslugjöf vettvanga krefjast áreiðanlegra tengsla á milli auðkennis seljanda, lögsögu, heildarfærslna, gjalda, endurgreiðslna og útborgana. Jafnað bókhaldskerfi skilar færslusönnunum. Það ákveður ekki hvort seljandi sé tilkynningarskyldur, og það kemur ekki í stað KYC, innleiðingar (onboarding) eða skýrslugerðarferlisins. Haltu færslubókhaldi og eftirlitsskýrslugjöf aðskildum.

PSD2 og eignarvarsla fjármuna. Að skrá peningahreyfingar er ekki það sama og að vera leyfisbundin greiðsluþjónusta eða varðveita fjármuni. Bókhaldskerfið ætti að gera flæði fjármuna og aðila ljóst. Það getur ekki, eitt og sér, veitt heimild fyrir greiðsluþjónustu eða sannað að reiðufé sé geymt á ákveðnum reikningi. Það er enn spurning um reglugerðarhlutverk þitt og greiðslumiðlara þinn (PSP).

GDPR. Óbreytanleiki skapar raunverulega spennu við persónuverndarreglur. Öruggasta arkitektúrinn geymir fjárhagslegar staðreyndir í óbreytanlegum kjarna og persónugreinanleg gögn utan hans. Notaðu stöðugar dulnefndar tilvísunarnúmer á seljendur og viðskiptavini í dagbókarlínum. Geymdu breytanlegar persónuupplýsingar í aðskildu, aðgangsstýrðu kerfi með sínu eigin varðveislu- og eyðingarferli. „Óbreytanlegt“ er ekki leyfi til að geyma alla greiðslupakka að eilífu.

Gátlisti til að meta API-bókhaldskerfi

Eiginleikamerki eru ódýr. Prófaðu hegðunina í sandkassa (sandbox) í staðinn. Keyrðu þessar sviðsmyndir og athugaðu sönnunargögnin:

• Bókaðu 100 evra pöntun skipt á milli seljanda og markaðstorgs, og staðfestu jafnaða dagbók með skýrum reikningum.
• Sendu sömu beiðni tvisvar og staðfestu eina færslu, engin tvítekning.
• Reyndu að breyta bókaðri færslu og staðfestu að henni sé hafnað eða hún takmörkuð við fjárhagslega óviðkomandi lýsigögn.
• Leiðréttu ranga þóknun og staðfestu tengda afturköllun ásamt leiðréttri færslu.
• Gerðu hlutaendurgreiðslu eftir útborgun og staðfestu rekjanlega endurgreiðslu með kröfu á seljanda eða neikvæðri stöðu þar sem þörf krefur.
• Endurspilaðu vefskilaboðum frá veitanda og staðfestu uppgötvun tvítekingar.
• Unnið uppgjör í mörgum gjaldmiðlum og staðfestu gjaldeyrisatriði og breytingabókhald.
• Fyrirspyrðu stöðu seljanda í lok tímabils og staðfestu endurmatssnið með skjalfestum skiladegi.
• Flytdu inn uppgjör veitanda og staðfestu samsvörun með undantekningsstöðu sem skilur sögu óskerta.
• Flyttu út mánaðarvirkni og staðfestu fullkomið, síðuskipt, endurtekningarhæft útdrátt.

Sterkustu sönnunargögnin eru skjöl ásamt endurtekningarhæfri prófun. Orð eins og „rauntími“, „tilbúið fyrir endurskoðun“ og „óbreytanlegt“ þýða ekkert án gagnalíkansins, villumerkinganna og varðveislunnar á bak við þau.

Það sem við myndum athuga fyrst

Ef við værum að meta bókhalds-API á morgun fyrir markaðstorg, myndum við byrja á tveimur hlutum áður en við litum á eitthvað annað. Í fyrsta lagi, sannaðu að staða seljanda sé leidd af dagbókarlínum en ekki breytanlegum reit, þar sem allt annað niður eftir ferlinu byggir á því. Í öðru lagi, endurspilaðu sama vefskilaboðinu og staðfestu nákvæmlega eina bókhaldsniðurstöðu. Þessi tvö próf segja þér meira um gæði undirliggjandi hönnunar en nokkur eiginleikalisti.

Eftir það skipta API-fyrstu atriðin máli um hversu hratt teymið þitt sendir frá sér: slóðasett (typed SDKs), vefskilaboð fyrir atburði eins og sale_invoice.paid, virkur sandkassi og tímabilalæsing (period locking) til að vernda lokaða mánuði. Nordlet var byggt í kringum þetta líkan, með sama eiginleikasett í gegnum API og í gegnum smáforritið, sem gerir vettvangi kleift að reka endurskoðunarhæft bókhald innan sinnar eigin vöru í stað þess að skeyta við þriðja aðila útritun. Fyrir stærri myndina af þess hvernig slíkt bókhald passar inn í vistkerfi markaðstorgs, sjá leiðarvísisgrein okkar um tvíhliða bókhalds-API fyrir bókhald markaðstorga.

FAQ

Tryggir tvíhliða bókhald að bókhaldið mitt sé rétt?

Nei. Bókhaldskerfi getur verið alveg í jafnvægi á meðan það bókar á röng reikninga, beitir rangri VSK-meðferð eða úthlutar fjármunum á rangann seljanda. Jafnvægi er kerfisbundið stjórntæki sem grípur reikningsvillur og vantar hliðar færslu. Það segir ekkert um hvort viðskiptafræði þín hafi kortlagt atburðinn rétt. Þess vegna skiptir sandkassaprófun gegn raunverulegum sviðsmyndum meira máli en jafnvægisathugunin ein og sér.

Er bókhaldskerfi greiðslumiðlara nægilegt fyrir markaðstorg?

Venjulega ekki. Greiðslumiðlari fylgist með fjármunum innan síns eigin kerfis, sem er gagnlegt fyrir hreyfingu og útborgun. Markaðstorgið þitt þarf samt sín eigin gögn fyrir þóknunartekjur, skuldbindingar við seljendur, VSK af gjöldum, endurgreiðslur, bindifjárhæðir, ágreining og stjórnendaskýrslur. Kerfin tvö verða að vera afstimuð og með því að meðhöndla sýn greiðslumiðlarans sem þitt bókhald skilur eftir eyður sem koma í ljós við endurskoðun.

Þarf ég blokklínu til að gera bókhald óbreytanlegt?

Nei. Venslagagnagrunnur sem tekur aðeins við viðbótum með ströngum skrifheimildum, stýrðum leiðréttingarferlum, endurskoðunarskráningu og áreiðanlegum afritum veitir þér rekstrarlegan og endurskoðunarlegan óbreytanleika. Blokklína bætir við dreifðri innbrotssönnun en veldur vandamálum varðandi persónuvernd, afköst og leiðréttingar sem vinna gegn evrópskum bókhalds- og GDPR-kröfum. Fyrir flest markaðstorg leysir hún vandamál sem þau eiga ekki.

Getur óbreytanlegt bókhald geymt gögn að eilífu samkvæmt GDPR?

Það er í lagi að varðveita bókhaldsgögn í lagalega krafinn tíma. Að varðveita full persónugreinanleg gögn eða greiðslupakka endalaust vegna þess að bókhaldskerfið er óbreytanlegt er það ekki. Geymdu fjárhagslegar staðreyndir og dulnefndar tilvísanir í óbreytanlegum kjarna og hafðu persónuupplýsingar í aðskildu kerfi með réttri varðveislu og eyðingu. Óbreytanleiki á við um fjárhagslegan atburð, ekki hverja einustu gagnagetu sem tengist honum.