Divkāršā ieraksta virsgrāmatas API tirgum paredzētajai grāmatvedībai

Lielākā daļa tirdzniecības platformu jeb marketplace saprot, ka tām ir problēmas ar grāmatvedību, vienā un tajā pašā veidā: uzņēmumā sāk strādāt jauns finanšu speciālists, atver izmaksu izklājlapu un uzdod jautājumu, kurš īsti reģistrē saistības pret pārdevējiem brīdī starp pircēja veikto maksājumu un līdzekļu aizplūšanu no platformas konta. Inženieru komanda norāda uz tabulu transactions. Finanšu speciālists norāda, ka notikumu tabula nav grāmatvedības reģistru kopa. Šo plaisu starp notikumu datiem un reālo grāmatvedību arī ir paredzēts aizpildīt ar divkāršā ieraksta virsgrāmatas API.

Šis ir tehniska rakstura jautājums, kam ir arī juridiska un normatīva nozīme. Tirdzniecības platformas tur citu cilvēku naudu, aprēķina PVN dažādās jurisdikcijās un izraksta rēķinus pārdevēju vārdā. Veikt šīs darbības, izmantojot pašu veidotu darījumu tabulu, darbojas līdz brīdim, kamēr revidents, valsts ieņēmumu dienests vai nopietns pircējs pieprasa pierādījumus.

Kas patiesībā ir divkāršā ieraksta virsgrāmatas API

Divkāršā ieraksta virsgrāmatas API ir programmējams grāmatvedības dzinējs, kas pieejams caur HTTP protokolu. Katrs finansiālais notikums, ko reģistrē jūsu platforma, tiek ierakstīts kā sabalansēts žurnāla ieraksts: vismaz viens debeta un viens kredīta ieraksts, kuru kopsummas ir vienādas, grāmatoti norādītajos kontos kontu plānā. API nodrošina šo bilances līdzsvaru ierakstīšanas brīdī un glabā ierakstus tā, ka tos vēlāk nav iespējams nemanāmi labot.

Jēdziens "divkāršs ieraksts" ir četrsimt gadus sens grāmatvedības likums, saskaņā ar kuru katrs darījums ietekmē vismaz divus kontus. Savukārt "API" nozīmē, ka izsaucējs ir jūsu produkts, nevis cilvēks-grāmatvedis. Jēdziens "nemainīgs" (immutable) nozīmē, ka labojumi tiek veikti, izmantojot korigējošos ierakstus, nevis labojot vēsturi. Kopā šīs trīs īpašības padara iegūtos grāmatvedības reģistrus gatavus revīzijai, nevis vienkārši sakārtotus.

Praktisks darba definējums:

Divkāršā ieraksta virsgrāmatas API pieņem finansiālos notikumus no jūsu lietojumprogrammas, katru no tiem pārvērš par sabalansētu žurnāla ierakstu atbilstoši noteiktam kontu plānam, glabā šos ierakstus nemaināmā veidā un nodrošina piekļuvi iegūtajai virsgrāmatai, apgrozījuma bilancei un finanšu pārskatiem, izmantojot paredzamus galapunktus (endpoints).

Nordlet ir izveidots, balstoties tieši uz šo ideju: reāli grāmatvedības reģistri kā API, kur virsgrāmata, PVN loģika, rēķinu izrakstīšana un saskaņošana ir pieejamas no tās pašas galapunktu kopas, ar kuru jūsu produkts jau mijiedarbojas.

Kāpēc tas īpaši nepieciešams tirdzniecības platformām

Viens tirgotājs vai SaaS uzņēmums bieži var iztikt ar datu sinhronizēšanu ar vispārējo grāmatvedības rīku reizi dienā. Tirdzniecības platformas to nevar trīs iemeslu dēļ.

Pirmkārt, tās atrodas naudas plūsmas centrā. Pircējs samaksā platformai, platforma patur līdzekļus un pēc tam izmaksā tos pārdevējiem, atskaitot komisijas maksu. Katra no šīm kustībām ir atsevišķs grāmatvedības notikums, kas ietekmē dažādus kontus: skaidro naudu, saistības pret pārdevējiem, platformas ieņēmumus, maksājamo PVN, atmaksu rezerves. Tabula payments ar kolonnu status to neattēlo.

