Continut principal

eFactura · Facturare pe marketplace

Reguli, fluxuri și monografie contabilă pentru facturarea electronică pe OutletMAG Marketplace. Document de transparență pentru vânzători, contabili și parteneri.

Ultima actualizare: 28 mai 2026

Audiență: contabil EOUTLETMAG + echipa tehnică Operator Cadru normativ:

  • OUG 120/2021 — instituirea sistemului electronic RO eFactura
  • OUG 130/2021 și modificările ulterioare — extinderea aplicabilității
  • Specificația UBL 2.1 — Universal Business Language ISO/IEC 19845
  • CIUS-RO — specificația de utilizare pentru România (publicată de Ministerul Finanțelor)

Ultima actualizare: 2026-05-23

1. Ce este RO eFactura

Sistemul RO eFactura este platforma electronică obligatorie a Ministerului Finanțelor / ANAF prin care se transmit facturile fiscale între operatorii economici și se centralizează la nivel național. Funcționează din iulie 2022 (B2G obligatoriu), s-a extins în 2024 (B2B obligatoriu) și în 2025 (B2C obligatoriu).

Pentru marketplace, eFactura este obligatorie atât pentru facturile de comision (B2B — Operator → Vânzător), cât și pentru facturile de vânzare către Cumpărători (B2B sau B2C, în funcție de model).

2. Cine emite eFactura — funcție de model

În Modelul A (intermediar transparent) — recomandat

FacturăEmitentDestinatarObligație eFactura
Factura de produsVânzătorCumpărător (B2B sau B2C)DA — în sarcina Vânzătorului
Factura de comisionOperator (EOUTLETMAG)Vânzător (B2B)DA — în sarcina Operatorului

Consecință: Vânzătorii trebuie să aibă capacitatea tehnică de eFactura ÎNAINTE de a fi aprobați. Verificarea se face în pasul 4 al procedurii interne de aprobare Vânzător (vezi documentația operațională internă a echipei admin).

În Modelul B (revânzător)

FacturăEmitentDestinatarObligație eFactura
Factura Vânzător → OperatorVânzătorOperatorDA
Factura Operator → CumpărătorOperatorCumpărător (B2B sau B2C)DA

În Modelul B, Operatorul are dublu rol: primește eFactura de la Vânzător și emite eFactura către Cumpărător.

3. Cerințe tehnice — implementare în Platformă

3.1. Format

  • XML conform UBL 2.1 + CIUS-RO (constraint pe câmpuri obligatorii și opționale).
  • Codificare: UTF-8 fără BOM.
  • Schema XSD oficială: publicată pe site-ul ANAF / Ministerul Finanțelor.

