Integruota apskaita: kurti ar pirkti prekyvietėms?

Funkcijų apimties sąrašas, sąnaudų modelis su aiškiomis prielaidomis ir sąlygos, kuriomis kiekvienas atsakymas yra teisingas.

Anksčiau ar vėliau kiekviena prekyvietė (marketplace) susikuria savo didžiąją knygą (ledger). Vienintelis klausimas – ar ji sukuriama sąmoningai, kaip kontroliuojama sistema, ar atsitiktinai, kaip balance stulpelis, į kurį rašo trys skirtingi servisai ir kuriu niekas iki galo nepasitiki.

Šis straipsnis yra apie tai, kaip šį pasirinkimą padaryti apgalvotai. Jame aptariama, ką iš tikrųjų apima šis darbas, kaip įvertinti jo sąnaudas be saviapgaulės ir kokios konkrečios sąlygos pateisina sprendimą kurti patiems, nes kartais tai tikrai yra teisingas kelias.

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

Integruotoji apskaita reiškia, kad apskaitos registrai gyvena jūsų produkte, o ne atskiroje programoje, kurią kas nors atidaro atskirai. Jūsų programinė įranga fiksuoja įrašus įvykių metu, vartotojai mato tai, ką rodo jūsų sąsaja, o mėnesio pabaigoje niekam nereikia eksportuoti skaičiuoklės buhalteriui.

Prekyvietevei tai mažiausiai apima: gautus pirkėjų mokėjimus, sumas, kurias skolingas pardavėjams, uždirbtus komisinius, mokėjimų apdorojimo mokesčius, PVM už jūsų paslaugas ir pagrindinį sandorį, grąžinimus, mokėjimo grąžinimus (chargebacks), rezervus, išmokėjimus ir viso šio turinio suderinimą (reconciliation) su banku ar mokėjimų paslaugų teikėju.

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

Didžioji knyga tėra maža šio darbo dalis. Komandos nuolat klaidingai įvertina apimtį, pradėdamos nuo pirmo punkto ir tik vėliau atrandamos visa kita.

Komponentas	Ką tai apima
Žurnalas ir sąskaitos	Subalansuoti įrašai, sąskaitų planas, sąskaitų tipai, pradiniai likučiai
Nekeičiamumas (immutability)	Tik įrašų pildymo (append-only) saugykla, anuliavimo ir taisymo darbo eiga, jokių vietinių redagavimų
Laikotarpio valdymas	Uždarymas, užrakinimas, vėlyvų įrašų atmetimas, kontroliuojamas atidarymas išsaugant audito pėdsaką
Idempotencija	Raktai, ankstesnių atsakymų saugojimas, dubliavimosi aptikimas pasikeitus siuntiniams (payload)
Pinigų valdymas	Tiksli dešimtainė arba mažiausių piniginių vienetų aritmetika, valiutų kodai, valiutų kursai ir jų šaltinis, apvalinimo sąskaitos
PVM variklis	Šalių tarifai su galiojimo datomis, prekių ar paslaugų teikimo vieta, atvirkštinis PVM apmokestinimas, prievolinio tiekėjo (deemed supplier) taisyklės, išimtys
PVM mokėtojo kodo patikra	Patikra oficialiame registre, kaupinimas (caching), laiko žymos, užklausų identifikatoriai, rankinės peržiūros eilė gedimams
Dokumentai	Sąskaitos faktūros, kreditiniai dokumentai, nenutrūkstamas numeravimas pagal serijas ir metus, PDF generavimas, pristatymas
E. sąskaitų faktūrų išrašymas	Struktūrizuoti formatai, tokie kaip EN 16931 UBL, ir šalies nacionaliniai formatai, kur tai privaloma
Banko duomenų įkėlimas	Išrašo importas arba sutikimu pagrįstas banko ryšys, jau importuotų operacijų dublikatų šalinimas
Suderinimas (reconciliation)	Suderinimo taisyklės, vertinimas, daliniai atitikimai, išimtys, kurias žmogus gali išspręsti
Išmokėjimai (payouts)	Mokėjimo failų generavimas, išmokėjimų paketų sudarymas, išmokėjimų susiejimas su pirminiais elementais
Atskaitomybė	Bandomasis balansas (trial balance), balansas, pelno (nuostolio) ataskaita, pinigų srautai, PVM suvestinės, senstantys įsiskolinimai
Mokesčių registrai ir deklaracijos	Viskas, ko reikalauja jūsų šalys, institucijos priimamu formatu
Auditas	Vykdytojas, veiksmas, subjektas ir pats pakeitimas, užklausiamas kiekvienam pakeitimui
Saugojimas ir eksportas	Dešimties metų saugojimas OSS įrašams, pilnas duomenų eksportas, apsaugomas archyvas

Apytiksliai tik du iš šių septyniolika punktų yra tai, ką dauguma komandų įsivaizduoja sakydamos „mes pasidarysime savo didžiąją knygą“.

