Skip to main content

Bilko HR Autopilot — Implementation Plan

Bilko HR — plan za kontrolirano autonomno knjigovodstvo

Verzija: 1.12
Datum bazne procjene: 2026-08-02
Zadnja provedbena sinkronizacija: 2026-08-03
Status: Gate 0 u provedbi — tehničkiG0-07 idokumentacijske neovisnikontrole dokazisu postoje,zatvorene, ali završni Gate 0 exit gate još nije zatvoren
Tržište: Hrvatska (HR)
Prvi proizvodni segment: paušalni uslužni obrt bez zaposlenih
Drugi segment: mikro d.o.o. u sustavu PDV-a

Ovaj dokument konsolidira postojeću gap analizu, competitive research, market-readiness matricu, sprint plan i provjerene dijelove Kotlin koda. Ne zamjenjuje pravno ili računovodstveno mišljenje. Svaka regulatorna funkcija mora imati datiran izvor, stručni HR pregled i produkcijski dokaz prije javne tvrdnje.

1. Izvršni sažetak

Bilko već ima dobar tehnički temelj: API-first arhitekturu, dvojno knjigovodstvo, audit trag, ulazne račune, inbox, KPO/paušalni modul, compliance kalendar, osnovni bankovni CSV import, ručno usklađenje i posting-rule engine. To ga pozicionira bolje od običnog invoicing alata.

Bilko još nije zatvoren autonomni računovodstveni sustav. Najveći nedostaci su:

  1. verificirani produkcijski eRačun/Fiskalizacija 2.0 tok;
  2. verificirani PSD2/AIS bankovni feed;
  3. potpuni i od hrvatskog stručnjaka potvrđen RRiF kontni plan;
  4. širi, efektivno datirani set hrvatskih pravila knjiženja;
  5. jedinstveni confidence/risk gate i exception inbox;
  6. period lock, close engine i kontrolirano ponovno otvaranje;
  7. verificirane porezne prijave i produkcijska predaja;
  8. produkcijski onboarding, billing i dubinski E2E/UAT dokaz.

Preporuka nije graditi još jedan široki ERP. Bilko treba pobijediti zatvorenim tokom i jednostavnošću:

dokument → normalizacija → prijedlog → deterministička provjera →
risk gate → knjiženje ili iznimka → bankovno usklađenje →
kontrola razdoblja → nacrt prijave → odobrenje/predaja → audit

Prvi cilj je Bilko Autopilot za paušalni obrt. Tek nakon kontroliranog pilota treba otvoriti mikro d.o.o. u PDV-u.

2. Produktna odluka

2.1 Što gradimo

Bilko Autopilot je sustav kontrolirane autonomije koji:

  • prima strukturirane i nestrukturirane poslovne dokumente;
  • predlaže računovodstveni tretman;
  • deterministički provjerava porezna i knjigovodstvena pravila;
  • automatski provodi samo unaprijed definirane sigurne slučajeve;
  • sve nejasnoće šalje u jedinstveni red za pregled;
  • čuva izvor, odluku, pravilo, korisnika i svaku promjenu;
  • nikada ne skriva grešku i nikada ne podnosi prijavu samo na temelju AI izlaza.

2.2 Što sada ne gradimo

Do završetka prvog pilota ne širimo scope na:

  • skladište i proizvodnju;
  • puni vlastiti payroll/JOPPD engine;
  • kompleksne grupe i konsolidaciju;
  • velika poduzeća, IFRS i industrijske vertikale;
  • autonomne godišnje prijave bez stručnog odobrenja;
  • RS i BA produkcijsku autonomiju;
  • mobilnu aplikaciju kao preduvjet osnovnog knjigovodstvenog toka.

2.3 Redoslijed segmenata

Segment Zašto prvi/kasniji Početni opseg
Paušalni uslužni obrt bez zaposlenih najmanje rubnih slučajeva; nema punog GL/PDV toka za sve korisnike računi, naplate, KPO, inbox, dokumenti, rokovi, iznimke
Mikro d.o.o. u PDV-u najveća komercijalna vrijednost, ali znatno viši regulatorni rizik URA/IRA, GL, banke, PDV, close, osnovna sredstva
Obrt/d.o.o. sa zaposlenima payroll i JOPPD povećavaju rizik partner integracija prije vlastitog enginea
Složeniji subjekti mnogo posebnih pravila i izvještaja tek nakon dokazano stabilnog corea

3. Provjerena bazna slika — 2026-08-02

Statusi su namjerno konzervativni. “Kod postoji” nije isto što i “produkcijski verificirano”.

