Factură storno: ce înseamnă, cum o emiți și cum se reflectă în e-Factura

Factura storno este documentul fiscal prin care anulezi total sau parțial o factură fiscală deja emisă. Are propriul număr de factură (din aceeași serie sau dintr-o serie dedicată storno), data emiterii (data deciziei de anulare) și conține sume negative sau mențiuni explicite de stornare care reduc valoarea facturii originale. Factura originală rămâne emisă și raportată în istoricul fiscal; storno-ul intervine separat pentru a-i anula efectele¹.

Conceptul există pentru că numerotarea fiscală în România este consecutivă și auditabilă: nu poți șterge un număr din serie, doar îl poți anula prin emisia unui document separat. Această regulă protejează integritatea evidenței contabile și permite trasabilitate completă a istoricului facturilor. Pentru contextul general al facturării și diferența față de proforma, vezi entry-ul dedicat.

Cui i se aplică factura storno și când o folosești?

Factura storno privește orice operator care a emis o factură fiscală ce trebuie anulată sau corectată: anulare de comandă, returnare de produs, eroare la emitere sau reducere de preț post-vânzare. Situațiile tipice:

• Anulare comandă după emiterea facturii. Clientul a comandat, factura a fost emisă și raportată în e-Factura, dar comanda este anulată ulterior. Storno-ul anulează efectele fiscale ale facturii originale.
• Returnare produs. Pentru bunuri vândute care sunt returnate de client în termenul legal sau contractual, emiți storno pentru factura corespunzătoare.
• Eroare la emitere. Sumă greșită, client greșit, perioadă greșită, cotă TVA greșită. Originalul nu poate fi ștearsă; emiți storno pentru anulare, apoi factură nouă corectă.
• Reducere de preț post-vânzare. Discount acordat ulterior, rambursare parțială, corecție de calcul. Folosești factură rectificativă (cod 384) în loc de storno standard (cod 381), pentru corecție parțială.

Termenul legal pentru emiterea storno-ului este, pentru returnări și anulări în condiții normale, până la data depunerii declarației fiscale pentru perioada respectivă. În practică, emite-l cât mai aproape de momentul deciziei de anulare; întârzierea produce discrepanță între datele tale operaționale și raportarea fiscală.

Care este structura legală a unei facturi storno?

Structura unei facturi storno respectă aceleași reguli ca o factură fiscală obișnuită, plus câteva particularități:

1. Număr propriu de factură fiscală. Stornoul are propriul număr, separat de cel al originalului. Convenția practică este o serie dedicată (de exemplu, „STO" sau prefixul „FAC-STO") care marchează vizibil natura documentului.
2. Referință explicită la factura originală. În câmpurile UBL specifice (referință document precedent), declari numărul și data facturii originale stornate. ANAF urmărește perechea original plus storno prin această legătură.
3. Sume negative sau mențiunea de stornare. Pentru storno total, sumele liniilor sunt cele ale originalului dar cu semn negativ, total general negativ. Alternativ, mențiunea „STORNO" pe document plus suma originală pozitivă, interpretată invers.
4. TVA tratat corespunzător. Cota și suma TVA-ului sunt cele ale facturii originale (pentru consistență), inversate aritmetic. Modificarea cotei la momentul storno-ului produce erori de validare.

Profilul CIUS-RO oferă două coduri pentru tipuri diferite: 381 (notă de credit, pentru storno total) și 384 (factură corectivă, pentru corecții parțiale precum schimbare de preț pe linie sau modificare de cantitate). Alegerea corectă a tipului influențează validarea.

Cum emiți tehnic o factură storno?

O emiți prin aceleași trei căi ca factura fiscală obișnuită: SaaS de facturare (SmartBill, Oblio, FGO), implementare proprie în UBL sau manual prin portalul SPV:

