Pakistan Digital Invoicing Solution (for Manager.io Users)

the cause of error is due to one invoice having multiple items. i deleted all items leaving only one and error is resolved. i think system is not accepting one invoice with multiple items.

Firstly, great work on the current functionality — it’s quite efficient. However, I would like to suggest a small but impactful improvement for user convenience.

I believe it would be ideal to introduce a dropdown list for HS Codes, since these are predefined and limited in number. This would prevent input errors and streamline data entry.

Additionally, once a specific HS Code is selected, the relevant Unit of Measurement (UOM) should be automatically populated based on that selection. This would further ease the process for users, especially during data entry at both the item stage and the invoice line level.

This enhancement would not only improve accuracy but also enhance the overall user experience.

System accepting multiple item invoice.

2 Likes

Thanks to the valuable clarification provided by @Mabaega the concept is now much clearer.

In order for the system to accept multiple invoice items, each item must have a unique HS Code. If two or more items share the same HS Code, they should be combined into a single invoice line rather than listed separately.

This distinction is important to ensure smooth validation and compliance with the system’s logic.

Appreciate the guidance, and I hope this helps others who might face similar confusion.

Thanks for clarification

1 Like

here is complete excel file containing each and every hs code along with corresponding UOM
https://e.fbr.gov.pk/SOP/IRIS/ST_AnnexH_Template.xlsm

@Mabaega
One more important observation:

The FBR Extension currently does not honor the “Tax Inclusive” checkbox during invoice entry. When we enter the unit price and check the “Tax Inclusive” box, the expectation is that the extension should treat the entered price as already inclusive of tax.

However, what’s happening instead is that the extension still fetches the same unit price and adds tax on top of it, which results in an inflated invoice total when submitting to FBR.

Yes, the extension currently does not support tax-inclusive pricing. I plan to add this capability in a future update.

Regarding HS Codes, since there are over 10,000 entries, including them all in a combo box would be inefficient and could affect performance. HS Codes only need to be entered once—when creating the inventory item. Users can type the HS Code manually at that point. There’s no need to re-enter or modify the HS Code or Unit of Measure (UOM) when creating invoices, as these values will automatically populate based on the selected inventory item.

It is important for users to understand how to configure Manager to align with FBR invoice requirements. This includes understanding transaction types, when to use Sro Schedule Numbers, when to use Sro Serial Numbers, and how tax should be applied for each transaction and item type.

1 Like

ok perfect. But what about when user just have to enter invoice line not using inventory items?

It’s not a problem, the conversion will use the HS Code from the invoice line if it’s not set on the inventory item. However, entering HS Code and UoM directly on the invoice line is not efficient.

Ideally, HS Code and UoM should not even be displayed during invoice creation, but they must still be shown in the invoice view.

The FBR Extension has been updated to support invoice conversion with tax-inclusive pricing.
You can try it now.

However, please note that you may notice differences between the invoice values in Manager and those in the FBR invoice. This is because FBR invoices only support integer values for Quantity and SalesTax, whereas Manager allows decimal values for SalesTax.

2 Likes

{
“success”: false,
“data”: {
“dated”: “2025-07-24 00:34:58”,
“validationResponse”: {
“statusCode”: “01”,
“status”: “Invalid”,
“errorCode”: null,
“error”: “”,
“invoiceStatuses”: [
{
“itemSNo”: “1”,
“statusCode”: “01”,
“status”: “Invalid”,
“errorCode”: “0104”,
“error”: “Provided sales tax amount does not match the calculated sales tax amount. Please ensure that the provided Sale Value is used to calculate the Sales Tax Amount for the provided Rate.”
},
{
“itemSNo”: “2”,
“statusCode”: “01”,
“status”: “Invalid”,
“errorCode”: “0104”,
“error”: “Provided sales tax amount does not match the calculated sales tax amount. Please ensure that the provided Sale Value is used to calculate the Sales Tax Amount for the provided Rate.”
}
]
}
},
“message”: “Validation failed, please review the server response for details”
}

iam getting this error

