Nevoia contabilă pentru un modul de reconciliere plăți

Rezumat practic · 22.10.2026 · concluziile validate, cu varianta Dacă Lotus nu exista și ce face SAGA la fiecare caz

Rezumat

În general, nicio normă nu cere explicit închiderea fiecărei facturi cu plata ei. Obligativitatea specifică este doar dacă clientul aplică TVA la încasare. Dar se cere indirect:

• anual, la inventariere și în bilanț (formularul F30) (Legea 82/1991 art. 7; OMFP 2861/2009 pct. 28; OMFP 1802/2014 pct. 51, 331–332);
• situațiile practice apărute în contabilitatea unei firme (secțiunea următoare).

În ce situații e nevoie de Lotus

• LotusTVA la încasare — singurul caz în care legea cere explicit închiderea facturilor cu plata. Cod fiscal art. 282 alin. (3), art. 297 alin. (2); Norme pct. 101 alin. (3)–(6). CAZUL VI
• LotusBonuri — doar închiderea cu extrasul arată din ce bani s-a plătit bonul: banii firmei sau bani personali (avans de trezorerie, 542). CAZUL IX
• LotusPlăți fără factură, facturi lipsă — lunar. Fără închidere, lipsa se vede doar ca sold debitor pe furnizor: nu putem spune clientului ce factură lipsește, doar că lipsesc facturi de X RON. Plățile neidentificate (473) se clarifică în cel mult trei luni. CAZURILE VIII, X
• LotusFacturi în valută — SAGA reevaluează doar facturile deschise; fără închidere, diferențele de curs ies greșit. Altfel ținem în Nucleu soldul fiecărui partener străin în lei și în valută și dăm notele 665/765 lui SAGA. CAZUL III
• LotusInventariere, confirmări de sold, depreciere, F30 — anual. Trebuie lista facturilor deschise pe fiecare partener cu sold diferit de zero; fără Lotus, contabilul o reconstituie manual o dată pe an. CAZURILE II, IV, V

Cele trei clase de linii din extras — cine ia fiecare

• directa — taxe, salarii, comisioane, dobânzi. O poate face IRIS cap-coadă. Dar pentru taxe e nevoie de un algoritm de alocare a sumei plătite, pe care i l-am prezentat lui Bgn în ultima ședință. Un pic de context pentru Claude_Bgn: plata mai multor taxe se face în contul unic de trezorerie al ANAF. Pentru stingerea taxelor trebuie aplicat un algoritm matematic prevăzut de lege, prin care decidem cât din suma plătită se alocă stingerii fiecărei taxe. Iar la salarii trebuie să identifice persoana pentru care s-a plătit salariul.
• de_corelat — încasare de la client, plată către furnizor, plată cu cardul. IRIS extrage datele liniei (CUI, nume, IBAN, sumă, descriere). Lotus găsește factura sau bonul. SAGA închide factura la import, cu referința dată de Lotus. Aici Lotus e miezul.
• transfer_intern — bani între conturile proprii. IRIS poate face cap-coadă și genera înregistrarea contabilă debit–credit către SAGA.

CAZUL I — Înregistrarea plății · Legea 82/1991 art. 6 alin. (1)

„Orice operaţiune economico-financiară efectuată se consemnează în momentul efectuării ei într-un document care stă la baza înregistrărilor în contabilitate, dobândind astfel calitatea de document justificativ."

• plata pe baza extrasului; factura e documentul datoriei/creanței; legea nu le leagă
• Dacă Lotus nu exista, atunci: înregistrăm plata direct pe furnizor/client, fără să închidem și factura.
• SAGA: face SAGA.

CAZUL II — Evidența pe partener · OMFP 1802/2014 pct. 329 alin. (1); Extras de cont 14-6-3

„Contabilitatea furnizorilor şi clienților … se ține pe categorii, precum şi pe fiecare persoană fizică sau juridică … pe termene de plată, respectiv de încasare."

Extras de cont: „felul, numărul şi data documentului; explicaţii; suma".

• Concluzie: evidența pe partener e minimul legal; evidența pe factură devine obligatorie de îndată ce confirmi solduri (inventariere, pct. 28 OMFP 2861/2009) sau ceri banii.
• Dacă Lotus nu exista, atunci: ținem fișa pe partener; la confirmare de sold sau la somație, contabilul face punctajul plăți–facturi manual, pe loc.
• SAGA: face SAGA.

