Designing your own FBR sandbox test cases
FBR’s sandbox scenarios prove that your connection works. They do not prove that your invoices will. The test cases you design yourself, from your own sales, are what make the first live week quiet.
Answer first. Clear the scenarios FBR assigns, then test your own business. Take last month’s sales and pick real invoices that cover every product type, sale type, buyer type and branch you use. Add the invoices that should fail, and check that your team can see why. Then test two things the scenarios never touch: an invoice whose reply never arrives, and a busy day’s volume. Because FBR issues the production token automatically once your assigned scenarios pass, nobody else will ask you to do any of this. Your own test set is the only check between sandbox and live customers.
What FBR’s scenarios prove
FBR publishes test scenarios numbered SN001 to SN028. No business gets all 28. The set you get depends on the business nature and sector you chose when you enrolled, and it ranges from two scenarios for a service provider to fifteen at most. Each scenario is cleared by an invoice with the sale type it expects.
Passing them shows that your system can reach FBR, that your token works and that you can send each assigned sale type in the right shape. It does not show that your product list has the right HS codes, that your buyers’ numbers are valid, that your staff can handle a rejection, or that your system copes with a timeout. Those are the gaps your own cases fill.
One detail to remember: the scenario ID is required in sandbox and rejected in production. Your own test cases should carry it too, because they are going to the same sandbox.
Start from last month’s sales
The best test set is built from invoices you actually issued. Pull last month’s sales and choose:
- your twenty best-selling items, so the most common HS codes, units and rates are proven
- at least one invoice for every sale type you use, including those FBR did not assign
- a registered buyer, an unregistered buyer and a buyer identified by CNIC
- your largest invoice by value and your longest by number of lines
- one invoice from each branch, and each province you ship to
- anything unusual: a reduced-rate item under an SRO, a Third Schedule item sold at retail price, an exempt item
- a debit note against an earlier invoice, if you ever issue one
Finance should choose the invoices and say what the right tax treatment is. IT should send them. Your tax adviser should confirm the treatment for anything unusual before it becomes a pattern your system repeats on every live invoice.
Cases that should pass
For each case, write down what you send and what a correct result looks like. An invoice that is accepted with the wrong tax is not a pass.
| Case | What to send | Correct result |
|---|---|---|
| Standard-rate goods | A common item to a registered buyer | FBR number returned; tax matches your books |
| Unregistered buyer | The same item to a buyer with no NTN | Accepted with the treatment your adviser confirmed, including further tax where it applies |
| Reduced rate | An item taxed under an SRO | Accepted with the SRO number and the item’s serial in that SRO |
| Retail price item | A Third Schedule item | Accepted with tax worked out on the printed retail price |
| Mixed invoice | Standard, reduced and exempt lines together | Every line returns clean, not only the invoice as a whole |
| Long invoice | Your longest real invoice | All lines accepted; totals match |
| Other branch or province | An invoice from each origin | Province sent as a province, not a city; rate correct |
| Debit note | A note against a test invoice | Accepted, carrying the original FBR invoice number and a reason |
| Validate only | Any invoice through the validate method | Same checks, no FBR number, nothing filed |
Cases that should fail
Failures are where teams learn the most, and they are cheap in sandbox. Send each one on purpose and check two things: FBR rejects it, and the person who will fix it can see the reason without calling a developer.
| Send this | FBR’s message | The lesson |
|---|---|---|
| A buyer’s STRN pasted into the NTN field | Invalid Buyer Registration No or NTN | Clean buyer numbers before they reach invoices |
| A goods HS code with a services sale type | HS Code that does not match with provided sale type | Take both from FBR’s lists, not from memory |
| A unit your product list uses but FBR does not allow for that code | Unit of measurement not allowed for this HS code | Units come from FBR’s lookup, and they are case-sensitive |
| The city “Karachi” as the province | Provide Sale Origination Province of Supplier | Send provinces, not cities |
| Date as 01/10/2026 | Provide invoice date in YYYY-MM-DD format | Convert dates before sending |
| Invoice number INV/2026/001 | Alphanumeric and (-) contained invoice No | Letters, digits and hyphens only |
| A zero in a tax field that does not apply | Extra tax must be empty | “Not applicable” is blank, not 0 |
| A reduced rate with no SRO serial | Provide Item Sr No | Store the SRO and serial with the product |
| A note pointing to your own invoice number | Reference Invoice does not exist | Keep FBR’s number against every invoice |
| A branch transfer with the same seller and buyer | Self-invoicing not allowed | Filter internal movements out before sending. Under STGO 25 of 2026, goods moved to your own warehouse under the same STRN travel with a stock transfer note, not an e-invoice |
FBR adds and renumbers its error codes, so judge each case by the message text. Our error code guide lists what each message means.
The lost reply test
This is the test teams skip most often, and the one that causes the most expensive live problem. Sometimes FBR records an invoice but the reply never reaches you, because of a timeout or a dropped connection. FBR does not reject a second copy of an invoice it already has. If your system simply sends it again, you now have two live invoices, and cancelling one uses part of a monthly allowance shared by every edit and cancellation.
So in sandbox, cut the connection on purpose while an invoice is being sent. Then check what your system does. The right behaviour is to mark the invoice as unknown and check whether FBR has it before trying again. If your system resends without asking, fix that before go-live. eInvoicePro’s API accepts an idempotency key so a retry after a timeout on your side is recognised as the same invoice, and it keeps the invoice in a status your team can see.
The busy day test
A system that handles ten test invoices may not handle your busiest day. Send a realistic peak through sandbox: a month-end run for a distributor, an evening rush for a retailer, a file of several hundred invoices for a bulk user.
Watch three things. How long the whole run takes. Whether one failed invoice holds up the rest. And whether the person on duty can find the failures in the middle of the run. FBR expects each invoice to be sent on its own, so the real question is how your process copes with hundreds of single answers.
The switch to live
Go-live failures often happen at the switch itself rather than in the invoices. Test the switch like any other case:
- The production token belongs to the right registration. Another entity’s token fails as an access error.
- The scenario ID is gone from live invoices. It is rejected in production.
- The whitelisted IP is the one your live system sends from.
- Your system points at the production address, and test invoices can no longer reach it by mistake.
- The first live invoices are checked by a person, one by one, before volume is opened up.
The evidence pack
Keep the results in one place. For each case, store what was sent, what came back and who checked it. The pack is useful three times: for the go-live decision, for training new staff, and when your tax adviser or auditor later asks how the setup was proven.
A simple rule for the go-live meeting: if any case in the failure table could not be read and fixed by the person who will do it live, you are not ready yet.
FAQs
How many sandbox scenarios does FBR assign? Between two and fifteen, depending on the business nature and sector chosen at enrolment. FBR publishes SN001 to SN028, but no business gets all 28. A service provider selling services clears two.
Why test more than FBR’s scenarios? Because FBR issues the production token automatically once your assigned scenarios pass. The scenarios prove your connection works. They say nothing about whether your products, buyers and staff are ready.
Do our own test invoices need a scenario ID? Yes, while they go to the sandbox. The scenario ID is required in sandbox and rejected in production, so remove it at the switch to live.
What is the lost reply test? Cutting the connection while an invoice is sent, then checking that your system marks it as unknown and checks with FBR before resending. FBR does not block duplicates, so a blind resend can file the invoice twice.
Can we check an invoice without filing it? Yes. FBR’s validate method runs the same checks on the same invoice and returns the same errors, but issues no number and files nothing.
Related reading: sandbox to go-live, FBR error codes and what to store once FBR answers.
Ready to simplify your FBR digital invoicing?
Join 2000+ businesses that use eInvoicePro to make invoices and send them to FBR.