Sąžiningas sąnaudų apskaičiavimas

Bet koks skaičius čia priklauso nuo jūsų komandos, todėl šį skyrių vertinkite kaip metodą, o ne kaip fiksuotą kainos pasiūlymą. Paimkite pirmiau išvardytus komponentus, priskirkite kiekvienam iš jų apimtį inžinieriumi-savaitėmis, remdamiesi savo komandos greičiu, ir pritaikykite tris pataisas, kurias vertinimai dažniausiai praleidžia.

Pirmoji pataisa: atitikties komponentai nėra vienkartiniai. Keičiasi tarifai, keičiasi ribos, keičiasi formatai, o ES PVM skaitmeniniame amžiuje (VAT in the Digital Age) paketas atneša konkrečių datų įpareigojimus – OSS ir IOSS pakeitimus nuo 2027 m. sausio 1 d., išplėstas platformų taisykles nuo 2028 m. liepos 1 d., tarpvalstybinį skaitmeninį teikimą nuo 2030 m. liepos 1 d. Kūrimas reiškia, kad kiekvieną iš šių migracijų turėsite atlikti patys.

Antroji pataisa: koregavimo darbai perauga funkcijų kūrimą. Pirmoji versija susitvarko su idealiuoju scenarijumi (happy path). Ilgąją uodegą sudaro grąžinimai po išmokėjimo, daliniai grąžinimai, po kelių savaičių atkeliaujantys mokėjimo grąžinimai, valiutos apvalinimas, pasikartojantys internetiniai pranešimai (webhooks) ir atsiskaitymų failai, kurie nesutampa su jūsų įrašais. Štai čia ir ištirpsta laikas kalendoriuje.

Trečioji pataisa: buhalteris yra suinteresuotas asmuo, o ne recenzentas. Apskaita, kurios finansų profesionalas nepasirašys, nėra baigta, o tokie atsiliepimai dažniausiai gaunami vėlyvame kūrimo etape.

Naudingas sveikojo proto patikrinimas: įkainokite mažiausią patikimą kūrimą – didžiąją knygą, pataisymus, laikotarpio užrakinimą, idempotenciją, pinigų valdymą, vienos šalies PVM, sąskaitas faktūras, banko importą, suderinimą ir bazinį ataskaitų rinkinį – ir palyginkite tai su vienerių metų pagal naudojimą apmokamos paslaugos kaina. „Nordlet“ skelbiami planai prasideda nuo 10 Eur per mėnesį, įskaitant 3 000 užklausų, ir siekia 300 Eur per mėnesį su 200 000 užklausų. Jei sukūrimas kainuoja tik dalį vieno inžinieriaus metinio atlyginimo, tai yra rimtas argumentas kurti. Jei tai kainuoja kelis inžinierius-metus plius nuolatinę priežiūrą, palyginimas netenka prasmės, o bėgant metams ir keičiantis taisyklėms ši atskirtis tik didėja.

Kada kūrimas iš tikrųjų yra teisingas pasirinkimas

Trys atvejai, visi realūs.

Jūsų didžioji knyga yra jūsų produktas. Jei kuriate mokėjimų platformą, bankininkystės produktą ar piniginę, kurioje balanso elgsena esant lygiagretumui yra jūsų išskirtinumas, didžioji knyga yra jūsų branduolys ir turėtų priklausyti jums. Tokiu atveju svarstykite didžiosios knygos infrastruktūros produktus, o ne kūrimą nuo nulio, ir atskirkite įstatyminę apskaitą.

Jūsų modelis netelpa į jokią apskaitos sistemą. Kai kurios prekyvietės turi išties neįprastas atsiskaitymų struktūras – kelių šalių padalijimus su sąlyginiais išmokėjimais, sąlyginį deponavimą (escrow) su etapiniais pasiekimais, sudėtingas rezervų politikas. Jei joks produktas to nemodeliuoja, o aplinkiniai sprendimai prastesni už pačių kūrimą – kurkite.

Dėl jūsų masto paslaugos kaina pagal naudojimą tampa netinkama. Esant pakankamai dideliam sandorių dažniui, kainodara už užklausą nustoja būti patraukli. Prieš darant prielaidas, išmėginkite tai su realiais skaičiais, nes čia „didžiulis mastas“ yra didesnis, nei pasiekia daugelis platformų.

Kada pirkti yra geriau

Pirkimas laimi tada, kai apskaita yra būtina, bet neišskiria jūsų iš konkurentų. Tai yra dažniausias atvejis. Nėra vartotojų, kurie pasirinktų jūsų prekyvietę dėl elegantiškų žurnalo įrašų. Jie pastebi apskaitą tik tada, kai ji neteisinga.

