Fiscal POS guide

Fiscal POS Software: A Merchant Checklist

A plain-language guide to fiscal POS workflows, official requirements, integration and deployment evidence.

By EazSell product team · Published 29 July 2026 · Reviewed 29 July 2026

The short answer

Fiscal POS software helps a merchant prepare required invoice data, communicate through the approved local route and retain the resulting status or receipt evidence. Product capability alone does not prove tax-authority approval: verify the applicable rules, integration and authorization for each market.

Separate product capability from approval

A POS may support invoice fields, QR data, signing or API communication, while local rules still require approved equipment, a certified integrator or a taxpayer onboarding process. Ask for official evidence that matches the exact country and deployment.

Identify the tax authority and current rule.
Confirm the merchant category and invoice type.
Verify the integration or device approval path.

Make status understandable

Cashiers, managers and support teams need different levels of detail, but all should know whether an invoice is ready, queued, submitted, accepted or needs attention. A printed receipt should not be presented as accepted when confirmation is still pending.

Show validation before submission.
Retain authority references and responses.
Control refunds, credit notes and voids.

Use official sources

Requirements change. Start with the relevant authority, then confirm implementation details with a qualified local adviser or approved integration partner. EazSell country pages link to sources such as KRA in Kenya, ZIMRA in Zimbabwe and MRA in Malawi.

Record the source and review date.
Retest when rules or interfaces change.
Avoid making certification claims based only on a demo.

Map the complete invoice lifecycle

Do not evaluate only the moment an invoice is created. Follow a normal sale, refund, credit note, void, failed submission and end-of-day close. For each event, record who may perform it, which data is required, what the authority returns and where support teams can find the evidence.

This lifecycle review often reveals gaps that a feature checklist misses. A system may create a compliant-looking receipt while leaving managers without a reliable way to resolve a rejected invoice or reconcile a fiscal day.

Use the merchant's real taxpayer and product scenarios in a controlled test environment.
Confirm numbering, tax groups, QR or signature data and retained responses.
Define how corrections affect stock, payments and the original invoice.
Keep test evidence for the exact software, device and integration version.

Build a deployment evidence pack

Before a partner sells or installs the solution, create a small evidence pack for the target market. It should identify the official rule, applicable merchant type, approved integration route, tested version, support owner and last review date. Marketing language should stay within what that evidence proves.

Approval in a country, or for a particular taxpayer category, does not transfer automatically to another market. The same is true when an authority changes its API, security process or invoice format. Treat the evidence pack as a maintained operational record, not a static sales document.

Compare the practical choices

Capability, integration and approval answer different questions
Evidence	What it demonstrates	What it does not demonstrate
Product demonstration	The POS can perform a configured workflow.	Tax-authority approval or production eligibility.
Integration test	The tested version can exchange the expected data in that environment.	Approval for every merchant, device or market.
Official authorization	The named party or configuration has the stated status under the cited rule.	Permanent compliance after requirements change.
Production monitoring	Real transactions and exceptions are being reviewed.	That future updates require no retesting.

Official and primary sources

These sources support the regulatory or platform context in this guide. Always check the latest version before making a deployment decision.