How Sales Tax Is Calculated on an FBR Digital Invoice: The Formulas FBR Actually Validates
FBR recomputes the tax on every posted invoice line and rejects mismatches with errors 0102–0105. The exact formulas by sale type — standard 18%, 3rd Schedule retail price, fixed per-unit rates, composite rates — plus the rounding and decimal rules that make them pass.
FBR checks your arithmetic on every line
The Digital Invoicing API does not take the salesTaxApplicable figure on trust: for each item it recalculates the expected tax from the sale type, rate and base value, and rejects the line when the submitted number disagrees. The rejection family is specific — 0104 when value × percentage does not match, 0102 for 3rd Schedule retail-price goods, 0105 for quantity-based fixed rates, and 0103 for the composite Potassium Chlorate formula.
The base value depends on the schedule. Normal goods tax the transaction value in valueSalesExcludingST; 3rd Schedule (retail-price) goods tax the printed retail price in fixedNotifiedValueOrRetailPrice while valueSalesExcludingST is sent as 0. The two bases are mutually exclusive on a line — mixing them is the single most common cause of a calculated-tax mismatch.
The formulas by sale type
Standard-rate goods (18%): salesTaxApplicable = value excluding sales tax × 0.18, rounded to 2 decimals. Reduced-rate goods use the same shape with the notified percentage (1%, 5%, and so on). 3rd Schedule goods: retail price × rate ÷ 100 — the MRP, not your selling price, drives the tax. Exempt and zero-rated supplies simply carry 0 sales tax with the correct rate label ("Exempt" or "0%") and SRO reference where required.
Fixed per-unit rates skip percentages entirely: cement/concrete block at Rs.3 per unit and CNG at Rs.200 per unit compute quantity × rupees-per-unit — which is why quantity accuracy matters there. Potassium Chlorate is the composite case: (value × 18%) + (quantity in KG × Rs 60), with KG as the mandatory unit of measure.
Rounding, decimals and the fields around the tax
Two decimal places is the ceiling for monetary fields and four for quantity — exceeding either fails with error 0302, and negative, empty or non-numeric values fail with 0300. Round the computed tax to 2 decimals before submission; a fraction of a paisa left unrounded is enough to trigger a mismatch on high-value lines.
The neighbouring fields follow their own rules: further tax (commonly ~4% of value for unregistered buyers) and extra tax sit outside salesTaxApplicable, and extraTax must be an empty value for reduced-rate, exempt and similar non-standard categories (error 0091). Sales tax withheld at source must be 0 or exactly equal to the sales tax (0008), and rates carry conditions — the 5% rate, for instance, is not allowed where per-unit value exceeds Rs 20,000 (0079).
Worked examples that pass validation
A standard sale of Rs 100,000 excluding tax posts salesTaxApplicable 18,000.00. A 3rd Schedule product with MRP Rs 1,000 posts tax 180.00 against the retail price with valueSalesExcludingST 0. Twelve concrete blocks at the Rs.3 fixed rate post 36.00. One KG of Potassium Chlorate on a value of Rs 100 posts 78.00 — 18 from the percentage plus 60 from the per-kilogram component.
The practical lesson: the rate string, the base field and the formula must agree as a set, per line. Software that derives the tax from the selected sale type — instead of letting it be typed — eliminates the whole 0102–0105 family. Digi Invoice computes each line with the applicable formula and validates against the DI v1.12 rules before posting, so the arithmetic FBR checks has already been checked.