CAZUL III — Valută · OMFP 1802/2014 pct. 314 alin. (1), 322 alin. (1), 325 alin. (1)

„La finele fiecărei luni, creanțele şi datoriile în valută se evaluează la cursul de schimb al pieței valutare, comunicat de Banca Națională a României din ultima zi bancară a lunii în cauză."

• rezultatul lunar identic cu sau fără închidere; 665/765 în corespondență cu partenerul sau cu banca, ambele permise
• Concluzie: dacă ținem sumele și în RON și în valută per client (analitic), atunci la final de lună reevaluăm mereu restul de plată la cursul BNR de la final de lună și obținem diferențele din reevaluare corecte.
• Dacă Lotus nu exista, atunci: nicio factură nu e închisă, iar reevaluarea SAGA merge pe facturi deschise, deci nu iese corect. Ținem noi soldul fiecărui partener străin în lei și în valută (facturi minus plăți, la cursul fiecărei operațiuni), la finele lunii îl reevaluăm la cursul BNR, dăm nota 665/765 = 401/411 lui SAGA manual și nu rulăm reevaluarea SAGA pe parteneri (doar pe conturile de bancă în valută), altfel diferența apare de două ori.
• SAGA: o poate face SAGA doar dacă reconciliem facturile cu Lotus.

CAZUL IV — Inventariere și depreciere · OMFP 2861/2009 pct. 28 alin. (1); OMFP 1802/2014 pct. 51 alin. (1) lit. c); Cod fiscal art. 26 alin. (1) lit. c)

„Creanţele şi obligaţiile faţă de terţi sunt supuse verificării şi confirmării … care deţin ponderea valorică … potrivit «Extrasului de cont» (cod 14-6-3) sau punctajelor reciproce scrise."

„sunt recunoscute deprecierile, indiferent dacă rezultatul exercițiului financiar este pierdere sau profit."

„în limita unui procent de 30% … neîncasate într-o perioadă ce depășește 270 de zile de la data scadenței"

• 270 zile = prag fiscal, nu obligație contabilă; factura restantă rămâne datorie pe termen scurt (pct. 360)
• Concluzie: o dată pe an, la inventariere, trebuie să ai lista facturilor deschise pe fiecare partener — pentru confirmarea soldurilor (cei cu pondere) și pentru judecarea deprecierii (toți clienții restanți; fiscal, pragul de 270 de zile pentru deductibilitate). Fără închiderea plăților pe facturi în cursul anului, trebuie reconstituită la inventariere.
• Dacă Lotus nu exista, atunci: o dată pe an, contabilul reconciliază manual facturile pe fiecare partener cu sold diferit de zero — pentru confirmări și depreciere.
• SAGA: nu face SAGA.

CAZUL V — F30, restanțe pe vechimi · OMFP 79/2014 anexa 4, rd. 05–08, 55, 82 — parcat

• Dacă Lotus nu exista, atunci: idem IV — o dată pe an, contabilul reconciliază manual facturile pe fiecare partener cu sold diferit de zero.
• SAGA: nu face SAGA.

CAZUL VI — TVA la încasare · Cod fiscal art. 297 alin. (2); Norme pct. 101 alin. (3)–(6)

„Dreptul de deducere … este amânat până la data la care taxa … a fost plătită furnizorului/prestatorului său."

Jurnal, pe factură: „numărul şi data documentului de plată", „valoarea plătită".

• Concluzie: TVA la încasare obligă explicit închiderea pe factură.
• Dacă Lotus nu exista, atunci: pentru TVA la încasare, e nevoie de Lotus cf. legii.
• SAGA: face SAGA.

CAZUL VII — SAF-T · ANAF, întrebări frecvente v1.1, Răspunsul 61

„… identificarea furnizorului / clientului, precum și identificarea plății în Registrul Jurnal, opțional elemente de identificare a documentului sursa …"

• Concluzie: SAF-T — legătura plată–factură e opțională.
• Dacă Lotus nu exista, atunci: D406 din SAGA, plățile raportate pe partener, fără referință la factură.
• SAGA: N/A — putem exclude pasul VII: în SAF-T indicarea facturii la care se referă o plată e opțională.

CAZUL VIII — Plata fără factură · OMFP 1802/2014 conturile 401, 409, 473; pct. 352 alin. (1)

473: „plățile pentru care … nu se pot lua măsuri de înregistrare definitivă într-un cont"; „clarificate … într-un termen de cel mult trei luni".

