Dauguma prekyviečių sužino, kad turi apskaitos problemų, visada vienodai: pasamdžiamas finansų specialistas, jis atidaro išmokų skaičiuoklę ir paklausia, kas iš tikrųjų fiksuoja įsipareigojimus pardavėjams nuo to momento, kai pirkėjas sumoka, iki to momento, kai lėšos palieka platformos sąskaitą. Inžinerijos komanda nurodo į transactions lentelę duomenų bazėje. Finansų specialistas atkreipia dėmesį, kad įvykių sąrašas nėra tas pats, kas buhalterinės knygos. Šią spragą tarp įvykių duomenų ir tikrosios apskaitos ir turi užpildyti dvigubo įrašo (double-entry) didžiosios knygos API.
Tai techninis klausimas, turintis teisinį svorį. Prekyvietės laiko kitų žmonių pinigus, skaičiuoja PVM įvairiose jurisdikcijose ir išrašo sąskaitas faktūras pardavėjų vardu. Tai daryti su pačių sukurta operacijų lentele veikia tol, kol auditorius, mokesčių administratorius ar rimtas pirkėjas nepareikalauja įrodymų.
Kas iš tikrųjų yra dvigubo įrašo didžiosios knygos API
Dvigubo įrašo didžiosios knygos API yra programuojamas apskaitos variklis, veikiantis per HTTP. Kiekvienas jūsų platformos užfiksuotas finansinis įvykis įrašomas kaip subalansuotas žurnalo įrašas: bent vienas debetas ir vienas kreditas, kurių suma lygi, įrašyti į konkrečias sąskaitas sąskaitų plane. API užtikrina balansą įrašymo metu ir saugo įrašus taip, kad jų vėliau nebūtų galima nepastebimai pakeisti.
„Dvigubo įrašo“ dalis yra keturių šimtų metų senumo apskaitos taisyklė, kad kiekviena operacija turi įtakos bent dviem sąskaitoms. „API“ dalis reiškia, kad kvietimą atlieka jūsų produktas, o ne buhalteris. „Nekintamumo“ (immutable) dalis reiškia, kad taisymai atliekami per atvirkštinius įrašus, o ne redaguojant istoriją.
Naudingas darbinis apibrėžimas:
Dvigubo įrašo didžiosios knygos API priima finansinius įvykius iš jūsų programos, paverčia kiekvieną iš jų subalansuotu žurnalo įrašu pagal nustatytą sąskaitų planą, saugo tuos įrašus nekintamai ir pateikia rezultatą (didžiąją knygą, bandomąjį balansą ir finansines ataskaitas) per nuspėjamus galinius punktus.
Kodėl prekyvietėms to reikia
- Pinigų srauto kontrolė: Jos yra pinigų srauto viduryje. Kiekvienas lėšų judėjimas (pirkėjas -> platforma -> pardavėjas) yra skirtingas apskaitos įvykis.
- Mokesčių jurisdikcijos: ES prekyvietė privalo taikyti teisingą PVM tvarką, tikrinti pardavėjų PVM kodus per VIES ir teikti ataskaitas.
- Apimtys: Platforma, atliekanti dešimtis tūkstančių užsakymų per mėnesį, privalo automatizuoti apskaitą, kitaip finansų komanda taps augimo kliūtimi.
Kaip veikia API: žingsnis po žingsnio
- Jūsų platforma sugeneruoja finansinį įvykį.
- Didžioji knyga suformuoja žurnalo įrašą. API paverčia įvykį į subalansuotus debetus ir kreditus.
- Įrašas tampa nekintamas. Įrašas turi identifikatorių ir laiko žymą; redagavimas neįmanomas.
- Tolesnės ataskaitos atnaujinamos realiuoju laiku. Bandomasis balansas ir pelno/nuostolių ataskaitos atspindi naują įrašą nedelsiant.
- Webhook pranešimai. Jūsų sistema reaguoja į įvykius be nuolatinio užklausų siuntimo.
Palyginimas: Build vs. Buy vs. Embed
| Požiūris | Laikas iki gamybos | Pasiruošimas auditui | ES PVM tvarkymas | Tinka jūsų produkte |
|---|---|---|---|---|
| Kurti savo didžiąją knygą | 12–24+ mėn. | Priklauso nuo komandos | Jūs kuriate patys | Taip |
| Sinchronizuoti su Xero/QuickBooks | Savaitės | Geras, bet ne prekyvietėms | Dalinis, reikia priedų | Ne |
| Integruoti API (pvz., Nordlet) | Savaitės | Įdiegtas (nekintamas) | Pilnas ES palaikymas | Taip |
Svarbiausi punktai vertinant tiekėją
- Nekintamas dvigubo įrašo saugojimas (reversiniai įrašai, o ne redagavimas).
- Laikotarpių užrakinimas (su registruojamais atidarymo veiksmais).
- Idempotency raktai (saugu pakartoti užklausas).
- PVM logika pagal šalis (VIES, i.SAF, OSS/IOSS palaikymas).