RAG pentru finanțe și raportare: cifra nu se inventează

Un controller îți trimite întrebarea pe care o primește de zeci de ori pe lună: „cheltuiala asta cu chiria intră pe rezultat sau se capitalizează?”. Are un răspuns. Are și o cifră. Iar cele două nu stau în același loc.

Tratamentul stă într-un corpus normativ: reglementarea contabilă aplicabilă, manualul de grup, politica internă, un memo de tratament semnat acum doi ani. Cifra stă în ERP, într-un cont analitic, la o dată de referință. Un sistem de RAG pentru finanțe și raportare are voie să explice primul lucru. Nu are voie să producă al doilea, chiar dacă poate.

Aici e diferența față de toate celelalte cazuri de utilizare pe documentație internă tratate până acum. Granița nu mai e „poate sau nu poate să numere?”. E mai fină și mai incomodă: sistemul poate produce o cifră perfect plauzibilă, uneori chiar corectă, dar cifra aceea nu e autoritativă — există deja una autoritativă, în altă parte, care intră în situațiile financiare. Dacă nu ai citit fundamentele, ce este RAG acoperă mecanica; aici tratăm strict specificul financiar-contabil.

Întrebarea de finanțe are două jumătăți, iar doar una e de regăsire

Prima decizie de arhitectură nu e despre chunking sau despre model. E despre unde tai întrebarea.

Tratamentul e text, cifra e înregistrare

„Cum se recunoaște venitul dintr-un contract cu livrări eșalonate?” e o întrebare de regăsire pură: răspunsul e într-un document normativ, se citează, se verifică. „Cât venit am recunoscut pe contractul cu Alfa în trimestrul II?” nu e o întrebare de regăsire, oricât de mult ar semăna cele două ca formulare.

A doua întrebare are un răspuns unic, calculabil, cu proprietar. Proprietarul e sistemul de evidență — ERP, registrul contabil, aplicația de facturare. Un top-k peste memo-uri și politici va găsi documente care conțin sume, le va combina și va produce un număr. Numărul acela nu e greșit din întâmplare. E greșit prin construcție, pentru că a fost obținut din altă sursă decât cea care ține adevărul.

Trei tipuri de întrebare, trei destinații

Rândul al treilea e cel care produce cele mai multe proiecte prost calibrate. Un răspuns onest la o întrebare mixtă are două părți vizibile: regula, cu citare, și indicația de unde se ia cifra — de preferat ca link direct în sistemul-sursă, cu contul și perioada precompletate.

De ce o cifră plauzibilă costă mai mult aici

Într-un helpdesk, un răspuns greșit produce un tichet reluat. În finanțe, produce o înregistrare contabilă — iar înregistrările se propagă. O sumă preluată dintr-un răspuns de model într-o notă explicativă traversează închiderea, consolidarea și raportul auditorului înainte să observe cineva.

Regula de proiectare care structurează tot restul: sistemul răspunde cu tratamentul și cu adresa cifrei, niciodată cu cifra însăși. Nu e o limitare de capabilitate. E o decizie de proprietate a datelor, iar sistemele care o încalcă din amabilitate sunt exact cele care ajung să fie oprite după primul trimestru.

Dublul referențial: același fapt, două tratamente corecte

Aici e problema specifică pe care nu o are niciun alt corpus intern. Într-o companie care raportează și local, și către un grup, același eveniment economic are simultan două tratamente valide și diferite. Nu e o contradicție de rezolvat. E starea normală.

Cadrele coexistă prin construcție

În România, cadrul general este dat de reglementările contabile aprobate prin Ordinul ministrului finanțelor publice nr. 1802/2014, aplicabile majorității entităților care nu sunt obligate prin lege să aplice IFRS. Reglementările conforme cu Standardele Internaționale de Raportare Financiară sunt aprobate separat, prin Ordinul nr. 2844/2016, și se aplică societăților ale căror valori mobiliare sunt admise la tranzacționare pe o piață reglementată, entităților cu capital de stat vizate de Ordinul nr. 666/2015, altor entități obligate prin lege, precum și celor care optează pentru ele în condițiile prevăzute.

Detaliul care sperie corect: nici măcar „IFRS” nu e un singur lucru. Reglementările naționale conforme cu IFRS pot conține prevederi care le fac să difere de IFRS așa cum sunt adoptate la nivelul Uniunii. Un emitent listat la București a explicat public exact acest tip de divergență, apărută după introducerea, prin Ordinul nr. 3900/2022, a unei prevederi privind conturile de reglementare — cu efect asupra recunoașterii unor active necorporale în situațiile consolidate întocmite conform Ordinului 2844/2016 față de cele întocmite conform IFRS adoptate în Uniune.

