Kas yra apskaitos API? Aiškus gidas platformų kūrėjams

Paprastas apskaitos API apibrėžimas, kuo jis skiriasi nuo mokesčių ar mokėjimų API ir ką būtina patikrinti prieš pradedant integraciją.

Apskaitos API yra sąsaja, leidžianti vienai programai tvarkyti kitos programos buhalteriją. Jūsų programinė įranga HTTP protokolu išsiunčia finansinį įvykį. API paverčia šį įvykį subalansuotais dvejybinio įrašo (double-entry) žurnalo įrašais pagal sąskaitų planą (chart of accounts), išsaugo juos taip, kad jų nebūtų galima nepastebimai pakeisti, pritaiko mokesčius ir per tą pačią sąsają grąžina ataskaitas, dokumentus bei eksporto failus.

Šis apibrėžimas atlieka didžiąją dalį darbo. Viskas, kas rašoma šiame straipsnyje, yra tik jo išdava.

Versija vienu sakiniu

Apskaitos API priima finansinius įvykius iš jūsų programėlės, kiekvieną iš jų paverčia subalansuotu žurnalo įrašu, saugo nekintamai kartu su mokesčių taikymu bei pagrindžiančiais dokumentais, o gautą didžiąją knygą (ledger), dokumentus ir ataskaitas pateikia per programuojamus galinius punktus (endpoints).

Jei produktas vadinasi apskaitos API, bet negeneruoja žurnalo įrašų, tai yra kažkas kita, tiesiog turintį gražų pavadinimą. Tai nebūtinai blogai. Tai tiesiog reiškia, kad jis neatliks to darbo, kurį ketinate jam pavesti.

Kuo apskaitos API NĖRA

Keturios gretutinės produktų kategorijos dažnai painiojamos su apskaitos API, paprastai projekto eigoje.

Kategorija	Ką ji daro	Ką ji nedaro
Mokesčių skaičiavimo API	Grąžina teisingą mokesčio tarifą arba sumą operacijai	Netvarko jūsų apskaitos ir nesaugo sprendimą pagrindžiančių įrodymų saugojimo laikotarpiu
Mokėjimų API	Perkelia pinigus tarp šalių ir teikia ataskaitas apie šiuos judėjimus	Nefiksuoja uždirbtos komisijos, mokėtino PVM arba įsipareigojimo pardavėjui tarp mokėjimo ir išmokėjimo
Jungtinis arba agregavimo API	Skaito ir rašo duomenis esamoje jūsų kliento apskaitos programoje	Veikia kaip pirminis apskaitos šaltinis (system of record); jūsų buhalterija gyvena ten, kur kliaujasi kiekvienas klientas
Ataskaitų arba BI API	Nuskaito skaičius iš esamos didžiosios knygos ir juos vizualizuoja	Nekuria įrašų, iš kurių tie skaičiai yra kildinami

Kiekvienas iš šių įrankių turi realių pritaikymo sričių. Platformai, kuri turi būti pirminis apskaitos šaltinis, po apačia reikia apskaitos API, o ne jos pakaitalo.

Penki dalykai, kuriuos apskaitos API privalo atlikti

1. Fiksuoti subalansuotus įrašus. Kiekvienas įvykis virsta debetais ir kreditais, kurių suma sutampa. Kai pirkėjas sumoka 100 EUR prekyvietėje, kuri paima 15 EUR komisiją, įrašas debetuoja lėšų pervedimo sąskaitą (clearing account) 100 EUR, kredituoja mokėtinas sumas pardavėjui 85 EUR ir kredituoja komisinio mokesčio pajamas 15 EUR. Čia ne biurokratinė buhalterijos ceremonija. Tai struktūrinis patikrinimas, kuris aptinka visas integracijos klaidų klases dar prieš joms patenkant į ataskaitą.

2. Saugoti istoriją. Įtrauktas įrašas (posted entry) nėra redaguojamas. Klaida ištaisoma atvirkštiniu įrašu (reversal) plus pataisytu įrašu, ir abu jie susieti su originalu. Užblokuoti mėnesiai yra užrakinami, kad į juos nebūtų galima įtraukti jokių naujų dokumentų su ankstesne data.

3. Spręsti mokesčių klausimus. ES prekybai tai reiškia prievolių vykdymo vietos nustatymą (place of supply), atvirkštinį PVM apmokestinimą (reverse charge), PVM mokėtojo kodų patikrinimą oficialiame registre ir sprendimą pagrindžiančius įrodymus – visa tai saugoma kartu su operacija, o ne ištrinama po apskaičiavimo.