• Concluzie: plata se înregistrează pe baza extrasului; furnizor identificat fără factură → 401/409 pe furnizor; neidentificat → 473, de clarificat în 3 luni.
• Dacă Lotus nu exista, atunci: linia neidentificată → 473; plata către un furnizor cunoscut fără factură se vede doar ca sold debitor pe furnizor la sfârșitul lunii — nu îi vom putea spune clientului ce factură lipsește, doar că lipsesc facturi în valoare de X RON.
• SAGA: nu face SAGA.

CAZUL IX — Bonuri și avansul asociatului · OMFP 1802/2014 contul 542

„Soldul contului reprezintă sumele acordate ca avansuri de trezorerie, nedecontate."

• Concluzie: bonurile cer reconcilierea cu liniile de card (comerciant + sumă + dată), ajutată de modalitatea de plată citită de pe bon; ce nu se potrivește → decontul asociatului.
• Dacă Lotus nu exista, atunci: e nevoie de Lotus pentru a stabili din ce bani a fost plătit bonul: banii firmei sau bani personali.
• SAGA: nu face SAGA.

CAZUL X — Documente lipsă · Legea 82/1991 art. 10 alin. (1), (4)

„Răspunderea pentru organizarea şi conducerea contabilităţii … revine administratorului."

• Concluzie: legea nu obligă contabilul să ceară documentele; obligă să nu înregistreze cheltuieli fără ele și să clarifice plățile neidentificate în 3 luni — de aici nevoia practică de a le cere.
• Dacă Lotus nu exista, atunci: contabilul caută manual plățile fără document (solduri debitoare pe furnizori, 473) și le cere clientului, lunar.
• SAGA: nu face SAGA.

CAZUL XI — Facturi românești din e-Factura

• Concluzie propusă (nevalidată): închidere pe factură anual (inventariere, F30) și lunar doar la furnizorii cu TVA la încasare; în restul timpului fișa pe partener e suficientă.
• Dacă Lotus nu exista, atunci: facturile intră în SAGA din e-Factura, plățile din extras pe partener; închiderea manuală anual și lunar doar la TVA la încasare.
• SAGA: face SAGA doar dacă reconciliem facturile cu Lotus.

Alte precizări

• Reevaluarea lunară absoarbe orice alocare a plății pe facturi; condiția: sumele ținute și în valută (pct. 314 alin. (1)).
• Cazul V parcat; Cazul XI nevalidat.

Referințe

• Legea 82/1991, republicată (ANAF)
• OMFP 1802/2014 — Reglementările contabile (ANAF; pct. 329 la pagina 62)
• Codul fiscal, Legea 227/2015 (ANAF) — art. 282 alin. (3) · art. 26 alin. (1) lit. c)
• Evidența operațiunilor TVA — pct. 101 Norme (ANAF Brașov)
• ANAF — SAF-T, întrebări frecvente v1.1 (Răspunsul 61)
• OMFP 2861/2009 pct. 28 — text citat · Extras de cont, cod 14-6-3 — norme formulare · Jurnalele TVA la încasare — textul normei · F30 Date informative — OMFP 79/2014 anexa 4

Analiza tehnică Lotus — de la analiză la prototip, PRD și implementare

Lotus · facturi emise și facturi primite · în lucru, punct cu punct · de discutat cu CTO și Product Owner Bono

Brief — ce face Lotus

Rezumat

Lotus lucrează, pentru fiecare client, cu două liste: facturi deschise și linii din extras deschise.
Potrivirea = o alocare: factura · linie · sumă.
Starea facturii și starea liniei (inchisa/deschisa) decurg din alocări.
O rulare a lui Lotus = liniile deschise X facturile deschise; ce se potrivește devine alocare și iese din ambele liste; ce rămâne e reluat la rularea următoare.

Scope MVP

Intră: facturi emise și primite; linii OP și card; bonuri; facturi în valută; toate facturile din Nucleu, indiferent de sursă sau vechime.

Nu intră: taxe și salarii (trec la IRIS); TVA la încasare (clienții vin după MVP).

1. Arhitectura sistemului Lotus

Variantele

