Which IP address do you whitelist for FBR digital invoicing?

The IP address you whitelist for FBR digital invoicing is the outbound public IP address of the server that actually calls FBR's API. It is not your office internet connection, not the desktop or laptop where somebody clicks save, and not the POS terminal at the counter, unless that exact machine is the one opening the connection to FBR.

The confusion is understandable. The person filling in the form is usually sitting in the office, looking at the office connection, and reasonably assumes that is what FBR is asking about. It is not. FBR and PRAL want to know which machine on the internet will be sending invoices.

What PRAL actually asks for on the whitelisting screen

The clearest evidence of what is wanted is the form itself. PRAL's Digital Invoicing User Manual, version 1.6, sets out the registration flow inside IRIS. You choose API Integration as your integration mode, then choose a licensed integrator, then fill in Technical Details. The step immediately after that is IP Whitelisting, and it asks for exactly three things:

• Hosting Server Company Name
• Hosting Server Country
• IP Address, minimum one and maximum three

If you need more than three, the manual says you upload a file instead: click the Download Sample File link, fill it in, and upload it, in .xls format up to 1 MB in size.

PRAL's own frequently asked questions in the same manual state the purpose plainly: IP whitelisting ensures that only approved IP addresses can access the integration, and you can enter one to three IPs or upload a file with multiple IPs.

Whitelisting happens before sandbox testing, not after

This is the part that decides your timeline. The user manual states that the PRAL Data Centre will accept or reject the submitted IPs within two working hours, and that this acceptance automatically initiates sandbox testing. The whitelist is the gate you pass through to reach the sandbox, so an address that is wrong or not yet approved stops the project before a single test invoice is posted.

There is one important exception, also stated in the manual: where you have chosen a licensed integrator other than PRAL, PRAL does not perform IP whitelisting for taxpayers. In that case the address is handled by your integrator under their own process, and the two working hour figure does not apply. If you are still deciding, we set out the trade offs in how to choose a licensed FBR integrator.

The three addresses people register by mistake

Each of these is right in some setups and wrong in most.

• The office internet connection. Correct only if the machine that calls FBR sits in that office and leaves through that connection. If your invoicing software runs on a hosted server, in a data centre, or as a service somebody else operates, the office line never touches FBR at all.
• The computer the user is sitting at. Opening a "what is my IP" page in a browser tells you the egress address of that browser, which matters only if that same machine is making the API calls. In a typical setup the browser talks to your application, and your application talks to FBR from somewhere else entirely.
• The POS terminal. In most retail deployments the terminal talks to a local server or a cloud service, and that server talks to FBR. The terminal's address is invisible to FBR. We describe the full chain in connecting your POS to FBR digital invoicing.

The same logic applies in reverse when you buy invoicing as a service. If your invoices are transmitted by a provider's servers, the address that has to be on the list is the provider's, not yours, and getting it registered is their job rather than something you buy from your ISP.

How to find the outbound IP of the server that calls FBR

Find it from the server, not from anywhere else. Log in to the machine that runs the invoicing software and ask the internet what address it sees, using a command run on that machine rather than a page opened on your laptop. On Linux that is a single command line request to any public address reflector, and on Windows Server the PowerShell equivalent does the same job. The answer only counts if the question was asked from the machine that will be talking to FBR.

Three things commonly make the answer different from what you expect:

• The server's own interface address is usually private. Something like 10.0.1.20 or 192.168.1.50 is an internal address. It is never what you register.
• A router, firewall, NAT gateway or proxy sits in front. FBR sees the address of that device, not the server behind it. Register the device's public address.
• There may be more than one exit. If traffic can leave through either of two links, or through a pool of addresses, every address in the pool has to be registered or the calls that happen to take the unregistered path will fail intermittently. Intermittent is the worst version of this problem, because the integration looks like it works.

The endpoints your traffic is going to are on FBR's gateway host, as published in the DI API Technical Specification version 1.12: the post and validate methods sit under gw.fbr.gov.pk. Ask your hosting provider or network administrator for the egress address used for outbound traffic to that host, and ask in the same breath whether it is fixed.

What happens when the IP changes

Nothing warns you. A previously working integration simply stops working, and because nothing about the invoice data changed, the first instinct is to look at the invoice data, which is the one place the problem is not.

There is no invoice validation error code for a source address that is not on the whitelist. Sections 7 and 8 of the DI API Technical Specification version 1.12 list the sales error codes from 0001 to 0402 and the purchase error codes from 0156 to 0177. Every one of them describes either the content of an invoice, a registration number, an HS code, a rate, a date, a quantity, or, in the case of codes 0401 and 0402, a seller or buyer registration number that has no authorised access token against it. None of them describes the address the request came from. The only transport level responses the specification documents are HTTP 200 for OK, 401 for Unauthorized, and 500 for an internal server error. So a blocked address surfaces as a connection failure or an HTTP level rejection, not as a message telling you which IP to fix. We cover the codes that do exist in the FBR error codes glossary.

