Kaj je računovodski API? Vodnik v preprostem jeziku za graditelje platform

Preprosta opredelitev računovodskega API-ja, razlike med davčnim ali plačilnim API-jem ter ključne točke, ki jih je treba preveriti pred uvedbo.

Računovodski API je vmesnik, ki enemu programu omogoča vodenje poslovnih knjig drugega programa. Vaša programska oprema prek protokola HTTP pošlje finančni dogodek. API ta dogodek spremeni v uravnovešene dvostavne temeljne vknjižbe v kontnem načrtu, jih shrani tako, da jih ni mogoče neopazno spremeniti, uveljavi davčno obravnavo ter vam prek istega vmesnika vrne poročila, dokumente in izvoze podatkov.

Ta opredelitev opravi večji del naloge. Vse ostalo v tem članku je le posledica tega.

Različica v enem stavku

Računovodski API sprejema finančne dogodke iz vaše aplikacije, vsakega pretvori v uravnovešeno temeljno vknjižbo, jo nespremenljivo shrani skupaj z davčno obravnavo in ustreznimi dokazili ter nastali glavni knjigi, dokumentom in poročilom omogoča dostop prek programabilnih končnih točk.

Če se določen izdelek poimenoval računovodski API, vendar ne ustvarja temeljnih vknjižb, gre za nekaj drugega s privlačnim imenom. To ni nujno slabo, pomeni le, da ne bo opravil naloge, za katero ga nameravate uporabiti.

Česa računovodski API ni

Štiri sorodne kategorije izdelkov se pogosto mešajo z računovodskimi API-ji, običajno v poznejih fazah projekta.

Kategorija	Kaj počne	Česa ne počne
API za izračun davkov	Vrne ustrezno stopnjo ali znesek davka za transakcijo	Ne vodi vaših poslovnih knjig in ne hrani dokazil v ozadju odločitve za obdobje hrambe
Plačilni API	Prenos denarja med strankami in poročanje o teh premikih	Ne beleži ustvarjene provizije, dolgovega DDV-ja ali obveznosti do prodajalca med plačilom in izplačilom
Zbirni (aggregating) ali poenoteni API	Bere in zapisuje podatke v obstoječi računovodski program vaše stranke	Ne deluje kot sistem evidence; vaše knjige so tam, kjer jih posamezna stranka že uporablja
Poročevalski ali poslovno-obveščevalni API	Bere številke iz obstoječe glavne knjige in jih vizualizira	Ne ustvarja vknjižb, iz katerih so te številke izpeljane

Vsaka od teh rešitev ima svojo veljavno vlogo. Platforma, ki mora delovati kot sistem evidence, pa potrebuje računovodski API v ozadju, in ne namesto sebe.

Pet nalog, ki jih mora opraviti računovodski API

1. Beleženje uravnovešenih vknjižb. Vsak dogodek se pretvori v bremene in dobre v korist, katerih vsota je enaka. Ko kupec plača 100 EUR na tržnici (marketplace), ki si vzame 15 EUR provizije, vknjižba bremeni prehodni konto za 100 EUR, v korist knjiži obveznost do prodajalca v višini 85 EUR in v korist prihodke od provizij v višini 15 EUR. To ni knjigovodski birokratski ritual, temveč strukturni nadzor, ki odkrije celotne razrede integracijskih napak, preden sploh dosežejo poročilo.

2. Ohranjanje zgodovine. Knjižena vknjižba se ne ureja. Napaka se odpravi s stornacijo in popravljeno vknjižbo, pri čemer sta obe povezani z izvirnikom. Zaključeni meseci so zaklenjeni, zato vanje ni mogoče knjižiti novih dogodkov z datumom v preteklosti.

3. Obravnava davkov. Pri trgovanju znotraj EU to pomeni določitev kraja obdavčitve, obrnjeno davčno obveznost (reverse charge), preverjanje identifikacijskih številk za DDV v uradnem registru ter shranjevanje dokazil, ki utemeljujejo odločitev, neposredno ob transakciji, namesto da bi se ta podatki po izračunu zavrgli.