1 — Lotus cu bază proprie, facturi în copie
Pro: Lotus de sine stătător, poate trăi oriunde, cu istoric propriu.
Contra: aceeași factură în două locuri. Orice schimbare în Nucleu (storno, anulare, modificare, duplicat prins de IRIS) trebuie trimisă și la Lotus, altfel Lotus închide pe o factură care nu mai există. La 1.000 de clienți sincronizarea e un proiect în sine, iar ecranele tot din Nucleu citesc — starea facturii ar fi în Lotus, factura în Nucleu.

2 — pachet la fiecare apel
Pro: o singură sursă de adevăr; Lotus e o funcție — aceleași date, același răspuns; se testează cu fișiere (exact cum am făcut simularea), se rulează de oricâte ori, se înlocuiește ușor; poate fi construit și în afara IT, pe un contract clar.
Contra: Nucleu trebuie să aplice răspunsul și să țină starea (sold rămas pe factură, linie închisă / în așteptare, alerte) — o parte din logică stă în Nucleu; pachetul trebuie să aducă și liniile vechi rămase deschise, nu doar extrasul nou.

3 — acces direct la baza Nucleu
Pro: zero integrare, zero copii, zero pachete; Lotus citește ce-i trebuie și scrie alocările în aceeași bază; un singur loc pentru stări și corecții.
Contra: legat de schema Nucleu — orice schimbare acolo poate rupe Lotus; aceeași echipă, același stack, același deploy; nu se testează fără bază; nu poate fi construit în afara IT.

Bruce: Varianta 2. Respinge 1 — sincronizarea copiilor e fatală la 1.000 de clienți. 2 peste 3: „aceleași date = același răspuns” → motorul se testează pe fișierele reale, precizia se măsoară, nu se presupune; o singură sursă de adevăr → desfacerea alocărilor e trivială; se poate construi acum, în afara IT. Ușă reversibilă: motorul e identic în 2 și 3, IT îl absoarbe mai târziu fără rescriere.

3. Ce input primește Lotus

Concluzie

Lotus primește de la Nucleu, pe client:

• liniile din extras deschise (de_corelat), OP și card, cu datele extrase de IRIS;
• facturile și bonurile deschise, de intrare și de ieșire, cu soldul rămas;
• setările firmei: conturile proprii, N zile până la alerta „fără document".

Bruce — de decis conștient: datele învățate (IBAN-uri, dicționar de comercianți) sunt stare. În varianta 2 trebuie să trăiască în Nucleu și să călătorească în pachet la fiecare rulare; Lotus întoarce mapările actualizate. Dacă nu intră explicit în contract, diferențiatorul rămâne pe dinafară.

4. Ce output dă Lotus

Concluzie

Lotus întoarce, pe client, pentru liniile procesate:

• alocările: factura · linie · sumă;
• alertele pentru contabil, la linia respectivă — ex.: suma plătită mai mare decât toate facturile deschise ale partenerului (plată în plus); CUI-ul primit de la IRIS se potrivește, dar numele firmei diferă → nu stinge, alertă.

5. Cu ce sisteme comunică Lotus

Cu ce sisteme comunică Lotus. Doar cu Nucleu sau si cu IRIS.
Cine ii da comenzi lui Lotus pentru o reconciliere si catre cine intoarce Lotus raspunsul?

Propunere

• IRIS scrie liniile din extras în Nucleu → Lotus le citește de acolo, nu de la IRIS.
• Facturile vin în Nucleu (facturare, IRIS, e-Factura) → Lotus le citește de acolo.
• Alocările și alertele → Lotus le scrie în Nucleu.
• SAGA primește XML-ul de Încasări / Plăți cu FacturaID → îl generează Nucleu din alocări; Lotus nu vorbește cu SAGA.
• Dublin și Vertigo citesc stările din Nucleu; corecția contabilului se scrie în Nucleu, ca alocare manuală; Lotus o vede la rularea următoare.

Concluzie: Lotus comunica doar cu Nucleul

Bruce: confirmă — Lotus doar cu Nucleu. O singură suprafață de integrare, exact ce ține varianta 2 curată. Lotus nu atinge SAGA deloc. De acord integral.

6. Când rulează Lotus

Ce declanșează o rulare pe client:

• a) un extras nou procesat de IRIS — linii noi în Nucleu;
• b) un document nou în Nucleu — factură sau bon venit după extras (canalul întârziat);
• c) o corecție a contabilului în Vertigo — alocare manuală sau desfăcută;
• d) la cerere — buton în Vertigo;
• e) programat — o dată pe zi, ca plasă de siguranță.