4. Suderinti su išoriniais pinigais. Buhalterija, kuri niekada nesusitinka su banko išrašu, tėra spėlionė. API privalo nuskaityti išrašus arba paslaugų teikėjų atsiskaitymus ir sulyginti juos su tuo, kas buvo užfiksuota.

5. Eksportuoti. Ataskaitos, dokumentai ir audito failai formatais, kuriuos priima profesionalus buhalteris ir mokesčių inspekcija.

Produktas, kuris atlieka pirmuosius tris punktus, bet ne paskutinius du, vis tiek privers žmogų kas mėnesį dirbti su skaičiuoklėmis.

Kaip iš tikrųjų atrodo užklausa

Techninė pusė yra paprastesnė nei pati buhalterija. Naudojant Nordlet API, kiekviena operacija yra RPC stiliaus POST užklausa su nuspėjama struktūra:

POST /v1/{module}/{resource}/{action}
Authorization: Bearer <api key>
Idempotency-Key: <your event id>

Jūs sukuriamas pardavimo sąskaitą faktūrą (sales invoice), o tada ją išrašote. Išrašymas yra momentas, kai įvyksta apskaita: dokumentas gauna savo eilės numerį be tarpų, sugeneruojamas subalansuotas žurnalo įrašas, o kartu įregistruojamos ir PVM eilutės. Jūsų platforma niekada pati nerenka debetų ir kreditų rankiniu būdu.

Trys detalės šiame kodo fragmentas yra svarbesnės už patį galinio punkto pavadinimą:

Rakto apimtis (scope). Raktas turi tokius leidimus kaip sales:write, todėl integracija gauna tik jai reikalingą prieigą.
Idempotentiškumo raktas (idempotency key). Pakartokite tą pačią užklausą su tuo pačiu turiniu ir gausite išsaugotą atsakymą, o ne antrą sąskaitą faktūrą. Jei atsiųsite tą patį raktą su kitu turiniu, užklausa bus atmesta su klaida idempotency_key_reuse, o ne tyliai priimta.
Pinigai kaip eilutės (strings). Sumos yra dešimtainės eilutės, o ne slankiojo kablelio skaičiai (floats), nes pastarieji praranda centus būdais, kurie iškyla į paviršių metų pabaigoje.

Kur tai yra jūsų architektūroje

Jūsų programa lieka vartotojo sąsaja ir verslo įvykių šaltiniu. Apskaitos API tampa finansiniu apskaitos šaltiniu už jos ribų. Procesas dažniausiai atrodo taip:

Jūsų produkte kažkas įvyksta: užsakymas, grąžinimas, išmokėjimas, prenumeratos pratęsimas.
Jūsų serveris iškviečia apskaitos API su įvykiu ir idempotentiškumo raktu.
API įregistruoja žurnalo įrašą, pritaiko PVM ir grąžina identifikatorius, kuriuos išsaugote prie savo įrašų.
Internetinis pranešimas (webhook), pavyzdžiui, sale_invoice.paid, praneša jūsų sistemai, kai pasikeičia būsena, todėl reaguojate į įvykius, o ne periodiškai tikrinate (polling).
Banko operacijos atvyksta per banko srautą (bank feed) arba išrašo importą ir yra sutepinamos su užregistruotais dokumentais.
Laikotarpio pabaigoje iš tų pačių duomenų sugeneruojamos ataskaitos bei mokesčių registrai, o uždarytas mėnuo užrakinamas.

Nė viename iš šių punktų nereikia žmogaus, kuris atidarytų apskaitos programą. Tai ir yra šios kategorijos esmė.

Kaip tai lyginama su alternatyvomis

Požymis	Pradžios pastangos	Audito pozicija	Keitimasis didėjant operacijų apimčiai
Skaičiuoklės ir rankinis įvedimas	Mažiausios	Silpna; istorija redaguojama	Ne
Apskaitos programa plius CSV eksportas	Žemos	Visiškai priklauso nuo drausmės	Prastai; kažkas turi importuoti failus
Agregavimo API į kiekvieno kliento apskaitą	Vidutinės	Paveldi tai, ką daro kliento įrankis	Taip, bet jūs niekada nevaldote įrašo
Įterptasis apskaitos API (embedded accounting API)	Vidutinės	Stipri, jei didžioji knyga nekintama ir laikotarpiai užrakinami	Taip
Kurti savo didžiąją knygą	Didžiausios	Stipri tik tuo atveju, jei patys sukuriate valdiklius	Taip, ir privalote ją palaikyti amžinai

