An invoice must have at least one line

Why it fires on invoices that look fine

Almost nobody hits this rule because they forgot the field exists. They hit it because something between their system and the document dropped it, changed its shape, or filled it with a value that is right somewhere else. These are the causes worth checking first.

• The document is a pure adjustment, expressed only as a document-level allowance or charge, with nothing at line level.
• All lines were filtered out upstream, typically because a zero-quantity or zero-amount filter ran before the export rather than after it.
• The invoice is a rounding or fee document produced by a process that thinks in totals rather than in lines.

What to change

• Give the document a line, even for a single fee. A line with a description, a quantity of 1 and an amount is a valid and readable invoice.
• Move any zero-value filter to after the export decision, or drop it. A zero-amount line is legal and is sometimes the whole point of the document.

The validator runs in your browser. Nothing is uploaded, and you can confirm that yourself with the network panel open.

Rules you are likely to hit next

A document that breaks BR-16 usually breaks one of these too, because the same mapping gap tends to affect neighbouring fields.

• BR-21: line identifier
• BR-24: line net amount

Questions people actually ask

What does BR-16 mean?

Every invoice has at least one invoice line, the group that carries what was actually sold and for how much.

Which field does BR-16 apply to?

BG-25, Invoice line. That is the name the semantic model uses, which is what you search for in your own system's mapping when the identifier alone does not tell you which field to look at.

Does our validator check BR-16?

Yes. Paste your invoice data into the free validator and it reports this rule with the value it actually saw, without the document leaving your browser.