Why invoices fail NBR validation: four surprises from real testing
We ran a day of real invoices through the NBR validation program and then through the live NBR platform. Several invoices with correct amounts were still refused. These are the four causes worth knowing before you go live.
1. The buyer address, even on a till receipt
The validator requires the buyer's street, block, building, flat or shop number, city and country on every invoice, including simplified ones. A sale with only a first name fails with a postal address error. A standard walk-in customer address, with any real buyer name kept, solves it.
2. VAT that falls exactly between two fils
When taxable amount times the rate gives a result such as 0.7545, the question is which way to round. The validator rounds half to even (0.754). Rounding half up (0.755), as many accounting tools do, is refused. We confirmed the half-even result on the live platform.
3. Sums that are exact on paper but not in a computer
The validator adds line amounts using floating-point numbers and demands an exact match with the taxable amount. Binary arithmetic cannot represent most decimals exactly, so a correct invoice with many fractional lines can fail depending only on the order of its lines. Changing the order in which lines appear in the XML, without changing any amount, fixes it.
4. Buyer identifier schemes
In our testing the validator accepted only a short list of schemes for the buyer's identifier (IGA, GOVEN, CPRID, GCCID, OTH and SUBCRN) and refused the commercial registration scheme that appears in the NBR's own code list. Confirm the correct scheme with the NBR.
The lesson
Run every invoice through the NBR validation before sending, and show the exact rule message beside a failure. A dry run that never sends anything turns these surprises into a ten-second fix.