Ce este CIUS-RO și de ce nu e suficient un XML de factură obișnuit?
Un fișier poate fi în același timp valid față de standardul european și respins de sistemul românesc. Nu e o contradicție — sunt două niveluri de reguli, iar al doilea e mai strict.
Răspuns scurt
CIUS-RO (Core Invoice Usage Specification – România) este stratul național de reguli aplicat peste standardul european de facturare electronică. Standardul european spune ce POATE conține o factură; CIUS-RO spune ce TREBUIE să conțină ca să fie acceptată în România.
- Nivelul de bază: standardul european EN 16931 definește modelul semantic al facturii.
- Sintaxa: fișierul se exprimă ca XML, în formatul UBL folosit de sistemul românesc.
- Nivelul național: CIUS-RO restrânge și completează — câmpuri opționale în Europa devin obligatorii aici.
- Fișierul își declară conformitatea printr-un identificator de specificație. Un identificator greșit sau lipsă face fișierul respins înainte de orice verificare de conținut.
- Validarea rulează ambele niveluri. Trecerea de primul nu garantează trecerea de al doilea.
Ce spune sursa
Componentele sunt publicate în specificația sistemului. Versiunile se schimbă în timp — verifică întotdeauna versiunea curentă înainte de a fixa un identificator în cod:
- EN 16931specificație tehnică
- Standardul european pentru modelul semantic al facturii electronice. Este baza comună; nu conține regulile specifice unei țări.
- UBL 2.1specificație tehnică
- Sintaxa XML în care se exprimă factura în sistemul românesc. Structura elementelor și ordinea lor sunt impuse de această sintaxă.
- Identificatorul de specificațiespecificație tehnică
- Fișierul declară explicit că respectă CIUS-RO, printr-un identificator de personalizare care include atât conformitatea europeană, cât și versiunea națională. Această valoare se schimbă la versiuni noi ale specificației.
Ce adaugă stratul românesc peste cel european
Standardul european este proiectat să acopere practicile din toate statele membre, deci lasă multe câmpuri opționale. Fiecare țară își publică apoi propria specificație de utilizare, care alege ce e obligatoriu la ea.
În practică, asta înseamnă că o factură generată de un sistem european generic — corect, după standard — poate să nu treacă în România pentru că îi lipsesc elemente pe care CIUS-RO le cere. Invers nu se întâmplă: un fișier conform CIUS-RO respectă și standardul european.
Categorii de reguli naționale care produc respingeri
- Identificarea părților: informațiile despre emitent și cumpărător sunt cerute într-o formă mai completă decât minimul european.
- Adresele: componentele de adresă cerute pentru partenerii români sunt mai stricte decât în varianta generică.
- Codificările: tipul documentului, unitățile de măsură, categoriile de TVA se exprimă prin coduri din liste închise. O valoare din afara listei e respinsă, chiar dacă e inteligibilă pentru un om.
- Coerența aritmetică: totalurile pe linii, pe categorii de TVA și pe document trebuie să se închidă exact. O rotunjire diferită față de regula standardului rupe validarea.
Consecința practică pentru cine integrează
Nu poți valida complet un fișier doar cu un validator european generic. Ai nevoie de validarea cu regulile naționale, altfel descoperi problemele abia la respingere, pe facturi reale, cu termenul în curs.
Și nu poți fixa versiunea specificației o dată pentru totdeauna. Identificatorul de personalizare include o versiune, iar versiunile se schimbă. Un sistem care are valoarea scrisă în cod, fără posibilitate de actualizare, se blochează la următoarea revizie a specificației.
Greșeli frecvente
- Presupui că „XML valid” înseamnă „factură acceptată”Validarea față de schema XML e primul filtru, cel mai slab. Regulile de conținut și cele naționale se verifică după el și resping fișiere perfect bine formate.
- Scrii versiunea specificației în cod, ca literal fixIdentificatorul include o versiune. Când specificația avansează, un literal fix devine motiv de respingere pentru toate facturile, deodată. Ține valoarea în configurație.
- Improvizezi coduri în loc să folosești listele închiseUnitatea de măsură „buc” sau „ore” scrisă liber nu e cod valid. Codificările vin din liste standardizate, iar orice altceva e respins.
- Testezi doar cu facturi simpleO factură cu o linie, o cotă de TVA și un client român trece aproape întotdeauna. Problemele apar la mai multe cote pe document, la reduceri, la clienți din afara României — exact cazurile netestate.
Cum te ajută 4invoices
Ce face 4invoices pentru facturile în lei:
- Generează fișierul UBL 2.1 cu personalizarea CIUS-RO pornind din datele facturii.
- Înainte de trimitere rulează o verificare a datelor (număr, dată, linii, părți, adresă), cu mesaje în română pe câmpul lipsă.
- Unitățile de măsură din factură sunt transformate în coduri standard; dacă unitatea nu e recunoscută se folosește un cod implicit.
- Verifică totalurile documentului generat față de reguli de coerență aritmetică.
- Sunt suportate doar facturile (cod 380) și autofacturile (cod 389), iar doar în lei; notele de credit și facturile în altă monedă nu se transmit încă din aplicație.
- Validarea oficială rămâne cea a sistemului ANAF: 4invoices nu promite că orice factură va fi acceptată.
Toate întrebările despre e-Factura
Informațiile marcate text de lege reflectă legislația în vigoare la data publicării. Cele marcate specificație tehnică descriu felul în care funcționează sistemul și se pot modifica la o versiune nouă a acestuia, fără modificare legislativă — verifică documentația oficială înainte de a le fixa în cod. Pagina nu înlocuiește consultanța fiscală sau de conformitate.