The usual causes, in the order we encounter them:

• A dynamic address from the ISP. The connection is handed a different public address after a reboot, an outage or a lease expiry.
• ISP renumbering. The provider migrates the customer to a different address range, often without telling anyone who would recognise the consequence.
• A move. New office, new provider, new address, same software.
• A hosting change. The server is rebuilt, migrated to another data centre, or moved to a different plan, and the public address goes with the old machine.
• Cloud egress that was never fixed in the first place. A container or virtual machine that leaves through a shared or rotating pool of addresses will present a different address over time even though nobody changed anything.

The remedy in all five cases is administrative rather than technical: register the new address and wait for it to be accepted. Nothing in the invoicing software needs to change.

If you host in the cloud, pin the egress address deliberately

Cloud hosting is where this goes wrong most quietly, because the default behaviour of most platforms is the opposite of what FBR needs. A virtual machine given a public address on creation may lose it on stop and start. A container platform may send outbound traffic through a shared gateway whose address is not guaranteed. An autoscaling group may add a second instance that leaves through a path nobody registered.

Because the whitelist accepts up to three addresses typed in, you have room for a small, deliberate set: a primary, a standby, and a maintenance path, for example. What you cannot have is an address that changes without notice. In practice that means attaching a reserved public address to the instance, or routing all outbound traffic through a single gateway with a fixed address, and registering that one address. Treat it as part of the compliance configuration rather than as an infrastructure detail.

Why a static IP matters here, even though no rule names one

We want to be precise about the status of this requirement, because it is widely stated and rarely sourced. We read the Sales Tax Rules 2006 as updated to 6 August 2025, including Chapter XIV, the chapter headed procedure for licensing, issuance of electronic sales tax invoices and integration of registered persons. The words static IP, IP address and whitelist do not appear in it. Rule 150R(1) of that chapter requires the integrated person to register, install and integrate his electronic invoicing hardware and software with the Board's computerised system in the manner specified by the Board through a Sales Tax General Order, which is exactly how an operational requirement of this kind ends up living outside the rules. We also read the DI API Technical Specification version 1.12 in full: it says nothing about IP addresses either, and its only security section covers the bearer token passed in the request header.

So the honest position is this. A fixed, registered address is a practical requirement of the integration process rather than something the published specification states. It is documented in PRAL's Digital Invoicing User Manual and it is enforced by the IRIS registration screen, which will not let you past it. That is the same framing we use in do you need a static IP for FBR digital invoicing, and nothing we found this time changes it. What the user manual adds is the detail that makes the requirement workable: you are allowed a small set of addresses rather than exactly one, and the thing that actually breaks you is not having several, it is having one that moves.

A short checklist before you submit the form

• Identify the machine, or the small set of machines, that will call FBR, and get the outbound public address from that machine.
• Confirm with the hosting provider or ISP in writing that the address is fixed, and ask what would change it.
• Register every address that traffic can legitimately leave from, up to the limit of three, or use the file upload if there are more.
• Submit before you plan to start sandbox testing, and allow for the acceptance step.
• Record the registered addresses where your IT staff will see them, so a future server migration triggers a re registration rather than an outage.

If you are working through the wider integration sequence, the order of the other steps is set out in FBR sandbox testing scenarios explained, and the service itself is described on our FBR digital invoicing page.

Last verified: 27 August 2026. Primary sources read directly for this page: the PRAL Digital Invoicing User Manual, document version 1.6, privacy level marked Public, specifically section 4.1.1 covering Technical Details, the IP Whitelisting step and its field list, the two working hour acceptance by the PRAL Data Centre, the sandbox and production environment steps, the note in section 4.1.2 that PRAL does not perform IP whitelisting where the licensed integrator is not PRAL, and the frequently asked questions section; the PRAL Technical Specification for DI API, document version 1.12, last updated 24 July 2025 and published by FBR, specifically section 3.1 on Web API security, the post and validate endpoints on gw.fbr.gov.pk, the HTTP status codes in section 4.1.6, and the sales and purchase error code tables in sections 7 and 8; and the Sales Tax Rules 2006 as consolidated and updated to 6 August 2025, specifically Chapter XIV and rule 150R. The absence of any reference to IP addresses, whitelisting or a static IP in the technical specification and in the Sales Tax Rules is a deliberate finding of this page, not an omission. General information, not tax advice. Confirm current integration requirements with FBR, PRAL or your licensed integrator.