Peste asta se așază manualul de politici contabile de grup, care poate impune praguri de capitalizare, criterii de provizionare sau clasificări mai stricte decât minimul legal.

Un fragment fără etichetă de referențial e activ înșelător

Consecința tehnică e directă. Dacă indexezi manualul de grup și politica statutară în același spațiu, fără ca fiecare fragment să poarte referențialul de care aparține, retrievalul le va amesteca. Ambele descriu „tratamentul cheltuielilor de dezvoltare”. Ambele sunt scrise în același registru profesional. Semantic sunt aproape identice.

Rezultatul nu e un răspuns vag. E un răspuns precis și greșit: regula de grup prezentată ca regulă statutară, cu încredere maximă și fără niciun semnal că referențialul a fost schimbat pe drum. E o problemă de metadate, nu de retrieval — și nu se rezolvă cu un model mai bun sau cu reranking.

Metadatele minime pe fiecare fragment

Un chunk de corpus financiar pleacă în index cu cel puțin atât:

1{
2  "document_id": "POL-FIN-012",
3  "referential": "statutar",
4  "cadru": "OMFP 1802/2014",
5  "entitate": "RO-01",
6  "versiune": "4.2",
7  "valabil_de_la": "2025-01-01",
8  "valabil_pana_la": null,
9  "aprobat_de": "Director financiar",
10  "tip": "politica_interna"
11}

1{
2  "document_id": "POL-FIN-012",
3  "referential": "statutar",
4  "cadru": "OMFP 1802/2014",
5  "entitate": "RO-01",
6  "versiune": "4.2",
7  "valabil_de_la": "2025-01-01",
8  "valabil_pana_la": null,
9  "aprobat_de": "Director financiar",
10  "tip": "politica_interna"
11}

Câmpul referential devine filtru obligatoriu, nu opțional: fără el, interogarea nu pleacă. Iar când utilizatorul nu specifică referențialul, răspunsul corect nu e să alegi unul tăcut, ci să livrezi ambele tratamente, etichetate, cu diferența marcată explicit. Un sistem care alege singur produce exact eroarea pe care un revizor o caută.

La grupuri cu mai multe filiale, entitate e al doilea filtru obligatoriu: politica de provizionare a entității din România nu se aplică celei din Bulgaria, iar manualul de grup are de regulă adaptări locale documentate separat.

Corpusul normativ are patru straturi, cu precedență între ele

„Politicile noastre contabile” nu e un document. E o stivă, iar ordinea din stivă decide ce răspuns e corect când două surse spun lucruri diferite.

Ce indexezi, de fapt

• Reglementarea aplicabilă — textul normativ, cu versiunea în vigoare pentru perioada relevantă.
• Manualul de politici contabile de grup — obligatoriu pentru raportarea către grup, adesea mai restrictiv.
• Politica internă a entității — cum se aplică regula concret, cu praguri și responsabili.
• Memo-urile de tratament — decizia luată pe un caz punctual, cu argumentația și semnătura. Stratul cel mai valoros și cel mai prost păstrat.

Precedența trebuie să fie explicită, nu implicită

Un sistem care regăsește simultan un paragraf din manualul de grup și unul din politica internă trebuie să știe care primează în contextul întrebării. Codifică precedența ca metadată, la nivel de document, nu ca instrucțiune în prompt: promptul se pierde la reformulare, metadata nu.

Regula practică: pentru o întrebare statutară, precedența e reglementare > politică internă > memo, iar memo-ul contează doar dacă e mai specific decât politica. Pentru o întrebare de grup, manualul urcă în vârf.

Memo-urile de tratament sunt aurul îngropat

Într-o companie cu vechime, cele mai bune răspunsuri la întrebările reale nu sunt în politici. Sunt în memo-uri: „de ce am tratat contractul cu Beta ca leasing financiar”, „de ce am reluat provizionul în T3”. Fiecare conține un caz, o argumentație și o concluzie.

Problema e că trăiesc în atașamente de e-mail și în foldere personale. Recuperarea lor e un proiect de arheologie, nu de retrieval, iar rezultatul e disproporționat de bun: sunt exact documentele care răspund la întrebarea „s-a mai întâmplat, și cum am tratat?”. Mecanica de căutare de precedent pe un corpus de cazuri e detaliată pe alt tip de corpus în RAG pentru calitate și neconformități; ce se adaugă aici e că precedentul contabil e valabil doar sub referențialul și versiunea în care a fost decis.