4. Usklajevanje z zunanjim denarjem. Knjige, ki se nikoli ne srečajo z bančnim izpiskom, so le ugibanje. API mora sprejeti bančne izpiske ali poravnave ponudnikov ter jih uskladiti z zabeleženimi podatki.

5. Izvoz podatkov. Poročila, dokumenti in revizijske datoteke v oblikah, ki jih sprejemata človeški računovodja in davčni urad.

Izdelek, ki opravi prve tri naloge, zadnjih dveh pa ne, bo poskrbel za to, da bo nekdo še vedno vsak mesec ročno delal v preglednicah.

Kako je videti dejanski klic

Mehanika je preprostejša od računovodstva. V Nordletovem API-ju je vsaka operacija zahtevek POST v slogu oddaljenega klicanja procedur (RPC) s predvidljivo strukturo:

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

Ustvarite prodajni račun in ga nato izdate. Izdaja je trenutek, ko se zgodi računovodski del: dokument dobi svojo zaporedno številko brez vrzeli, knjiži se uravnovešena temeljna vknjižba, z njo pa se zabeležijo tudi vrstice DDV-ja. Vaši platformi ni treba nikoli ročno sestavljati bremen in koristi.

Tri podrobnosti v tem vzorcu so pomembnejše od imena končne točke:

Obseg (scope) ključa. Ključ nosi dovoljenja, kot je sales:write, zato integracija dobi samo tisti dostop, ki ga dejansko potrebuje.
Ključ za enkratnost (idempotency key). Če ponovite isto zahtevo z istim bremenitvijo, prejmete shranjen odziv namesto drugega računa. Če pošljete isti ključ z drugačno vsebino, je zahtevek zavrnjen z napako idempotency_key_reuse namesto tiho sprejet.
Denar kot nizi znakov. Zneski so zapisani kot decimalni nizi in ne kot števila s plavajočo vejico (floating-point), ker slednja pri zaokroževanju izgubljajo cente, kar privede do težav ob koncu leta.

Kje se nahaja v vaši arhitekturi

Vaša aplikacija ostaja čelni del (front-end) in vir poslovnih dogodkov. Računovodski API pa za njim postane finančni sistem evidence. Potek je običajno naslednji:

V vašem izdelku se nekaj zgodi: naročilo, vračilo denarja, izplačilo ali obnova naročnine.
Vaše zaledje pokliče računovodski API z dogodkom in ključem za enkratnost.
API knjiži temeljno vknjižbo, obračuna DDV in vrne identifikatorje, ki jih shranite poleg lastnih zapisov.
Spletni kavelj (webhook), kot je sale_invoice.paid, obvesti vaš sistem o spremembi stanja, kar vam omogoča odzivanje na dogodke namesto stalnega poizvedovanja (polling).
Bančne transakcije prispedejo prek bančnega pretoka ali uvoza izpiska ter se uskladijo z zabeleženimi dokumenti.
Ob koncu obdobja se iz istih podatkov ustvarijo poročila in davčni knjigi, zaključen mesec pa se zaklene.

Nič na tem seznamu ne zahteva, da bi moral človek odpreti računovodski program. To je tudi glavni namen te kategorije.

Primerjava z alternativnimi pristopi

Pristop	Napor za začetek	Revizijski položaj	Skaliranje z obsegom transakcij
Preglednice in ročni vnos	Najnižji	Šibak; zgodovino je mogoče urejati	Ne
Računovodska aplikacija in izvozi CSV	Nizek	Popolnoma odvisen od discipline	Slabo; nekdo mora uvažati datoteke
Zbirni API v knjige vsake stranke	Srednji	Prevzame lastnosti orodja posamezne stranke	Da, vendar niste lastnik evidence
Vgrajeni (embedded) računovodski API	Srednji	Močan, če je glavna knjiga nespremenljiva in se obdobja zaklepajo	Da
Izdelava lastne glavne knjige	Najvišji	Močan le, če zgradite tudi nadzorne mehanizme	Da, ob tem pa ga vzdržujete za vedno

