Integruota apskaita: kurti patiems ar pirkti prekyvietėms

Apimties sąrašas, kaštų modelis su aiškiomis prielaidomis ir sąlygos, kuriomis kiekvienas sprendimas yra teisingas.

Kiekviena prekyvietė (marketplace) anksčiau ar vėliau susikuria didžiąją knygą. Vienintelis klausimas – ar ji sukuriama apgalvotai, kaip valdoma sistema, ar atsitiktinai, kaip balance stulpelis, į kurį rašo trys skirtingos tarnybos ir kuriuo niekas iki galo nepasitiki.

Šis straipsnis padės priimti šį sprendimą sąmoningai. Jame aptariama, ką iš tiesų apima šis darbas, kaip objektyviai įvertinti jo kaštus ir kokios yra konkrečios sąlygos, kai kurti patiems yra teisingas pasirinkimas – nes kartais taip tikrai yra.

Ką čia reiškia „integruota apskaita“ (embedded accounting)

Integruota apskaita reiškia, kad apskaitos registrai gyvuoja jūsų produkte, o ne atskiroje programoje. Jūsų programinė įranga registruoja įrašus įvykių metu, vartotojai mato tai, ką pateikia jūsų sąsaja, ir niekas mėnesio pabaigoje neeksportuoja skaičiuoklės buhalteriui.

Prekyvietės atveju tai apima bent jau šiuos dalykus: gautus pirkėjų mokėjimus, mokėtinas sumas pardavėjams, uždirbtą komisinį atlyginimą, mokėjimų apdorojimo mokesčius, PVM nuo jūsų mokesčių ir nuo pagrindinio prekių ar paslaugų tiekimo, grąžinimus, ginčijamus mokėjimus (chargebacks), rezervus, išmokas (payouts) ir viso to suderinimą su banku ar mokėjimo paslaugų teikėju.

Ką iš tiesų kuriate, jei nusprendžiate kurti patys

Pati didžioji knyga tėra maža dalis. Komandos nuolat įvertina tik pirmąjį punktą, o visą likusią dalį atranda vėliau.

Komponentas	Ką tai apima
Bendražurnalis ir sąskaitos	Subalansuoti įrašai (dvejybinis įrašas), sąskaitų planas, sąskaitų tipai, pradiniai likučiai
Nekeičiamumas (Immutability)	Tik papildoma (append-only) duomenų saugykla, stornavimo ir taisymo darbo eiga, jokių tiesioginių redagavimų
Laikotarpių kontrolė	Uždarymas, užrakinimas, pavėluotų įrašų atmetimas, kontroliuojamas atidarymas su audito seka
Idempotentiškumas	Raktai, ankstesnių atsakymų saugojimas, konfliktų aptikimas pasikeitus duomenų apkrovai (payloads)
Operacijos su pinigais	Tiksli dešimtainė arba smulkiausių vienetų aritmetika, valiutų kodai, valiutų kursai ir jų šaltinis, apvalinimo sąskaitos
PVM modulis	Skirtingų šalių tarifai su galiojimo datomis, prekių tiekimo / paslaugų teikimo vieta, atvirkštinis apmokestinimas, numanomo prekių tiekėjo (deemed supplier) taisyklės, neapmokestinami atvejai
PVM mokėtojų identifikacinių duomenų tikrinimas	Tikrinimas oficialiame registre, podėliavimas (caching), laiko žymos, užklausų identifikatoriai, rankinės peržiūros eilė klaidų atveju
Dokumentai	Sąskaitos faktūros, kreditinės sąskaitos, ištisinis numeravimas pagal seriją ir metus (be spragų), PDF generavimas, pristatymas
Elektroninės sąskaitos faktūros (e. sąskaitos)	Struktūrizuoti formatai, tokie kaip EN 16931 UBL, ir privalomi nacionaliniai šalių formatai
Banko duomenų importas	Išrašų importas arba banko ryšys su sutikimu, jau importuotų operacijų dublikatų šalinimas
Suderinimas (Reconciliation)	Gretinimo taisyklės, vertinimas (scoring), daliniai sutapimai, išimtys, kurias turi išspręsti žmogus
Išmokos	Mokėjimo failų generavimas, išmokų grupavimas (batching), išmokų susiejimas su pirminiais įrašais
Ataskaitos	Bandomasis balansas (trial balance), balansas, pelno (nuostolių) ataskaita, pinigų srautų ataskaita, PVM suvestinės, skolos pagal vėlavimą (aged debt)
Mokesčių registrai ir deklaracijos	Tai, ko reikalauja jūsų šalys, formatu, kurį priima institucijos
Auditas	Veikėjas, veiksmas, subjektas ir pats pakeitimas – su galimybe atlikti užklausas kiekvienam pakeitimui
Saugojimas ir eksportas	Dešimties metų OSS įrašų saugojimas, pilnas duomenų eksportas, patikimas archyvas

Maždaug dvi iš šių septyniolikos eilučių yra tai, ką dauguma komandų įsivaizduoja sakydamos „mes sukursime didžiąją knygą“.

Kaip objektyviai įvertinti išlaidas

