In brief: the direct answer
Line structure, allowances, charges and the line total, and how a small line error becomes a large total error. Invoice lines is best approached through lines as the arithmetic core. For invoice lines, the line quantity, price and allowance decides the outcome. For invoice lines, the line quantity, price and allowance missing means rejection. For invoice lines, the line quantity, price and allowance wrongly mapped means wrong meaning. This guide keeps returning to one check for invoice lines: recalculate one line by hand before trusting the total.
The route stage for invoice lines is Create. At Create, the line quantity, price and allowance is what follows next. For invoice lines, a Create decision cannot be repaired later. For invoice lines, a Create decision cannot be repaired cheaply. Check the line quantity, price and allowance for invoice lines before moving on.
The record at this stage
Follow the invoice as a record through invoice lines. At Create, the record for invoice lines carries the line quantity, price and allowance. Answer the line quantity, price and allowance for invoice lines with evidence. Then the rest of invoice data fields and master data becomes easier. Then the rest of invoice lines becomes easier to check.
Describe the record before the system for invoice lines. Systems change, but the line quantity, price and allowance for invoice lines stays. Providers change, but the line quantity, price and allowance for invoice lines stays. Formats change, but the line quantity, price and allowance for invoice lines stays. For invoice lines, ask what record a system produces. For invoice lines, ask what record a system accepts. For invoice lines, ask what status evidence it returns.
What the data must carry
The data that matters most for invoice lines is the line quantity, price and allowance. That is not a slogan for invoice lines. It is what the next invoice lines check looks at. If the line quantity, price and allowance for invoice lines is missing, expect rejection. If the line quantity, price and allowance for invoice lines is ambiguous, expect rejection. If the line quantity, price and allowance for invoice lines is wrongly formatted, expect rejection.
Check the line quantity, price and allowance as the receiver reads invoice lines. For invoice lines, screen correctness is not enough. For invoice lines, file correctness is not enough. For invoice lines, mapping correctness matters too. Use the mapping table for invoice lines first. Use the receiver test for invoice lines second. Use a sample invoice for invoice lines third.
Validation and evidence
For invoice lines, validation has three gates. Invoice lines structure comes first. Invoice lines business rules come second. Invoice lines receiver rules come third. Each invoice lines gate has its own failure message.
A invoice lines rejection should name its rule. A invoice lines rejection should name its field. A invoice lines rejection should name the value sent. A invoice lines rejection should name the value expected. Without those facts, a invoice lines rejection is a delay. Return a invoice lines rejection with that request.
Evidence for invoice lines is what remains afterwards. Keep the invoice lines invoice as exchanged. Keep invoice lines status messages with it. Keep any invoice lines correction linked to it. An auditor for invoice lines asks for that set.
Where it breaks, and the check to make first
The common invoice lines break is simple. For invoice lines, recalculate one line by hand before trusting the total was skipped. For invoice lines, the receiver found the problem. For invoice lines, the sender must now correct it. For invoice lines, the sender must resend it. For invoice lines, the sender must explain it.
Illustration, with round numbers only, for invoice lines: A seller sends 10 invoices for invoice lines. 2 fail on the line quantity, price and allowance for invoice lines. Checking the line quantity, price and allowance first for invoice lines costs minutes. A invoice lines receiver rejection costs days. Sometimes a invoice lines rejection costs a payment cycle. That is why invoice lines repeats one check: recalculate one line by hand before trusting the total.
What to verify before acting
Before acting on invoice lines, verify three things. First, jurisdiction and transaction for invoice lines. First, buyer and country for invoice lines. Second, European Commission: Compliance with the eInvoicing standard for invoice lines today. Third, the invoice lines buyer requirement in writing.
A guide on invoice lines organises those questions. A guide on invoice lines cannot answer a specific transaction. This guide on invoice lines gives general information only. This guide on invoice lines is not advice for a specific invoice. For a specific invoice about invoice lines, check European Commission: Compliance with the eInvoicing standard. For a specific question about invoice lines, ask a qualified adviser.
How this guide is layered
Every guide on this site is read through the same twelve layers, in the order that fits its topic: obligation, data, format, network, validation, tax, accounting, lifecycle, evidence, direct intent, transaction, jurisdiction. The layers are a reading method, not a claim about any single system.
Evidence basis: Primary sources named in the sources section, checked 2026-10-27; country guides are dated research routes, not mandate calendars. Scope: General educational information only; no individual legal, tax, accounting or compliance advice; jurisdiction and transaction specific checks remain with the reader.
Related guides
- Invoice data fields and master data: the complete field guide - Parties, lines, totals, references and identifiers, and the master data that keeps them consistent across systems.
- Totals, tax and payable amounts: the arithmetic chain - Net, tax, allowances, charges and payable, in the order a validation rule checks them.
- References: orders, contracts and delivery notes - How references tie an invoice to the transaction that created it, and why a missing reference blocks matching.
Back to the pillar guide: Invoice data fields and master data: the complete field guide.
In this topic
- Invoice data fields and master data: the complete field guide
- Dates on an invoice: issue, supply and due
- Field mapping that survives change
- Master data governance for invoicing
- Payment terms and bank details on an invoice
- Product and service coding on invoice lines
- References: orders, contracts and delivery notes
- Seller and buyer party fields: identifiers that must match
- Tax identifiers and VAT numbers on an invoice
- Totals, tax and payable amounts: the arithmetic chain
Primary sources and further reading
These official resources support the standards and regulatory context. Check their current versions before implementation.
- European Commission: Compliance with the eInvoicing standard - Semantic model and UBL/CII syntax bindings
- OpenPeppol: Peppol BIS Billing 3.0 - Billing profile, information elements and validation