Sposobnost Provjereno stanje Produkcijski zaključak
PDV izračun i izdavanje računa PluginHR označava AVAILABLE; postoje HR stope i validacije temelj postoji; potreban regresijski paket i HR stručni pregled rubnih slučajeva
eRačun serializacija UBL 2.1/HR XML je AVAILABLE_OFFLINE može se koristiti za testiranje, ali nije dokaz live predaje
eRačun slanje sveRačun TEST API je BETA; live je iza SVERACUN_HR_LIVE nije GA; trebaju produkcijski ugovor, tajne, E2E, inbound statusi i operativni dokaz
Storecove stari/stubirani put, supersediran sveRačun smjerom ukloniti iz aktivnog plana i označiti kao legacy dok se ne donese nova odluka
Banka — CSV GlBankService implementira CSV staging, deduplikaciju, prijedloge i ručni match postoji ručni fallback; nije isto što i live bank feed
Banka — PSD2/AIS PluginHR.BANKING_IMPORT = NOT_IMPLEMENTED; Tok je samo planiran nema verificiranog provider toka
Usklađenje osnovni 1:1 prijedlozi i ručno kreiranje DRAFT knjiženja postoje nedostaju split/merge, parcijalna plaćanja, naknade, transferi i pouzdan auto-match
Posting rules PostingRuleEngine provjerava balans, ne računa porez, proizvodi DRAFT i ima ZA_KONTIRANJE dobar temelj; pravila su nedovoljno široka i nemaju potpuni lifecycle/efektivno datiranje
Kontni plan PluginHR vraća reprezentativnih 12 seed konta nije puni verificirani RRiF plan
OCR PDF tekst radi; image OCR je BETA i ovisi o Azure Document Intelligence konfiguraciji dopušten samo kontrolirani pilot nakon provjere konfiguracije, točnosti i fallbacka
Document inbox postoje InboxService, migracije i archive mehanizmi treba objediniti eRačun, email, upload, hash, malware scan, deduplikaciju i lifecycle
Email Resend je ožičen u kodu i PluginHR ga označava AVAILABLE uz konfiguraciju produkcijska domena, deliverability i E2E moraju imati dokaz
Payroll HR gross-to-net modul je PREVIEW i feature-gated nije HR GA; koristiti partnera dok nema poreznog stručnog sign-offa i JOPPD E2E
PDV prijava postoje izvještaji; XML je ranije označen kao stub/neprovjeren samo nacrt/pregled, ne službena predaja
Compliance kalendar servisi i katalog postoje potreban versioned legal source, scheduler i dokaz dostave podsjetnika
Accountant portal dio backend temelja postoji potreban završeni cross-org UX, RLS dokaz, review/approval workflow
Close/lock nema dokazanog potpunog close enginea produkcijski blocker za autonomno knjigovodstvo
Onboarding/billing Entra-only login radi; self-serve signup/trial-to-paid i nijeme 403 billing greške su ranije nađene blocker za samostalan komercijalni onboarding

3.1 Obvezna korekcija statusa

docs/product/MARKET-READINESS-MATRIX.md i dio starijih gap dokumenata zaostaju za trenutnim kodom. Prije razvoja mora se uspostaviti jedan source of truth:

  1. runtime /market/capabilities kao izvršna istina;
  2. test koji provjerava capability statuse;
  3. generirana ili ručno kontrolirana market-readiness dokumentacija;
  4. datiran evidence zapis za svaki AVAILABLE/GA status;
  5. zabrana prodajne tvrdnje koja nema evidence ID.

4. Ciljni operativni model

4.1 Green / amber / red lane

Lane Značenje Dozvoljena akcija
Green pravilo je determinističko, dokument potpun, identitet i iznosi usklađeni, period otvoren, nema duplikata automatski DRAFT; POST samo ako je organizacija eksplicitno uključila odobrenu politiku za taj tip događaja
Amber postoji razuman prijedlog, ali nedostaje podatak, confidence je srednji ili je slučaj nov obvezni ljudski pregled u exception inboxu
Red porezni rizik, nepoznat partner, neuobičajen iznos, zatvoren period, sumnja na duplikat/prijevaru, prijava ili isplata blokada i eskalacija ovlaštenom računovođi

4.2 Pravilo za AI

AI smije:

  • čitati i normalizirati dokument;
  • predložiti kategoriju, konto i objašnjenje;
  • prepoznati odstupanje i tražiti podatak;
  • rangirati potencijalne match kandidate.

AI ne smije:

  • izravno pisati u glavnu knjigu;
  • izmišljati porezno pravilo ili konto;
  • zaobići period lock, RBAC ili tenant izolaciju;
  • podnijeti poreznu prijavu bez determinističke validacije i definirane politike odobrenja;
  • mijenjati već knjiženu stavku; ispravak ide kroz storno/reversal.

4.3 Ciljni tehnički tok

[Kanali]
eRačun | email-in | PDF/XML | fotografija | banka | ručni unos
    ↓
[Document Gateway]
hash + malware scan + tenant + source metadata + immutable original
    ↓
[Normalizer]
canonical document + extracted fields + field-level confidence/provenance
    ↓
[Rules & Proposal]
accounting event + tax treatment + posting proposal + rule version
    ↓
[Deterministic Validators]
math + OIB/IBAN + PDV + duplicates + period + CoA + permissions
    ↓
[Risk Gate]
GREEN / AMBER / RED + reasons
    ↓
[Posting Command]
idempotency key + DRAFT/POST policy + append-only audit
    ↓
[Reconciliation]
bank 1:1 / 1:n / n:1 / partial / fee / transfer
    ↓
[Close & Filing]
checklist + lock + reconciliation completeness + filing draft + approval

4.4 Minimalni audit zapis za svaku odluku

Svaka automatska ili ručna odluka mora sadržavati:

  • tenant i korisnika/servis koji je pokrenuo akciju;
  • hash i lokaciju originalnog dokumenta;
  • izvor svakog ekstrahiranog polja;
  • model/prompt verziju ako je AI korišten;
  • pravilo i verziju pravila;
  • confidence, lane i razloge;
  • ulazni i izlazni payload bez tajni;
  • idempotency key;
  • vezu na DRAFT/POST/REVERSAL zapis;
  • vrijeme, korelacijski ID i odobritelja.

5. Izvršni plan po gateovima