Bet kokie skaičiai čia priklauso nuo jūsų komandos, todėl vertinkite tai kaip metodą, o ne kaip komercinį pasiūlymą. Paimkite aukščiau išvardintus komponentus, priskirkite kiekvienam apimtį inžinierių darbo savaitėmis (engineer-weeks) pagal savo komandos greitį, o tada pritaikykite tris korekcijas, kurios dažniausiai praleidžiamos sąmatose.

Pirmoji korekcija: atitikties reikalavimų komponentai nėra vienkartiniai. Keičiasi tarifai, ribos, formatai, o ES „PVM skaitmeniniame amžiuje“ (VAT in the Digital Age) paketas įveda terminuotus įsipareigojimus – OSS ir IOSS pakeitimai nuo 1 January 2027, išplėstos platformų taisyklės nuo 1 July 2028, tarptautinė skaitmeninė atskaitomybė nuo 1 July 2030. Kūrimas pačiam reiškia, kad jūs prisiimate atsakomybę už kiekvieną iš šių migracijų.

Antroji korekcija: duomenų tikslumo užtikrinimas trunka ilgiau nei funkcijų kūrimas. Pirmoji versija apdoroja standartinį, sklandų scenarijų (happy path). Ilgoji „uodega“ yra lėšų grąžinimai po išmokėjimo, daliniai grąžinimai, ginčijami mokėjimai (chargebacks), gaunami po kelių savaičių, valiutų apvalinimas, besidubliuojantys „webhooks“ pranešimai ir atsiskaitymo failai, kurie nesutampa su jūsų įrašais. Būtent čia pranyksta visi kalendoriuose suplanuoti terminai.

Trečioji korekcija: buhalteris yra suinteresuotoji šalis, o ne tik vertintojas. Apskaitos registrai, kurių nepatvirtins finansų specialistas, nėra baigti, o šis atgalinis ryšys gaunamas jau vėlyvose kūrimo stadijose.

Naudingas realybės patikrinimas: įvertinkite mažiausio įmanomo sprendimo sukūrimo kainą – didžioji knyga, korekcijos, laikotarpio užrakinimas, idempotentiškumas, operacijos su pinigais, vienos šalies PVM, sąskaitos faktūros, banko išrašų importas, gretinimas ir bazinis ataskaitų rinkinys – ir palyginkite tai su vienų metų paslaugos, apmokestinamos pagal suvartojimą (metered service), prenumeratos kaina. Nordlet skelbiami planai prasideda nuo €10 per mėnesį su įtrauktomis 3,000 užklausų ir siekia €300 per mėnesį su 200,000 užklausų. Jei kūrimas kainuoja tik dalį vieno inžinieriaus metų atlyginimo, tai yra rimtas argumentas kurti patiems. Jei tai kainuoja kelis inžinieriaus metus plius nuolatinė priežiūra, skirtumas yra akivaizdus, ir jis dar labiau didėja kiekvienais metais, kai keičiasi taisyklės.

Kada kurti patiems yra tikrai teisingas sprendimas

Trys atvejai, visi jie realūs.

Jūsų didžioji knyga yra jūsų produktas. Jei kuriate mokėjimų platformą, bankinį produktą arba e. piniginę, kurioje balanso elgsena esant lygiagrečioms užklausoms (concurrency) yra jūsų išskirtinumas, didžioji knyga yra branduolys ir ji turėtų būti jūsų. Apsvarstykite galimybę naudoti didžiosios knygos infrastruktūros produktus, užuot kūrę ją nuo nulio, ir laikykite oficialiąją (statutory) apskaitą atskirai.

Jūsų modelis netinka jokiai apskaitos sistemai. Kai kurios prekyvietės turi tikrai neįprastas atsiskaitymo struktūras – kelių šalių padalijimus (splits) su sąlyginiu lėšų atpalaidavimu, sąlyginio deponavimo sąskaitas (escrow) su etapais, sudėtingas rezervų taisykles. Jei joks produktas negali to sumodeliuoti, o apėjimai (workarounds) yra prastesni nei sprendimo sukūrimas – kurkite patys.

Dėl jūsų apimčių kainodara pagal suvartojimą tampa nenaudinga. Pasiekus pakankamai ekstremalų operacijų kiekį, kainodara už užklausą nustoja būti patraukli. Prieš darydami tokią prielaidą, sumodeliuokite tai su realiais skaičiais, nes „ekstremalu“ čia yra daugiau, nei pasiekia dauguma platformų.

Kada pirkti yra teisingas sprendimas

Pirkimas laimi tada, kai apskaita yra būtina, bet nesukuria jūsų produkto išskirtinumo, o tai yra dažniausiai pasitaikantis atvejis. Niekas nesirenka jūsų prekyvietės dėl to, kad jūsų bendražurnalio įrašai (journal entries) yra elegantiški. Žmonės tai pastebi tik tada, kai apskaita yra klaidinga.

