FBR Digital Invoicing Error Codes: The Complete Reference (0001–0402)
Every rejection code the FBR Digital Invoicing API can return on a sales invoice — what each code means, why it fired and how to fix it. Format errors, debit note rules, tax calculation mismatches, SRO requirements and token failures, organised the way PRAL's own error guide defines them.
How FBR reports an error
Every response from the Digital Invoicing API carries a validationResponse with a statusCode: 00 means Valid, 01 means Invalid. Errors surface at two levels. An invoice-level failure (a bad header field such as the seller registration or the date) returns errorCode and error text at the top with invoiceStatuses set to null. An item-level failure returns statusCode 00 or 01 per line inside invoiceStatuses, so a five-item invoice can pass four lines and reject one — the whole invoice still fails to post until that line is fixed.
The error text FBR returns is short and often generic, which is why the four-digit code matters more than the message. The sections below group the sales-module codes the way they fail in practice: identity and format, invoice type and sale type, debit notes, SRO and schedule requirements, tax calculation, and authorisation.
Identity, format and date errors
0002 and 0108 — buyer or seller registration number is not in the proper format: an NTN must be 7 digits and a CNIC 13 digits, with no dashes or special characters. 0010 — buyer name is missing. 0012 and 0053 — buyer registration type must be exactly Registered or Unregistered and must match the buyer's actual FBR profile (verify through the Get_Reg_Type reference API). 0082 fires when the seller's registration number does not belong to a sales-tax-registered person at all.
Dates have three codes of their own: 0042 (date missing), 0043 (date in the future) and 0005/0113 (wrong format — the API accepts YYYY-MM-DD only). 0058 rejects self-invoicing: the buyer and seller NTN/CNIC cannot be the same. 0088 and 0173 govern the invoice number format — alphanumeric with hyphens between segments, such as Inv-001, never a leading or trailing hyphen.
Sale type, HS code and unit-of-measure errors
0003 and 0109 — the invoice type must be Sale Invoice or Debit Note exactly as the doctypecode reference API spells it. 0007, 0013 and 0092 — the sale type is missing or not valid for the seller's registered business activity and sector; 0093 specifically blocks manufacturers from posting Non-Adjustable Supplies. 0019, 0044 and 0052 cover the HS code: missing, invalid, or not permitted for the chosen sale type (steel HS codes only work with steel sale types, for example).
Units of measure carry their own family: 0099 means the UoM does not match the HS code (look up the allowed list via the HS_UOM reference API), 0062 requires MT for steel melting and re-rolling, 0097 requires KG for Potassium Chlorate, 0096 allows only KWH for electricity HS codes, and 0060/0061 pin services rates like 50/SqY or 200/bill to their specific units. 0020 and 0046 fire when the rate is empty or does not exist for the selected sale type on the invoice date — rates must come from the SaleTypeToRate reference API, not typed by hand.
Debit note errors (0026–0067)
Debit notes validate against the original invoice. 0026 — the invoice reference number is required: 22 digits when the original was NTN-based, 28 when CNIC-based. 0057 — that reference does not exist in FBR's system. 0027 and 0028 — a reason is mandatory, and remarks become mandatory when the reason is Others. 0029 and 0035 — the note date cannot be earlier than the original invoice date, and 0034 caps the window at 180 days from the original.
The value caps close the family: 0036 and 0067 reject a note whose quantity, sale value or sales tax exceeds the referenced invoice, and 0064 blocks a debit note against an invoice that already has a credit note attached. The practical fix for all of these is the same — pull the original invoice's figures and dates first, then build the note within those limits.
SRO, schedule and tax-calculation errors
Any rate other than the standard 18% needs its legal reference: 0077 demands a valid SRO or schedule number and 0078 demands the item serial within it — the two always travel together. 0090 requires the fixed/notified retail price for 3rd Schedule goods, and 0091 is the best-known code in the family: extra tax must be empty (not zero, not a number) for reduced-rate, zero-rated, exempt and non-adjustable supplies. 0079 blocks the 5% rate where the per-unit value exceeds Rs 20,000, and 0098 rejects goods lines with no quantity.
The calculated-tax quartet compares your salesTaxApplicable against FBR's own arithmetic: 0104 for value × percentage, 0102 for 3rd Schedule retail-price × rate, 0105 for quantity × fixed per-unit rupees, and 0103 for the Potassium Chlorate composite of 18% plus Rs 60 per KG. 0008 and 0050 require sales tax withheld at source to be either 0 or exactly equal to the sales tax. 0300 rejects negative, empty or non-numeric values in any numeric field, and 0302 rejects more than 2 decimal places on money or 4 on quantity.
Token and authorisation errors (0401, 0402)
0401 and 0402 mean the seller's or buyer's NTN/CNIC has no valid authorised access token — the bearer token is missing, expired, revoked, or belongs to the wrong environment. PRAL tokens are issued per environment (sandbox and production are separate) and are valid for five years; the token itself decides which environment the invoice lands in, regardless of the URL used.
Software that validates against these rules before posting turns most of this list into a non-event. Digi Invoice checks registration formats, sale-type and HS-code compatibility, SRO pairing, extra-tax handling and every tax formula locally, then shows a plain-English decoded explanation for anything FBR still rejects — including the exact code, cause and fix.