Trajanje je raspon za planiranje, ne obećanje. Pretpostavka je jedan fokusirani cross-functional squad, hrvatski računovodstveni stručnjak dostupan najmanje 1–2 dana tjedno i neblokirani provider ugovori. Radni tokovi se mogu preklapati tek kada su ovisnosti zatvorene.

Gate 0 — Istina, sigurnost i release baseline

Procjena: 1–2 tjedna
Cilj: svi grade prema istom provjerenom stanju i nema P0 rizika prije pilot podataka.

Zadaci

ID Prioritet Zadatak Primarni owner Acceptance
G0-01 P0 Napraviti capability inventory iz runtimea, koda, migracija, UI-a i E2E testova Product + CodeCraft jedna matrica; svaki status ima evidence link i datum
G0-02 P0 Uskladiti PluginHR, market-readiness matricu i prodajni copy CodeCraft + Product nema proturječnih OCR/banking/payroll/eRačun tvrdnji
G0-03 P0 Zatvoriti otvorene security/tenant isolation nalaze Securion + CodeCraft RLS negativni testovi prolaze; nema cross-org čitanja ni mutacije
G0-04 P0 Verificirati Entra onboarding, pozive, trial-to-paid i billing error UX CodeCraft + Vizu novi korisnik može završiti onboarding; svaka billing greška je vidljiva i akcijska
G0-05 P0 Definirati feature flags, secret provisioning i environment promotion FlowForge dev/test/stage/prod su odvojeni; nijedna tajna nije u kodu ili dokumentaciji
G0-06 P0 Uspostaviti evidence strukturu i release checklist Proveo backend, frontend, browser, DB i provider dokazi imaju standardni format

Exit gate

  • capability API, dokumentacija i UI govore isto;
  • nema otvorenog P0 tenant/security nalaza;
  • staging se reproducibilno deploya i vraća;
  • onboarding i osnovni billing prolaze E2E;
  • pilot podaci se ne unose prije Proveo sign-offa.

Provedbeno stanje — 2026-08-03

Izvršni korak Stanje Provjereni rezultat
G0-00 baseline i collision map PASS Azure DevOps main baseline 9f7cbd14dbbcbbafed5ef4da48e36980556ba9d8; odvojeni čisti worktreeovi; nema preuzimanja scopea MC #106632 ni izmjene dirty primary worktreea
G0-01 capability inventory PASS konzervativni strojni inventory i evidence veze postoje; live eRačun, PSD2/AIS, konfigurirani OCR, puni RRiF, payroll i filing nisu označeni GA
G0-02 runtime/docs/UI SSOT PASS EMAIL_SEND ostaje BLOCKED_PROVIDER; provider-backed akcije zahtijevaju AVAILABLE; HR live integracije ostaju fail-closed/non-GA
G0-03 tenant isolation PASS uz otvoreni P1 live blocker stvarni PostgreSQL/Testcontainers RLS paket: 29/29, bez skip/failure/error; cross-tenant čitanja i mutacije blokirani; nema otvorenog P0
G0-04 onboarding i billing E2E PASS aktualni Entra-only tok, fail-loud billing UX i local-only Playwright 4/4 imaju builder i neovisni Proveo dokaz
G0-05 environment/release controls PARTIAL verzionirana Azure matrica, OFF defaulti, CI verifier, promotion i rollback procedura te zero-new-secret scoped scan prolaze; nije izvršen live stage deploy ni live rollback, a produkcija nije provisionirana
G0-06 neovisna validacija PASS za builder/evidence readiness Proveo je neovisno dao PASS za D1/D2/D3/D5 te za D4/D6; PASS ne znači deployed, GA, DONE ni završetak parent programa
G0-07 dokumentacija i BookStack U TIJEKUPASS ova stranica bilježi provjerene rezultate i blokere; završniZAKON lint, Prettier, Bilko-shelf sync, BookStack syncAPI provjera i postflight potvrdemarkeri morajuprolaze; jošMC proći#106706 i #106722 su ready_for_review, ne DONE

Implementacijski commitovi:

  • D2/D3/D5: 29fabe92471e99993fb23685ba3aead688e3b54b
  • D4 tenant-isolation testovi: c27bb1a5b653c491d9261904210642cbbd36c5af
  • D6 release kontrole: 7cb895a035ad4715714d5a87cf1e3c427fc12008

Kanonski strojni dokazi:

  • /Users/makinja/system/evidence/106701/baseline-collision-map.json
  • /Users/makinja/system/evidence/106701/proveo-106706-final.json
  • /Users/makinja/system/evidence/106701/tenant-isolation-verdict.json
  • /Users/makinja/system/evidence/106701/environment-release-matrix.json
  • /Users/makinja/system/evidence/106701/proveo-106722-verdict.json
  • /Users/makinja/system/evidence/106701/g0-07-bookstack-validation.log
  • /Users/makinja/system/state/postflight-cleared-106706.json
  • /Users/makinja/system/state/postflight-cleared-106722.json