• SaaS de facturare (SmartBill, Oblio, FGO): toate expun endpoint dedicat pentru emiterea storno-ului, plecând de la factura originală. Apelul tipic: POST /SBORO/api/invoice/cancel sau echivalent, având parametrul de identificare a facturii originale. SaaS-ul construiește XML-ul storno automat și îl trimite în e-Factura².
• Implementare proprie în UBL: generezi XML-ul UBL conform CIUS-RO având codul tip 381 sau 384, semnezi XAdES, încarci prin API-ul e-Factura. Aceleași reguli de validare locală Schematron ca pentru facturile fiscale obișnuite.
• Manual prin portalul SPV: pentru volume foarte mici sau pentru cazuri ocazionale. Acceptabil ca tranziție, nu ca stare finală pentru un flux operațional repetabil.

Pentru implementări automate, atenție la idempotență: un singur trigger (anulare comandă) nu trebuie să producă două storno-uri. Folosește identificatorul facturii originale ca cheie de unicitate pe partea emisiunii storno.

Pentru integrările cu procesatori de plată, alinierea storno-ului cu rambursarea financiară este partea care provoacă cele mai multe erori operaționale. Stripe livrează un webhook charge.refunded sau refund.created când rambursarea către card este procesată; handler-ul trebuie să declanșeze emiterea storno-ului pentru factura corespunzătoare, având legătura prin identificatorul comenzii sau al sesiunii de plată. Lipsa acestei sincronizări produce situația tipică: clientul a primit banii înapoi, dar factura fiscală rămâne emisă în sistemul tău și raportată ANAF.

Cum se reflectă storno în e-Factura și SAF-T?

Storno-ul intră în e-Factura ca document fiscal separat, având referință la originalul stornat. ANAF urmărește perechea: dacă originalul există în e-Factura dar storno-ul lipsește (sau invers), sistemul detectează automat discrepanța la cross-check cu jurnalul contabil din SAF-T.

În SAF-T, storno-ul apare în zona SourceDocuments ca o factură fiscală separată, plus în zona GeneralLedgerEntries ca înregistrare contabilă de anulare. Storno-urile pe perioade SAF-T deja închise cer redepunerea perioadei vechi: pipeline-ul tău trebuie să identifice că factura corectată aparține altei perioade decât cea curentă, să regenereze SAF-T-ul pentru perioada veche având efectul storno-ului inclus, și să îl redepună ca depunere rectificativă prin D406.

Acest „rippling effect" face storno-urile costisitoare operațional la volume mari. Pipeline-uri robuste de SAF-T tratează corectarea perioadelor închise ca un caz prioritar, nu ca un caz marginal.

De ce contează factura storno pentru un dezvoltator?

Două motive practice: primul, dacă lucrezi pe orice produs care emite facturi fiscale, vei avea de gestionat anulări, returnări și corecții. Fluxul de storno nu este opțional; este partea de „happy path" la fel de importantă ca emisia inițială. O implementare care emite factura corect dar nu o poate storna corect este un risc operațional care explodează la prima anulare reală.

Al doilea: storno-urile cer disciplină arhitecturală pe partea de retransmiteri și pe partea de detecție a perioadelor afectate. La crawlerra construim fluxurile de storno cu același nivel de rigoare ca pe cele de emisie: identificator de unicitate pe factura originală, validare strictă a tipului (381 vs 384), redepunere automată a perioadelor SAF-T afectate. Pentru cadrul mai larg, vezi e-Factura și factura proforma; pentru semantica autentificării pe API-urile de facturare, JWT.

1. Regimul legal al facturii storno: Codul Fiscal (art. 319) prevede regulile pentru factura fiscală inițială; storno-ul respectă aceleași reguli ca document fiscal nou. Profilul CIUS-RO definește codurile 381 (notă de credit) și 384 (factură corectivă) pentru cele două variante uzuale, ambele acceptate la încărcare în e-Factura. Documentația tehnică este publicată la efactura.anaf.ro. [seo.storno_legal_framework]
2. Comportamentul observat în clientul SmartBill de producție: endpoint-ul dedicat storno acceptă referință la factura originală prin numărul ei fiscal și emite documentul nou cu numărul corespunzător din seria configurată. Rate limit-ul rămâne același (aproximativ 3 cereri pe secundă, 403 la depășire), deci storno-urile masive cer aceeași coadă serializată ca emisiile normale. [crawlerra.smartbill_backoff]