3.2. Câmpuri obligatorii principale

  • cbc:CustomizationID — identificator CIUS-RO (urn:cen.eu:en16931:2017#compliant#urn:efactura.mfinante.ro:CIUS-RO:1.0.1 sau versiunea curentă)
  • cbc:ID — numărul facturii (serie + număr, conform numerotării interne EOUTLETMAG)
  • cbc:IssueDate, cbc:DueDate, cbc:InvoiceTypeCode
  • cac:AccountingSupplierParty — date Operator (denumire, CUI cu prefix RO43098329, adresă, IBAN)
  • cac:AccountingCustomerParty — date destinatar (denumire, CUI / CNP pentru B2C, adresă)
  • cac:InvoiceLine — linii produs (denumire, cantitate, preț unitar, TVA, total)
  • cac:TaxTotal — defalcare TVA pe cote (21%, 11%, 9%, 0%)
  • cac:LegalMonetaryTotal — total factură

3.3. Reguli speciale CIUS-RO

  • CUI cu prefix RO doar pentru plătitorii de TVA (Operator EOUTLETMAG RO43098329, cu RO);
  • pentru persoane fizice, în cac:AccountingCustomerParty se completează cbc:CompanyID cu CNP (cu mascare conform GDPR opțional);
  • adresa cu județ, localitate, cod poștal RO valid (cod SIRUTA opțional);
  • monedă: RON (alte monede impun curs BNR raportat).

3.4. Transmitere către ANAF

  • Autentificare: certificat digital calificat (token USB sau soft) înregistrat pe SPV (Spațiul Privat Virtual) sau prin OAuth2 cu certificat.
  • Endpoint API ANAF: https://api.anaf.ro/prod/FCTEL/rest/upload (transmitere) și https://api.anaf.ro/prod/FCTEL/rest/listaMesajeFactura (status).
  • Termen: maximum 5 zile lucrătoare de la data emiterii facturii.
  • Status: la transmitere, ANAF returnează un ID unic. La validare (în ~secunde-minute), ANAF returnează „OK" sau erori (cu rule ID — vezi documentația oficială).

3.5. Erori frecvente la transmitere

  • BR-AE-09 — CUI destinatar invalid sau lipsă cifră check.
  • BR-CO-15 — total factură nu corespunde sumei liniilor + TVA.
  • BR-RO-01 — CIUS-RO specific: cod TVA neasignat la o linie (frecvent la importuri).
  • BR-S-09 — cota TVA neacceptată pentru categoria de produs.

4. Stack tehnic — implementare în Marketplace

4.1. Bibliotecă recomandată

Pentru Next.js / Node.js, opțiuni:

  • Implementare directă XML prin librării (de ex. xml2js, xmlbuilder2) — control total dar mai mult cod de scris și mentenanță;
  • Wrapper open-source RO (de ex. proiecte GitHub în .NET / PHP cu echivalent JS) — verifică cu echipa;
  • Furnizor extern certificat (de ex. SmartBill, FGO, Saga, Oblio prin API) — externalizează generarea eFactura, plătești per factură.

Decizie internă MVP: pentru lansarea MVP se merge pe integrare directă API ANAF prin generator XML UBL 2.1 + CIUS-RO scris în-house (folosind utilitarele existente în src/lib/efactura/ubl-generator.ts), pentru a păstra controlul complet asupra fluxului și a evita costul recurent per factură. Evaluarea unui furnizor extern (Oblio API ~0.5–1 leu/factură, SmartBill, FGO) rămâne deschisă pentru momentul în care volumul depășește ~500 facturi/lună, când efortul de mentenanță in-house devine semnificativ. [REVIEW CONTABIL — Decizie de revalidat cu contabilul EOUTLETMAG la 6 luni post-lansare.]

4.2. Flux în Platformă (Model A)

1. Cumpărător plasează comandă pe MKT.
2. Vânzător este notificat → pregătește factura în propriul sistem (Oblio, SmartBill, custom).
3. Vânzător încarcă factura în propriul SPV → ANAF.
4. (paralel) Operatorul generează factura de comision săptămânal (batch luni dimineața):
   a. Identifică toate tranzacțiile finalizate (livrate, ieșite din 14-zile retur).
   b. Agregă pe Vânzător → o factură de comision per Vânzător per săptămână.
   c. Generează XML UBL 2.1 + CIUS-RO.
   d. Transmite la ANAF prin API.
   e. Stochează XML semnat în DB + S3 archive.
   f. Notifică Vânzătorul cu link de descărcare PDF + XML.

4.3. Stocare și arhivare

  • XML eFactura semnat ANAF — păstrare obligatorie 10 ani în format digital (Legea 82/1991, Codul Fiscal).
  • Stocare recomandată: S3 / object storage cu encryption at rest + backup off-site.
  • Index în baza de date (Invoice.efactura_id, Invoice.efactura_status, Invoice.efactura_xml_url).

4.4. Reconciliere periodică

Săptămânal sau lunar, comparare:

  • Facturile emise în Platformă vs. Facturile transmise ANAF (raport listaMesajeFactura din SPV);
  • Identifică facturi care au eșuat la transmitere (status nok sau lipsă) → retransmitere automată sau manuală.

5. Aspecte specifice marketplace

5.1. Numerotare factură

  • Serie: OMG-MKT (sau EFO-MKT în funcție de entitatea aleasă) pentru facturile de comision.
  • Format număr: OMG-MKT-{YYYY}-{NNNNNN} (de ex. OMG-MKT-2026-000001).
  • Numerotare strict crescătoare, fără goluri, conform Codului Fiscal art. 319 alin. (20).
  • Vezi skill-ul import-nexus / nexus-import-rules pentru convenția existentă în grupul OutletMAG.

5.2. Storno / Anulare

  • O factură transmisă în ANAF NU poate fi ștearsă.
  • Anulare se face prin emiterea unei facturi de stornare (factură nouă, cu valori negative sau prefix STORNO-).
  • Pentru retururi de la Cumpărători → factură de storno emisă de Vânzător (Model A) sau de Operator (Model B).

5.3. Multi-entitate

Operatorul poate decide ulterior să mute marketplace-ul pe o altă entitate (EVENDI, ORW etc.). În acest caz:

  • Schimbarea CUI emitent în XML eFactura;
  • Re-înregistrare separată în SPV;
  • Migrare serie facturi (continuare numerotare sau pornire de la 1 cu serie nouă, decizie contabil).

Decizie inițială: marketplace-ul operează pe entitatea EOUTLETMAG S.R.L. (CIF RO43098329) încă din MVP. [REVIEW CONTABIL — Decizie de revalidat cu contabilul EOUTLETMAG la depășirea plafonului de microîntreprindere (100.000 EUR cifră de afaceri anuală conform Codului Fiscal 2026), moment în care se evaluează dacă marketplace-ul se mută pe o entitate separată (EVENDI, ORW sau entitate nouă) pentru optimizare fiscală.]

6. Resurse oficiale

  • ANAF — RO eFactura: https://www.anaf.ro/anaf/internet/ANAF/asistenta_contribuabili/e_factura/
  • Specificația CIUS-RO: https://mfinante.gov.ro/documents/ (caută „CIUS-RO")
  • API ANAF — documentație: https://www.anaf.ro/anaf/internet/ANAF/asistenta_contribuabili/colaborare_terti/api
  • DUKIntegrator — instrument oficial validare XML local (offline) — recomandat în CI/CD ca pre-check înainte de transmitere.

7. Cross-reference

  • Skill-ul legislatie_conta (din ~/.claude/skills/) conține detaliile complete despre RO eFactura — schema XML, validare, declarații conexe (D300, D394).
  • Documentul monografie contabilă marketplace (intern, în acest folder docs/contabilitate/) conține schemele contabile complete (debit/credit) pentru fiecare tip de factură.
  • Documentul playbook aprobare Vânzător (intern, în docs/operatii/) include verificarea capacității Vânzătorului de a emite eFactura, ca parte din pasul 4 (Documente obligatorii).
[REVIEW CONTABIL — Checklist pre-producție, de confirmat cu contabilul EOUTLETMAG înainte de prima factură emisă din producție]:
1. Confirmare CUI emitent (EOUTLETMAG — RO43098329 — vs. eventuala mutare ulterioară pe altă entitate);
2. Înregistrarea certificatului digital calificat în SPV (Spațiul Privat Virtual) pentru entitatea aleasă;
3. Confirmarea deciziei: integrare directă API (varianta selectată) vs. furnizor extern (Oblio, SmartBill, FGO);
4. Test end-to-end cu o factură test în mediul de test ANAF (https://api.anaf.ro/test/FCTEL/);
5. Configurarea numerotării seriei + început număr coordonat cu numerotarea contabilă existentă a EOUTLETMAG (a se evita coliziunea cu seria utilizată în retail-ul fizic).