on this JSON
{
“invoiceType”: “Sale Invoice”,
“invoiceDate”: “2025-07-24”,

“sellerProvince”: “PUNJAB”,
“sellerAddress”: “Lahore”,
“buyerAddress”: “Lahore.”,
“buyerRegistrationType”: “Registered”,
“invoiceRefNo”: “”,
“scenarioId”: “SN001”,
“items”: [
{
“hsCode”: “3004.9099”,
“productDescription”: “”,
“rate”: “18%”,
“uoM”: “KG”,
“quantity”: 2,
“totalValues”: 77288.14,
“valueSalesExcludingST”: 77288.14,
“fixedNotifiedValueOrRetailPrice”: 0,
“salesTaxApplicable”: 13912,
“salesTaxWithheldAtSource”: 0,
“extraTax”: 0,
“furtherTax”: 0,
“sroScheduleNo”: “”,
“fedPayable”: 0,
“discount”: 0,
“saleType”: “Goods at standard rate (default)”,
“sroItemSerialNo”: “”
},
{
“hsCode”: “7326.9070”,
“productDescription”: “”,
“rate”: “18%”,
“uoM”: “KG”,
“quantity”: 1,
“totalValues”: 33898.31,
“valueSalesExcludingST”: 33898.31,
“fixedNotifiedValueOrRetailPrice”: 0,
“salesTaxApplicable”: 6102,
“salesTaxWithheldAtSource”: 0,
“extraTax”: 0,
“furtherTax”: 0,
“sroScheduleNo”: “”,
“fedPayable”: 0,
“discount”: 0,
“saleType”: “Goods at standard rate (default)”,
“sroItemSerialNo”: “”
}
]
}

in my test system is accepting decimal value upto 2 points in sales tax field.

“items”: [
{
“hsCode”: “3004.9099”,
“productDescription”: “”,
“rate”: “18%”,
“uoM”: “KG”,
“quantity”: 2,
“totalValues”: 77288.14,
“valueSalesExcludingST”: 77288.14,
“fixedNotifiedValueOrRetailPrice”: 0,
“salesTaxApplicable”: 13911.87,
“salesTaxWithheldAtSource”: 0,
“extraTax”: 0,
“furtherTax”: 0,
“sroScheduleNo”: “”,
“fedPayable”: 0,
“discount”: 0,
“saleType”: “Goods at standard rate (default)”,
“sroItemSerialNo”: “”
},
{
“hsCode”: “7326.9070”,
“productDescription”: “”,
“rate”: “18%”,
“uoM”: “KG”,
“quantity”: 1,
“totalValues”: 33898.31,
“valueSalesExcludingST”: 33898.31,
“fixedNotifiedValueOrRetailPrice”: 0,
“salesTaxApplicable”: 6101.70,
“salesTaxWithheldAtSource”: 0,
“extraTax”: 0,
“furtherTax”: 0,
“sroScheduleNo”: “”,
“fedPayable”: 0,
“discount”: 0,
“saleType”: “Goods at standard rate (default)”,
“sroItemSerialNo”: “”
}
]
}

(post deleted by author)

I can also reproduce this issue in sandbox and live production.

According to the Guide, the JSON data type for both Quantity and SalesTax is int. Therefore, I applied standard rounding (round to the nearest whole number), and this works well for some invoices. However, the rounding method might be the root of the issue. We may need to consider using RoundUp, RoundDown, or simply truncate the value without rounding, depending on which approach aligns best with FBR’s validation rules.

We have also found an inconsistency in the guide, where the ExtraTax field works correctly as a Double for certain ScenarioIDs, but for other ScenarioIDs, it requires the ExtraTax to be in String format.

            "itemSNo": "1",
            "statusCode": "01",
            "status": "Invalid",
            "invoiceNo": 0,
            "errorCode": "0300",
            "error": "Decimal value is not valid at item 1 for ExtraTax"

To confirm this, it would be best if someone could manually create the same invoice on the FBR Portal and inspect the generated JSON file. This would help us understand exactly how the FBR handles rounding and formatting of values such as Quantity and SalesTax.

For now, I have reverted the SalesTaxApplicable value back to 2 decimal digits. Let’s try again and see how it behaves.

Yes it is working now today i will check with more examples and let you know.

1 Like

Hi @Mabaega and team,

I believe it’s time we consider implementing support for the salesTaxWithheldAtSource field in the FBR integration. This feature is crucial for vendors working with government departments.

In practice, government clients often withhold 1/5th or 1/10th of GST when processing payments, depending on the applicable rules and thresholds. Capturing this in the invoice submission is essential to reflect accurate tax liability and reconciliation.

Adding support for this field would significantly benefit those working in the public procurement domain, ensuring better alignment with actual payment practices and compliance reporting.