Otvorene granice i blocker-i:

  1. DbIssuerProfileRepository.findByOrgId() koristi transakciju bez postavljenog org konteksta. RLS se ponaša fail-closed i nije dokazan cross-tenant pristup, ali nalaz ostaje P1 blocker za SVERACUN_HR_LIVE dok se ne popravi i neovisno ponovno validira.
  2. staging_path_verified i rollback_path_verified dokazuju verzioniranu konfiguraciju i proceduru, ne izvršeni live deployment ili rollback.
  3. Cijeli repo Gitleaks baseline ima dva ranije postojeća synthetic test nalaza u apps/api/build.gradle.kts; scoped D6 promjene imaju nula nalaza. Ne smije se tvrditi da cijeli repo ima nula nalaza.
  4. SVERACUN_HR_LIVE, SEF_RS_LIVE, STORECOVE_HR_LIVE i DB adapter enablement ostaju OFF po defaultu; nema produkcijskog deploya ni provider aktivacije.
  5. Potrebno je imenovati hrvatskog računovodstvenog reviewera i provider ownere prije regulatornog/live rada.

Gate 1 preporuka: NO-GO za pilot podatke i produkcijske akcije. Dopušteno je samo planiranje/remedijacija. G0-07 postflight/BookStack kontrole su zatvorene, ali GO se može ponovno razmotriti tek nakon dokaza stvarnog stage deploy/rollback toka, zatvaranja obveznih postflight/BookStack kontrola, imenovanja ownera te eksplicitne odluke da otvoreni P1 ne ugrožava odabrani Gate 1 scope. Ova preporuka ne odobrava Gateove 1–6.

Gate 1 — Autopilot za paušalni obrt

Procjena: 4–6 tjedana nakon Gatea 0
Cilj: zatvoren svakodnevni tok za jednostavan paušalni obrt bez zaposlenih.

Opseg

  1. izdavanje računa i eRačun TEST tok;
  2. email/PDF/XML/fotografija u document inbox;
  3. naplata putem CSV bankovnog izvoda;
  4. KPO automatski izveden iz verificiranih naplata;
  5. compliance obveze i podsjetnici;
  6. jedinstveni exception inbox;
  7. mjesečni paket za računovođu.

Zadaci

ID Prioritet Zadatak Primarni owner Acceptance
G1-01 P0 Unified Document Gateway CodeCraft svi kanali daju canonical dokument; original je immutable; hash i tenant su obvezni
G1-02 P0 Upload sigurnost Securion + CodeCraft allowlist formata, size limit, malware scan, MIME provjera i karantena
G1-03 P0 Deduplikacija CodeCraft isti dokument kroz dva kanala ne stvara dva poslovna događaja
G1-04 P0 Field provenance i confidence AgentForge + CodeCraft svako polje ima vrijednost, izvor, confidence i raw evidence lokaciju
G1-05 P0 KPO pravila po naplati CodeCraft + HR računovođa KPO ulaz nastaje samo iz dopuštenog događaja i može se povezati s računom i uplatom
G1-06 P0 Paušalni compliance profil CodeCraft + HR računovođa korisnik ne vidi PDV tok ako nije PDV obveznik; pragovi i rokovi su verzionirani
G1-07 P0 Exception inbox v1 CodeCraft + Vizu missing data, duplicate, unmatched payment i invalid document su u jednom redu s ownerom i SLA-om
G1-08 P1 Accountant export/package CodeCraft + Vizu mjesečni ZIP/PDF/CSV paket ima manifest i hash; jasno označen kao pregled, ne službena predaja
G1-09 P1 Compliance podsjetnici CodeCraft scheduler je idempotentan; email/in-app status je auditiran; nema duplih podsjetnika

Produkcijski acceptance scenariji

  • isti PDF poslan emailom i ručno uploadan proizvodi jedan dokument;
  • nečitljiva fotografija ide u amber lane, ne stvara lažni zapis;
  • bankovna uplata s ispravnim pozivom na broj predlaže pravi račun;
  • parcijalna uplata ne označava račun potpuno plaćenim;
  • naplata u zatvorenom razdoblju ne mijenja KPO bez odobrenog reopen toka;
  • korisnik iz Org A ne može dohvatiti dokument, iznimku ili KPO zapis Org B;
  • svaki automatski rezultat može se objasniti i povezati s originalom.

Exit gate

  • najmanje 95% valjanih testnih dokumenata ulazi bez ručne tehničke intervencije;
  • 100% duplikata iz determinističkog duplicate testa je blokirano;
  • nema automatskog financijskog zapisa bez audit i idempotency ključa;
  • Proveo E2E paket pokriva happy path, greške i tenant izolaciju;
  • HR računovođa potpisuje KPO i paušalni rule pack.

Gate 2 — Produkcijski eRačun/Fiskalizacija 2.0

Procjena: 4–6 tjedana, uz provider ovisnost
Može paralelno s dijelom Gatea 1 nakon G0.

Zadaci

ID Prioritet Zadatak Primarni owner Acceptance
G2-01 P0 Potvrditi sveRačun produkcijski ugovor, SLA, DPA i tehnički kontakt Product + Lexicon potpisani uvjeti i vlasnik eskalacije; bez tajni u evidenciji
G2-02 P0 Prod credential provisioning i rotacija FlowForge + Securion secrets manager, least privilege, rotacija i break-glass procedura testirani
G2-03 P0 Outbound submit lifecycle CodeCraft CREATED→QUEUED→SENT→ACCEPTED/REJECTED; idempotentni submit; nema dvostrukog slanja
G2-04 P0 Status polling/webhook CodeCraft potpis/izvor validiran; out-of-order događaji ne kvare konačni status
G2-05 P0 Retry i DLQ CodeCraft + FlowForge retry samo za retryable greške; backoff; DLQ s replayom i alertom
G2-06 P0 Inbound eRačun CodeCraft primljeni XML se validira, arhivira, deduplicira i šalje u inbox
G2-07 P0 11-godišnja arhiva CodeCraft + FlowForge original XML, prikaz, statusi i potvrde su nepromjenjivo povezani i restorabilni
G2-08 P0 Provider observability FlowForge metričke ploče i alarmi za submit latency, reject rate, backlog, DLQ i webhook failure
G2-09 P0 Independent E2E Proveo TEST i kontrolirani PROD slučaj imaju machine evidence, bez izlaganja podataka/tajni