Pirkimas taip pat yra teisingas sprendimas, kai jūsų mokestiniai įsipareigojimai apima kelias šalis. Skirtingų šalių PVM taisyklės, įrodymų saugojimas ir privalomi reikalavimai e. sąskaitoms faktūroms yra nuolatinis priežiūros srautas, o tiekėjas amortizuoja šį darbą padalindamas jį visiems savo klientams. Nordlet pateikia šalių ES PVM (EU VAT) su VIES tikrinimu, OSS ir IOSS deklaracijų apskaičiavimu, i.SAF registrais ir EN 16931 UBL Peppol tinklui kaip produkto dalį, o ne kaip projektą, kurį turite planuotis patys.

Vidurio kelias, kurį dažniausiai pasirenka komandos

Praktikoje atsakymas dažniausiai nėra nei viena, nei kita. Jis skamba taip: pirkite didžiąją knygą, kurkite darbo eigą (workflow).

Apskaitos posistemė (backend) yra atsakinga už įrašus, mokestinį vertinimą, dokumentus, laikotarpio uždarymą ir audito seką. Jūsų produktas valdo visa tai, ką mato vartotojai, ir kiekvieną jūsų prekyvietės verslo taisyklę – kada atpalaiduojamos lėšos, kokia yra rezervų politika, kaip nagrinėjami ginčai, ką rodo pardavėjo skydelis (dashboard). Jūs iškviečiate apskaitos API tuo metu, kai pinigai yra patvirtinami (committed), ir pasiliekate tas dalis, kurios iš tiesų priklauso jums.

Toks atskyrimas taip pat geriau atlaiko pokyčius nei alternatyvos. Nauja šalis prideda tik konfigūraciją, o ne naują projektą. Nauja išmokų politika yra jūsų kodas, o ne prašymas tiekėjui.

Ką nuspręsti prieš įsipareigojant

Ar jūsų didžioji knyga kuria išskirtinumą, ar tėra prievolė? Būkite atviri; dažniausiai tai yra prievolė.
Kiek šalių ir ko reikalauja kiekviena iš jų? Tik tarifų, ar deklaracijų, registrų, pateikimo.
Kokia jūsų klaidų taisymo logika? Lėšų grąžinimai po išmokėjimo ir pavėluoti ginčijami mokėjimai (chargebacks) yra atvejai, kurie atskleidžia silpną architektūrą.
Kas tvirtina apskaitos registrus? Įtraukite šį žmogų prieš galutinai patvirtindami architektūrą, o ne po to.
Koks yra dešimties metų duomenų saugojimo planas? OSS įrašai turi būti saugomi dešimt metų nuo sandorio metų pabaigos, o archyvas yra sistema, ne tik atsarginė kopija (backup).
Kaip atrodys migracija po trejų metų? Abiem kryptimis. Sukurkite bandomąjį eksportą pirmąją dieną ir užtikrinkite, kad jis nuolat veiktų.

D.U.K.

Kiek laiko trunka sukurti prekyvietės didžiąją knygą?

Pirmoji versija, registruojanti subalansuotus įrašus (dvejybiniu įrašu), gali pradėti veikti per kelias savaites. Versija, kuri apdoroja lėšų grąžinimus po išmokėjimo, pavėluotus ginčijamus mokėjimus (chargebacks), kelių valiutų apvalinimą, besidubliuojančius paslaugų teikėjo „webhooks“, laikotarpio uždarymą ir buhalterio priimtiną auditą, trunka žymiai ilgiau, o jos priežiūra niekada nesibaigia. Skaičiuokite antrosios versijos kaštus, nes būtent tai reiškia produktą gamybinėje aplinkoje (production).

Ar galime pradėti nuo `balance` stulpelio ir vėliau atlikti migraciją?

Galite, ir daugelis taip daro, bet planuokite, kad migracija bus sunkesnė nei pirminis sukūrimas. Atkurti istoriją iš keičiamo (mutable) balanso įmanoma tik tuo atveju, jei išsaugojote kiekvieną jį pakeitusį įvykį – kitaip tariant, tik tuo atveju, jei jau turėjote didžiąją knygą.

Ar integruotos apskaitos API pakeičia mūsų finansų komandą?

Ne. Jis pašalina rankinį duomenų įvedimą ir derinimą. Kažkas vis tiek turi uždaryti mėnesį, peržiūrėti išimtis, priimti sprendimus ir teikti deklaracijas.

Kaip dėl BDAR (GDPR), jei didžioji knyga yra nekeičiama?

Nekeičiamuose įrašuose saugokite piniginius faktus ir pseudonimizuotas nuorodas, o asmeninius duomenis – atskiroje sistemoje, turinčioje savo saugojimo ir trynimo procesą. Nekeičiamumas (immutability) taikomas finansiniam įvykiui, o ne kiekvienam prie jo pridėtam atributui.

Ar atvirojo kodo apskaitos programinė įranga yra tarpinis variantas?

Tai yra reali galimybė, ir ji pakeičia išlaidų pobūdį, o ne jas pašalina: jūs patys prisiimate prieglobą (hosting), atnaujinimus, kiekvienos šalies lokalizaciją ir atitikties reikalavimų palaikymą. Įvertinkite šiuos kaštus prieš manydami, kad sutaupytos licencijos išlaidos atspindi visą situaciją.