Designing your own FBR sandbox test cases

Your own cases sit on top of the ones FBR assigns

FBR allocates a set of test scenarios you must clear before production credentials are issued — how many depends on your business nature and sector, and it is never all 28. Clearing those proves the connection works. Everything below proves your business is ready, which is a different question. See the sandbox guide for how allocation works.

Why one “happy path” invoice is not enough

Teams that submit a single clean sandbox invoice often feel ready. Then live week one arrives with mixed tax lines, a walk-in buyer without a clean NTN, a credit note, and a peak-hour spike — and the process breaks.

Sandbox quality predicts live quality. Your test set should look like a busy week of real selling, not a demo script. Finance should own the invoice patterns; IT should own environments and credentials; your tax advisor should confirm that the patterns you are testing match the obligations you actually have.

Scenario checklist: data and tax patterns

Work through each item until someone can show evidence, not just say “done”:

• Buyer NTN / CNIC quality — valid formats, inactive or wrong identifiers caught before submission
• Unregistered / incomplete buyer cases — whatever your advisor says applies for your channel
• Standard-rated and exempt lines — including mixed carts if you sell them
• Credit and debit notes — if you issue them in production, test them in sandbox
• Product / HS or tax category mapping — especially after ERP or POS catalogue changes
• Branch or location differences — if counters or plants invoice differently

If a pattern is rare but high-risk (exports, special rates, large B2B corrections), include at least one deliberate sample.

Scenario checklist: failures, ownership, and proof

Passing invoices are only half the story. Before go-live, confirm:

1. Visible rejection reasons — staff can see why a submission failed without calling a developer every time
2. Named retry owner — finance ops, branch manager, or IT support — written down for peak hours
3. Retry procedure — what gets edited, what gets reissued, what needs advisor input
4. Proof storage — where official confirmation / QR-related details live for customer copies and audits
5. Access control — who can switch environments, rotate tokens, or change tax defaults

A sandbox that only stores success screenshots still leaves you blind when the first live rejection lands at 7pm on a Saturday.

Volume and channel readiness

Ask whether sandbox traffic resembles production shape:

• Counter / POS pace for retail peaks
• Wholesale batch size for distribution days
• Month-end or cut-off bursts for manufacturing and ERP users
• Whether bulk belongs in product screens or API before go-live day — not after pain appears

eInvoicePro can support screen-based, bulk, and API workflows — alongside whatever FBR path your setup requires. Tool choice should follow volume reality, not the other way around.

Ready vs not-ready signals

Closer to ready when:

• Representative scenarios (including failures) are documented with owners
• Sandbox credentials and integrator path are proven end to end
• Proof retrieval is demonstrated for ops and auditors
• A controlled live pilot plan exists (limited volume, monitoring window)

Not ready when:

• Only one sample invoice “worked once”
• Nobody owns retries
• Production credentials are already in use “to save time”
• Peak volume and bulk have never been discussed
• Legal scope is still a WhatsApp rumour instead of advisor confirmation