RO e-Factura: XML Validator

Quick structure checks for common required fields (browser-based).

Validate XML

The file stays in your browser. Nothing is uploaded.

TL;DR

Run quick, practical checks on a Romanian e-Factura XML (UBL) so you can answer:

  • “Is this even a valid XML?”
  • “Does it look like an invoice document?”
  • “Do the key fields exist (ID/date/supplier/customer/totals/lines)?”

This is meant to catch obvious breakage fast, before you waste time forwarding, importing, or archiving a broken file.

Who this is for

  • Anyone receiving XML and wanting a fast “is this obviously broken?” check.
  • Contractors who get XML from a client portal and need a quick sanity check before bookkeeping.
  • Teams integrating e-Factura exports and wanting a first-pass guardrail for bad inputs.

How to use it

  1. Upload the XML file.
  2. Review the validation output:
    • Errors usually mean “this cannot be treated as an invoice”.
    • Warnings usually mean “you can proceed, but verify this detail”.
  3. If errors appear, fix the upstream generator or ask the issuer to resend.

What we validate (practical checks)

This validator focuses on “human-critical” fields that should exist in nearly every real invoice:

  • Root document resembles an Invoice (invoice-like UBL structure)
  • Invoice ID / number exists
  • Issue date exists
  • Supplier name exists
  • Customer name exists
  • Total payable exists
  • At least one invoice line exists

It also flags warnings for common “missing-but-expected” fields (e.g., currency or tax totals), depending on what’s present in the XML.

What we do NOT validate

To set expectations clearly:

  • This is not a complete UBL schema validation.
  • Passing these checks does not guarantee acceptance by ANAF.
  • We do not validate signatures, transport envelopes, or every mandatory element per specific e-Factura scenarios.

If you need strict compliance validation, you should also use the official tooling provided in your e-Factura workflow and/or your accounting/ERP validations.

How to interpret results

If you see an error

Treat it as “stop and fix upstream”. Typical next steps:

  • re-export the XML from the issuer’s system
  • check if the downloaded file is actually an HTML error page renamed to .xml
  • confirm you didn’t receive a different document type (e.g., credit note vs invoice)

If you see only warnings

Warnings are prompts to double-check. Example:

  • currency missing → verify the amounts and currency (especially for non-RON invoices)
  • tax total missing → verify if VAT should exist or if this is a VAT-exempt scenario

Worked examples

Example 1: parser error

If the XML is malformed, you’ll see an “invalid XML” error. Re-download from the source system.

Example 2: missing totals

You may still be able to open the file, but warnings about totals often mean the upstream export is incomplete or uses unexpected nodes. Use the preview tool to inspect what’s available.

Example 3: missing lines

No invoice lines is a strong red flag. Ask for a corrected XML or confirm it isn’t a different UBL document type.

Best practice: validate + preview

Most people get the best outcome by combining:

  1. Check XML validity (fast checks)
  2. Open e‑Factura XML (human preview you can archive)

Privacy & data handling

Validation is done in your browser (client-side). Still, invoice XML can be sensitive—avoid using shared devices and don’t share screenshots unless you intend to.

FAQ

Is this a full schema validation?

Not yet. It’s a practical validator for common issues and “must-have” invoice fields.

What if my XML passes here but fails in ANAF?

That can happen. This tool is a first-pass sanity check, not an official acceptance guarantee. Treat it as a quick filter to catch obvious breakage early.

What next?

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

Sources

Next steps (IT Jobs List)

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

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.
By Ivo Pereira Last updated: 2025-12-27
Quick notes & assumptions

Notes

  • This is a fast sanity-check. For full compliance, use official validation and your accounting workflow.

How to validate an e-Factura XML (quick checks)

This validator runs a small set of sanity checks so you can quickly spot missing or unusual fields before you upload or process an invoice.

It does not replace full UBL schema validation or official platform checks. It is meant to catch obvious issues early.

What “OK / Warning / Error” means

  • OK: a common required field was found (e.g., invoice ID, issue date, supplier/customer, payable total).
  • Warning: a field is often present but not always mandatory (currency, subtotal, tax total).
  • Error: a key element was not detected and the file might be incomplete or structured differently.

If you get errors

  • Try the XML → PDF tool to inspect what is present and whether namespaces/structure differ.
  • Confirm you are using the correct file (some systems export multiple XML types).
  • If your workflow requires strict validation, run the official checks in your accounting/e-Factura tooling.

Sources

Last updated: 2025-12-27