Exit gate

  • najmanje jedan kontrolirani stvarni outbound i inbound poslovni tok je dokazano završen;
  • duplicate submit, timeout, 4xx, 5xx, invalid XML i out-of-order webhook testovi prolaze;
  • XML, potvrda i audit mogu se restaurirati;
  • live flag se uključuje samo po environmentu i uz CEO/release approval;
  • capability ostaje BETA dok pilot ne zadovolji dogovorene metrike; AVAILABLE/GA traži poseban sign-off.

Gate 3 — Bank feed i reconciliation engine

Procjena: 4–6 tjedana
Cilj: banka postaje pouzdan zatvarač računovodstvenog toka, ne samo import ekran.

Provider odluka

Prije implementacije odabrati jednu od opcija:

  1. Tok, ali samo ako postoji verificirani licencirani/partnerski AIS put, stvarni bank coverage i SLA;
  2. drugi licencirani AIS agregator;
  3. direktni bank partner samo ako je ukupni regulatorni i operativni trošak prihvatljiv.

CSV ostaje trajni fallback. Dodati CAMT.053 i, ako pilot banke zahtijevaju, MT940.

Zadaci

ID Prioritet Zadatak Primarni owner Acceptance
G3-01 P0 Provider due diligence i odluka Product + Lexicon + Securion licenca/partnerstvo, DPA, bank coverage, consent i SLA dokumentirani
G3-02 P0 Consent lifecycle CodeCraft connect, SCA redirect, callback, refresh, revoke i expiry rade bez curenja tokena
G3-03 P0 Idempotent transaction sync CodeCraft pending/booked promjena ne duplicira transakciju; stable provider ID i hash fallback
G3-04 P0 CAMT.053 importer CodeCraft validni izvodi iz pilot banaka reproducibilno se parsiraju s potpunim auditom
G3-05 P0 Reconciliation v2 CodeCraft + HR računovođa podržani 1:1, 1:n, n:1, partial, overpayment, fee, transfer i refund slučajevi
G3-06 P0 Matching score AgentForge + CodeCraft iznos, datum, poziv na broj, IBAN/OIB, partner i povijest daju objašnjiv score
G3-07 P0 Safe auto-match policy CodeCraft auto-match samo iznad odobrenog praga i bez konflikta; nikad auto-post samo zbog fuzzy naziva
G3-08 P1 Reconciliation UX Vizu + CodeCraft korisnik vidi razlog, alternative, split/merge i undo/reversal put
G3-09 P0 Bank security review Securion tokeni šifrirani; webhook provjera; scope minimalan; incident revoke runbook testiran

Exit gate

  • sync je idempotentan preko najmanje dva puna ciklusa;
  • svi definirani reconciliation slučajevi imaju unit, integration i browser test;
  • 100% auto-match odluka ima objašnjenje i policy verziju;
  • pogrešan match se ispravlja reversalom bez brisanja audita;
  • provider outage ne blokira CSV/CAMT fallback.

Gate 4 — GL Autopilot za mikro d.o.o.

Procjena: 6–8 tjedana nakon Gateova 1–3
Cilj: kontrolirano knjiženje ulaznih/izlaznih dokumenata i uplata za jednostavni mikro d.o.o. u PDV-u.

Zadaci

ID Prioritet Zadatak Primarni owner Acceptance
G4-01 P0 Verificirani RRiF seed i mapping HR računovođa + CodeCraft puni odobreni minimum za ciljni segment; verzija, effective dates i migracija
G4-02 P0 Versioned PostingRule lifecycle CodeCraft draft/review/approve/activate/retire; nema retroaktivne promjene već knjiženih rezultata
G4-03 P0 HR rule pack v1 HR računovođa + CodeCraft domaća prodaja/nabava, predujam/konačni, storno, reprezentacija, reverse charge i EU stjecanje u dogovorenom scopeu
G4-04 P0 Risk gate service CodeCraft + AgentForge centralni lane rezultat; hard rules imaju prioritet nad AI confidenceom
G4-05 P0 Posting command/idempotency CodeCraft isti poslovni događaj ne može proizvesti dva journal entryja
G4-06 P0 Approval policy per org/event CodeCraft + Vizu owner/accountant može uključiti auto-POST samo za odobrene green evente
G4-07 P0 Exception inbox v2 CodeCraft + Vizu konto, PDV, partner, duplikat, period, amount mismatch i rule-not-found imaju akcije i SLA
G4-08 P0 Reversal/undo CodeCraft POST se ne briše; ispravak stvara povezani reversal i novi zapis
G4-09 P0 Accounting golden dataset HR računovođa + Proveo najmanje 100 reprezentativnih HR slučajeva s očekivanim knjiženjima i poreznim tretmanom

