FBR Digital Invoicing Readiness Checklist for ERP and POS Teams

Digital-invoicing readiness is not an API task assigned only to information technology. It affects tax, finance, sales, product data, branches, POS operations, customer service, and support.

The most common implementation risk is not the successful demonstration invoice. It is an unusual live case: missing buyer data, a return, a timeout, an inactive terminal, an incorrect item classification, or a difference between local and external records.

Use this checklist with current FBR primary guidance and qualified tax advice.

1. Establish applicability

• Confirm the current legal requirement for each entity.
• Confirm effective dates.
• Identify notified activities.
• List registrations and branches.
• Identify every invoicing channel.
• Identify buyer and transaction types.
• Document retention requirements.
• Record the advice source and review date.

Do not assume all companies or transactions follow one configuration.

2. Name owners

Assign:

• Executive sponsor
• Tax owner
• Finance owner
• Sales owner
• Master-data owner
• ERP owner
• POS owner
• Integration owner
• Branch owner
• Support owner

Create one decision and issue log. Define who can approve corrections and who communicates with the integration provider.

3. Map invoice flows

Map:

• ERP sales invoice
• Counter POS sale
• Restaurant order
• Business customer sale
• Consumer sale
• Delivery or online order
• Return
• Refund
• Cancellation
• Credit note
• Advance or other relevant scenario

For each flow, show trigger, data source, validation, submission, response, output, accounting, stock effect, and reconciliation.

4. Clean company and branch data

Verify:

• Legal name
• Registration numbers
• Address
• Business activity
• Branch mapping
• Terminal mapping
• Credentials
• Environment
• Invoice sequence
• Time and timezone

Protect credentials and separate test from production.

5. Clean buyer data

Define when buyer information is required and how it is validated.

Review:

• Buyer name
• Registration or identity field
• Address or province where required
• Registered status
• Customer category
• Credit account
• Consent and privacy handling

Prevent branch staff from entering arbitrary placeholders that later cause rejection.

6. Clean item and tax data

For every sellable item or service, review:

• Description
• Item code
• Classification
• Unit
• Tax category
• Rate
• Price
• Discount behavior
• Exemption or special treatment
• Effective date

Assign a qualified owner for tax classification. Oyo can identify missing fields, but it should not invent legal treatment.

7. Confirm the integration route

Document:

• Approved integrator or PRAL route
• Contract and service scope
• Test and production endpoints
• Credential owner
• Payload and response version
• Availability expectations
• Support escalation
• Change notification process

Do not use a partner logo as proof. Retain written scope and test evidence.

8. Build validation

Validate before submission:

• Required seller data
• Required buyer data
• Item classification and unit
• Quantity
• Price and discount
• Tax
• Transaction type
• Original invoice reference
• Branch and terminal
• Totals

Messages should tell the operator what to correct and who owns the field.

9. Design status and queue

Use clear states:

• Ready
• Submitted
• Accepted
• Rejected
• Waiting to retry
• Needs correction
• Cancelled
• Reconciled

Show the last attempt, response, owner, and next action. Protect against duplicate queue processing.

10. Plan outage handling

Document:

• Allowed point-of-sale behavior
• Local record retention
• Operator message
• Queue order
• Retry intervals
• Retry limit
• Escalation time
• Reconnection process
• Duplicate check
• Reconciliation

Follow current approved requirements. Do not improvise this during an outage.

11. Test corrections

Test:

• Missing required field
• Incorrect buyer status
• Incorrect classification
• Wrong price or quantity
• Full and partial return
• Credit note
• Cancelled transaction
• Failed original
• Duplicate attempt
• Correction after period close

Require approval for material changes. Preserve original and correcting records.

12. Build reconciliation

Daily reconciliation should compare:

• Eligible local invoices
• Submitted invoices
• Accepted responses
• Rejections
• Pending retries
• Corrections
• Cancellations
• Duplicates

Show count and value. Assign every difference. Close only when evidence exists.

13. Test accounting and stock

External submission does not replace internal accounting control.

Confirm:

• Revenue and tax posting
• Tender and receivable posting
• Stock issue
• Cost of sales
• Return posting
• Credit note
• Branch and company dimensions
• Period close behavior

Reconcile POS, ERP, payment, stock, and external records.

14. Train each role

Train cashier, branch manager, finance reviewer, tax owner, support, and administrator separately.

Practice:

• Normal sale
• Missing buyer or item data
• Rejection
• Outage
• Return
• Duplicate warning
• End-of-day reconciliation
• Escalation

Provide a short role-based guide and named support channel.

15. Prepare go-live

Before cutover:

• Freeze mapping changes.
• Complete production credential testing.
• Confirm terminals and branches.
• Reconcile opening state.
• Staff a command channel.
• Schedule branch waves.
• Keep rollback and continuity procedures.
• Confirm specialist availability.

Record approval to go live.

16. Monitor after launch

Track:

• Submission success rate
• Rejection reason
• Queue age
• Duplicate attempts
• Correction volume
• Reconciliation differences
• Terminal availability
• Support response
• Regulatory changes

Review daily during stabilization.

17. Use Oyo reviews carefully

An FBR exception Oyo review can classify errors, retry transient failures, prepare correction tasks, monitor queue age, and summarize reconciliation.

It should not change tax classification, buyer status, amount, or transaction type without approved evidence and authority.

Every Oyo action needs:

• Defined ERP action
• Role
• Limit
• Approval
• Audit
• Duplicate prevention
• Recovery

Readiness score

Score each section:

• 0: Not started
• 1: Owner identified
• 2: Designed
• 3: Tested
• 4: Production proven