Otrkārt, tās darbojas dažādās nodokļu jurisdikcijās. ES tirdzniecības platformai ar pārdevējiem Lietuvā, Vācijā un Polijā, kā arī pircējiem visā blokā ir jāpiemēro pareizais PVN režīms katram darījumam, jāpārbauda pārdevēju PVN numuri VIES sistēmā un jāsagatavo atskaites, kas apmierina katras vietējās iestādes prasības. Šīs sistēmas pareiza darbība lietojumprogrammas kodā un tās vēlāka saskaņošana ar atsevišķu grāmatvedības sistēmu ir vieta, kur lielākā daļa tirdzniecības platformu klusi pieļauj kļūdas.

Treškārt, apjoms nav piemērots manuālai grāmatvedībai. Platforma, kas mēnesī veic desmit tūkstošus pasūtījumu, ģenerē desmitiem tūkstošu žurnāla ierakstu. Tam ir jābūt automatizētam no gala līdz galam, pretējā gadījumā finanšu komanda kļūst par izaugsmes vājo vietu.

Kā API darbojas soli pa solim

Mehānika ir mazāk sarežģīta, nekā izklausās. Tipiska tirdzniecības platformas pasūtījuma plūsma izskatās šādi.

1. Jūsu platforma ģenerē finansiālu notikumu. Pircējs pabeidz norēķinu. Jūsu aizmugursistēma (backend) izsauc virsgrāmatas API ar šādiem datiem: pasūtījuma ID, pircējs, pārdevējs, bruto summa, PVN likme, platformas komisija, valūta un idempotences atslēga (idempotency key).

2. Virsgrāmata izveido žurnāla ierakstu. API pārvērš šo notikumu debetpunktos un kredītpunktos. Vienkāršam tirdzniecības platformas pārdošanas darījumam tas varētu nozīmēt debeta ierakstu ceļā esošās skaidras naudas kontā, kredīta ierakstu pārdevēja saistību kontā par neto summu, kredīta ierakstu platformas ieņēmumu kontā par komisijas maksu un kredīta ierakstu maksājamā PVN kontā par nodokļa daļu. Viss ir sabalansēts. Viss tiek grāmatots atomāri.

3. Ieraksts tiek ierakstīts nemaināmā veidā. Pēc grāmatošanas ierakstam ir identifikators un laika zīmogs, un to nevar labot. Ja kaut kas nav kārtībā, jūs iegrāmatojat korigējošo ierakstu un laboto ierakstu. Revīzijas izsekojamība ir šī procesa galvenais mērķis.

4. Lejteces pārskati tiek atjaunināti reāllaikā. Apgrozījuma bilance, pārdevēju saistību atlikumi, PVN kopsavilkumi un peļņas vai zaudējumu aprēķins atspoguļo jauno ierakstu nekavējoties. Nav nakts datu apstrādes darbu, nav eksportēšanas, nav saskaņošanas loga, kurā skaitļi "nostabilizējas".

5. Webhook paziņojumi informē jūsu sistēmu. Tādi notikumi kā sale_invoice.paid vai bank_transaction.matched tiek nosūtīti uz jūsu galapunktiem, lai jūsu produkts varētu reaģēt bez pastāvīgas datu vaicāšanas (polling). Apvienojumā ar idempotences atslēgām tas nozīmē, ka atkārtoti mēģinājumi ir droši un dublikāti nerodas tīkla kļūmju gadījumā.

Svarīgs arhitektūras aspekts: virsgrāmata ir patiesības avots par to, kas noticis finansiālā ziņā. Jūsu lietojumprogrammas datubāze ir patiesības avots par produkta stāvokli. Abas sistēmas saskaņojas, jo virsgrāmata tiek aizpildīta, pamatojoties uz lietojumprogrammas notikumiem, nevis otrādi.

Kontu plāns ir vieta, kur notiek galvenais projektēšanas darbs

Lielākā daļa intelektuālā darba, iestatot virsgrāmatu tirdzniecības platformai, ir saistīta ar kontu plānu. Šis ir nosaukto kontu saraksts, kurā nonāk debeta un kredīta summas: skaidras naudas konti pa bankām, pārdevēju saistību konti (bieži vien pa vienam katram pārdevējam vai viens kopējs konts ar apakšvirsgrāmatām), platformas ieņēmumi pa kategorijām, maksājamais PVN pa valstīm, atmaksu rezerves, prasību (chargeback) rezerves un tā tālāk.

Daži modeļi, kas atkārtojas dažādās tirdzniecības platformās:

