Changing your POS without breaking your ZATCA compliance
A system migration touches the hash chain, your device certificates and your invoice archive. Here is the sequence that keeps all three intact, and the three mistakes that do not.
4 min read
Migrating a point of sale used to be about products and prices. Under Phase 2 it also touches three things the authority cares about: your device certificates, your invoice hash chain, and your archive.
Done in the right order, none of this is difficult. Done in the wrong order, it produces exactly the kind of gap that is hard to explain later.
The three things that must survive
1. Device identity. Certificates are per device and per system. Your new system needs its own onboarding for every terminal. The old certificates do not transfer.
2. The hash chain. Each system maintains its own chain per device. The new system starts a new chain; the old one ends. This is expected and correct — what must not happen is invoices issued from two systems on the same device, interleaved.
3. The archive. You must be able to produce old invoices after the old system is gone. Not "probably still in the vendor's cloud" — actually retrievable, by you.
The safe sequence
Before you cancel anything
- Export the full invoice archive from the old system. XML where possible, plus a readable format. Verify you can open and search it.
- Export master data — products, prices, VAT treatment per product, customers with VAT numbers, suppliers.
- Record the last invoice number and hash per device. Write it down. If a question ever arises about the join, this is the answer.
- Get the archive retention terms in writing from the outgoing vendor: how long will they hold your data, and can you get it later?
Cutover
- Onboard the new system's terminals in advance — CSR, OTP, compliance CSID, checks, production CSID. Do this before cutover day, not on it. See theonboarding guide.
- Choose a clean boundary. End of a trading day is ideal; end of a VAT period is better still.
- Stop issuing on the old system completely before the new one issues anything on that device.
- Issue a test invoice on the new system and verify: QR scans, totals correct, reporting accepted.
- Count stock on the day. The opening balance in the new system should be counted, not carried.
After
- Watch the acceptance dashboard daily for two weeks. Early rejections are configuration and are cheap to fix now.
- Verify a B2B invoice clears, not just that simplified invoices report.
- Keep the old archive somewhere you control, for the full retention period.
The three mistakes
Running both systems on the same terminal on the same day
This is the one that breaks the chain. Two systems issuing from one device produce two chains that interleave in time, and neither is continuous. Choose a boundary and respect it.
Cancelling the old subscription before exporting
Vendors are not obliged to keep your data available indefinitely after you leave, and some make retrieval a paid service. Export first, verify the export opens, then cancel.
Assuming stock will carry over
Even a perfect catalogue import does not mean your quantities are right. Count on the day. Every migration where the count was skipped ends with a month of arguments about whether the discrepancy is data or theft.
Parallel running — the right and wrong ways
Wrong: both systems live on the same terminals at once.
Right: the new system on one branch or one terminal, the old system on the rest, with a clean boundary per device. Run for a week, compare the daily reports, then move the next terminal.
The busiest branch goes last, not first. If something is wrong, you want to discover it where it costs least.
A short checklist
- [ ] Invoice archive exported and verified openable
- [ ] Master data exported, including VAT treatment per product
- [ ] Last invoice number and hash recorded per device
- [ ] Retention terms from the old vendor, in writing
- [ ] All new terminals onboarded before cutover
- [ ] Clean boundary chosen and communicated to staff
- [ ] Stock counted on cutover day
- [ ] Test invoice verified — QR, totals, accepted
- [ ] B2B clearance verified
- [ ] Acceptance dashboard watched daily for two weeks
What Wameed does to make this easier
Self-service per-device onboarding you run yourself; a catalogue import that reports what it could not match rather than silently dropping rows; an invoice archive you can export in full at any time, because the ability to leave is part of what makes staying a choice.
More on theZATCA page. For the commercial side of switching, see thepricing comparison.
Not tax or legal advice; confirm your position with ZATCA or your adviser.
- #migration
- #انتقال
- #ZATCA
- #switching
Ask about your own shop
Thirty minutes on your products, your tax setup and your hardware — not a slide deck.
Keep reading
5 min read
ZATCA Phase 2: the complete guide for Saudi merchants
What Phase 2 actually requires of your till, in plain language: the XML, the cryptographic stamp, the hash chain, clearance versus reporting, and the eight things to check before your wave arrives.
4 min read
Simplified vs standard tax invoice: which one are you issuing?
Getting this wrong is the most common Phase 2 mistake. The two invoice types follow different flows, carry different fields and have different deadlines — and your POS must choose correctly at the counter.
4 min read
The ZATCA QR code: what is inside it and how to check yours
The square on your receipt is a signed data structure, not a link. Here is exactly what it encodes, why Phase 2 added three fields to it, and how to verify your own printer is producing a valid one.