Sąskaitų faktūrų išrašymas ir siuntimas automatiškai: i.SAF bei bankų integracija

1. Finansinė rankinio sąskaitų valdymo kaina

Vidutinė Lietuvos B2B įmonė, per mėnesį išrašanti 600–900 sąskaitų faktūrų, kas mėnesį sudegina nuo 70 iki 110 kvalifikuoto apskaitos specialisto darbo valandų vien tik tam, kad perrašytų duomenis iš CRM ar sandėlio valdymo sistemos į apskaitos programą, sugeneruotų PDF failus, prisegtų juos prie el. laiškų ir iki mėnesio 20 dienos rankiniu būdu suformuotų bei įkeltų i.SAF registrą į VMI i.MAS posistemę.

Skaičiuojant tiesioginius kaštus, kai buhalterio ar finansų administratoriaus darbo vietos kaina darbdaviui siekia 19,50 €/val. (įskaitant VSD ir darbdavio įmokas), vien sąskaitų formavimas ir išsiuntimas generuoja 1 365–2 145 € mėnesinių išlaidų. Tačiau tai tik ledkalnio viršūnė. Tikrieji nuostoliai prasideda ten, kur atsiranda žmogiškojo faktoriaus klaidos:

• Pavėluoti mokėjimai (DSO – Days Sales Outstanding): Kai sąskaita klientą pasiekia ne sandorio sudarymo ar prekės išsiuntimo akimirką, o po 3–5 dienų (kai buhalterija randa laiko suvesti duomenis), bendras pinigų surinkimo ciklas pailgėja vidutiniškai 4,2 dienos. 500 000 € mėnesinę apyvartą turinčiai įmonei tai reiškia įšaldytą apyvartinį kapitalą, kurio vertė siekia mažiausiai 70 000 €.
• Klaidos PVM klasifikatoriuose: Neteisingai nurodytas PVM kodas (pvz., PVM1 vietoje PVM100 taikant atvirkštinį apmokestinimą) sukelia neatitikimus VMI kryžminio sutikrinimo metu, kas lemia pakartotinį registrų tikslinimą, buhalterijos viršvalandžius ir padidintą riziką patekti į VMI stebėsenos radarą.
• Prarasti užsakymai ir klientų trintis: B2B pirkėjai tikisi sąskaitos faktūros iškart po pristatymo patvirtinimo. Rankinis vėlavimas sukuria trintį tarp pardavimų skyriaus, logistikos ir kliento apskaitos.

Šiuolaikinė saskaitu israsymo programa privalo būti ne atskiras „langas darbuotojui suvesti duomenis“, o nematomas, fone veikiantis orkestratorius, sujungiantis komercinius įvykius, ERP, bankų sąskaitas ir valstybinius registrus į vientisą bežmogiškį srautą.

2. Architektūra: nuo CRM įvykio iki i.SAF XML ir banko suderinimo

Tikroji procesų automatizacija veikia be vartotojo sąsajos (headless). Tai reiškia, kad sąskaitos išrašymo procesas inicijuojamas automatiniu įvykiu (event-driven architecture). Žemiau pateikiama pilna duomenų srautų orkestracijos schema, užtikrinanti nulinę rankinio darbo toleranciją.

+---------------------------------------------------------------------------------------------------+
|                                DUOMENŲ SRAUTŲ ARCHITEKTŪRA                                         |
+---------------------------------------------------------------------------------------------------+

 [ CRM / E-komercija / Sandėlis ]
         |
         | (1) Webhook: Užsakymas atliktas / Sutartis pasirašyta (JSON payload)
         v
 +-------------------------------------------------------------------------------------------------+
 |                           SUDERINTA.LT AUTOMATIZAVIMO BRANDUOLYS                                |
 |                                                                                                 |
 |  [Duomenų validavimas] -> [Kliento rekvizitų patikra] -> [PVM kodo priskyrimas (PVM1/PVM100/kt)]|
 +-------------------------------------------------------------------------------------------------+
         |                                           |                                   |
         | (2A) REST API                             | (2B) PDF & Storage                | (2C) Pasirašymas
         v                                           v                                   v
 +-------------------+                     +-------------------+               +-------------------+
 |  Apskaitos ERP    |                     |  Headless HTML2PDF|               | Dokobit Gateway / |
 | (Rivilė, Directo, |                     |  & S3 Saugykla    |               | Smart-ID API      |
 |  B1.lt)           |                     +-------------------+               | (Jei reikalingas) |
 +-------------------+                               |                         +-------------------+
         |                                           |                                   |
         | (3) Įrašo ID                              +-----------------+-----------------+
         v                                                             v
 +-------------------------------------------------------------------------------------------------+
 |  (4) SMTP / SendGrid / Postmark: El. laiškas klientui su PDF ir unikaliu mokėjimo QR kodu       |
 +-------------------------------------------------------------------------------------------------+
         |                                                             |
         | (5) Mėnesio pabaiga / Real-time                             | (6) Kasdienis banko išrašas
         v                                                             v
 +-----------------------------------+                     +---------------------------------------+
 | VMI i.MAS / i.SAF                 |                     | Open Banking API (PSD2) / ISO 20022   |
 | Automatinis XML generavimas &     |                     | camt.053 suderinimas su atviromis     |
 | tiesioginis REST Web Service push |                     | sąskaitomis (Reconciliation engine)   |
 +-----------------------------------+                     +---------------------------------------+