Hard controls

  • Σ debit = Σ credit za svaki draft i post;
  • porez se računa iz determinističkih pravila, ne iz AI teksta;
  • nepoznato pravilo daje ZA_KONTIRANJE, nikad tihi fallback;
  • konto mora postojati i biti aktivan na datum knjiženja;
  • zatvoreni period odbija posting;
  • posting mora nositi rule version i original source;
  • green lane nije automatski post ako organizacijska policy to ne dopušta.

Exit gate

  • golden dataset prolazi 100% za determinističke iznose i konta u odobrenom scopeu;
  • nema nebalansiranog journal entryja;
  • svaki unsupported slučaj ide u exception, ne u pogrešan konto;
  • računovođa odobrava rule pack i pilot subjekte;
  • Proveo radi neovisnu replay provjeru istih dokumenata.

Gate 5 — Period close i porezne prijave

Procjena: 6–8 tjedana
Cilj: sigurno zatvaranje razdoblja i kontrolirani nacrt PDV prijave. Produkcijska predaja je zaseban pod-gate.

Zadaci

ID Prioritet Zadatak Primarni owner Acceptance
G5-01 P0 Period lock CodeCraft soft close, hard close, ovlašteni reopen s razlogom i auditom
G5-02 P0 Close checklist engine CodeCraft + HR računovođa neusklađena banka, otvorene iznimke, draft knjiženja, duplikati i missing docs blokiraju close
G5-03 P0 Trial balance i subledger controls CodeCraft GL=AR/AP/PDV/banka kontrolne sume imaju nula neobjašnjenih razlika
G5-04 P0 PDV obrazac mapping HR računovođa + CodeCraft svako polje ima pravni izvor, GL mapping, effective date i test case
G5-05 P0 PDV validators CodeCraft cross-field, period, OIB, total i threshold validacije daju akcijske greške
G5-06 P0 Filing draft UX Vizu + CodeCraft korisnik vidi izvor svake brojke, razliku prema prethodnom periodu i otvorene rizike
G5-07 P0 Approval workflow CodeCraft preparer/approver segregacija; prijava se ne može predati s P0/P1 iznimkom
G5-08 P0 ePorezna feasibility i legal path Lexicon + Product + CodeCraft dokumentirana tehnička i pravna mogućnost; ako nije dostupna, ostaje export + manual submit
G5-09 P0 Controlled submit adapter CodeCraft + Securion samo ako G5-08 odobri; idempotentno, potpisano, statusi, potvrda i retry/DLQ
G5-10 P0 Filing E2E evidence Proveo sandbox/odobreni live dokaz i potpuna rekonstrukcija prijave iz audita

Exit gate za nacrt

  • close checklist je zelen;
  • PDV vrijednosti se mogu rekonstruirati do dokumenta i journal postings;
  • stručnjak potvrđuje mapping i validatore;
  • PDF/XML je jasno označen kao nacrt dok submit gate nije završen.

Exit gate za produkcijsku predaju

  • pravni i tehnički kanal je potvrđen;
  • postoji neovisni E2E dokaz potvrde zaprimanja;
  • dual control i least privilege su testirani;
  • rollback znači korektivnu prijavu/reversal po propisu, nikad brisanje povijesti.

Gate 6 — Kontrolirani pilot i GA odluka

Procjena: najmanje 8–12 tjedana stvarnog poslovnog rada
Cilj: dokazati sigurnost i operativnu vrijednost prije širenja.

Pilot kohorta

  • približno 10 jednostavnih paušalnih uslužnih obrta;
  • bez zaposlenih, skladišta, uvoza i kompleksnih EU transakcija;
  • 1–2 partnerska hrvatska računovođe;
  • eksplicitni pristanak za pilot i definirani support kanal;
  • početni shadow mode: Bilko predlaže, računovođa uspoređuje sa stvarnim rezultatom.

Faze pilota

  1. Shadow (2–4 tjedna): nema auto-POST/submit; mjeri se točnost.
  2. Assisted (2–4 tjedna): green DRAFT automatski; čovjek potvrđuje.
  3. Controlled autopilot (4+ tjedna): samo odobreni green eventi mogu auto-POST; filing ostaje dual-control.

Pilot metrike i stop uvjeti

Metrika Cilj za razmatranje GA Stop uvjet
Dokumenti uspješno ingestirani ≥ 95% podržanih formata gubitak originala ili tenant leak
Duplikati 100% determinističkog test seta blokirano jedan stvarni dvostruki posting
Green-lane precision ≥ 99.5% u odobrenom uskom scopeu pogrešno porezno ili GL knjiženje koje je auto-POSTano
Straight-through processing ≥ 70% nakon stabilizacije, bez spuštanja kontrola rast STP-a kroz ignoriranje iznimki
Neriješene P0/P1 iznimke pri closeu 0 close ili filing s otvorenom P0/P1 iznimkom
Bank reconciliation coverage ≥ 95% transakcija klasificirano ili u aktivnom exceptionu nestala/duplicirana bankovna transakcija
Audit rekonstruiran 100% uzorka odluka bez izvora/rule verzije
P0 sigurnosni incident 0 bilo koji P0 incident pauzira pilot

GA se ne proglašava automatski nakon isteka vremena. Potreban je pisani go/no-go zapis s računovodstvenim, sigurnosnim, produktnim i Proveo odobrenjem.

6. Prioritizirani backlog