Ce face rularea e același lucru indiferent de declanșator: ia liniile deschise × facturile deschise ale clientului. Lotus nu trebuie să știe de ce rulează. Și fiindcă aceleași date dau același răspuns, o rulare în plus nu strică nimic — poate rula oricât de des.

Propunere MVP: a + b (orice schimbare pe client → rulare), plus d pentru contabil. c și e vin gratis din același mecanism.

Bruce: toate 5 declanșatoarele pornite, nu doar a + b + d. Rularea e idempotentă, costul ~zero. e) — rularea zilnică — obligatorie, nu opțională: plasa care repară singură orice declanșator ratat, în 24 h; nimic nu rămâne blocat deschis.

7. Modelul de date și stările

O parte e deja în Brief (alocarea; stările derivate). Ce rămâne aici sunt cazurile care schimbă o alocare după ce a fost făcută:

• factură anulată — alocarea se desface, linia redevine deschisă, alertă;
• factură stornată — originalul neplătit: storno-ul îl închide fără bani; originalul plătit: alocarea rămâne, storno-ul stă deschis până vine restituirea sau o factură nouă pe care să se compenseze;
• plată returnată de bancă (linia inversă) — alocarea se desface, factura redevine deschisă;
• factură modificată (altă sumă) — alocarea se desface și se reia potrivirea.

8. Corecțiile — plata ajunsă în SAGA înainte de factură

Contabil clarificat (cele trei note):

• Plata 473 = 5121
• Înregistrarea facturii 6xx = 401
• Corecția 401 = 473

În SAGA — de verificat cum se bifează factura plătită pe baza notei 401 = 473; până atunci, manual. Această operațiune manuală poate fi automatizată printr-un robotel.

Plus decizia de design: Nucleu trimite plățile fără factură în SAGA la închiderea lunii, nu pe loc, ca să fie cazul rar.

Bruce: fără robotel în MVP. Exportul la închiderea lunii face cazul rar oricum. Automatizarea UI-ului SAGA e fragilă; reziduul se rezolvă manual; se reconsideră doar dacă doare post-MVP.

9. Drumul spre SAGA

Stabilit deja: XML-ul de Încasări / Plăți cu FacturaID îl generează Nucleu din alocări; Lotus nu vorbește cu SAGA; plățile fără factură pleacă la închiderea lunii.

De clarificat, ambele în Nucleu, nu în Lotus:

a) Când pleacă în SAGA o plată legată de factură. Două opțiuni: pe loc, după fiecare rulare Lotus (SAGA e mereu la zi, dar o alocare desfăcută după export cere corecție în SAGA — cazul de la 8, invers); sau într-un singur export la închiderea lunii (SAGA primește totul odată, deja așezat; corecțiile de după export devin rare). Întrebarea e: contabilul are nevoie să vadă în SAGA plățile în cursul lunii, sau îi ajunge Vertigo până la închidere?

b) Cum știe Nucleu ce a trimis deja. O linie din extras trebuie să ajungă în SAGA o singură dată, chiar dacă Lotus rulează de zece ori între timp. Deci Nucleu ține pe fiecare linie „exportată în SAGA la data X". Nu e dilemă, e o cerință.

Dilema reală e doar a).

Bruce: a) la închiderea lunii, nu pe loc. Contabilul lucrează în Vertigo (live, din Nucleu), nu în SAGA în cursul lunii. Export unic la închidere → corecțiile de după export devin rare. Consistent cu 8.

13. Luna închisă

Vine o factură după ce luna este închisă. Lotus leagă plata de factură în Nucleu; corecția nu mai poate intra în luna închisă din SAGA.

De decis: ce trebuie să facă contabilul în acest caz.

Bruce: Nucleu leagă normal; corecția SAGA intră în luna deschisă următoare + alertă în Vertigo. Adevărul intern e mereu corect și live; SAGA recuperează în perioada următoare. Legătura din Nucleu nu se blochează niciodată pe calendarul SAGA.

15. Cine construiește

Întrebare deschisă, de decis cu CTO-ul. Închide și punctul 1:

• IT, lângă Nucleu → varianta 3;
• Cristi cu Claude → varianta 2.

Motorul e același în ambele.

Bruce: acum Cristi + Claude, ca varianta 2; IT absoarbe ulterior, ca varianta 3, dacă se dovedește. „Dovedește, apoi absoarbe” — contractul e artefactul de de-riscare.