Šios architektūros esmė – asinchroniškumas ir atsparumas klaidoms (fault tolerance). Jei VMI serveriai patiria laikiną perkrovą ar banko API neatsako, pranešimai kaupiami eilių sistemoje (RabbitMQ arba Redis Queue) su eksponentinio atidėjimo (exponential backoff) pakartojimo mechanizmu. Nė vienas įrašas nepasimeta, o apskaitos žurnale išsaugomas pilnas audito pėdsakas (audit trail).

3. Integracijos su Lietuvos ERP sistemomis ir VMI i.MAS

Lietuvos verslo ekosistemoje veikiančios įmonės dažniausiai susiduria su problema, kad standartinė „iš dėžutės“ siūloma saskaitu israsymo programa neturi lanksčių integracinių modulių su specifinėmis vietinėmis sistemomis. Pažvelkime į giliuosius integracinius mazgus:

Rivilė ERP (GAMA ir REST API v2)

Rivilė yra rinkos lyderė, tačiau jos integracija reikalauja griežto duomenų struktūrizavimo. Naudojant Rivilės REST API v2, sąskaitos faktūros įrašas kuriamas per operacijų lenteles (pvz., N08_KROV, I06_PARD). Svarbiausia užtikrinti teisingą kliento kodo priskyrimą: sistema privalo pirmiausia patikrinti, ar pirkėjo įmonės kodas jau egzistuoja klientų sąraše (N17_KLIENT). Jei ne – automatizuotai sukurti naują kortelę, automatiškai užpildant rekvizitus iš Registrų centro ar VMI atvirųjų duomenų bazių.

Directo ir B1.lt ekosistemos

Directo siūlo XML pagrindu veikiantį API, kuriame kritinis elementas yra sąskaitų eilučių dimensijavimas (projektai, kaštų centrai, filialai). Mūsų sprendimas leidžia pagal CRM gautus požymius automatiškai priskirti dimensijas be buhalterio įsikišimo. Dirbant su B1.lt, REST API leidžia tiesiogiai siųsti JSON struktūras, kuriose iškart pažymimas apmokėjimo statusas, jei sandoris buvo apmokėtas per elektroninę bankininkystę ar mokėjimų surinkimo platformą (pvz., Kevin, Neopay, Montonio).

VMI i.MAS posistemės: i.SAF ir i.VAZ

Kiekviena PVM sąskaita faktūra privalo paklusti VMI reikalavimams. Automatizuojant i.SAF registrą, programinis kodas realiu laiku sugeneruoja XML dokumentą pagal galiojančią iSAF1.2.xsd schemą:

• PVM klasifikatoriai: Priklausomai nuo pirkėjo šalies (Lietuva, ES, trečiosios šalys) ir PVM mokėtojo statuso, algoritmas automatiškai parenka teisingą kodą (pvz., standartinis 21% – PVM1, 0% ES tiekimai – PVM13, statybos darbų atvirkštinis apmokestinimas – PVM100).
• Tiesioginis perdavimas: Užuot eksportavus XML failą ir jį rankiniu būdu kėlus per naršyklę į VMI i.MAS portalą, integracija naudoja VMI i.MAS Web Services (WSDL/SOAP API), autentifikuojasi per sertifikatus ir pateikia registrą visiškai automatiškai kiekvienos savaitės ar mėnesio pabaigoje.
• i.VAZ integracija logistikai: Jei kartu su sąskaita išrašomas prekių gabenimo važtaraštis, sistema lygiagrečiai sugeneruoja ir užregistruoja i.VAZ duomenis, grąžindama vairuotojui ar sandėlininkui unikalų važtaraščio numerį ir QR kodą prieš išvažiuojant transportui.