• Pārdevēju līdzekļi ir saistības, nevis ieņēmumi. Nauda, ko jūs turat pārdevēju vārdā, ir saistības. Tās uzskatīšana par ieņēmumiem un vēlāka izmaksu norakstīšana izdevumos ir klasiķa kļūda, kas parādās finanšu un juridiskajā izpētē (due diligence).
• PVN ir atsevišķas saistības katrā valstī. Ja jūs darbojaties vairākās ES jurisdikcijās, jums ir nepieciešami atsevišķi maksājamā PVN konti katrā valstī, lai atskaites veidotos precīzi.
• Komisijas maksas ir jāmodelē brīdī, kad tās tiek nopelnītas, nevis tad, kad tās tiek izmaksātas. Uzkrāšanas grāmatvedība šeit nav izvēles iespēja.
• Atmaksām, prasībām un strīdiem ir nepieciešami savi konti, lai peļņas un zaudējumu aprēķins atspoguļotu realitāti, nevis pozitīvu un negatīvu pārdošanas darījumu virpuli.

Labs virsgrāmatas API ļauj definēt šo struktūru vienu reizi un pēc tam droši veikt ierakstus, nevis no jauna izgudrot grāmatvedības loģiku savā norēķinu kodā.

Nemainīgums, periodu slēgšana un iemesls, kāpēc revidentiem tas rūp

Nemainīgums izklausās pēc datubāzes tehniskās detaļas. Patiesībā tā ir atšķirība starp grāmatvedības reģistriem, kurus revidents parakstīs, un tādiem, kurus neparakstīs.

Ja tirdzniecības platforma var nemanāmi labot iepriekšējā ceturkšņa ierakstus, tad iepriekšējā ceturkšņa skaitļi grāmatvedības izpratnē nav nosakāmi. Nemainīga virsgrāmata ievieš likumu, ka vēsture paliek vēsture. Labojumi ir redzami kā labojumi. Periodu slēgšana to papildina: kad mēnesis ir slēgts, šajā periodā nevar tikt veikti jauni ieraksti vai labojumi bez skaidras atkārtotas atvēršanas darbības, kas pati par sevi tiek reģistrēta žurnālā.

Platformām, kuras nākotnē piesaistīs finansējumu, tiks pārdotas vai saskarsies ar nodokļu revīziju, tas nav vienkārši "patīkams papildinājums". Tā ir lieta, kas padara grāmatvedības datus aizstāvamus. Nordlet virsgrāmata pēc noklusējuma ir izstrādāta, balstoties uz šo principu, un nemainīgā divkāršā ieraksta struktūra un periodu slēgšana tajā ir iebūvēta, nevis pievienota vēlāk.

ES PVN: daļa, kas patērē inženieru laiku

PVN ir joma, kurā lielākā daļa tirdzniecības platformu grāmatvedības projektu pārsniedz plānoto laiku. Noteikumi nav vienkārši "piemērot procentu". Tie ir atkarīgi no tā, kur atrodas pircējs, kur atrodas pārdevējs, kas tiek pārdots, vai pārdevējs ir reģistrēts kā PVN maksātājs, vai tirdzniecības platforma saskaņā ar 2021. gada e-komercijas noteikumiem tiek uzskatīta par piegādātāju (deemed supplier), un kurš ziņošanas režīms attiecas uz vietējo tirgu.

Nopietnam virsgrāmatas API ES reģionā ir jānodrošina vismaz:

• VIES pārbaude pārdevēju un pircēju PVN numuriem, ideālā gadījumā ar rezultātu saglabāšanu kešatmiņā un pievienošanu darījumam
• PVN likmju loģika katrai valstij, ieskaitot samazinātās likmes un atbrīvojumus
• i.SAF reģistra ģenerēšana Lietuvas atskaitēm un līdzvērtīgi strukturēti dati, ja to pieprasa citas dalībvalstis
• Peppol BIS 3.0 e-rēķinu izrakstīšana jurisdikcijām, kuras pāriet uz obligāto elektronisko rēķinu apriti
• OSS/IOSS apstrāde pārrobežu B2C pārdošanas darījumiem

Veikt šo procesu lietojumprogrammas kodā katrai valstij ir pilnvērtīgs inženieru komandas darbs, kas nekad īsti nebeidzas, jo noteikumi turpina mainīties. Šīs funkcionalitātes pārvietošana uz virsgrāmatas līmeni ir pragmatisks lēmums.

Saskaņošana ir vieta, kur parādās laika ietaupījums

Kad virsgrāmata kļūst par patiesības avotu, bankas konta izrakstu saskaņošana pārstāj būt ikmēneša murgs. Bankas izraksti tiek saņemti, virsgrāmata jau zina, kam tur vajadzētu atrasties, un saskaņošana lielā mērā notiek automātiski.