P0 — mora prije pilota

  • CAP-001 capability SSOT i status reconciliation;
  • SEC-001 tenant/RLS negativni testovi;
  • ONB-001 onboarding + invite + trial-to-paid E2E;
  • DOC-001 unified document gateway;
  • DOC-002 malware/MIME/hash/dedupe;
  • EXC-001 exception inbox;
  • PAU-001 KPO/payment rule pack;
  • ERA-001 sveRačun produkcijski lifecycle;
  • BNK-001 provider odluka i CSV/CAMT fallback;
  • AUD-001 decision audit schema;
  • QA-001 golden datasets i end-to-end evidence.

P1 — mora prije mikro d.o.o. autonomije

  • COA-001 puni ciljani RRiF seed;
  • RUL-001 versioned HR posting rules;
  • RSK-001 risk gate;
  • REC-001 split/merge/partial reconciliation;
  • CLS-001 period lock i close checklist;
  • VAT-001 verificirani PDV mapping i nacrt;
  • ACC-001 accountant review/approval portal;
  • OBS-001 provider i autonomy observability.

P2 — nakon uspješnog pilota

  • osnovna sredstva i amortizacija;
  • širi EU/reverse-charge scope;
  • godišnje zatvaranje i RGFI priprema;
  • payroll partner integracija;
  • mobilni capture kao kanal;
  • dodatne banke i naprednije predviđanje matcha;
  • RS/BA adaptacija tek uz zasebne regulatorne gateove.

7. Test i evidence strategija

7.1 Test piramida

  1. Unit: porezne formule, rounding, OIB/IBAN, rule matching, lane odluka.
  2. Property-based: debit=credit, idempotency, duplicate prevention, monotoni status lifecycle.
  3. Contract: sveRačun, AIS provider, email, OCR i webhook sheme.
  4. Integration: PostgreSQL/RLS, object storage, queue, retry/DLQ, scheduler.
  5. Golden accounting dataset: dokument → očekivani tax/account/posting/exception.
  6. Browser E2E: stvarni korisnički tokovi, ne samo render stranice.
  7. Operational: backup/restore, replay, provider outage, alert i incident runbook.
  8. Security: tenant isolation, RBAC, upload, SSRF/XXE/XML, webhook spoofing, secrets.

7.2 Obvezni negativni scenariji

  • isti event zaprimljen dvaput;
  • provider timeout nakon što je zapravo prihvatio zahtjev;
  • out-of-order webhook;
  • zatvoren period;
  • nepoznati konto ili povučeno pravilo;
  • krivi OIB/IBAN/PDV stopa;
  • iznos dokumenta i zbroj stavki se razlikuju;
  • parcijalna i prekomjerna uplata;
  • jedan bankovni red zatvara više računa i obratno;
  • račun ili dokument drugog tenanta;
  • zlonamjerni PDF/XML/slika;
  • nedostupan OCR, banka, email ili eRačun provider;
  • model daje visoki confidence, ali hard validator pada.

7.3 Evidence paket po releaseu

Svaki release kandidat mora sadržavati:

  • commit/build identitet;
  • rezultate backend i frontend testova;
  • migracijski dry-run i rollback/recovery dokaz;
  • Playwright JSON i screenshotove ključnih tokova;
  • RLS/security rezultate;
  • provider contract/E2E dokaz bez tajni i osobnih podataka;
  • golden dataset diff;
  • log/metrics provjeru bez 5xx i DLQ backloga;
  • računovodstveni reviewer verdict;
  • Proveo PASS/PARTIAL/BLOCKED verdict;
  • ažurirani BookStack status.

8. Operativni model i odgovornosti

Uloga/tim Odgovornost
Product owner scope, segment, prioriteti, provider/commercial odluke
Hrvatski računovodstveni stručnjak RRiF, KPO, PDV, rule pack, golden dataset i regulatorni sign-off
CodeCraft backend, frontend integracija, GL, workflow, provider adapteri
Vizu exception, reconciliation, close i filing UX
AgentForge extraction/classification/matching modeli; bez direktnog postinga
Securion tenant izolacija, threat model, upload/provider/secrets review
FlowForge environments, queues, secrets, deploy, observability, backup/restore
Proveo / Angie neovisna validacija, E2E i release evidence
Skillforge / D1 dokumentacija, BookStack, runbookovi i statusna matrica
Partnerski računovođa pilot shadow comparison, iznimke i mjesečni close review

8.1 Definition of Done za svaki backlog item

Stavka nije završena dok nema:

  • odobrene acceptance kriterije;
  • kod i migracije gdje je potrebno;
  • unit/integration test;
  • tenant/RBAC provjeru ako dira podatke;
  • audit/observability;
  • UI error/empty/loading state ako je user-facing;
  • Proveo dokaz za release-kritične tokove;
  • dokumentaciju i BookStack update;
  • nema otvorenog P0/P1 nalaza.

9. Obvezne odluke prije dispatcha

Odluka Rok u planu Preporuka
eRačun provider prije G2-01 nastaviti sa sveRačun, ali tek nakon produkcijskog ugovora i E2E; Storecove maknuti iz aktivnog narativa
AIS/PSD2 provider prije G3-02 Tok samo uz dokaz licenciranog operativnog puta; inače vanjski agregator
OCR provider prije G1 image-OCR aktivacije zadržati Azure Document Intelligence uz test točnosti, troška i data-processing uvjeta
Porezna predaja prije G5-08 prvo verificirani nacrt/export; API submit samo ako je pravno i tehnički potvrđen
Payroll prije segmenta sa zaposlenima partner-first; vlastiti engine ostaje preview
Auto-POST politika prije G4-06 default OFF; eksplicitno per-org i per-event uključivanje nakon shadow dokaza
Pilot partneri prije Gatea 1 exit 10 jednostavnih firmi i 1–2 računovođe s jasnim uključnim/isključnim kriterijima

