What MTCA actually wants from your POS in 2026

If you run a restaurant, café or retail shop in Malta, the Malta Tax and Customs Administration (MTCA) cares about exactly one thing from your POS: that every receipt is real, sequential, and impossible to quietly alter. Most days the rule is invisible. The day someone audits you, it is the only rule in the room.

This is the checklist we wish we had when we started building VIND. No jargon, no acronyms-without-explanation, no “consult your accountant” wave-offs.

1. Every receipt has a number, and the numbers never skip

The receipt your POS prints — the slip the customer takes home — must carry a unique number. That number has to be strictly monotonic: 1, 2, 3, 4, with no gaps. If a receipt is voided you don’t reuse its number; you issue a separate Void → Credit Note pair, and both stay in the record.

This is the single rule that catches the most POS systems out. A well-meaning developer thinks “if a payment fails, let’s just not number the receipt.” MTCA’s view is that the gap is the problem, not the solution. A sequence gap in your fiscal log is something a tax inspector can ask you to explain, and “we deleted it” is the wrong answer.

In VIND, numbering is pre-allocated in blocks at clock-in. The terminal owns its range locally and consumes numbers sequentially — even when the network is down. When the shift closes, we reconcile the range against the server, and any unused numbers are released. There is no path that lets a number get lost.

2. The receipt body has the things MTCA expects to see

Receipts must include:

• VAT number of the issuer, your trading name and address.
• Date and time of the sale (with seconds — disputes happen).
• A per-line breakdown: item, quantity, unit price, VAT rate, line total.
• Subtotal, VAT amount, total in EUR, and the rounding rule applied.
• The sequential receipt number.
• A QR code with the cryptographic signature, so an inspector can verify the receipt at a glance.

The Maltese VAT rates that come up in hospitality are 18 %, 7 %, 5 %, and 0 %. A pizza is 18 %; the bottled water served with it is 18 %; bread sold to take away is 5 %; a printed magazine is 5 %; a child’s vaccination at a pharmacy is 0 %. Your POS has to apply the correct rate per line — and any item-creation flow that silently defaults to 18 % is a problem waiting for an audit.

3. Z-readings, every day, no exceptions

At the end of every business day, your POS must produce a Z-reading: a cumulative total of every receipt issued that day, broken down by VAT rate, plus a closing fiscal stamp. The Z-reading is what proves your daily takings number. It is signed, immutable, and archived.

Two questions to ask any POS vendor:

1. What happens if I forget to close the day? A real fiscal POS auto-closes the day at the configured cutover time (often 02:00 or 04:00 for late hospitality) so a forgotten close doesn’t bleed into tomorrow’s total.
2. What happens if a Z-reading is mid-flight when power is cut? It has to be atomic — either the Z is complete or it never happened. There is no “half-Z”.

VIND emits Z-readings atomically and archives them in a WORM (Write-Once, Read-Many) store: once written, no one — not the cashier, not the owner, not us — can modify a Z that’s been issued. That’s not “we choose not to”; the schema literally has no UPDATE path.

4. Voids and refunds are paired, not deletions

If a customer changes their mind ten seconds after you ring up an order, the wrong move is to delete the receipt. The right move — and what MTCA expects — is to issue a Void Receipt that cancels the first one, and then a Credit Note if money has actually changed hands. Both documents persist in the fiscal log. The pair tells the inspector a complete story: “this was rung up, then cancelled, no funds moved.”

If your current POS lets you “edit and reprint” a receipt after the fact, it’s a compliance liability and a refund-fraud surface. Walk away.

5. Seven years of archive — and you control it

MTCA’s archive period for fiscal data is seven years. Most cloud POS vendors will tell you they archive “in their data centre”, which is fine until you change providers and discover you can’t take your data with you. The right setup is:

• The fiscal store is yours, in your tenant, in the EU.
• You can export the whole archive as a signed, machine-readable file at any time.
• The vendor cannot read or modify your fiscal data even with admin access (we use HMAC-SHA256 signatures per receipt; tampering invalidates the signature).
• If the vendor is acquired or goes bust, the export still works.

VIND runs in eu-central-1. The store is structurally append-only. Export is a single command (vind export --tenant=foo --year=2026).

The five gotchas that catch people

1. “We void receipts by deleting the row.” No. Paired Void → Credit Note.
2. “We let cashiers reset the receipt number on a slow day.” No. Numbers come from a pre-allocated range.
3. “VAT defaults to 18 % so the cashier doesn’t have to think.” Costs a 13-point VAT margin to fix when a 5 %-rated item is sold as 18 %.
4. “We auto-close the day at midnight.” Hospitality closes at 02:00 or later. Move the cutover.
5. “We back up fiscal data weekly.” A weekly backup is a six-day audit gap. Stream-write to the WORM store, not nightly batch.

Where VIND sits

Every one of the rules above is implemented in @fluzzio/business and services/fiscal-processor. The MTCA page walks through the sequence-numbering, HMAC signing, and Z-reading flow with the source-of-truth receipt sample. The pricing page is on /pricing — every tier ships MTCA compliance, because compliance is not an upsell.

If you’re switching POS this year, ask the vendor each of the five gotchas above. If you get a wave-off on any of them, you’ve got your answer.