Subject:Escalation & Feature Request: Third Schedule (FBR) Retail-Price-Based Sales Tax Support in D365 F&O and Commerce

Dear Microsoft Team,

We are writing to formally escalate a product gap in Dynamics 365 Finance & Operations (including Commerce/POS) that is preventing us from meeting a statutory tax compliance requirement mandated by Pakistan's Federal Board of Revenue (FBR). Despite previous support engagement, this issue remains unresolved, and it is currently affecting our ability to comply with local law. We are requesting that Microsoft review this and consider incorporating native support for this requirement into the product.

BACKGROUND OF THE ISSUE

Under the Third Schedule of the Sales Tax Act, 1990, certain goods are required to be taxed at 18% sales tax calculated on the item's retail price, rather than on the transaction value (purchase price on procurement, or the discounted selling price at the point of sale). This is a legal requirement, not a business preference, and applies specifically to goods listed in the Third Schedule (a category that FBR periodically updates through Finance Acts and Sales Tax General Orders).

We have found that D365 Finance & Operations, and Commerce/POS, do not currently support this out of the box:

1. Purchase Orders: Sales tax calculation methods available on the Sales Tax Code (Origin field: Percentage of net amount, Percentage of gross amount, Amount per unit, etc.) all calculate tax based on the transaction's own line amount. There is no native way to base the tax calculation on a separate retail price field rather than the purchase price.

2. Commerce POS: Sales tax at the point of sale is calculated on the net amount after any discount is applied. There is no native option to calculate tax on the original retail price when a discount or promotional offer is applied to the selling price, which is what FBR's rule requires for Third Schedule items.

As a result, we are currently unable to correctly calculate and report Third Schedule tax through standard system functionality, and are having to evaluate custom development to work around this gap.

BUSINESS AND COMPLIANCE IMPACT

- We are at risk of incorrect tax calculation and reporting to FBR for all Third Schedule items we purchase and sell.

- FBR is currently actively enforcing retail price and tax visibility requirements on Third Schedule goods (per recent Sales Tax General Orders), which increases our exposure if this is not resolved.

- We are being forced to pursue custom X++ and Commerce Runtime development to address a requirement that we believe should be part of standard localization functionality for markets with retail-price-based tax rules.

DETAILS OF THE THIRD SCHEDULE REQUIREMENT (FOR YOUR REFERENCE)

- Legal basis: Section 3(2)(a) and the Third Schedule of the Sales Tax Act, 1990 (Pakistan)

- Applicable goods: A defined list of goods (currently including items such as fragrances/perfumes, and periodically expanded by FBR — for example, additional categories were added under the Finance Act 2025)

- Tax treatment: 18% sales tax, calculated on the retail price printed on the product, not on the purchase price or any discounted/promotional selling price

- Enforcement: FBR requires the retail price and applicable tax to be clearly printed/reflected at the point of sale and on packaging, and has issued recent Sales Tax General Orders (STGO 8 and 9 of 2026) reinforcing enforcement of this requirement

- Practical implication for ERP systems: the tax calculation engine must be able to use a price reference other than the transaction's own line amount, and must be able to ignore point-of-sale discounts when calculating tax for these specific items

REQUEST TO MICROSOFT

We would appreciate it if Microsoft could:

1. Confirm whether there is an existing supported way to configure tax calculation based on a reference price (such as retail price) independent of the transaction/discounted amount, in either the classic Sales Tax engine or the Tax Calculation Service, that we may not be aware of.

2. If no such option currently exists, log this as a product gap/feature request for the Pakistan localization (and potentially other markets with similar retail-price-based tax regimes, such as certain GCC or South Asian jurisdictions).

3. Advise on the recommended supported approach if custom development is currently the only path, including any guidance on the correct extension points in both the F&O tax engine and Commerce Runtime (CRT), so that our implementation remains upgrade-safe and aligned with Microsoft's architecture.

4. Provide an estimated timeline, if this is accepted as a roadmap item, so we can plan our interim compliance approach accordingly.

We are happy to provide further documentation, sample transactions, or a call with our functional and technical teams to walk through the exact scenarios if that would help Microsoft's product and localization teams assess this properly.

We appreciate your attention to this matter given the compliance risk involved, and look forward to your response.

Regards

Rafaqat Ali

Rafum Group