Izdelava lastne rešitve je za določene ekipe povsem smiselna izbira. Podrobneje je opisana v našem vodniku o izbiri med lastnim razvojem in nakupom za tržnice.

Kaj je treba preveriti pred začetkom razvoja z izbranim API-jem

Ali je stanje izračunano ali shranjeno? Vprašajte, ali je stanje prodajalca rezultat poizvedbe po vrsticah temeljne vknjižbe ali le polje, ki ga nekdo posodobi. Samo ena od teh možnosti uspešno prestane revizijo.
Kaj se zgodi ob ponovnem poskusu zahteve? Pošljite isto zahtevo dvakrat in preštejte vknjižbe.
Ali lahko urejate knjiženo vknjižbo? Odgovor mora biti ne, ob obstoju dokumentirane poti za popravke.
Ali zaklenjeno obdobje dejansko zavrne knjiženje? Preizkusite to v preskusnem okolju (sandbox). Nordlet vrne kodo 409 za knjiženje z datumom znotraj zaklenjenega obdobja.
Kako je predstavljen denar? Decimalni nizi ali najmanjše denarne enote v celi številki. Nikoli števila s plavajočo vejico.
Kaj vsebuje revizijska sled? Subjekt, dejanje, entiteto in spremembo samostojno, tako da je mogoče poizvedovati po njih, namesto da so zakopane v datotekah dnevnika (logih).
Kakšne so omejitve števila klicev (rate limits)? Nordlet dovoljuje 300 zahtev na minuto na posamezen ključ API in v odzivnih glavah poroča o preostalem proračunu. Ne glede na številko jo preverite, preden zasnujete sinhronizacijo.
Kako lahko izvozite svoje podatke? Poročila, dokumenti in dnevniki v obliki, ki jo lahko predate računovodji.

Vsako od teh vprašanj lahko preizkusite v enem popoldnevu z uporabo preskusnega podjetja. Seznami funkcij ponudnikov niso dokaz; zanesljiv preizkus pa je.

FAQ

Ali je računovodski API isto kot računovodska programska oprema?

Gre za računovodsko programsko opremo s prestavljenim vmesnikom. Tradicionalna programska oprema postavi človeka pred glavno knjigo, računovodski API pa tja postavi vašo kodo. Osnovne obveznosti, struktura dvostavnega knjigovodstva in poročila ostajajo nespremenjeni.

Ali ob uporabi API-ja še vedno potrebujem računovodjo?

Da. API avtomatizira beleženje, izračunavanje in poročanje. Ne sprejema pa presoje o kontiranju, rezervacijah ali o tem, kako je treba obravnavati določeno pogodbo, poleg tega pa v večini držav ne podpiše ali odda vaših zakonskih računovodskih izkazov.

Ali lahko uporabljam računovodski API, ne da bi razumel dvostavno knjigovodstvo?

Delno. Dober API sestavi temeljne vknjižbe za vas na podlagi poslovnega dokumenta, kot je račun. Kljub temu morate razumeti, kaj pomenijo posamezni konti, ko berete poročilo ali razlagate stanje revizorju.

Kakšna je razlika med računovodskim API-jem in API-jem glavne knjige?

API glavne knjige beleži uravnovešene premike med konti. Računovodski API naredi prav to in na vrh dodaja še zakonsko plast: dokumente z zakonskim številčenjem, obravnavo DDV-ja, davčne knjige, osnovna sredstva, zaključevanje obdobij in poročila, ki jih zahteva posamezna jurisdikcija. Vsak računovodski API vsebuje glavno knjigo, vendar vsaka glavna knjiga ni nujno računovodski sistem.

Koliko časa traja integracija?

Za prvo delujočo pot - ustvarjanje stranke, izdajo računa, prejem plačila in vpogled v temeljno vknjižbo - ob uporabi tipiziranega SDK-ja in preskusnega okolja načrtujte dneve in ne tednov. Produkcijska integracija, ki vključuje vračila, popravke, večvalutnost, usklajevanje in zaključevanje obdobij, pa zahteva več dela, pri čemer je poštena ocena odvisna od tega, koliko teh primerov vaš izdelek dejansko ustvarja.