Romanian e-Factura can feel stressful for one simple reason: the “real” document is an XML file, and when something is wrong, error messages can be hard to interpret.
This guide is intentionally practical: how to sanity-check an XML, what mistakes show up most often, and how to build a privacy-first workflow so you don’t leak invoice data while debugging.
This is not tax/legal advice. For compliance and complex cases, confirm with your accountant and/or invoicing provider.
TL;DR
- e-Factura is, in practice, an invoice in a standardized XML format (often UBL) + official transmission.
- Before uploading, do two checks:
- human-readable preview (XML → “PDF”)
- basic validation (sanity checks)
- Useful tools:
- A browser validator does not guarantee official acceptance, but it catches common issues fast.
What e-Factura is (in practical terms)
In day-to-day work:
- you generate a standardized XML invoice (often UBL)
- you transmit it through the required workflow (depending on your case)
- you receive feedback/confirmation (sometimes cryptic)
The tricky part is that:
- XML has many fields
- some are mandatory depending on context
- tiny differences (totals, currency, missing parties) can break validation
Privacy-first: the real risk most people ignore
Invoices almost always contain sensitive data:
- company/person names
- addresses
- identifiers
- financial amounts
Practical recommendation:
- avoid uploading XML to random tools unless you understand where data goes
- prefer tools that can parse/preview locally in your browser
Our tools are designed for client-side preview/validation: use the e-Factura XML → PDF preview and the e-Factura XML validator.
60-second checklist (before you send it anywhere)
- Invoice ID exists.
- IssueDate exists.
- Supplier and customer names exist.
- At least one invoice line exists.
- Totals exist (subtotal/tax/total) or you know exactly why they don’t.
- Currency is consistent (RON/EUR) and not missing.
Common mistakes (and how to spot them quickly)
1) Invalid XML (parser error)
Symptom: you see an “invalid XML”/parser error.
Typical causes:
- truncated file
- invalid characters
- encoding mismatch
Fix: re-export/regenerate from the source system.
2) Missing parties (supplier/customer)
Symptom: supplier or customer name doesn’t show up.
Fix:
- ensure issuer data is configured in the invoicing system
- ensure customer details are complete
3) Totals don’t match
Symptom: line totals don’t match subtotal/tax/total.
Why it happens:
- rounding differences (per line vs total)
- VAT math mismatch
- discounts applied on net vs gross
Fix:
- verify line totals
- sanity-check net VAT gross using the VAT calculator (2025)
- regenerate XML from the source (avoid manual edits if you’re not sure)
4) Currency/formatting issues
Symptom: missing currency code or amounts interpreted oddly.
Fix:
- confirm invoice currency
- avoid mixing currencies within a single total
How to use XML → PDF preview
Goal: quickly verify if the XML “looks right” to a human.
Steps:
- Open the e-Factura XML → PDF preview
- Upload the XML
- Verify:
- supplier/customer
- line items (description, qty, unit price, totals)
- totals (subtotal, VAT, total payable)
- If you need a readable archive: Print → Save as PDF
Tip: store the PDF alongside the XML for faster future lookup.
How to use the validator (sanity checks)
Goal: catch obvious issues before you waste time in the official flow.
Steps:
- Open the e-Factura XML validator
- Upload the XML
- Read results:
- errors: the XML doesn’t look invoice-like / missing critical parts
- warnings: useful fields missing (may be optional)
- Fix upstream and re-export until errors are gone
Limitations (set expectations correctly)
- A lightweight validator does not mean “ANAF acceptance guaranteed”.
- Some rules depend on transaction context.
- For compliance, the source of truth is your official workflow and accounting.
FAQ
Does this replace the official portal?
No. It’s for preview and fast checks.
Is my XML uploaded to a server?
The intent is client-side parsing in the browser. If you have strict privacy requirements, use only tools you control and follow your internal policy.
How does e-Factura relate to normal invoicing?
It changes the format and sometimes the steps, but the core billing logic (what you bill, VAT clarity, totals) remains. See Invoice vs proforma vs receipt (Romania).
What if validation keeps failing?
In most cases you should fix at the source system and regenerate XML, not manually edit it.
Next steps
Start with VAT for IT contractors (2025) to keep “base vs VAT vs total” clear, then revisit Invoice vs proforma vs receipt (Romania) for the basics.
For the practical e-Factura workflow, use e-Factura XML to PDF and the e-Factura XML validator to catch errors before sending.
Sources
- ANAF: https://www.anaf.ro/
- Romanian legislation portal: https://legislatie.just.ro/
