Registered vs Unregistered Buyers on FBR Invoices: Registration Type, Further Tax and ATL Checks
Every FBR digital invoice must declare the buyer as Registered or Unregistered — and the declaration must match the buyer's actual FBR profile. What changes between the two (further tax, withholding, input-tax credit), and the checks that prevent errors 0053, 0070 and 0080.
One field, two legal treatments
The DI API accepts exactly two values in buyerRegistrationType: "Registered" or "Unregistered" (anything else fails with error 0012). A registered buyer is a sales-tax registered person with an active STRN buying B2B; an unregistered buyer is everyone else — walk-in consumers, businesses without sales tax registration, and B2C sales generally.
The declaration is not free text you choose — FBR validates it against the buyer's actual registration profile, and a mismatch rejects the invoice with error 0053. FBR's Get_Reg_Type reference service returns whether a given NTN/CNIC is Registered or Unregistered, and its STATL service reports active-taxpayer status, so the correct value can be looked up rather than guessed.
What changes when the buyer is unregistered
Further tax is the headline difference: for standard-rate goods sold to an unregistered buyer, further tax — commonly around 4% of the value excluding sales tax under the current notification — generally applies on top of the 18% sales tax, and the amount goes in the furtherTax field of the invoice line. Where it applies and is missing, FBR rejects with error 0080; sectors and schedules have exceptions, so the rate should always be confirmed against the current notification.
Withholding flips the other way: sales tax withheld at source is not allowed against unregistered buyers (error 0070) — the salesTaxWithheldAtSource field stays 0. Some sale types restrict unregistered buyers entirely: the cotton-ginners scenario is valid only against registered buyers (error 0100), and toll manufacturing requires steel-sector registered buyers (error 0056).
Identity formats and the placeholder question
Buyer identity must be a 7-digit NTN or a 13-digit CNIC with no special characters — wrong lengths fail with error 0002. For registered buyers the NTN is mandatory and must be the buyer's real, active registration, because their input-tax claim depends on the invoice being posted against it.
For unregistered consumers, the specification treats the buyer NTN/CNIC as effectively optional: retail B2C invoices are commonly posted with a placeholder value where no CNIC is collected (PRAL's own sandbox samples do this), while the buyer's name, province and address fields are still filled. A CNIC, where provided, is captured as the 13-digit number.
Why getting it right protects both sides
For the seller, the registration type drives the tax math — further tax charged or not, withholding allowed or not — so a wrong declaration produces a wrong total and often a rejection. Repeatedly invoicing a registered business as unregistered also burns the relationship: only an invoice posted against the buyer's NTN gives that buyer input-tax adjustment.
For the buyer, the stake is the input-tax credit itself, which is why registered buyers increasingly verify the IRN and QR on supplier invoices. A platform removes the guesswork: Digi Invoice stores each buyer's NTN/CNIC and registration type in a buyer register, checks formats before submission, and applies the further-tax and withholding rules that match the declared type — so the invoice that reaches FBR is consistent from the first field to the last.