Dokobit ir Smart-ID integracija

Didelės vertės B2B sandoriuose ar rangos aktuose reikalaujama abipusio juridinę galią turinčio el. parašo. Integracija su Dokobit API leidžia sugeneruotą PDF sąskaitą ar atliktų darbų aktą automatiškai pateikti pasirašymui įmonės vadovui per Smart-ID arba Mobile-ID, o gavus parašą – nukreipti tiesiai kliento įgaliotam asmeniui.

4. Lyginamoji analizė: SaaS įrankiai prieš individualią orkestraciją

Rinkoje gausu standartinių sąskaitų išrašymo platformų, tačiau jos dažniausiai išsprendžia tik vieną izoliuotą grandies dalį. Žemiau pateikiamas sisteminis palyginimas tarp tradicinių metodų ir individualiai pritaikytos automatizavimo architektūros.

5. Techniniai spąstai ir kraštutiniai atvejai (Edge Cases)

Daugelis standartinių IT diegimų patiria nesėkmę todėl, kad inžinieriai neįvertina specifinių apskaitos niuansų. Kuriant profesionalų automatizavimo mechanizmą, būtina iš anksto suprogramuoti logiką šiems kraštutiniams atvejams:

1. PVM apvalinimo klaidos (Centų neatitikimai)

Klasikinė problema: skaičiuojant PVM nuo kiekvienos eilutės atskirai ir juos sudedant, gaunamas 0,01 € skirtumas, palyginus su PVM skaičiavimu nuo bendros sumos. Pagal Lietuvos PVM įstatymą leistini abu būdai, tačiau i.SAF XML schema reikalauja griežto matematinio balanso tarp apmokestinamosios vertės ir apskaičiuoto mokesčio pagal kiekvieną PVM tarifą. Sistema privalo turėti vidinį algoritmą, kuris eilučių lygmeniu išlygina apvalinimo nuokrypius pagal VMI validatoriaus taisykles.

2. Avansiniai mokėjimai ir galutinis sudengimas

Kai klientas sumoka avansą, išrašoma avansinė sąskaita faktūra arba PVM sąskaita faktūra avansui. Išrašant galutinę sąskaitą, sistema privalo:

• Automatiškai identifikuoti anksčiau išrašytus ir apmokėtus avansus pagal kliento kodą ir sutarties numerį.
• Galutinėje sąskaitoje suformuoti minusinę eilutę avanso sumai su atitinkama PVM proporcija.
• Apskaitos sistemoje (ERP) automatiškai sukurti tarpusavio užskaitos operaciją, kad skolos likutis taptų lygus nuliui.

3. Kreditinės sąskaitos ir grąžinimai

Rankinis kreditinių sąskaitų išrašymas dažnai sukelia chaosą sandėlio likučiuose. Automatizuotas sprendimas, gavęs signalą apie prekių grąžinimą, privalo patikrinti pradinės sąskaitos seriją ir numerį, automatiškai sugeneruoti kreditinę PVM sąskaitą faktūrą su nuoroda į pirminį dokumentą ir perduoti koreguotą įrašą į i.SAF su tipo kodu KS (Kreditinė sąskaita).

4. Užsienio valiutos ir LB oficialus kursas

Jei sąskaita išrašoma užsienio valiuta (USD, GBP, PLN), pagal įstatymą PVM suma privalo būti perskaičiuota ir nurodyta eurais pagal sąskaitos išrašymo dienos Lietuvos banko (arba ECB) oficialų valiutos kursą. Mūsų branduolys tiesiogiai per REST API kreipiasi į LB duomenų bazę, nuskaito tos dienos kursą ir sugeneruoja teisiškai nepriekaištingą dokumentą.

6. Finansinis ROI modelis: CFO kalkuliacija

Priimant sprendimą dėl automatizavimo, CFO domina ne „technologinis grožis“, o investicijų grąža (ROI) ir atsipirkimo periodas. Pateikiame realų finansinį modelį, pritaikytą Lietuvos didmeninės prekybos arba B2B paslaugų įmonei.

Pradiniai duomenys:

