Connecting to FBR digital invoicing is not a single switch that goes from off to on. Between registering your integration and issuing your first live invoice sits a testing phase, run against FBR's sandbox environment rather than its production one, where a set of defined scenarios has to pass before FBR will issue a production token.
What the sandbox actually is
The sandbox is a separate, parallel version of FBR's Digital Invoicing API that behaves like the real thing but does not create legally binding invoices. Submissions go through the same validation logic, the same status codes, the same error messages, so what passes in sandbox is a genuine signal about what will happen in production. It is not a simplified demo mode, it is the real rulebook without the real-world consequences of a mistake.
What a scenario is, using SN001 as an example
FBR defines a set of named scenarios, each representing a distinct kind of transaction your business might realistically issue. SN001, for example, covers the sale of standard-rate goods to a registered buyer, the most ordinary case: a normal item, a normal tax rate, a buyer who is properly registered for sales tax. Other scenarios cover things like sales to unregistered buyers, goods under a reduced rate or exemption, or transactions that trigger further tax. Which scenarios actually apply to you depends on how your business operates, not every scenario applies to every taxpayer.
Why it exists as a gate
This step exists because a badly configured integration submitting real invoices in production is a much bigger problem than one failing in sandbox. Requiring at least one successful invoice per applicable scenario before issuing a production token is FBR's way of confirming your product catalogue, tax mapping, and buyer handling are correct before anything you submit becomes an unchangeable live record.
What this means for a first-time integration
Budget real time for this stage, it is not a formality you click through. Each scenario needs test data that genuinely represents that case, a real registered buyer record, a real HS code with the matching tax rate, and so on, so getting through the full applicable list usually surfaces gaps in a product catalogue or client records that were not obvious until FBR's own validation flagged them. That is the sandbox doing its job, better to find those gaps here than after go-live.
What happens after
Once the applicable scenarios pass, FBR issues a production security token, and requests from your registered, whitelisted setup start being treated as real invoices rather than test submissions. The move from sandbox to production is a credential and endpoint change on your side, not a rebuild, the same integration that passed testing is what goes live.
The sandbox step, without building the integration yourself
AxiomSquare's integration has already been through this process. You do not need to run scenario testing yourself to start invoicing.
See AxiomSquareGeneral information, not tax advice. Confirm which scenarios apply to your business with FBR/PRAL or your tax consultant.