Federal and provincial
A Pakistani forwarder's invoice routinely carries a federal sales tax and a provincial one — PRA in Punjab, SRB in Sindh — each with its own rate and its own tax invoice number. An accountant's first question is never whether the software can print both. It is whether they land in the same account. They do not.
On the document
Sales tax appears on 5 of the 30 money-document screens — the local invoices for air export, sea export, air import, sea import and the mode-less Other Invoice. On the rest, the tax fields are not hidden or disabled: they are not on the document at all, because a credit note to a foreign agent, a payable, a refund, a quotation and a document receipt do not carry output tax.
A selector across PST, SST, PRA, SRB, ST and VAT — the vocabulary the trade already uses, rather than a single "tax" flag.
The rate, and a sales-tax invoice number that is its own field. It is deliberately not the invoice number: many houses run a separate S/Tax series, and forcing the two together is a common reason a system gets rejected.
The provincial tax, charged on the same subtotal beside the federal one, with a rate of its own and a third document number of its own.
Withholding, offered on every money document rather than only the sales ones — because it is a deduction on receivables and payables alike. What happens to it afterwards differs, and that is in the limits below.
Grand total = subtotal + sales tax + PRA fee + provincial tax − withholding. Each of those is stored twice: once in the invoice currency the customer signs, once in PKR at the document's own exchange rate.
Choosing PRA as the Tax Type zeroes the percentage and carries a configured fixed fee instead, folded into the amount the customer sees and never printed as a charge line of its own. That is a real client's standing rule, honoured in the code.
In the ledger
Finalising the invoice writes a journal voucher of its own, entirely in PKR. These are its legs, in the order they are built.
The invoice face less any withholding: what the customer will actually pay. Booking the withheld portion to receivable too would leave a balance nobody ever settles.
Only when the customer withholds. It is your recoverable advance tax, so it is an asset, not a receivable from them. Zero withholding writes no leg at all — a zero line is not a posting.
The subtotal, before tax. Output tax is money you are holding for a revenue authority and is never credited to income.
The federal tax, plus the PRA fixed fee where one applies.
The second tax, converted to PKR at the document's own rate, in a liability of its own — so what is owed to a provincial authority is never mixed with what is owed federally, and each can be remitted from its own balance.
Debits and credits are summed and compared to the paisa before the voucher may save; a voucher that does not balance is rolled back and reported as a fault rather than stored. Un-finalising deletes the voucher. A credit note posts every leg above in reverse.
If the document date falls inside a locked period the posting is refused outright, and the message names your Data Block Date and tells you to re-date the document or move the boundary.
On the return
Two of the 150 report screens exist for sales tax specifically, and both were built column-for-column against the register Pakistani forwarders already file from.
Sr. No., No., Date, Type, Inv. Type, Br., Name, S/Tax No., NTN No., PCS., Custom Clea., Service Charges and Amount — banded under PARTY/SUB-AGENT PARTY and SALE TAX the way the printed register bands them, and totalled on Custom Clea., Service Charges and Amount.
The same population grouped under each party, with NTN No./SalesTax No. in one column and the addition of SUB-AGENT PARTY, S.B. / GD No. and Value Incl. S/Tax.
S/Tax No. and NTN No. are read off the party master, where they sit beside Export Reg. No. and Import Reg. No. — one place, so a corrected registration number corrects every register.
Fiscal year, branch, date range, party range, invoice range, mode, sale tax type, a PRA-only switch, currency, and whether to run on invoice date or job date.
Voided and deleted documents never appear. They keep their numbers for the audit trail, but a cancelled document is not money and does not belong in a register you file from.
Every amount is converted to PKR at that document's own rate before it is added in, while the Currency column still shows what the invoice was raised in. A register never sums dollars and rupees one for one.
Fiscalisation
This part is real, and it is also narrower than the heading suggests. Both facts matter.
An invoice screen that posts to the PRA e-IMS fiscalisation service, with a payload following Chapter 6 of the PRAL POS Component manual: POS ID, USIN, buyer NTN and CNIC, per-item PCT code, tax rate, tax charged and totals. Sandbox and production endpoints are separate.
The fiscal invoice number, written onto the invoice with a sync status. Already-synced invoices are not re-sent, and a voided invoice is refused rather than transmitted.
A POS ID and an access token from PRA, held per company alongside the environment, the default PCT code, the default rate and the fixed fee. A company without a POS ID is refused before anything is sent, with a message that says so.
Every attempt writes a log against the invoice — environment, POS ID, endpoint, the request, the response, the code and the message — including the failures, which is the half you need when PRA rejects something.
Taxable value, tax, discount and gross for the month, broken down by rate, with synced and unsynced counts — and a CSV carrying Invoice No (USIN), party NTN, PRA status and the PRA fiscal invoice number.
These are the Invoicing module's own invoices, not the freight local invoices described above. They are separate document types today, the freight invoice is not sent to e-IMS, and — see below — the Invoicing module's invoices do not post to the ledger.
The limits
This section is the reason to believe the rest of the page. Every item here is a real gap, described accurately, and none of them is on a roadmap slide pretending to be finished.
No input-tax account, no purchase-tax register, no credit mechanism. A payable posts whole — debit Freight & Handling Cost, credit the Agent / Vendor Payable control — with nothing carved out of it. The system computes what you owe on your output; it says nothing about what you may claim on your input. If your return depends on the input side, that half is prepared outside this system.
The W.H.T % box is offered on every money document, but only the sales side books it, and it books it as an asset — Advance Income Tax (WHT Recoverable). Tax you withhold from a vendor is not credited to a withholding-payable account, so your liability to deposit it is not on the balance sheet.
System Configuration has a GST block with an account each for P.S.T, S.S.T, S.R.B and PRA. The freight invoice poster does not read it — it credits the two control accounts, 2300 and 2350. The split it makes is federal against provincial, not one account per province. Only the courier consignment posting reads a configured C/N Sales Tax code.
Following from the same split: where the Tax Type is PRA and the flat fee applies, that fee is credited to Sales Tax Payable (2300), not to the provincial liability (2350). Only an amount keyed into the 2nd Tax (PRA/SRB) fields reaches 2350.
The two import local invoices carry a block labelled "WHT Sales Tax % (Not included in Invoice Total)". It means it: the figure prints under the grand total on the invoice and is read nowhere else — no total, no posting, no ledger entry, no register.
Posting into and un-finalising inside a closed period are refused. Voiding a freight document is not held to that boundary, although the finance vouchers are. If you have filed a period, a void can still reach back into it.
The Invoicing module's own invoices — the ones that go to PRA e-IMS — do not post a journal voucher, and neither does a payroll run. Both are entered on the finance side.
There is no return-preparation or e-filing feature for FBR, PRA, SRB or anyone else. The registers and the ledger are working papers. The return is filed on the portal, by a person.
Straight answers
Yes. The primary Tax Type carries one and the 2nd Tax (PRA/SRB) selector carries the other. Each has its own rate and its own tax invoice number, both are charged on the same subtotal, and they credit two different liability accounts — 2300 Sales Tax Payable and 2350 Provincial Sales Tax Payable (PRA/SRB).
No. S/Tax Invoice No is a field of its own on the document, and the provincial tax carries a third number beside it. A house running a separate sales-tax series can keep doing so.
Posting into a closed period and un-finalising inside one are both refused, and the message names the Data Block Date and the fix. The exception is voiding a freight document, which is not held to that boundary today — it is a known gap, not a design.
No. You can produce the output side: the two sale tax registers, the two liability balances off the ledger, and a monthly PST report over the e-IMS invoices. There is no input tax, no purchase register and no filing. Anyone who tells you their system files your return should be asked to demonstrate it.
Next
If the tax treatment is what decides this for you, the demo is the shortest route: raise a local invoice with both taxes on it, finalise it, and read the journal voucher it wrote.