• Išrašomų sąskaitų kiekis: 850 vnt./mėnesį.
• Rankinio apdorojimo laikas: 7 minutės vienai sąskaitai (suvedimas į ERP, PDF kūrimas, el. laiško siuntimas, kliento skambučiai dėl patikslinimų).
• Iš viso laiko per mėnesį: (850 × 7) / 60 = 99,17 val.
• Banko išrašų suderinimas ir i.SAF ataskaitos formavimas: 16 val./mėnesį.
• Bendros darbo laiko sąnaudos: 115,17 val./mėnesį.
• Apskaitininko / finansų asistento valandinis įkainis darbdaviui: 19,50 €/val.

Tiesioginiai kaštai dabartinėje būsenoje:

115,17 val. × 19,50 € = 2 245,82 € per mėnesį (arba 26 949,84 € per metus).

Būsena po automatizacijos:

• Žmogiškojo įsikišimo poreikis: sumažėja 95% (lieka tik nestandartinių situacijų priežiūra – apie 5 val./mėn.).
• Naujos mėnesinės darbo laiko sąnaudos: 5 val. × 19,50 € = 97,50 €/mėn.
• Mėnesinis tiesioginis sutaupymas: 2 245,82 € - 97,50 € = 2 148,32 €/mėn.
• Papildoma vertė: DSO sutrumpėjimas 4 dienomis atlaisvina vidutiniškai 35 000 € apyvartinio kapitalo, kas prie 6% trumpalaikio skolinimosi palūkanų normos duoda papildomus 2 100 € per metus finansinių sąnaudų sutaupymo.

Atsipirkimo laikas (Break-even):

Tipinio individualaus Suderinta.lt integracijos projekto įgyvendinimo investicija siekia apie 4 200 – 5 500 € (vienkartinis diegimas be kasmėnesinių brangių licencijų mokesčių).

Atsipirkimo terminas: 58–75 dienos (mažiau nei 2,5 mėnesio).

7. 4 savaičių diegimo planas

Automatizacijos diegimas neturi paralyžiuoti įmonės kasdienės veiklos. Mes taikome griežtą 4 savaičių inžinerinį ciklą, kurio metu senoji sistema veikia lygiagrečiai, kol naujasis sprendimas pasiekia 100% patikimumo rodiklį.

• 1 Savaitė: Duomenų auditas ir architektūrinis projektas. Išanalizuojame Jūsų CRM, ERP (Rivilė, Directo ar kt.) struktūrą, pirkėjų duomenų kokybę, PVM kodų logiką ir banko išrašų formatus. Parengiama techninė specifikacija ir API schemos.
• 2 Savaitė: Integracinio branduolio kūrimas. Sukonfigūruojami webhooks, paruošiama PDF generavimo infrastruktūra pagal Jūsų firminį stilių, suprogramuojamos taisyklės PVM kodų parinkimui ir i.SAF XML generavimui pagal iSAF1.2.xsd.
• 3 Savaitė: Bankų (Open Banking / camt.053) ir ERP susiejimas. Integruojamas automatinis banko išrašų nuskaitymas ir skolų dengimas. Atliekami testai „smėlio dėžėje“ (Sandbox aplinkoje), imituojant šimtus skirtingų scenarijų: nuo užsienio valiutos iki kreditinių sąskaitų.
• 4 Savaitė: Bandomasis paleidimas (Shadow Run) ir perdavimas. Sistema 5 dienas veikia šešėliniu režimu: apdoroja realius duomenis, bet sąskaitas tikrina specialistai. Pasiekus nulinį klaidų lygį, atliekamas pilnas perjungimas į gamybinę aplinką, apmokoma komanda ir perduodama dokumentacija.

8. Veikiantis prototipas per 48 valandas

Nustokite eikvoti brangų finansų komandos laiką mechaniniam duomenų perrašinėjimui ir klaidų taisymui. Šiuolaikinė saskaitu israsymo programa privalo dirbti Jums, o ne reikalauti papildomo darbuotojo jos priežiūrai.

Atsiųskite mums savo šiuo metu naudojamos sąskaitos pavyzdį, Excel ataskaitą arba trumpą proceso aprašymą, ir per 48 valandas visiškai nemokamai parengsime veikiantį Jūsų sąskaitų generavimo bei i.SAF integracijos prototipą. Jokių įsipareigojimų – tiesiog pamatykite, kaip Jūsų procesas veikia be žmogaus rankų.