Reālistiska šī procesa versija nav "nulle manuālā darba". Tā ir "izņēmumu situāciju nonākšana redzeslaukā". Ar vienu klikšķi veicama saskaņošana deviņdesmit procentiem darījumu, kas precīzi sakrīt, un rinda ar desmit procentiem darījumu, kuriem nepieciešams cilvēka lēmums, ir aptuveni tas, ko nodrošina labi izstrādāts saskaņošanas API. Vieda maksājumu saskaņošana apstrādā daļējus maksājumus, pārmaksas un maksājumus, kas sedz vairākus rēķinus, bez nepieciešamības cilvēkam rakstīt noteikumus katram gadījumam.

SEPA eksports (pain.001 formātā) piegādātāju un pārdevēju izmaksām noslēdz ciklu izejošo maksājumu pusē. Jūs apstiprināt izmaksas savā produktā, virsgrāmata ģenerē SEPA failu, jūsu banka to apstrādā, un rezultātā notikusī naudas kustība tiek automātiski saskaņota atpakaļ.

Izstrādāt pašam, iegādāties vai integrēt

Tirdzniecības platformu komandas parasti izskata trīs iespējamos ceļus. Lūk, kā tie salīdzinās pēc būtiskākajiem kritērijiem.

Pieeja	Laiks līdz nonākšanai ražošanā	Gatavība revīzijai	ES PVN apstrāde	Iekļaujas jūsu produktā
Izstrādāt savu virsgrāmatu	12 līdz 24+ mēneši	Pilnībā atkarīgs no jūsu komandas	Jums tas jāizstrādā katrai valstij pašiem	Jā
Sinhronizēt ar Xero/QuickBooks	Nedēļas	Laba grāmatvedības pusei, vāja tirgum specifiskām plūsmām	Daļēja, nepieciešami papildinājumi	Nē, atrodas atsevišķā rīkā
Integrēt virsgrāmatas API (piem., Nordlet)	Nedēļas	Iebūvēta, pateicoties nemainīgajai virsgrāmatai un periodu slēgšanai	Iebūvēta ES, ieskaitot VIES un i.SAF	Jā, caur API un SDK

Pašu izstrādāta sistēma ir pamatojama tad, ja grāmatvedība ir jūsu produkts. Visiem pārējiem šāds aprēķins reti kad atmaksājas. Sinhronizācija ar tradicionālo grāmatvedības rīku darbojas uzņēmumiem ar vienu juridisko personu, bet tā cieš neveiksmi tirdzniecības platformu plūsmu priekšā: sadalītie maksājumi, pārdevēju apakšvirsgrāmatas, PVN pa valstīm un platformas kā piegādātāja (deemed supplier) scenāriji nav viegli kartējami rīkiem, kas paredzēti viena uzņēmuma grāmatvedībai.

API pirmās kārtas virsgrāmatas integrēšana ir risinājums, uz kuru virzās lielākā daļa moderno platformu. Grāmatvedības dati atrodas jūsu produkta lietotāja saskarnē, pārdevēji redz savus finanšu datus jūsu saskarnē, un atbilstības prasību smagais darbs tiek paveikts infrastruktūras līmenī.

Kam pievērst uzmanību, izvērtējot virsgrāmatas API

Īss kontrolsaraksts, ko vērts turēt pa rokai sarunās ar pakalpojumu sniedzējiem:

• Nemainīga divkāršā ieraksta krātuve ar korigējošo ierakstu labojumiem, nevis labojamām rindām
• Periodu slēgšana ar reģistrētām perioda atkārtotas atvēršanas darbībām
• Idempotences atslēgos katram rakstīšanas galapunktam
• Webhook paziņojumi notikumiem, uz kuriem jūsu produktam jāreaģē, nevis tikai datu vaicāšanas API
• Tipizēti SDK programmēšanas valodās, kuras jūsu komanda reāli izmanto
• PVN loģika katrai valstij, ieskaitot VIES, i.SAF vai ekvivalentus, kā arī OSS un IOSS
• Vairāku uzņēmumu atbalsts, ja pārvaldāt vairākas juridiskās personas vai plānojat to darīt
• Lomu piekļuves kontrole, kas ir pietiekami detalizēta, lai nodalītu izstrādātājus, grāmatvežus un skatītājus
• Pārskatu eksports XLSX, PDF un JSON formātos ar webhook paziņojumiem, kad lieli pārskati ir gatavi
• Smilšu kaste (sandbox), kas atspoguļo ražošanas vides uzvedību, nevis vienkāršotu demonstrācijas versiju

Ja pakalpojumu sniedzējs tehniskajā sarunā nevar nodemonstrēt pirmās trīs prasības, pārējam vairs nav nozīmes.