10. Rizici i mitigacije

Rizik Utjecaj Mitigacija
Netočna regulatorna logika kazne i gubitak povjerenja versioned legal sources, HR ekspert, golden dataset, dual control
Provider blokada onemogućuje zatvoren tok adapter ugovor, fallback, feature flag, ugovor/SLA prije obećanja
AI halucinacija pogrešno knjiženje AI samo predlaže; deterministički validator i lane gate odlučuju
Duplikati/asinkroni retry dvostruki račun ili posting business idempotency key, provider ID, hash, monotoni statusi
Tenant leak kritični sigurnosni incident RLS, org transaction context, negativni testovi i neovisni audit
Stari dokumenti proturječe kodu pogrešne prodajne odluke runtime capability SSOT i datirani evidence linkovi
Preširok scope spor launch i nestabilnost paušalac-first, izričit out-of-scope, gateovi umjesto velikog ERP backloga
Accountant bottleneck neriješene iznimke queue SLA, bulk actions, reason analytics, partner portal
Nevidljive greške korisnik misli da je posao završen fail-loud UX, DLQ, alarmi, status timeline i support runbook

11. Metrike proizvoda i autonomije

Uz prihod i aktivaciju pratiti:

  • postotak dokumenata s potpunim provenanceom;
  • ingest success/failure po kanalu;
  • duplicate-prevention rate;
  • green/amber/red distribuciju;
  • green-lane precision nakon ljudskog uzorka;
  • straight-through processing rate;
  • median time-to-resolve exception;
  • unmatched bank age i reconciliation coverage;
  • post/reversal omjer i razlog reversala;
  • close cycle time;
  • filing validation failure rate;
  • provider latency/reject/DLQ;
  • broj incidenata i near-miss slučajeva;
  • sate računovođe po firmi/mjesecu.

Autonomija se ne mjeri samo STP postotkom. Uspjeh je smanjenje ručnog rada bez smanjenja točnosti, objašnjivosti i kontrole.

12. Prva izvršna iteracija — narednih 10 radnih dana nakon odobrenja

  1. otvoriti jedan parent epic “Bilko HR Autopilot” s gateovima G0–G6;
  2. napraviti capability inventory i uskladiti tri statusna izvora;
  3. imenovati hrvatskog računovodstvenog reviewera;
  4. potvrditi komercijalnog i tehničkog ownera za sveRačun;
  5. provesti AIS/Tok feasibility checkpoint;
  6. definirati canonical document i decision-audit shemu;
  7. izvući pilot uključne/isključne kriterije i listu kandidata;
  8. napisati prvih 25 golden KPO test slučajeva;
  9. zatvoriti onboarding/billing i tenant-isolation P0 nalaze;
  10. napraviti Proveo baseline E2E i objaviti PASS/PARTIAL/BLOCKED zapis.

Rezultat prve iteracije nije “autonomija”. Rezultat je izvršiv, dokaziv backlog bez proturječnih statusa i s uklonjenim P0 preduvjetima.

13. Mandatory plan tasks

Task V1 — VALIDATION (obvezno)

Owner: Proveo / Angie
Opis: neovisna end-to-end validacija svakog gatea i evidence bundle.
Acceptance: machine evidence postoji; verdict je eksplicitno PASS, PARTIAL ili BLOCKED; nijedna GA tvrdnja ne prolazi bez PASS-a.

Task D1 — DOCUMENTATION (obvezno)

Owner: Skillforge / D1
Opis: održavati dokumentaciju, BookStack stranicu, capability matricu, regulatorne izvore i operativne runbookove.
Acceptance: BookStack je sinkroniziran nakon svakog gatea; datum, status i evidence linkovi odgovaraju runtime stanju.

14. Go / no-go kriterij za početak implementacije

Implementacija može krenuti kada CEO/Product owner odobri:

  • paušalac-first segment i out-of-scope;
  • gate redoslijed G0→G6;
  • provider decision workstreamove;
  • obveznog HR računovodstvenog reviewera;
  • default auto-POST = OFF politiku;
  • pilot model i stop uvjete;
  • neovisni Proveo i BookStack gate.

Ako jedna od ovih točaka nije odobrena, rad se zadržava na Gateu 0 i ne šalju se GA/autonomija tvrdnje.

15. Izvori i trag do postojećih dokumenata

  • BUILD-BLUEPRINT.md
  • docs/product/MARKET-READINESS-MATRIX.md
  • docs/product/HR-GA-SCOPE.md
  • docs/business-requirements/GAP-ANALYSIS-LIVE.md
  • docs/business-requirements/ACCEPTANCE-CRITERIA.md
  • docs/architecture/BILKO-SPRINT-PLAN.md
  • docs/COMPETITIVE-RESEARCH.md
  • docs/INTEGRATION-WITH-TOK.md
  • apps/api/src/main/kotlin/no/alai/bilko/country/hr/PluginHR.kt
  • apps/api/src/main/kotlin/no/alai/bilko/gl/PostingRuleEngine.kt
  • apps/api/src/main/kotlin/no/alai/bilko/gl/GlBankService.kt

Preporučena odluka: odobriti Gate 0 i Gate 1 planiranje odmah; Gateove 2–5 izvršavati samo po navedenim provider, regulatornim i evidence uvjetima.

Back to top