PRA invoice QA should prove that line values, discounts, service charges, tax, payment modes, header totals, receipts and fiscal records agree under realistic edge cases. Do not hard-code a universal rate into the test plan. Use the taxpayer’s currently authorized configuration, calculate expected results independently, and test both the happy path and failures such as timeouts, duplicate clicks and printer problems.
Reviewed 28 August 2026. The examples below describe test structure, not a tax rate or legal treatment. Confirm current rates, service classification, payment treatment and invoice requirements for the taxpayer with PRA or a qualified adviser.
Build an independent expected result
A test is weak when the POS calculates the invoice and the tester merely copies the same screen values into the expected column. Use a reviewed spreadsheet or test harness that calculates expected line values, authorized discounts, tax and totals independently from the application code.
Controlled test data → independent expected result → POS invoice → fiscal response → receipt → reconciliation
Core arithmetic assertions
| Assertion | Question |
|---|---|
| Quantity × unit value | Does each line derive the expected sale value? |
| Line discount | Is it applied once and shown in the correct field? |
| Header discount | Is allocation consistent and auditable? |
| Service charge | Is the configured treatment applied consistently? |
| Tax | Does line and header tax match authorized configuration and rounding? |
| Bill total | Does the payable amount equal the controlled components? |
| Payment total | Do tender amounts equal the amount settled? |
| Payload versus receipt | Are values identical across the customer and fiscal records? |
Discount test matrix
- No discount: baseline arithmetic.
- Single-line percentage discount.
- Single-line fixed-value discount.
- Whole-invoice discount allocated across multiple lines.
- Maximum cashier-allowed discount.
- Discount above threshold requiring manager approval.
- Discount combined with quantity greater than one.
- Discount on a returned item.
- Complimentary item represented through the approved workflow.
- Attempted discount after fiscal acceptance.
For every test, capture original value, discount reason, user, approver, payload fields, receipt display and closing-report effect. See the PRA POS approval matrix.
Service-charge scenarios
Businesses may use different service-charge configurations and tax treatments. The goal of QA is not to assume one treatment; it is to prove that the configured, approved treatment flows consistently through the POS, payload, receipt and accounts.
| Scenario | Verify |
|---|---|
| No service charge | No hidden value appears in payload or receipt |
| Percentage service charge | Correct base, precision and display |
| Fixed service charge | Authorization and bill-total agreement |
| Service charge plus discount | Documented order of calculation |
| Partial return | Supported treatment and original reference |
| Waived charge | Manager approval and audit history |
Split-payment tests
- cash plus card exactly equals bill total;
- two cards or digital tenders under the supported POS workflow;
- partial payment rejected when the business requires full settlement;
- overpayment and change handled without altering the invoice total;
- payment reversal after fiscal acceptance;
- one tender fails after another has succeeded;
- closing report agrees with payment-terminal settlement.
The public invoice model includes PaymentMode, but a business POS may have richer tender detail. Define how the approved payment category in the fiscal payload maps to the operational settlement records; do not silently choose the first tender.
Rounding boundaries
Test values that create fractions at the smallest supported currency precision. Decide and document whether rounding occurs per line, per tax component or at header level according to the authorized implementation. Then ensure every layer uses the same result.
- One line with a fractional result.
- Several lines whose rounded values differ from rounding the final sum.
- Quantity greater than one with fractional unit value.
- Percentage discount producing a fraction.
- Tax and service charge both producing fractions.
- Partial return of one line from a multi-line invoice.
Never hide a mismatch with an unexplained “rounding adjustment” line. If such a control is authorized, it must be defined, visible and reconciled.
Payload validation tests
| Test | Expected result |
|---|---|
| Missing POSID | Blocked before submission with a clear field error |
| Duplicate USIN | Prevented or routed to investigation |
| Header total differs from lines | Blocked with expected and actual values |
| Credit without original reference | Blocked by the supported adjustment workflow |
| Invalid environment configuration | No production submission |
| Empty Items array | Rejected locally unless a documented case permits it |
Use the PRA invoice payload field guide as the field-level checklist.
Failure and concurrency tests
- cashier double-clicks Submit;
- two workers process the same USIN;
- network drops after the request leaves the POS;
- local SFD restarts during submission;
- fiscal acceptance succeeds but receipt printing fails;
- POS closes while an invoice is uncertain;
- retry occurs after the original fiscal result exists.
The expected behavior is controlled state and evidence, not a blind second invoice. See safe PRA invoice retries.
Receipt assertions
- Correct business and branch identity.
- USIN and returned fiscal reference stored correctly.
- QR generated from the supported data and remains scannable.
- Line descriptions, quantities, discounts and totals agree.
- Reprint uses the same accepted record.
- No sandbox label or test identity appears on production receipts.
- No token, endpoint or debug message appears to the customer.
Test evidence and sign-off
Record case ID, configuration revision, input data, expected result, actual payload, redacted response, receipt image, tester, date and pass/fail. A failed case should link to the defect and rerun evidence. Production approval should name the business, technical and finance owners.
Official references
- PRA Software Fiscal Device Technical Specification version 1.2
- Official PRA POS invoice search
- PRA e-services portal
Frequently asked questions
Which tax rate should be used in the test data?
Use the taxpayer’s currently authorized configuration after confirming current law and classification. This guide intentionally does not publish a universal rate.
Should rounding be tested only on the receipt?
No. Compare the item model, payload, fiscal response, receipt, payment and accounting export.
Can a printer failure cause the invoice to be resubmitted?
No. If fiscal acceptance already occurred, reprint the stored accepted record instead of creating another submission.
How many test cases are enough?
Use risk-based coverage for every enabled feature, payment method, adjustment and failure mode. One normal sale is not sufficient.
Need a PRA invoice QA pack?
NexZion Solutions can create expected-result cases, sandbox regression tests, receipt checks and production sign-off for your POS workflow.
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.