Do not treat a high average as permission to ignore a critical zero. Applicability, approved route, required data, duplicate prevention, corrections, and reconciliation are launch gates.

Build the evidence pack

For each readiness section, retain:

• Approved requirement
• Owner
• Configuration record
• Test case
• Expected result
• Actual result
• Screenshot or transaction identifier
• Defect and retest
• Approval
• Last-reviewed date

Organize evidence by entity, branch, channel, and transaction type. A single successful invoice does not prove every branch and return flow.

Test a complete scenario matrix

Build rows for:

• Cash retail sale
• Digital tender
• Credit customer
• Registered buyer
• Unregistered buyer
• Discount
• Full return
• Partial return
• Cancellation
• Credit note
• Outage
• Timeout with unknown response
• Duplicate event
• Invalid item classification
• Missing buyer data
• Branch or terminal error

Add columns for applicable entity, system, expected external response, invoice output, stock effect, accounting effect, correction, reconciliation, and evidence.

Mark nonapplicable scenarios with a reviewed reason rather than leaving them blank.

Rehearse branch operations

Run a supervised practice at representative branches. Include high-volume, low-connectivity, multi-terminal, and unusual sales environments.

Observe whether users can:

• Recognize status
• Correct ordinary data
• Avoid duplicate entry
• Continue through an outage according to policy
• Process a return
• Close and reconcile
• Escalate a blocked case

Record usability problems. A technically correct integration can still fail if status and correction are unclear.

Prepare master-data governance

Create an approved request and review process for:

• Registration and branch changes
• New items
• Classification
• Tax treatment
• Units
• Buyer status
• Terminal mapping
• Price and discount rules

Use effective dates. Review high-impact changes before they reach production. Report incomplete or invalid records before a branch tries to sell them.

Oyo may detect missing information and route it to the owner. It should not make unsupported classifications.

Plan period-end assurance

Finance and tax owners need more than daily operational status. At period end:

1. Confirm all eligible dates and channels are included.
2. Resolve or document pending records.
3. Reconcile count, gross value, tax, returns, and corrections.
4. Compare branch, ERP, POS, and external totals.
5. Review unusual manual changes.
6. Retain approval and evidence.

Define treatment for records that remain unresolved at close with qualified advice.

Maintain continuity

Document how the business operates during:

• Internet outage
• External-service outage
• POS failure
• ERP failure
• Credential failure
• Printer failure
• Integration-provider incident
• Cybersecurity incident

The continuity plan identifies allowed work, local records, communication, recovery order, duplicate protection, and later reconciliation.

Test the plan. A document that nobody has rehearsed is not enough.

Review vendor responsibility

Create a responsibility matrix across taxpayer, product vendor, POS provider, integration provider, hosting provider, and tax advisor.

For each issue, identify:

• First contact
• Diagnostic owner
• Correction owner
• Regulatory owner
• Customer communication
• Resolution target
• Evidence retention

Keep contractual service and technical capability separate from tax responsibility.

Readiness approval

The go-live paper should state:

• Scope
• Current primary guidance
• Specialist review
• Supported scenarios
• Excluded scenarios
• Test result
• Open risk
• Continuity readiness
• Support readiness
• Reconciliation owner
• Approval identities

Reapprove when scope or requirements materially change.

Run a readiness review meeting

The owner of each checklist area presents evidence, not a verbal percentage. Review critical gaps first: applicability, approved route, required data, transaction coverage, duplicate prevention, correction, continuity, reconciliation, and support.

For every open item, record:

• Affected entity, branch, channel, and transaction
• Operational or compliance impact
• Interim control
• Responsible owner
• Required decision or evidence
• Due date
• Launch effect

Do not average away a critical failure. One unsupported high-volume transaction can block a location even when most tests pass.

Prepare post-launch assurance

Schedule daily reconciliation during stabilization and a formal first-period review. Compare count and value across POS, ERP, integration records, and external responses. Sample printed output and corrections.

Review access, configuration changes, unresolved queue items, manual workarounds, and support incidents. Confirm that branches follow the approved outage and return procedures.

Document lessons and update training, validation, error catalogue, and acceptance tests before the next branch wave.

Control new branches and channels

Do not assume a proven configuration can be copied without review. A new branch, POS product, sales channel, item range, buyer type, or return process can introduce different data and failure paths.

Repeat applicability, mapping, credential, device, transaction, correction, continuity, reconciliation, training, and support checks. Retain a branch-specific opening approval.

Monitor the first trading days separately. Compare transaction count and value, rejection reasons, queue age, printed output, corrections, and support. Expand only after differences are resolved.

Maintain the checklist

Name one owner for regulatory and specification monitoring. Record each reviewed update, affected workflow, decision, configuration change, test, communication, and effective date.

Archive obsolete versions but keep evidence for the period in which they applied. A current checklist and historical audit serve different purposes.

Review the checklist with tax, finance, operations, and technology together. A technically complete change may still alter invoice treatment, branch procedure, accounting, or customer communication.

Record the final decision and effective date. Identify affected branches, items, channels, training, reports, and reconciliations.

After release, sample live transactions against the approved expectation. Review errors and manual corrections. Keep the prior configuration and evidence available for transactions created before the change.

This closes the path from regulatory monitoring to controlled production behavior.

Assign the next scheduled review before closing the change. Readiness must remain an owned operating process.

Related Oyo guides

• FBR POS integration in Pakistan
• A 90-day ERP implementation plan

Sources and further reading

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

Run a readiness workshop

Bring your entity, branch, POS, invoice, return, and integration map. Turn each gap into an owner and acceptance test.

Review FBR integration support