RO e-Factura: XML → PDF

TL;DR

Convert a Romanian e-Factura XML (UBL) into a readable PDF-like preview that you can print/save. It’s the fastest way to understand “what’s inside this XML?” without opening it in a code editor.

Who this is for

• Contractors and accountants who receive XML-only invoices and need a human-readable copy.
• Anyone doing a quick check before forwarding the file (customer, totals, due date, invoice lines).
• Teams that want to archive both the official XML and a readable PDF together for internal workflows.

How to use it

1. Upload the XML file.
2. Review the extracted fields (supplier, customer, invoice number/date, totals, line items).
3. Click Print to save as PDF from your browser (or print to paper).

What this tool does (and does not) do

It does:

• Parse the XML and show a clean invoice preview (supplier/customer, dates, totals, lines).
• Help you catch obvious mistakes fast (wrong customer, missing lines, totals that don’t make sense).
• Produce a readable copy you can attach to internal approvals or keep in your archive.

It does not:

• Replace an official ANAF renderer or guarantee acceptance by ANAF.
• Validate every e-Factura-specific rule, digital signatures, or transport metadata.
• Modify the XML. If the source file is wrong, you must fix it upstream (issuer, ERP, accounting tool).

What you should expect from an e-Factura XML (UBL)

Romanian e-Factura commonly uses UBL-style invoice structures. The XML is designed for systems, not humans, which is why it feels “unreadable” in a normal viewer.

A preview step is useful when you need to:

• confirm this file is for the right customer and period
• sanity-check totals and tax amounts
• quickly read invoice lines (what is being billed? how many units?)
• store a readable copy for internal audit/search (people search PDFs, not XML tags)

This page aims to be a fast human preview, not a pixel-perfect government template.

What we extract (typical fields)

Most invoice reviews come down to a small set of checks:

• Invoice number/ID and issue date (and due date when present)
• Supplier and customer names (as the XML declares them)
• Subtotal, VAT/tax total, and total payable
• Invoice lines: description/name, quantity, unit price, line total

If a field shows as “-”, it’s usually either optional or stored differently in that specific XML variant.

Recommended workflow (simple and safe)

If you want predictable results and fewer “surprises”:

1. ValidateValidate e‑Factura XML
2. Preview the invoice here and check the key fields (customer + totals + lines)
3. Archive both files together (XML + printed PDF)
4. If you also generate documents yourself compare with:
   Create an invoiceProforma template

Troubleshooting (common issues)

“Invalid XML” / parser error

Common causes:

• the downloaded file is not XML (sometimes it’s an HTML error page saved as .xml)
• the file is truncated/corrupted
• a copy/paste process removed parts of the file

Fix: re-download from the source system and upload again.

Supplier/customer name is missing

Different generators may store names in different UBL nodes. If it’s blank:

• search inside the XML for RegistrationName or PartyName
• ask the issuer to confirm which legal entity is being billed

Totals “look wrong”

Quick checks that often reveal issues:

• does subtotal + tax ≈ payable (allowing for rounding)?
• is tax total missing even though VAT should apply?
• are lines present but payable is empty?

If you suspect a bug, validate upstream calculation rules and rounding methods.

No invoice lines found

If the XML has no InvoiceLine, it may not be a proper invoice, or the upstream export is incomplete. Treat this as a red flag and request a corrected file.

Privacy & data handling

This tool parses the XML in your browser (client-side). The file contents are not meant to be uploaded to our server as part of this feature. Still, invoice XML can contain sensitive business data—avoid using shared devices and don’t share exported PDFs unless you intend to.

FAQ

Does this validate e-Factura compliance?

Use Verify e‑Factura XML for quick checks. Passing a practical check is not the same as full ANAF acceptance.

Can I use the generated PDF as “the official invoice”?

Treat it as a readable copy for humans. The authoritative file in e-Factura workflows is typically the XML (plus any official confirmations in your system).

Why does the preview miss some fields?

Some XMLs omit optional fields or store data differently. If something critical is missing, validate the XML and ask the issuer to resend/confirm the content.

What should I read next?

See RO e-Factura: a practical guide (XML, validation, PDF preview).

Related tools

Sources

• ANAF e-Factura: https://www.anaf.ro/
• Romanian legislation portal: https://legislatie.just.ro/

Next steps (IT Jobs List)

For e-Factura, aim for two things: (1) clearly understand what the XML contains, (2) catch common errors early.

Related tools

Related guides

• RO e-Factura: a practical guide (XML, validation, PDF preview)

Quick recommendation

• Save your assumptions (rates, breaks, thresholds) so you can reproduce the result.
• If you use the output in an invoice/offer, include a short explanation (what’s included and what’s not).

Practical checklist (IT Jobs List)

• Validate the XML and check: supplier/customer details, IDs, totals, currency.
• Use the preview as a human verification step before uploading.
• For official reference, compare against ANAF flow.