Romania Einvoice

Exempt intra-community/exports/outside-RO services

Exempt: invoices for intra-community supplies, exports, services taxed outside Romania.

Exempt OSS transactions

Exempt: transactions within the OSS (One-Stop Shop) regime.

Simplified invoices via electronic cash registers

Simplified invoices issued via electronic cash registers are exempt from RO e-Factura but require fiscal memory compliance.

Timeline Phases

| Date | Milestone | |---|---| | November 2021 | RO e-Factura launched for B2G and voluntary B2B | | July 2022 | B2G and high-risk B2B (fruit, vegetables, alcohol, mineral water, construction, new buildings) mandatory | | January 2024 | All B2B reporting mandatory (5 working day submission window) | | July 2024 | B2B clearance model active -- invoice legally valid only after ANAF validation | | January 2025 | B2C e-invoicing mandatory for established taxpayers | | July 2025 | Remaining B2C exemptions expire (non-profits, small farmers) |

Accepted syntaxes

Romania follows the European standard EN 16931 and accepts two syntaxes: - **UBL 2.1** (OASIS Universal Business Language) -- the primary and most common format - **CII** (UN/CEFACT Cross-Industry Invoice) -- accepted but rarely usedEN 16931

CIUS-RO

CIUS-RO (Core Invoice Usage Specification -- Romania) defines national business rules on top of EN 16931. Current version: ro16931-ubl-1.0.9 (effective from 5 June 2024). CIUS-RO specifies: - Mandatory Romanian fiscal identifiers (CUI/CIF) - Romanian-specific tax category codes - National validation schematrons (operational rules + VAT rules + code list rules) - Required document type codes for invoices and credit notesCIUS-RO ro16931-ubl-1.0.9, effective 5 June 2024

Schema and Namespaces

| Component | Value | |---|---| | UBL 2.1 Invoice schema | `UBL-Invoice-2.1.xsd` | | UBL 2.1 CreditNote schema | `UBL-CreditNote-2.1.xsd` | | EN 16931 schematron | CEN/TC 434 base rules | | CIUS-RO schematron | `ro16931-ubl-1.0.9.sch` | | Primary namespace | `urn:oasis:names:specification:ubl:schema:xsd:Invoice-2` | | Common components | `urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2` |

Fields Required by CIUS-RO (Beyond EN 16931 Baseline)

| Field | UBL Path | Notes | |---|---|---| | Supplier tax ID (CUI/CIF) | `cac:AccountingSupplierParty/cac:Party/cac:PartyTaxScheme/cbc:CompanyID` | Must be valid Romanian CUI or CIF | | Buyer tax ID | `cac:AccountingCustomerParty/cac:Party/cac:PartyTaxScheme/cbc:CompanyID` | Required for B2B; for B2C, use CNP or omit | | Invoice number | `cbc:ID` | Unique, sequential | | Issue date | `cbc:IssueDate` | ISO 8601 format | | Due date | `cbc:DueDate` | Required if applicable | | Invoice type code | `cbc:InvoiceTypeCode` | 380 (invoice), 381 (credit note), 389 (self-billed) | | Currency code | `cbc:DocumentCurrencyCode` | RON or EUR; if non-RON, must include exchange rate | | Tax point date | `cbc:TaxPointDate` | Date of supply | | Supplier name and address | `cac:AccountingSupplierParty/cac:Party/cac:PostalAddress` | Full legal address | | Buyer name and address | `cac:AccountingCustomerParty/cac:Party/cac:PostalAddress` | Full legal address | | Line item description | `cac:InvoiceLine/cac:Item/cbc:Name` | Description of goods/services | | Line quantity and unit | `cac:InvoiceLine/cbc:InvoicedQuantity` | With `@unitCode` | | Line net amount | `cac:InvoiceLine/cbc:LineExtensionAmount` | | | Tax category and rate | `cac:TaxTotal/cac:TaxSubtotal/cac:TaxCategory/cbc:ID` + `cbc:Percent` | Per VAT rate | | Total tax amount | `cac:TaxTotal/cbc:TaxAmount` | | | Payable amount | `cac:LegalMonetaryTotal/cbc:PayableAmount` | | | CPV code | `cac:InvoiceLine/cac:Item/cac:CommodityClassification/cbc:ItemClassificationCode` | Required for B2G; recommended for B2B |

B2C buyer identification and upload endpoint

For B2C e-reporting (from 2025), the buyer identification uses a unique identifier. On the test/production platform, a dedicated B2C upload endpoint is used (mandatory since 31 March 2025).

RO e-Factura Platform (SPV)

| Channel | Detail | |---|---| | SPV web portal | Manual upload of XML invoices at anaf.ro → Factura electronică → Trimitere Factură | | REST API | Automated submission via ANAF web services; separate endpoints for B2B/B2G and B2C | | Authentication | Qualified digital certificate (semnătură electronică calificată) registered in SPV | | Submission deadline | 5 calendar days from invoice issuance (but no later than 5 calendar days from the legal deadline for issuance under Art. 319(16) Fiscal Code) | | Recipient download | Buyer must download validated invoice within 60 days | | Download availability | Validated XML available for download for 60 days; after that, archived and available on request |

API Workflow steps

1. **Authenticate** with qualified digital certificate via SPV 2. **Upload** XML invoice to the appropriate endpoint (B2B/B2G or B2C) 3. **Receive** upload confirmation with upload index ID 4. **ANAF validates** the invoice (schema + CIUS-RO + business rules) 5. **Download** validation result: status = "ok" (validated) or "nok" (rejected with error codes) 6. **For B2B clearance (post-July 2024):** validated invoice = legally issued invoice; buyer retrieves from RO e-Factura