Savo sprendimo kūrimas yra suprantamas pasirinkimas kai kurioms komandoms. Tai išsamiau aptarta mūsų prekyviečių gido „sukurti ar pirkti“ dalyje.

Ką patikrinti prieš pradedant kurti integraciją

Ar likutis kildinamas, ar saugomas? Paklauskite, ar pardavėjo likutis yra užklausa per žurnalo eilutes, ar stulpelis, kurį kažkas atnaujina. Tik vienas iš šių variantų išgyvena auditą.
Kas nutinka pakartojimo (retry) atveju? Išsiųskite tą pačią užklausą dukart ir suskaičiuokite įrašus.
Ar galima redaguoti įtrauktą įrašą? Atsakymas turi būti „ne“, pateikiant dokumentuotą klaidų taisymo kelią.
Ar užrakintas laikotarpis iš tikrųjų atmeta įrašymą? Išbandykite tai smėlio dėžėje (sandbox). „Nordlet“ grąžina 409 klaidą už įrašą, kurio data patenka į užrakintą laikotarpį.
Kaip vaizduojami pinigai? Dešimtainės eilutės (decimal strings) arba mažiausieji sveikieji vienetai (minor units). Jokių slankiojo kablelio skaičių (floats).
Kas yra audito įraše? Subjektas, veiksmas, objektas ir pats pakeitimas, pasiekiami per užklausas, o ne paslėpti žurnalo failuose.
Kokie yra užklausų dažnio limitai (rate limits)? „Nordlet“ leidžia 300 užklausų per minutę vienam API raktui ir praneša apie jūsų likutinį limitą atsakymo antraštėse. Kad ir koks būtų skaičius, sužinokite jį prieš kurdami sinchronizaciją.
Kaip išsitraukti savo duomenis? Ataskaitos, dokumentai ir žurnalai formatais, kuriuos galite perduoti buhalteriui.

Kiekvieną iš šių punktų galima išbandyti per popietę smėlio dėžės įmonėje. Tiekėjų funkcijų sąrašai nėra įrodymas; įrodymas yra pakartojamas testas.

D.U.K.

Ar apskaitos API yra tas pats kas apskaitos programinė įranga?

Tai apskaitos programinė įranga su perkelta sąsaja. Tradicinė apskaitos programa pastato žmogų priešais didžiąją knygą, o apskaitos API ten pastato jūsų kodą. Pagrindiniai įsipareigojimai, dvejybinio įrašo struktūra ir ataskaitos išlieka tokie patys.

Ar man vis tiek reikės buhalterio, jei tai naudoju?

Taip. API automatizuoja registravimą, skaičiavimą ir ataskaitų teikimą. Ji nepriima subjektyvių sprendimų dėl klasifikavimo, atidėjinių ar to, kaip turėtų būti traktuojama konkrečia sutartis, ir daugelyje šalių ji nepasirašo bei neteikia jūsų finansinių ataskaitų rinkinio.

Ar galiu naudoti apskaitos API nesuprasdamas dvejybinio įrašo?

Iš dalies. Geras API sugeneruoja žurnalo įrašus už jus iš verslo dokumento, pavyzdžiui, sąskaitos faktūros. Tačiau vis tiek turite suprasti, ką reiškia sąskaitos, kai skaitote ataskaitą arba aiškinate likutį auditoriui.

Kuo skiriasi apskaitos API ir didžiosios knygos (ledger) API?

Didžiosios knygos API registruoja subalansuotus pinigų judėjimus tarp sąskaitų. Apskaitos API atlieka tai ir prideda teisinį sluoksnį: dokumentus su teisiniais numeriais, PVM apmokestinimą, mokesčių registrus, ilgalaikį turtą, laikotarpio uždarymą ir ataskaitas, kurių reikalauja jurisdikcija. Kiekviename apskaitos API yra didžioji knyga, tačiau ne kiekviena didžioji knyga yra apskaitos sistema.

Kiek laiko trunka integracija?

Pirminiam veikiančiam ciklui – sukurti klientą, išrašyti sąskaitą faktūrą, gauti mokėjimą, pamatyti žurnalo įrašą – naudojant tipizuotą SDK ir smėlio dėžę, planuokite dienas, o ne savaites. Gamybinė integracija, apimanti grąžinimus, pataisymus, kelias valiutas, suderinimą ir laikotarpio uždarymą, yra didesnės apimties darbas, o sąžiningas laiko įvertinimas priklauso nuo toho, kiek iš šių atvejų iš tikrųjų generuoja jūsų produktas.