Pirkimas taip pat yra teisingas pasirinkimas, kai jūsų prievolės apima kelias šalis. PVM taisyklės kiekvienoje šalyje, įrodymų saugojimas ir e. sąskaitų faktūrų išrašymo reikalavimai yra nuolatinis priežiūros srautas, o pardavėjas paskirsto šį darbą visiems savo klientams. „Nordlet“ savo produkte jau pateikia ES PVM pagal šalis su VIES patikra, OSS ir IOSS deklaracijų apskaičiavimu, i.SAF registrais ir EN 16931 UBL formatu, skirtu Peppol, o ne kaip projektą, kurį turite suplanuoti patys.

Vidurio kelias, kurį dažniausiai renkasi dauguma komandų

Praktinis atsakymas dažniausiai nėra nei viena, nei kita kraštutinybė. Jis skamba taip: pirkite didžiąją knygą, susikurkite darbo eigą.

Apskaitos vidinė sistema valdo įrašus, mokesčių apdorojimą, dokumentus, laikotarpio uždarymą ir audito pėdsaką. Jūsų produktas valdo viską, ką mato vartotojai, ir visas jūsų prekyvietei būdingas verslo taisykles – kada išmokamos lėšos, kokia yra rezervų politika, kaip sprendžiami ginčai, ką rodo pardavėjo skydelis. Jūs iškviečiate apskaitos API tuo momentu, kai pinigai yra įsipareigojami, ir pasiliekate tik tai, kas iš tikrųjų priklauso jums.

Ši riba taip pat geriau atlaiko pokyčius nei alternatyvos. Nauja šalis reikalauja tik konfigūracijos, o ne naujo projekto. Nauja išmokėjimų politika yra jūsų kodas, o ne užklausa pardavėjui.

Ką nuspręsti prieš įsipareigojant

Ar jūsų didžioji knyga yra išskirtinumas (differentiator), ar prievolė? Būkite sąžiningi; daugeliui tai tėra prievolė.
Kiek šalių ir ko reikalauja kiekviena iš jų? Tik tarifų, ar deklaracijų, ar registrų, ar pateikimo.
Kokia jūsų klaidų taisymo istorija? Grąžinimai po išmokėjimo ir vėlyvi mokėjimo grąžinimai yra atvejai, kurie atskleidžia silpną dizainą.
Kas pasirašo apskaitos knygas? Įtraukite šį asmenį dar prieš baigiant projektavimą, o ne po jo.
Koks yra dešimties metų saugojimo planas? OSS įrašai turi būti saugomi dešimt metų nuo sandorio metų pabaigos, o archyvas yra sistema, o ne atsarginė kopija.
Kaip atrodys migracija po trejų metų? Abiem kryptimis. Sukurkite bandomąjį eksportą pirmąją dieną ir užtikrinkite, kad jis veiktų.

D.U.K.

Per kiek laiko galima sukurti prekyvietės didžiąją knygą?

Pirmąją versiją, kuri registruoja subalansuotus įrašus, galima paleisti per kelias savaites. Versija, kuri tvarko grąžinimus po išmokėjimo, vėlyvus mokėjimo grąžinimus, daugiavaliutį apvalinimą, pasikartojančius teikėjo internetinius pranešimus, laikotarpio uždarymą ir auditą, kuriam pritaria buhalteris, užima pastebimai daugiau laiko, o jos priežiūra niekada nesibaigia. Planuokite antrąjį variantą, nes būtent tai reiškia gamybinė aplinka (production).

Ar galime pradėti nuo `balance` stulpelio ir migruoti vėliau?

Galite, ir daugelis taip daro, tačiau pasiruoškite tam, kad migracija bus sunkesnė nei pirminis kūrimas. Atkurti istoriją iš keičiamo balanso įmanoma tik tuo atveju, jei išsaugojote kiekvieną įvykį, kuris jį pakeitė – kitaip tariant, tik tuo atveju, jei jau turėjote didžiąją knygą.

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

Ne. Ji pašalina rankinį registravimą ir suderinimą. Kažkas vis tiek turi uždaryti mėnesį, peržiūrėti išimtis, priimti sprendimus ir pateikti deklaracijas.

O kaip su BDAR (GDPR), jei didžioji knyga yra nekeičiama?

Piniginius faktus ir pseudonimines nuorodas laikykite nekeičiamuose įrašuose, o asmens duomenis – atskiroje sistemoje su jos pačios saugojimo ir trynimo procesais. Nekeičiamumas taikomas finansiniam įvykiui, o ne kiekvienam su juo susijusiam atributui.

Ar atvirojo kodo apskaitos programinė įranga yra vidurio kelias?

Tai reali alternatyva, kuri keičia sąnaudas, o ne jas panaikina: jūs patys perimate prieglobą, naujinimus, pritaikymą šaliai ir atitikties atnaujinimus. Įkainokite visa tai prieš vertindami licencijos taupymą kaip visą paveikslą.