Phase 1 asked restaurants to produce compliant electronic invoices. For most groups that was a software update and a new receipt layout. Phase 2 asks something structurally different: the invoice has to reach the Authority’s platform, and for standard invoices it has to be cleared before it is handed to the customer.
Short on time
Ask about failure states
A successful test invoice does not show what happens when connectivity fails.
Check the queue
Pending invoices need a visible status and an owner for follow-up.
Test credit notes
A corrected order should stay linked to the original sale.
Assess POS in service
Practical compliance includes how the team handles errors, not just initial setup.
The difference that matters operationally
In Phase 1 the POS could be sure of the outcome at the moment it printed. In Phase 2 an external system is in the path. That introduces a state the branch has never had to handle before: an invoice that has been issued but not yet confirmed.
Where implementations go wrong
The compliance work is finished before the operational work starts.
Integration is generally delivered as a project with a go-live date, and it succeeds on that date under supervision. The failures appear weeks later, on a Friday evening, when connectivity drops at one branch and nobody has decided what the queue should do or who should be told.
That is not a compliance question. It is an operations question, and it is worth answering before it is asked by circumstances.
Questions to put to whoever is implementing
Treat it as part of the POS, not beside it
Where e-invoicing runs inside the POS rather than as middleware alongside it, the pending state is a state the POS already understands, and there is no second system for finance to reconcile at month end. That is the practical argument for keeping it in one place, and it is an operational argument rather than a regulatory one.
ROI calculator
Four inputs, and the workings stay on screen.
Open the calculator