Închiderea de lună: fereastra în care prospețimea are cost asimetric

În majoritatea sistemelor de retrieval, un corpus ușor învechit e un inconvenient. Într-o fereastră de închidere, e o eroare care se propagă în cifre depuse.

Închiderea e o fereastră, nu o zi

Între ultima zi a perioadei și depunerea raportării există câteva zile în care echipa lucrează în paralel, pe aceleași conturi. Volumul de întrebări crește brusc, iar toleranța la un răspuns care trebuie verificat scade la zero. Latența contează mai puțin decât certitudinea, iar un refuz clar e preferabil unui răspuns care cere validare.

Ce se schimbă chiar în timpul ferestrei

Corpusul normativ nu e static nici măcar la scara unei luni. Un ordin nou apare, o politică internă se modifică după o discuție cu auditorul, un prag se actualizează. Dacă indexul preia modificarea în ziua 3 a închiderii, jumătate din echipă a primit un răspuns și cealaltă jumătate altul, pentru aceeași perioadă contabilă.

Regula practică e contraintuitivă pentru cine vine din alte cazuri de utilizare: blochează versiunea corpusului la deschiderea ferestrei și marchează explicit modificările sosite după blocare, în loc să le publici imediat. Modificările nu se pierd — intră într-o listă vizibilă, cu data, și se aplică de la perioada următoare sau prin decizie explicită. Mecanica generală de actualizare, ștergere și reindexare e tratată în prospețime, ștergeri și reindexare; ce se adaugă aici e că momentul publicării devine el însuși o decizie de proces.

Data de referință e perioada contabilă, nu ziua de azi

Interogarea trebuie să poarte perioada contabilă ca parametru, nu data calendaristică a întrebării. Pe 5 august, o întrebare despre închiderea lunii iulie trebuie să selecteze versiunile valabile în iulie. Un sistem care aplică versiunea de azi la o perioadă din trecut produce un răspuns corect pentru o întrebare pe care nimeni nu a pus-o.

Ce nu face sistemul, chiar dacă pare că poate

Trei limite sunt structurale. Nu se rezolvă cu mai multe date sau cu un model mai mare.

Nu agregă și nu reconciliază

„Câte facturi neîncasate am peste 90 de zile?” e o interogare, nu o regăsire. Aceeași graniță apare pe un corpus de feedback în sinteza feedbackului de la clienți, dar diferența față de acel caz e importantă: acolo cifra nu există nicăieri într-o formă autoritativă și trebuie construită. Aici există, e calculată de un sistem tranzacțional și e cea care intră în raportare. Sistemul nu are voie să producă o a doua versiune a ei, oricât de aproape ar nimeri.

Consecința de proiectare: în loc să răspundă cu un număr, sistemul răspunde cu interogarea de rulat sau cu linkul către raportul standard. E mai puțin spectaculos într-un demo și infinit mai util în producție.

Nu decide calificarea, chiar dacă o poate descrie

Un tratament contabil corect depinde de fapte care nu sunt în corpus: ce s-a executat efectiv, ce prevede contractul, ce intenție are conducerea. Sistemul poate aduce regula și cazurile similare. Concluzia rămâne a profesionistului, iar în cazurile cu miză, a auditorului.

Aici intră și clauzele contractuale cu efect contabil — pragul de transfer al controlului, penalitățile, garanțiile care generează provizioane. Ele se regăsesc într-un corpus de contracte, cu mecanica descrisă în RAG pe contracte și documente juridice, și trebuie legate la tratamentul pe care îl declanșează, nu citite separat.

Nu înlocuiește un instrument de raportare

Dacă inventarul tău de întrebări arată că majoritatea cer solduri, evoluții, rulaje și reconcilieri, concluzia corectă nu e un strat de model peste documente. E raportare: un depozit de date, un set de rapoarte, o interfață de interogare. Pragurile de decizie sunt detaliate în când nu folosești RAG, iar ele se aplică aici mai tăios decât oriunde, pentru că alternativa e matură și ieftină — cât costă un ERP la comandă e o cifră pe care o afli înainte, nu după.

Raportările structurate nu sunt corpus, dar îți schimbă corpusul

Zona financiară din România are un strat de raportare digitală care produce, indirect, cerințe pentru sistemul tău de documente.

Fișierul standard de control fiscal

