Trei probleme practice ale sistemului e-Factura și de ce ar trebui soluționate

Unul dintre punctele principale pe care şi le propune sistemul e-Factura este ca, de la 1 iulie 2024, să nu mai fie nevoie să transmitem facturile prin e-mail (sau alte mijloace - prin poştă, curier etc.) în relaţia B2B. Bineînţeles, nu va fi interzis acest lucru, dar ideea este să nu mai fie nevoie de alte mijloace.

Dacă clienţii NU vor fi mulţumiţi să primească factura doar prin sistemul e-Factura, în practică, furnizorii vor fi nevoiţi să le trimită în continuare şi prin varianta „clasică”. Astfel, am încercat să identificăm punctele pe care ar trebui să le atingă un emitent de e-factură aşa încât clientul să fie mulţumit, iar factura în format XML să nu aibă niciun dezavantaj faţă de modul de lucru de până acum.

1. Includerea facturii în format PDF în fişierul XML

Cea mai mare problemă, în momentul de faţă, este rezultatul final, adică felul cum arată factura în formatul pentru tipărire (PDF, după cum ne-am obişnuit în ultimii mulţi ani). Chiar dacă încercăm să spunem că factura originală, de fapt, nu mai este o pagină de hârtie pe care o putem pune într-un dosar, ci un fişier abstract pe care îl putem accesa doar cu diverse softuri, bineînţeles că aproape oricine va avea nevoie şi să „vadă” respectivul document, să-l tipărească, să-l arate într-o şedinţă, într-o întâlnire online etc.

Este, evident, extrem de important ca acest document în format tipăribil (PDF) să arate exact aşa cum ne-am obişnuit să-l avem. Odată cu „liberalizarea” formatului facturilor (care a fost un pas revoluţionar pentru oricine se uită vreodată la o factură), emitenţii facturilor au făcut tot posibilul să ne ofere nouă, cumpărătorilor, o experienţă cât mai bună. Începând de la furnizorii mari de utilităţi, telefonie, internet și până la sutele de mii de firme care utilizează softuri dedicate de facturare sau contabilitate, toţi au încercat şi au reuşit, în majoritatea cazurilor, să ne explice, într-un mod cât mai clar, ce anume cumpărăm sau consumăm.

Sistemul e-Factura funcţionează momentan aşa:

• furnizorul generează factura într-un format abstract XML;
• clientul o preia fie din interfaţa Spațiului Privat Virtual, fie prin intermediul unui soft (de exemplu, softul de contabilitate);
• softul de contabilitate sau platforma ANAF generează formatul PDF pe baza fişierului XML transmis.

Marea majoritate a softurilor utilizează platforma ANAF pentru a transforma fişierul XML în PDF, având în vedere că o astfel de implementare este extrem de complexă având în vedere specificaţiile vaste ale formatului e-Factura. Nu că ANAF ar genera PDF-ul perfect, ci că, dacă o anumită factură nu se generează perfect, putem să dăm vina pe ANAF. Prin urmare, în momentul de faţă, marea majoritate a celor care primesc facturile prin sistemul e-Factura vor vedea formatul PDF generat de platforma ANAF.

ANAF ar putea să facă un mic efort ca să genereze un format mai uşor de citit. De exemplu:

• factura să fie în mod portret, nu landscape;
• să fie afişate corect unităţile de măsură (de exemplu, „buc” în loc de H87);
• să afişeze corect caracterele româneşti (dacă tot le avem în alfabet);
• să utilizeze mai multe mărimi de font (evident, anumite părţi ale facturii sunt mai importante, iar altele mai puţin importante).

Aceste îmbunătăţiri cu siguranţă ar ajuta, însă tot nu ar reuşi să ajungă la calitatea formatului PDF al facturii „originale” cu care suntem obişnuiţi. Soluţia este simplă: factura XML poate avea ataşamente. Tot ce au de făcut cei care generează XML-ul facturii este să pună un ataşament cu factura în format PDF. Din punct de vedere tehnic, trebuie făcut asa:


Câţiva furnizori au implementat deja acest mod de lucru. De exemplu, Apa Nova, PPC Energie, RCS & RDS. Din testele noastre, marea majoritate a furnizorilor, inclusiv cele mai populare softuri de facturare și contabilitate, NU au implementat încă acest mod de lucru (deşi ar fi în avantajul utilizatorilor).

Presupunerea noastră este că nu au inclus în fişierul XML şi PDF-ul facturii pentru a-şi minimiza costurile de transmitere şi stocare a facturilor. Mai exact:

• o factură XML fără ataşament ocupă în jur de 2 KB;
• o factură XML care să includă şi PDF-ul facturii poate să ocupe zeci sau sute de KB (adică de zeci sau de sute de ori mai mult).

Chiar dacă există un cost mai mare pentru stocarea facturilor în acest fel, considerăm că beneficiul în favoarea utiliatorilor este evident şi total justificat. În plus, spaţiul de stocare este extrem de ieftin. De exemplu, pe un disc de 1 TB ar trebui să încapă câteva milioane de facturi.

2. Facturile XML să conţină IBAN-ul furnizorului

Dacă dorim ca facturile în format XML să înlocuiască formatul clasic, evident că acest format trebuie să includă toate informaţiile importante care se găsesc în varianta tipărită.

ANAF nu obligă furnizorul să pună un cont IBAN în factura XML (probabil fiindcă sunt situaţii rare în care nu există cont bancar sau nu este necesar). 

Însă, în marea majoritate a cazurilor, plata se face prin bancă. Prin urmare, este, evident, util să existe contul pe factură, nu să fie nevoie ca beneficiarul facturii să caute IBAN-ul în altă parte.

Am vazut facturi XML generate de softuri populare de factuare unde în formatul PDF apărea IBAN-ul, iar în XML lipsea.

3. Facturile XML să conţină codul de client, codul locului de consum și nu numai

În cazul furnizorilor mari de utilităţi, există deseori câmpuri de genul cod client, cod loc de consum, id factură etc.

Tot pe ideea că formatul XML ar trebui să conţină toate informaţiile utile din factura clasică, este, evident, util (şi foarte simplu) să apară şi informaţii de genul:

• codul de client;
• codul locului de consum;
• id-ul facturii;
• codul de plată.

Am văzut furnizori de utilităţi la care pe factura tipărită ne spunea să punem codul de client în momentul în care facem plata prin transfer bancar, iar factura XML nu conţinea codul respectiv.