UBL Invoice Viewer
UBL 2.1Open a UBL 2.1 Invoice or CreditNote and read it as a document: parties, lines, VAT breakdown, totals and payment details, alongside the raw XML and the parsed model.
Your document never leaves your device — the file is read and parsed in this browser tab.
Drop an XML document here, or choose a file
Read in your browser. Never uploaded. Up to 12.0 MB.
What this viewer does
A UBL invoice is a deeply nested XML document. Reading one in a text editor means tracking which cac:Party you are inside and mentally joining cac:TaxTotal to cac:LegalMonetaryTotal. This tool does that for you: it resolves the document into the business objects the standard describes and shows them as an invoice, while keeping the source one tab away.
Three views are available. Preview renders the invoice. Raw XML re-indents and highlights the source with line numbers. Parsed data shows the exact object this site built from your file, which is what you want when a field is not appearing where you expect.
Namespaces, not prefixes
The most common mistake in home-grown UBL tooling is to search for literal cac: and cbc: strings. Those prefixes are conventions, not part of the standard. A conformant invoice may bind the UBL Common Basic Components namespace to any prefix, or make it the default namespace with no prefix at all, and it is still the same document.
This viewer resolves every element by namespace URI and local name, walking direct children rather than searching descendants — so an invoice using foo: and bar: parses exactly like one using the conventional prefixes, and a seller name is never accidentally picked up from a nested structure.
What the viewer reads
- Document identity — invoice number, issue and due dates, document type code, currency, buyer reference, invoicing period, notes and their subject qualifiers.
- Parties — trading name and registered legal name kept apart, electronic address, party identifiers with their scheme, VAT and other tax registrations, postal address and contact details.
- Lines — quantity with unit code, net price and base quantity, item identifiers, classified tax category and line net amount.
- VAT — every
cac:TaxSubtotalwith its category, rate, taxable amount, tax amount and exemption reason. - Totals — line total, allowances, charges, tax exclusive and inclusive amounts, prepaid amount, rounding and the amount due for payment.
- Payment — payment means code, account identifier or IBAN, account holder, BIC, remittance information and payment terms.
Values are shown as written
Amounts, quantities and dates keep the exact text found in the document alongside the interpreted value. If an amount is 1 234,56 rather than a valid XSD decimal, the viewer shows you that string instead of silently rendering a number that is not in your file. This is deliberate: a debugging tool that quietly corrects your data is hiding the bug you came to find.
Related reading
For the structure behind these elements see UBL 2.1 for invoicing, and for the semantic model both UBL and CII implement see EN 16931. If your file is a UN/CEFACT Cross Industry Invoice rather than UBL, use the CII viewer.
Frequently asked questions
Is my invoice uploaded anywhere?
No. The file is read by your browser using the File API and parsed with the browser’s own XML parser. It is never sent to a server, never written to storage, and never included in any analytics. You can verify this by opening your browser’s network panel while you open a file — no request is made.
Which UBL versions are supported?
UBL 2.1 Invoice and CreditNote documents, which is what EN 16931, Peppol BIS Billing 3.0 and most European CIUS profiles are built on. UBL 2.0 and 2.2 documents will usually display correctly too, because the invoice elements this viewer reads are unchanged, but they are not a supported target.
Does the viewer depend on the cac: and cbc: prefixes?
No, and this matters more than it sounds. In XML a prefix is just a local alias for a namespace URI: a perfectly valid UBL invoice can use foo: and bar: instead. This viewer resolves every element by its namespace URI and local name, so any conformant document parses identically regardless of the prefixes its producer chose.
Does this tool tell me whether my document is valid?
This viewer confirms that the file is well-formed XML and that it is a UBL document, and it says so explicitly; the schema and rule layers are shown as “not run” here because a viewer does not execute them. To validate, use the UBL validator, which runs the OASIS XML Schema and the EN 16931 business rules and reports a verdict per layer.
What happens with a malformed file?
You get the parser’s own diagnostic, including the line and column of the first problem where the browser reports one, plus a suggestion of what usually causes it. Documents containing a DOCTYPE declaration are refused outright, because DTDs are the entry point for XXE and entity-expansion attacks and no legitimate invoice needs one.