Validation steps

Upon upload, ANAF performs: 1. **XML schema validation** against UBL 2.1 or CII XSD 2. **EN 16931 base rule validation** (CEN/TC 434 schematrons) 3. **CIUS-RO rule validation** (national schematrons for operational rules, VAT rules, code lists) 4. **Business rule validation** (NIF/CUI validity, duplicate check, date consistency) 5. **Return status**: validated (with download ID for buyer) or rejected (with error details)

Pre-submission checklist

- Validate XML locally against UBL 2.1 XSD and CIUS-RO schematron before uploading - Verify CUI/CIF validity using ANAF's public API - Ensure invoice number uniqueness within your series - Confirm tax point date and issue date are consistent - Verify VAT rates match current Romanian rates

Common Rejection Reasons

| Reason | Detail | |---|---| | Schema violation | XML does not conform to UBL 2.1 XSD | | CIUS-RO rule failure | National business rule violation (e.g., missing Romanian tax ID format) | | Invalid CUI/CIF | Tax identification number fails ANAF validation | | Duplicate invoice | Invoice number already submitted for the same supplier | | Invalid tax category | Tax code does not match VAT treatment | | Missing mandatory field | Required element absent or empty | | Date inconsistency | Issue date after upload date, or tax point date mismatch |

VAT Rates (2026)

| Rate | Percentage | Application | |---|---|---| | Standard | 19% | Most goods and services | | Reduced 1 | 9% | Foodstuffs, water supply, medicines, hotel accommodation, restaurant services | | Reduced 2 | 5% | Social housing (under thresholds), cultural events, certain children's products | | Exempt with credit | 0% | Intra-community supplies, exports | | Exempt without credit | 0% | Financial services, insurance, education, healthcare |

VAT rounding and multi-currency

- VAT amounts calculated per line, rounded to 2 decimal places (RON bani or EUR cents). - Line totals summed; total VAT is the sum of rounded line-level VAT amounts. - For multi-currency invoices: amounts must appear in the document currency; if not RON, the BNR (National Bank of Romania) exchange rate on the tax point date applies.

Multi-rate handling

Each VAT rate requires a separate `cac:TaxSubtotal` element within `cac:TaxTotal`. Tax base and tax amount must be stated per rate category.

Credit note requirements

Credit notes must reference the original invoice number in `cac:BillingReference/cac:InvoiceDocumentReference/cbc:ID`. The invoice type code is 381. Negative amounts are expressed as positive values on the credit note (the document type signals the reversal).

Archiving Requirements

| Requirement | Detail | |---|---| | Retention period | 10 years from the end of the fiscal year in which the invoice was issued | | Format | Original XML as validated by ANAF (the validated XML is the legally binding document for B2B clearance) | | Accessibility | Must be available for tax inspection on demand throughout retention period | | ANAF download window | Validated invoices available on RO e-Factura for 60 days; after expiry, must be retrieved via archive request | | Buyer obligation | Buyer must download and archive the validated XML within 60 days | | Integrity | Digital certificate chain must remain verifiable; no modifications to the validated XML | | Location | May be stored within the EU; storage outside Romania requires notification to ANAF | | Conversion to PDF | ANAF provides XML-to-PDF conversion tools; the PDF is for human readability only and is not the legal document |

Late or Missing Submission Penalties

| Taxpayer Category | Fine per Incident (RON) | |---|---| | Large taxpayers (contribuabili mari) | 5,000 -- 10,000 | | Medium taxpayers (contribuabili mijlocii) | 2,500 -- 5,000 | | Small taxpayers and individuals | 1,000 -- 2,500 | Fines apply per month in which one or more invoices miss the submission deadline. Multiple invoices in the same month = one fine.

Additional Penalties

| Violation | Penalty | |---|---| | Receiving/registering a B2B invoice not transmitted via RO e-Factura (buyer penalty) | 15% of the total invoice value | | Failure to issue invoice via RO e-Factura for in-scope B2B transactions | Fine equal to the VAT amount on the invoice | | B2C non-compliance (post-grace period) | Same graduated fines as above by taxpayer category |

Non-fine consequences

- Loss of VAT deduction rights for invoices not properly issued/received through RO e-Factura - Increased audit risk from ANAF's risk-analysis system - Buyer notification right: if a buyer does not receive the invoice via RO e-Factura within the legal deadline, they can notify ANAF, triggering enforcement action against the supplier

e-Factura pre-populating VAT return

ANAF uses RO e-Factura data to pre-populate the draft VAT return (RO e-TVA initiative). From 2024, ANAF cross-references e-Factura submissions against VAT declarations. Discrepancies trigger automated notifications and potential audits.

RO e-TVA pre-filled VAT return

The RO e-TVA system provides taxpayers with a pre-filled VAT return based on RO e-Factura data, RO e-Transport data, and customs declarations. Taxpayers must review and adjust before submission.

SAF-T cross-checks

Romania also requires SAF-T reporting (Declarația 406) for large and medium taxpayers. Invoice data from RO e-Factura should be consistent with SAF-T submissions. ANAF cross-checks between the two systems.

e-Transport consistency requirement

For goods movements, RO e-Transport operates alongside RO e-Factura. Transport documents and invoices must carry consistent references. Goods in transit without matching e-Transport declarations face confiscation risk.

Corporate tax data feed

Invoice data feeds into corporate tax assessments. ANAF uses e-Factura data to verify revenue declarations and deduction claims.