FBR POS Integration in Pakistan: QR Codes, Errors, and Reconciliation

FBR POS integration should be evaluated as a complete operational workflow. A badge that says “integrated” does not explain which transaction types are supported, how errors behave, or how finance confirms that records match.

The full path begins before submission. Seller, buyer, item, tax, classification, price, discount, quantity, branch, and transaction information must be valid. It ends after response, print, exception handling, and reconciliation.

This guide is an operational checklist. It is not tax advice.

Confirm who and what is in scope

Start with current Federal Board of Revenue guidance. Identify:

• Taxpayer and registration status
• Business activity
• Notified requirement
• Branches and POS terminals
• ERP and POS sales channels
• Invoice and buyer types
• Returns, refunds, and cancellations
• Approved integration route
• Record-retention requirements

Requirements can change. Assign an internal owner and qualified tax reviewer.

The operating workflow

1. Create the sale

The POS records items, quantities, prices, discount, tax, tender, cashier, terminal, branch, and customer data where required.

The local sale needs a stable identifier before external submission.

2. Validate

Validate required fields before calling an external service. Data checks may include:

• Seller registration
• Branch and terminal mapping
• Buyer status and identifier
• Item classification
• Unit and quantity
• Tax rate
• Discount
• Invoice type
• Original reference for a return

Clear validation messages reduce support work.

3. Submit through the approved path

The system sends the required payload through the approved integration route. Store a request reference, time, endpoint or route, and safe diagnostic information.

Credentials must be protected. Test and production environments should remain separate.

4. Record the response

Store the FBR identifier or relevant response, status, timestamp, and message. Link the response to the immutable local sale identifier.

Do not depend only on printed text. Finance needs structured records for reconciliation.

5. Produce the invoice output

Generate the required reference and QR output according to current specifications. Confirm layout on the actual printer and paper used by branches.

6. Handle exceptions

Classify failures:

• Local validation error
• Authorization error
• External validation rejection
• Temporary outage
• Timeout with unknown result
• Duplicate response
• Print failure

Each class needs a different response.

7. Reconcile

Compare eligible local sales with external responses. Review missing, rejected, duplicated, corrected, and cancelled records.

8. Retain the history

Keep the request reference, response, correction, user action, retry, and final status according to current requirements and internal policy.

Prevent duplicate invoices

Timeouts create a difficult case. The POS may not know whether the external service accepted the request.

Use:

• Stable local invoice identifier
• Idempotency or duplicate-check mechanism supported by the integration
• Status query where available
• Controlled retry queue
• Operator warning against recreating the sale
• Reconciliation before manual correction

Never retry every error without individual review. A missing classification will remain missing. Repetition can create noise or duplicates.

Design offline and outage behavior

Restaurants and supermarkets cannot always stop physical sales because an external connection is slow.

The implementation must document:

• Whether offline sale is allowed
• Which data is retained locally
• Queue order
• Retry timing and limit
• What appears on customer output
• When a supervisor is alerted
• How reconnection is reconciled
• How duplicate processing is prevented

Do not invent an offline policy. Follow the current approved specification and tax advice.

Returns and corrections

A return is not simply a negative new sale. It may require the original invoice reference, eligible reason, transaction type, item and tax treatment, approval, and updated output.

Test:

• Full return
• Partial return
• Same-day void
• Later return
• Exchange
• Price correction
• Credit note
• Cancellation
• Failed original submission

Store the relationship between original and correcting records.

Multi-branch control

Map every branch and terminal. Prevent a terminal from using another branch’s credentials or sequence.

Monitor:

• Last successful submission
• Queue length
• Rejection rate
• Duplicate prevention
• Printer status
• Branch reconciliation completion
• Credential expiry

A central dashboard should show exceptions without exposing unnecessary customer data.

Oyo exception handling

An FBR exception Oyo review can:

1. Observe a failed submission.
2. Read the error and transaction data.
3. Classify transient versus data error.
4. Retry eligible transient failures within limits.
5. Prepare a correction task for data errors.
6. Ask an authorized reviewer to approve material corrections.
7. Resubmit through the same controlled action.
8. Confirm and record the final response.

It should not guess tax fields or change transaction values without authority.

Acceptance tests

Before go-live, test:

• Every supported sale type
• Registered and unregistered buyer scenarios
• Required field omissions
• Invalid classification
• Discount and tax calculations
• Timeout
• Service outage
• Duplicate event
• Restart during queue processing
• Refund and correction
• QR and print output
• Branch separation
• Daily reconciliation
• Audit export

Retain signed evidence with date, product version, environment, and reviewer.

Vendor evidence checklist

Ask for:

• Approved integration relationship
• Sandbox evidence
• Production evidence or customer reference
• Supported transaction matrix
• Error catalogue
• Retry design
• Duplicate-prevention demonstration
• Correction workflow
• Reconciliation report
• Release and regulation owner
• Support escalation

Use “FBR integration support” until stronger claims have this evidence.

Daily operating procedure

At shift or day start:

• Confirm terminal, credentials, network, and printer status.
• Check the retry queue from the prior period.
• Confirm branch mapping and active tax configuration.
• Escalate any unresolved high-risk exception.

During trading:

