What Veri*Factu is and when it applies to you
Veri*Factu (Spain's verified invoicing rules. Spain only) is the Spanish tax agency's (AEAT) system for invoicing records, set out in Royal Decree-law 15/2025. It becomes mandatory on 1 January 2027 for businesses that pay Spanish corporation tax, and on 1 July 2027 for everyone else it covers. It only applies in Spain: outside Spain, you leave it switched off
For a bar or restaurant, the change shows up where you take the most money: on the receipt. Each sale stops being an entry you can touch and becomes a record that can't be redone. If you're unsure how it applies to you, your accountant is the best person to ask
What changes on your receipt
In Omakasia, Veri*Factu is built into the POS. Every paid sale creates its own record, chained to the previous one, with its own fingerprint. The receipt carries the venue's tax details at the top, the breakdown of base and VAT by rate, the tax QR code and the VERI*FACTU legend. The QR isn't something you set up: the rules require it
The record isn't produced by the device taking payment. It's generated from the sale once it has been saved, so nobody can rewrite it from the till. And menu prices include VAT: the tax is worked out from within and rounded once on the total, so the receipt and the record show the same figure
There's a check before you start. Omakasia won't let you switch Veri*Factu on if any menu family has no VAT rate, and it tells you which ones. Better to find out when you switch it on than on a receipt
Why a paid sale can't be edited
In Omakasia, money that has been taken is never deleted or rewritten. It isn't a technical limitation: it's a design decision, pointing the same way as Veri*Factu. A sales record is only reliable if nobody can change it afterwards: not an employee, not the owner, not the software provider
The audit screen puts it in one line: a record that can be edited isn't an audit, it's a notebook. Once a line is written, it can't be changed or deleted, by you or by Omakasia support
This protects you as well. If sales can't be touched, nobody can make a receipt disappear at the end of a shift, and the numbers you see are the ones that actually happened
So how do you fix a mistake?
With another document, never by deleting the first one. If money has to be returned, you issue a credit note from POS › Receipts › Paid, with the Credit button. The screen explains it like this: it doesn't delete the receipt; it issues a new document, with its own number, that says the opposite. The same lines in negative, and the money returned the way it came in. Both documents stay
If a receipt was issued by mistake, the right move is different: cancel its record in Veri*Factu. A cancellation record is created, chained to the receipt's record. The receipt and its number still exist, and the cancellation is logged in the audit trail, along with who did it
Example · At Bistró Nora, a made-up venue in Valencia, a group pays for lunch and, after a problem with the service, the venue decides to refund them. The manager opens the receipt under Paid receipts, presses Credit, types the reason and issues the credit note. The original receipt is still there, so is the credit note, and the till balances
Everything that moves money, on record
The audit trail also records each event where it happens: the paid sale, a manual discount, an on-the-house item, opening and closing a shift with its cash count, a gift card, a price change and a change of access. Each one with who did it
Veri*Factu comes on every receipt from the Omakasia POS, at €20 a month, with kitchen displays and a QR menu. See it on the POS page
Venues and people in the examples are made up
See POS