0102·Calculated tax does not match for 3rd Schedule goods
What this means
Third Schedule goods are taxed on the printed maximum retail price, not on the price you actually sold at. FBR recomputes the tax from the retail price you submitted and rejects the line when your figure disagrees. The rejection is arithmetic, not judgement — it means your two numbers are inconsistent with each other.
Why it happens
- Sales tax was computed on the discounted or negotiated selling price rather than the printed MRP.
- The retail price field was populated with the unit MRP instead of MRP multiplied by quantity. FBR applies the rate directly to the value in that field, so a per-unit figure understates the tax on any line with quantity above one.
- Both value fields were populated. On a Third Schedule line the excluding-tax sales value should be zero, because the retail price field carries the taxable base instead.
- The item is classified as Third Schedule in your system but priced as a standard-rate good, or the reverse.
- Rounding was applied at a different stage than FBR applies it, leaving a paisa-level difference that still fails an exact comparison.
How to fix it
- 1Set the excluding-sales-tax value to 0 on Third Schedule lines.
- 2Set the fixed notified value or retail price field to the printed MRP multiplied by the line quantity — this is a line total, not a unit price.
- 3Compute sales tax as the rate applied to that line total, and round to two decimal places.
- 4Confirm the sale type string is exactly the Third Schedule label rather than the standard-rate default.
- 5Re-run the line through the validate endpoint before posting, so a mismatch costs you nothing.
Payload example
{
"quantity": 100,
"valueSalesExcludingST": 85000.00,
"fixedNotifiedValueOrRetailPrice": 1000.00,
"salesTaxApplicable": 15300.00,
"saleType": "3rd Schedule Goods"
}{
"quantity": 100,
"valueSalesExcludingST": 0.00,
"fixedNotifiedValueOrRetailPrice": 100000.00,
"salesTaxApplicable": 18000.00,
"saleType": "3rd Schedule Goods"
}MRP is Rs 1,000 per unit and quantity is 100, so the retail price field carries 100,000 and tax is 18% of that. Selling below MRP does not reduce the tax.
How Ordyoo handles this
Ordyoo's invoice engine branches on sale type at the line level, so Third Schedule items are taxed on MRP × quantity by construction and the transaction value never enters the tax base. MRP is inherited from the supplier's classification, which prevents a distributor override from drifting out of sync with how the manufacturer registered the item.
Scenarios where this appears
Sandbox scenarios that commonly produce 0102.
Related errors
Stop debugging FBR payloads by hand
Ordyoo builds and submits compliant invoices so most of these rejections never reach you. Start free.
