Why FBR invoices get rejected, and how to avoid it

An FBR digital invoicing rejection is not mysterious. FBR's API returns a specific status code and a plain-language message for exactly what failed, right down to the item line. Most rejections cluster around a small set of causes, and once you know them, they are straightforward to avoid.

Buyer registration details do not match

This is the single most common category. FBR checks the buyer's NTN or CNIC and registration type against its own records, and a mismatch is rejected outright: an unregistered buyer marked as registered, a registration number in the wrong format, or simply an empty field where FBR expects one. If your invoice form lets buyer details be entered freely rather than validated against a known format, this is where it shows up.

Missing or invalid HS code

Every line item needs a Harmonized System code, and FBR's validation rejects an invoice with a missing or malformed one immediately, this is treated as seriously as a missing tax rate. It is also the error most likely to surface only after your product catalogue has been in use for a while, if a product was added without one, every invoice using it fails the same way until the product record is fixed.

Tax rate does not match what FBR expects for that HS code

The tax rate on a digital invoice is not free text you type in, FBR checks it against the rate its own reference tables associate with the item's HS code and sale type. Picking the right HS code but the wrong rate, or leaving the rate blank, produces a rejection even though the invoice looks complete to a human reading it.

Invoice date not in the exact format FBR expects

Dates have to be in YYYY-MM-DD format specifically. A date that is technically valid but formatted differently, day-month-year, or with slashes instead of dashes, is rejected as an invalid date rather than silently reinterpreted. This is a small thing that catches out custom or in-house integrations more often than established software, where the format is already fixed.

Required sales figures left blank

Several numeric fields are mandatory even when their value is genuinely zero: sales tax applicable, the value of sales excluding tax, quantity. Leaving them empty is treated differently from entering a zero, an empty field is a validation failure, a zero is a valid number FBR can work with.

The pattern underneath all of these

Every one of these is a data problem, not a conceptual one. Nobody is confused about what a debit note is or why digital invoicing exists, the invoice fails because one field was empty, one code was missing, or one date was formatted differently than FBR expects. That is exactly the kind of error that disappears when invoice creation validates the data before it ever reaches FBR, rather than after.

General information, not tax advice. Error codes and messages are FBR's own and may be updated by FBR from time to time.