Connect existing systems

What should a Fawtara POS acceptance test include?

Use sale, rejection, retry, correction and reconciliation cases before a merchant goes live.

Reviewed by the EazSell editorial team · 22 September 2026

Direct answer

Acceptance testing should follow an invoice through the POS, mapping layer, accredited provider and back to staff. Include a normal sale, missing buyer data, a tax error, timeout, duplicate retry and credit note. Check the provider response and end-of-day totals, not only whether an API call returned success.

Reference: Oman Tax Authority: service-provider FAQs

The short version

Test the reverse response path.
Keep stable IDs across retries.
Get merchant and provider sign-off on evidence.

Build cases from the shop's work

Use the tax classes and payment patterns the business actually has. Ask a cashier to run the normal case, then let finance run correction and reconciliation. Record the source ID, structured document ID, status and customer copy for each test.

Rehearse failure deliberately

Disconnect after sending an invoice and before the response returns. Restore the network and inspect whether the same invoice was submitted twice. Also test a rule rejection and a corrected resubmission. Staff need clear instructions for each state.

What to check in your own setup

Agree test cases and expected outcomes in writing.
Capture source and provider IDs for every result.
Sign off exceptions, daily totals and support contacts.

Questions people ask

Is one accepted invoice enough for go-live?

No. It does not show how the system handles wrong data, outages or corrections.

Sources and verification

OTA and OpenPeppol material can change. Check the latest official version before making a tax or deployment decision.

Need to test this against your own checkout?

Tell us which POS or ERP you use, how many locations you run and who handles invoicing today. We can discuss the POS side and identify what needs confirmation with an accredited provider.

Discuss an Oman project