A PRA invoice timeout is not proof of failure. The request may have failed before transmission, reached the local SFD, reached the upstream service, or been accepted while the response was lost. Safe retry design therefore keeps one stable USIN, records every attempt, separates known rejection from uncertain status, checks available evidence and prevents a cashier from creating a second sale merely because the first response was not displayed.
Reviewed 28 August 2026. PRA’s public specification defines business invoice references and fiscal responses, but it does not make every implementation retry-safe automatically. Confirm the supported behavior of the actual SFD/API version and reconcile uncertain transactions. This is software guidance, not tax advice.
The dangerous moment: request sent, response missing
Submit USIN → connection times out → result unknown → investigate → recover same transaction → reconcile
If the POS immediately generates a new USIN and posts a second invoice, the business can end up with two fiscal records for one customer transaction. If it assumes success without evidence, it can print an unverifiable receipt. The correct state is “uncertain” until evidence resolves it.
Use an explicit state machine
| Status | Meaning | Allowed next action |
|---|---|---|
| Draft | Transaction still editable | Validate or cancel before fiscal submission |
| Ready | Authorized and assigned a stable USIN | Submit once |
| Submitting | Attempt in progress | Prevent duplicate cashier action |
| Accepted | Fiscal response stored | Print and reconcile |
| Rejected | Known response says data was not accepted | Correct the documented error under control |
| Uncertain | No authoritative result after a send attempt | Investigate and use controlled recovery |
| Queued | Held for supported onward processing | Monitor age and synchronization |
| Escalated | Manual evidence review required | Restrict changes and assign an owner |
Stable USIN is necessary, but not sufficient
Create the USIN once before the first attempt and store it transactionally with the invoice. Never derive it only from a screen counter that can reset. The same sale must not receive a fresh business identifier on every retry.
However, do not assume an upstream service guarantees idempotency merely because you resend the same field. Confirm the supported behavior of the installed component and environment. Your POS still needs local duplicate locks, attempt history and reconciliation.
Classify failures before retrying
| Failure class | Example | Retry? |
|---|---|---|
| Local validation | Missing POSID or totals mismatch | No; correct data under approval |
| Authentication/configuration | Invalid credential or wrong environment | No automatic loop; correct configuration |
| Known authority rejection | Documented response rejects the payload | Only after correcting the cause |
| Connection not opened | Local service unavailable before send | After service recovery and state confirmation |
| Timeout after send | No response after bytes may have left the client | Treat as uncertain; investigate first |
| Temporary upstream unavailability | Supported service unavailable | Controlled retry with backoff if documented |
| Duplicate indication | Existing transaction or reference found | Stop; retrieve and reconcile the original |
Retry lock and concurrency control
Only one worker should submit a given USIN at a time. Use a database constraint, transactional lock or queue ownership model rather than relying on a disabled button. Cashier double-clicks, two terminals, background jobs and support scripts can otherwise submit concurrently.
- Enforce uniqueness for the business invoice reference.
- Write the attempt record before the network call where practical.
- Record worker, device, software version and environment.
- Expire abandoned locks carefully; do not unlock an in-flight request blindly.
- Require reason and named user for a manual retry.
Backoff without hiding the incident
For failures documented as temporary, retries should be limited and spaced rather than immediate infinite loops. Use a short initial delay, increase the delay, add jitter where multiple counters could retry together, and cap both attempt count and maximum age. When the cap is reached, move the invoice to an exception queue with a visible owner.
Evidence-first recovery
- Freeze the transaction identity and prevent a replacement sale.
- Check the POS attempt log and local SFD status.
- Search available fiscal records or reports using the known references.
- Compare the customer receipt, payment settlement and closing record.
- Ask the responsible technical or PRA support channel with redacted evidence.
- Record the decision before retrying, reversing or escalating.
The official PRA invoice-search facility can help verify fiscal references where applicable. Do not paste tokens, passwords, CNICs or full customer data into informal support chats.
Receipt behavior during uncertainty
The UI should clearly distinguish a completed fiscal invoice from a transaction awaiting confirmation. Do not print a fabricated fiscal number. If business continuity requires a temporary document, its wording and later handling must follow the approved business and regulatory process, not an improvised developer label.
Reconciliation closes the loop
At shift and day closing, compare accepted fiscal invoices, uncertain transactions, queued records, refunds and payment totals. An automatic retry system without reconciliation can quietly leave aged failures or duplicate outcomes.
- Count and value by status.
- List the oldest uncertain and queued transactions.
- Compare USIN-to-fiscal-number uniqueness.
- Check repeated attempts and manual overrides.
- Require finance or management sign-off for unresolved exceptions.
Use the PRA eIMS monitoring runbook for alert thresholds and ownership, and the audit-log checklist for evidence fields.
Test the ambiguous cases
- Timeout before a connection is established.
- Connection drops immediately after request transmission.
- Response reaches the SFD but not the POS UI.
- Two workers attempt the same USIN.
- POS restarts while status is Submitting.
- Accepted response is stored but receipt printing fails.
- Manual retry is attempted after the fiscal number already exists.
These tests complement the 25-test PRA eIMS go-live checklist.
Official references
- PRA Software Fiscal Device Technical Specification version 1.2
- Official PRA POS invoice search
- PRA e-services portal
Frequently asked questions
Does a timeout mean PRA rejected the invoice?
No. A timeout describes the client’s wait, not the authority-side result. Treat the status as uncertain until evidence resolves it.
Should the POS create a new USIN for a retry?
No for the same business transaction. Preserve the original identity. Whether the transport call may be repeated should follow the supported integration behavior and evidence.
Can retries run forever in the background?
No. Set limits, age thresholds, alerts and manual escalation. Infinite retries hide incidents and can overload systems.
What if the receipt printer fails after acceptance?
Reprint from the stored accepted record with the same fiscal reference. Do not resubmit the invoice solely because printing failed.
Need duplicate-safe PRA invoice processing?
NexZion Solutions can review state handling, USIN generation, queues, retries, receipts and reconciliation before production use.
Continue: Explore the PRA POS Integration Software resource center for registration, SFD, testing, troubleshooting and industry workflows.
NexZion Solutions publishes practical guides based on business-software, compliance-workflow, website and automation implementation experience in Pakistan.