• Show the operator whether a transaction is accepted, pending, or needs action.
• Prevent a second sale from being created merely because submission is slow.
• Keep local and external identifiers linked.
• Restrict manual correction to authorized roles.

At close:

• Count eligible local invoices.
• Compare accepted, rejected, pending, corrected, and cancelled records.
• Reconcile total value and tax.
• Assign each difference.
• Retain the signed or approved closing evidence.

The exact procedure must follow current requirements and the approved integration design.

Build an error catalogue

For each observed response, record:

• Code and message
• Plain-language meaning
• Likely cause
• Data owner
• Retry eligibility
• Correction steps
• Required approval
• Escalation
• Example resolved case

Keep transient technical errors separate from transaction-data rejections. An operator should not repeatedly retry a record that requires correction.

Review the catalogue when specifications or software versions change.

Reconcile value and count

Counts alone can hide a material difference. Compare:

• Invoice count
• Gross value
• Tax value
• Discount
• Return and correction value
• Branch
• Terminal
• Transaction date

Use a stable status date and explain timing differences. A transaction created before midnight and accepted after midnight may need special reporting logic.

Every reconciling item gets an owner, reason, expected resolution, and age.

Secure the integration

Apply least privilege to credentials. Do not place secrets in client-side code, printouts, or support screenshots. Rotate credentials according to policy and immediately after suspected exposure.

Log enough to diagnose a problem without exposing unnecessary buyer or payment information. Restrict access to request and response data. Monitor repeated authentication failure, unusual volume, and configuration changes.

Test backup and recovery for the local transaction, queue, mapping, and audit history.

Support model

Define first response by severity:

• Store or branch cannot trade
• Transactions continue but submissions queue
• Individual invoice rejects
• Print or QR issue
• Reconciliation difference
• Master-data correction

Name the customer, product, integration-provider, and tax contacts. Tell branch users which channel to use and what evidence to provide.

For a severe incident, retain timeline, affected records, actions, resolution, reconciliation, and prevention.

Change control

Regulation, external specifications, ERP releases, POS versions, item data, and branch setup can all affect the flow.

Before a change:

1. Identify affected scenarios.
2. Update mapping and validation.
3. Run regression tests.
4. Confirm print output.
5. Rehearse rollback.
6. Train affected roles.
7. Record approval.

Keep a last-verified date on public and internal documentation.

Oyo review acceptance scenarios

If an Oyo review manages exceptions, verify that it:

• Reads only eligible transaction data.
• Distinguishes transient and validation errors.
• Respects retry limits.
• Prevents duplicates.
• Does not invent tax values.
• Requires approval for correction.
• Confirms the final response.
• Records every attempt.
• Escalates aged unresolved cases.

Run the same tests after rule, instruction, action, or specification changes.

Prepare a production evidence pack

Retain one approved example for every supported transaction type. Include local identifier, request reference, external response, customer output, stock and accounting effect, correction where relevant, reconciliation, product version, environment, date, and reviewer.

Keep failure evidence too. A timeout, validation rejection, duplicate event, return, and outage recovery show whether the implementation operates safely.

Control configuration by branch

Branch and terminal onboarding should follow a checklist:

1. Confirm legal and registration mapping.
2. Create branch and terminal identity.
3. Issue production credentials securely.
4. Load approved tax and item configuration.
5. Test network and printer.
6. Run representative sale and return.
7. Complete reconciliation.
8. Approve opening.

Record deactivation when a terminal is replaced or a branch closes. Remove credentials and resolve queued transactions.

Review customer-facing behavior

Operators need a clear message when a sale is accepted, pending, rejected, or requires correction. The customer output should not present a pending local reference as a confirmed external response.

Train staff to explain delay without making unsupported regulatory statements. Provide a supervisor path for unusual cases.

Measure integration quality

Monitor success rate, rejection by reason, response time, queue age, duplicate attempts prevented, correction rate, reconciliation difference, branch downtime, and support resolution.

Separate issues caused by local data, product configuration, network, integration provider, and external service. This directs work to the right owner and creates evidence for improvement.

Rehearse a support incident

Run a timed exercise in which a busy branch receives timeouts and the response status is uncertain. Confirm that cashiers preserve the sale, supervisors understand the queue, support sees diagnostics, retries remain controlled, and finance can reconcile the recovered records.

Repeat with a data rejection that must not retry. The system should direct the issue to the master-data owner and preserve the original response.

Document every communication and decision. Update the outage guide with language that branch staff can follow under pressure.

Repeat the exercise after material POS, ERP, connector, credential, or external-specification changes. Record recovery time and every transaction that required reconciliation.

Include branch representatives in the review. They can identify whether status labels, messages, print output, and escalation steps work during real trading pressure.

Close the exercise only after count and value reconcile. Retain the test records, timeline, product version, configuration, reviewers, and improvements as part of the production evidence pack.

Schedule the next continuity exercise and assign ownership before the current incident review closes.

Related Oyo guides

• FBR digital invoicing readiness checklist
• Restaurant POS and ERP

Sources and further reading

• FBR digital-invoicing FAQ
• FBR POS booklet
• FBR Sales Tax General Order 01 of 2026
• FBR official website

Review the complete path

Ask to see a successful sale, a validation error, a timeout, a return, and daily reconciliation in one demonstration.

Review FBR integration support