Raportarea SAF-T se face prin Declarația informativă D406, reglementată prin Ordinul președintelui ANAF nr. 1783/2021, care stabilește natura informațiilor declarate, modelul de raportare, procedura, termenele și datele de la care fiecare categorie de contribuabili intră în obligație. Implementarea a fost etapizată pe categorii de contribuabili, iar secțiunea de stocuri se transmite doar la solicitarea organului fiscal, într-un termen care nu poate fi mai scurt de 30 de zile calendaristice.

Nimic din toate astea nu e o problemă de retrieval. Fișierul se generează din ERP. Ce e problemă de retrieval: procedura internă de generare și validare, maparea conturilor, lista de erori frecvente și cum se remediază. Documentația procesului, nu datele procesului.

Decontul precompletat, ca studiu de caz de corpus volatil

Sistemul RO e-TVA, reglementat prin Ordonanța de urgență nr. 70/2024, a generat inițial atât deconturi precompletate, cât și notificări de conformare cu obligație de răspuns. De la 1 ianuarie 2026, prin Ordonanța de urgență nr. 89/2025, au fost eliminate obligația contribuabililor de a răspunde la notificările de conformare și sancțiunile aferente. Ulterior, prin Ordonanța de urgență nr. 13/2026, în vigoare din 9 martie 2026, a fost eliminată notificarea de conformare ca atare, prin abrogarea articolelor 5, 8 și 16 din OUG 70/2024, decontul precompletat rămânând la dispoziția contribuabililor.

Trei acte normative, două schimbări de regim, în mai puțin de doi ani. O procedură internă scrisă în 2025 și rămasă în index descrie acum un flux care nu mai există. Nu e un caz teoretic de prospețime — e cel mai bun argument practic pentru marcarea versiunilor și pentru un proces de retragere a documentelor depășite.

Facturarea electronică mută granița sursei de adevăr

Odată ce facturile circulă printr-un sistem național, datele de facturare au o sursă unică, iar copiile din documente interne devin secundare prin definiție. Consecința pentru index e simplă: nu indexa liste de facturi, sume sau situații extrase manual. Se învechesc între generare și interogare, iar utilizatorul nu are cum să vadă asta în răspuns.

Trasabilitate pentru cine revizuiește

Un răspuns care nu poate fi urmărit înapoi la versiunea aplicabilă a politicii nu e utilizabil într-o revizuire.

Ce conține un răspuns revizuibil

Cinci elemente, toate obligatorii:

1. Tratamentul, formulat strict, fără extrapolare la cazuri vecine.
2. Referențialul — statutar, grup sau ambele, marcat vizibil.
3. Documentul și versiunea citate, cu intervalul lor de valabilitate.
4. Perioada contabilă pentru care s-a selectat versiunea.
5. Adresa cifrei — sistemul, contul și perioada de unde se ia, nu valoarea.

Punctul 4 e cel omis cel mai des. Un răspuns care citează versiunea curentă a politicii pentru o întrebare despre o perioadă închisă arată identic cu unul corect și e complet inutilizabil în fața unui revizor. Forma generală a unui răspuns bine construit, cu sinteză și refuz, e tratată în cum arată un răspuns bun de RAG.

Granița față de dovada de conformitate

Merită trasată explicit, pentru că cele două cazuri se confundă des. Un sistem de audit intern demonstrează că un control a fost executat: politica, controlul, artefactul-dovadă, perioada acoperită — lanțul e detaliat în RAG pentru conformitate și audit intern. Aici obiectul e altul: nu că ai executat un control, ci că tratamentul aplicat unui fapt economic e cel corect sub referențialul aplicabil perioadei. Prima întrebare e despre proces, a doua despre substanță. Mecanismele de versionare seamănă; concluziile pe care le susțin, nu.

Jurnalul de interogări în perioada de închidere

Urma întrebărilor puse în fereastra de închidere spune unde s-a ezitat — deci e utilă la revizuire, interesantă pentru auditor și sensibilă în același timp, pentru că tiparul lor dezvăluie zonele de incertitudine din raportare. Regimul de acces și de retenție se stabilește înainte de prima închidere, nu după: RAG și GDPR acoperă partea de date personale, iar controlul accesului în RAG segmentarea pe drepturi, relevantă aici pentru că cifrele nepublicate sunt informație privilegiată până la publicare.

Cum validezi că sistemul e sigur de folosit

Un demo cu cinci întrebări nu spune nimic despre un sistem care va fi folosit sub presiune de timp, pe cifre care ajung în situații financiare.

Setul de evaluare vine din inbox, nu din imaginație