Ko es darītu vispirms

Ja tirdzniecības platforma sāk šo darbu no nulles, secība, kas ietaupa visvairāk pūļu:

1. Uz tāfeles uzzīmējiet reālās naudas plūsmas pirms jebkura koda rakstīšanas. Kurš ir parādā kam, kurā brīdī, kādā valūtā, ar kādu PVN režīmu.
2. Balstoties uz šo shēmu, izveidojiet kontu plāna melnrakstu. Pārdevēju saistības, platformas ieņēmumi, maksājamais PVN pa valstīm, rezerves. Pirms nonākšanas ražošanā lūdziet grāmatvedim to pārskatīt.
3. Izvēlieties virsgrāmatas līmeni. Izveidojiet pašas, sinhronizējiet vai integrējiet. Esiet godīgi pret sevi attiecībā uz to, kuru no šiem variantiem jūsu komanda reāli spēj piegādāt un uzturēt.
4. Ieviesiet vienu plūsmu no gala līdz galam: pasūtījums, rēķins, izmaksa, saskaņošana. Pierādiet, ka bilance sakrīt. Pēc tam mērogojiet.
5. Ieslēdziet periodu slēgšanu heti, kad pirmais mēnesis ir veiksmīgi noslēgts. Šī disciplīna laika gaitā nes arvien lielāku ieguvumu.

Komandas, kas to izdara pareizi, uzskata virsgrāmatu par pamata infrastruktūru, nevis par atskaišu sistēmu, kas izveidota pēdējā brīdī. Tā ir galvenā atšķirība, un tieši tā padara sarunu par finansēm ar revidentu, investoru vai nodokļu iestādi īsu, nevis garlaicīgu un ilgstošu.

FAQ

Vai divkāršā ieraksta virsgrāmatas API ir tas pats, kas grāmatvedības integrācija?

Nē. Integrācija sinhronizē datus no jūsu produkta uz ārēju grāmatvedības rīku, parasti ar laika nobīdi. Virsgrāmatas API ir pati grāmatvedības sistēma, kurā dati tiek rakstīti tieši un reāllaikā. Šī atšķirība ir svarīga, jo integrācijas zaudē datu precizitāti malu gadījumos: daļēji maksājumi, vairākas valūtas, tirdzniecības platformas maksājumu sadalījumi. Virsgrāmatas API šos datus reģistrē dabiski.

Vai mēs nevaram vienkārši izmantot Stripe vai Adyen atskaites?

Maksājumu apstrādātāja atskaites parāda to, kas ir izgājis caur apstrādātāju. Tās nav divkāršā ieraksta grāmatas. Tās nezina par jūsu saistībām pret pārdevējiem, kuras vēl nav izmaksātas, par jūsu PVN saistībām dažādās valstīs vai par izdevumiem, kas nav saistīti ar maksājumu apstrādātāju. Tās ir tikai viens no ievaddatiem virsgrāmatā, nevis tās aizstājējs.

Cik lielā mērā nemainīgs ir nemainīgs praksē?

Ierakstus nevar labot. Labojumi ir jauni ieraksti, kas atsaucas uz oriģinālo ierakstu. Tas ir arhitektūras lēmums, nevis tehnoloģija. Jebkura kompetenta virsgrāmata to nodrošinās. Iemesls tam pievērst uzmanību ir tas, ka "mēs to izlabojām, lai tas sakristu ar banku" ir tieši tas modelis, kas grāmatvedības reģistrus padara neuzticamus.

Kā ir ar tirdzniecības platformām, kas darbojas ārpus ES?

Divkāršā ieraksta mehānika ir universāla. Nodokļu loģika tāda nav. Virsgrāmatas API, kas pielāgota ES PVN prasībām, labi apstrādās ES orientētas operācijas un var atbalstīt darījumus ārpus ES, taču, ja jūsu galvenais tirgus ir ASV tirdzniecības nodoklis vai Latīņamerikas e-rēķinu režīmi, pirms saistību uzņemšanās pārliecinieties par konkrēto atbilstības prasību segumu.

Cik ilgs laiks faktiski nepieciešams ieviešanai?

Tirdzniecības platformai ar sakārtotu notikumu modeli virsgrāmatas API integrēšana līdz brīdim, kad viena pilna plūsma darbojas no gala līdz galam, parasti aizņem dažas nedēļas ilgu inženierdarbu. Pilna migrācija no mantotās sistēmas, ieskaitot vēsturiskos datus, aizņem ilgāku laiku. Mainīgais lielums gandrīz vienmēr ir esošo datu stāvoklis, nevis pats API.