60–100 de întrebări reale, luate din corespondența echipei de raportare din ultimele trei închideri. Pentru fiecare, notează înainte de a rula sistemul: tratamentul așteptat, referențialul, documentul și versiunea care trebuie citate, perioada aplicabilă și dacă întrebarea conține sau nu o componentă de cifră.

Include deliberat două categorii de capcane: întrebări formulate fără referențial, unde răspunsul corect e să ceară clarificare sau să livreze ambele tratamente, și întrebări care cer un număr, unde răspunsul corect e trimiterea la sursă.

Trei metrici, măsurate separat

Ultima linie decide dacă sistemul intră în producție. Un sistem cu regăsire excelentă și refuz slab e mai periculos decât unul mediocru pe ambele, pentru că inspiră încredere exact în zona în care nu trebuie. Metodologia generală, pragurile și construcția setului sunt în cum evaluezi un sistem RAG.

Pilotul: o entitate, o lună, un referențial

Nu porni pe tot grupul. Alege o singură entitate, o singură perioadă deja închisă și un singur referențial — de preferat cel statutar, unde ai deja răspunsurile validate. Compară ce produce sistemul cu ce s-a înregistrat efectiv și cu ce a acceptat auditorul. Diferența e lista de lucru, iar mărimea ei îți spune în două săptămâni dacă merită extins.

Ce am omis deliberat

Spațiul „AI scurtează închiderea cu X zile” e plin de cifre fără numitor. Nu vei găsi în articolul ăsta un procent de reducere a duratei de închidere, pentru că sursele care circulă sunt studii de furnizor, cu eșantioane necomunicate și cu definiții incompatibile ale momentului în care închiderea e „terminată” — unele numără până la balanța preliminară, altele până la raportarea consolidată.

Testul înainte de a cita o astfel de cifră: numitorul exact, eșantionul, cine a plătit studiul. Dacă lipsește unul, nu o pune într-un document care ajunge la comitetul de audit.

Întrebări frecvente

Poate sistemul să-mi spună soldul unui cont?

Poate produce un număr. Nu are voie să îl prezinte ca răspuns. Comportamentul corect e să identifice contul și perioada din întrebare și să întoarcă trimiterea către sistemul de evidență — ideal un link cu filtrele deja aplicate. Diferența dintre „poate” și „are voie” e chiar decizia de proiectare care face sistemul utilizabil în finanțe.

Cum gestionez politicile care diferă între statutar și raportarea de grup?

Le indexezi separat, cu referențialul ca metadată obligatorie pe fiecare fragment, și faci filtrul explicit la interogare. Când utilizatorul nu precizează cadrul, livrezi ambele tratamente etichetate, cu diferența marcată — niciodată unul singur, ales tăcut de sistem.

Merită să pornesc chiar înainte de închidere?

Nu. Prima fereastră de închidere e cel mai prost moment pentru un sistem nevalidat: presiune de timp, toleranță zero la verificare și cea mai mare probabilitate ca un răspuns nepotrivit să ajungă direct într-o înregistrare. Rulează pilotul pe o perioadă deja închisă, unde ai răspunsurile corecte.

Ce fac cu memo-urile vechi de tratament, dinainte de o schimbare de reglementare?

Le păstrezi, cu intervalul de valabilitate și cu referențialul de atunci. Nu le ștergi: pentru o perioadă auditată în trecut, ele sunt exact documentele aplicabile. Ce adaugi este un marcaj de superseded, cu trimitere la documentul care le-a înlocuit, ca să nu apară singure într-un răspuns despre perioada curentă.

Cine trebuie să valideze răspunsurile înainte de folosire?

Aceeași persoană care semnează și fără sistem. Un asistent de retrieval scurtează căutarea și aduce precedentul; nu transferă răspunderea profesională.

Începe cu inventarul, nu cu modelul. Ia ultimele cincizeci de întrebări primite de echipa de raportare, împarte-le în tratament, cifră și mixte, apoi marchează pentru fiecare sub ce referențial a fost pusă. Dacă mai mult de jumătate cer cifre, primul proiect nu e unul de retrieval. Iar dacă majoritatea sunt de tratament și răspunsurile stau împrăștiate în memo-uri fără dată, ai deja lista de lucru pentru ingestie.

Restul cazurilor de utilizare pe corpusuri de companie sunt adunate în hub-ul Cazuri de utilizare enterprise, articolele care ating zona de conformitate și audit sunt grupate separat, iar imaginea completă a serviciului — de la arhitectură la costuri — în AI & RAG.