VeriFactu in Spanish hospitality: what it requires of a bar or restaurant POS and how to get it ready

VeriFactu's date has changed twice in the BOE (Official State Gazette), and on October 5, 2026 the Ministerio de Hacienda (Spain's Ministry of Finance) announced a third change that has not yet been approved. Some blogs insist it is already mandatory, and some POS websites say 2027 in the headline and 2026 in their own FAQs. This guide explains what the regulation demands of a bar's till and translates it into scenes you know: the coffee at the bar, the table asking for an invoice, the till close in the small hours.

Short answer: VeriFactu requires that every receipt from a bar or restaurant POS generate a chained record that cannot be erased and carry a tax QR code, and that cancellations leave a trace. As of October 15, 2026, no business is yet required to invoice with an adapted system. The BOE requires having one before January 1, 2027 if the business pays corporate income tax (Impuesto sobre Sociedades) and before July 1, 2027 in all other cases (Royal Decree-Law 15/2025). The Ministerio de Hacienda has announced that it plans to postpone the pending obligations until October 2028, without setting a day or clarifying whether it includes companies, and no rule has been approved. Since July 29, 2025, your POS provider can only sell you adapted software.

In 60 seconds

VeriFactu in Spanish hospitality, the essentials:

1. Status as of October 15, 2026: the BOE requires the system to be adapted before January 1, 2027 for corporate income tax payers and before July 1, 2027 for everyone else (Royal Decree-Law 15/2025). October 2028 is only a plan by the Ministerio de Hacienda, with no set day and no approved rule, and it does not clarify whether it includes companies.
2. The Ministerio de Hacienda announced that plan on October 5, 2026. The 2026 dates still circulating belong to an earlier calendar (Real Decreto 254/2025), replaced before it ever applied. The full calendar, with the status of each date in the BOE, is in When is VeriFactu mandatory?.
3. The obligation falls on the invoicing program: the POS must generate chained records that cannot be erased, with a tax QR code on every receipt. The hardware almost never changes.
4. Since July 29, 2025, any invoicing software sold must already be adapted. Ask for the compliance declaration.
5. There is no list of POS systems approved by the Spanish tax agency (AEAT): the model relies on the manufacturer's own compliance declaration.
6. The €50,000 fine per financial year punishes a specific case: a non-compliant system that also lacks the required certification, or is certified but altered. The lack of certification can only be penalized from each business's obligation date. Making or selling dual-use software has been punishable since 2021, at €150,000 for the manufacturer or reseller per financial year with sales and type of system.
7. Anyone who pays tax under the regional (foral) rules of the Basque Country or Navarre is outside VeriFactu: TicketBAI applies in the Basque Country, and in Navarre there is no equivalent system in force today. The Canary Islands, Ceuta, and Melilla do fall under it.

At Plattio, the restaurant management software that brings reservations, orders, payment, and invoicing together in a single system, we see the same pattern as with working time records. The venue that adapts in the low season sorts it out calmly. The one that waits until the last quarter ends up migrating its POS in the middle of the company dinner season.

How this guide was created

This guide rests on primary sources. From the BOE it uses Royal Decree-Law 15/2025 (Real Decreto-ley 15/2025), which sets the calendar in force, and the consolidated text of Real Decreto 1007/2023, the regulation on invoicing systems. It also uses Orden HAC/1177/2024, which sets out the technical detail, and the invoicing regulation (Real Decreto 1619/2012). For the Bizkaia dates it uses the Batuz definitive implementation calendar. From the AEAT it uses the information note on Royal Decree-Law 15/2025 and the FAQs, updated as of July 21, 2026. The postponement to October 2028 comes from the Ministerio de Hacienda information note of October 5, 2026, which announces it with no approved rule.

Royal Decree-Law 15/2025 was ratified by Spain's Congress on December 11, 2025. The bill that came out of that ratification lapsed when the Cortes (Spain's Parliament) were dissolved on October 6, 2026. The royal decree-law remains in force, and this guide dates every statement. It is an operational guide for restaurant operators, not tax advice. For your specific case (tax regime, activity headings, foral territory, open proceedings), talk to your tax advisor.

What you should take away from this article

• Certainty: the date that affects you according to the BOE, and where to follow the status of the postponement.
• Judgment: what really changes in a bar's till, from the QR on the receipt to cancellations that leave a trace.
• Process: how to get the venue ready before your obligation date, without waiting for the last quarter.
• Checklist: the exact questions to ask your POS provider, downloadable to bring to the meeting.

Your VeriFactu date, in brief

The practical rule for finding your date, as long as no other rule is published, is to look at how the business pays tax. If the restaurant is an SL (limited company), it files corporate income tax and must have its system adapted before January 1, 2027. If you are self-employed, you pay personal income tax (IRPF) and must have it before July 1, 2027, the same date as comunidades de bienes and other income-attribution entities. Capacity and headcount do not change the date. Anyone in the SII (Spain's real-time VAT reporting system), whether required to be or by voluntary opt-in, is outside VeriFactu, and so is anyone who pays tax under the foral rules of the Basque Country or Navarre.

What it would take for the postponement to become the legal date, and what would happen if January 1, 2027 arrives with no rule, are explained in the status of the VeriFactu postponement.

If you read January 2026 somewhere else, it is because VeriFactu has had three dates in the BOE, with two approved postponements, and has a fourth that has only been announced, with no set day. The October 6, 2028 date that is circulating is the date on which electronic invoicing between businesses (B2B) reaches all other businesses, according to the AEAT, and applying it to VeriFactu is an inference. The chronology, rule by rule, is in the four VeriFactu dates. When a website gives you a date, check whether it separates what has been published in the BOE from what has been announced, and when it was last updated.

What VeriFactu is and what changes inside the POS

VeriFactu is the popular name for the regulation that governs computerized invoicing systems (SIF in the rule's jargon). The POS software of a bar issuing receipts is one of these systems, so the regulation applies to it in full. What it demands, in practice:

• A record for every receipt. Every time the system issues a receipt or an invoice, it generates at that same moment a record with the fiscal data of the operation: issuer, number and series, date, type, taxable base, VAT, and total amount. The record also carries the date, time, and time zone of its generation.
• A chained hash. Each record carries a cryptographic hash calculated over its own data and over part of the previous record's hash. The chain makes it mathematically detectable if someone deletes receipts or slips them in after the fact.
• Nothing gets deleted. A receipt issued by mistake is cancelled with a record that leaves a trace. Errors in amounts or details are corrected with a corrective invoice. The system cannot allow deleting, renumbering, or rewriting anything already issued.
• A tax QR code on every receipt. Every receipt and every invoice coming out of the system carries, on paper or as a PDF, a QR code between 30 × 30 and 40 × 40 millimeters with the basic data of the operation. A structured electronic invoice carries it as a URL, without the graphic. It is mandatory in both modes, but it does not do the same thing in each. In VERI*FACTU, the customer who scans it checks the receipt against the records the AEAT already holds. In the retention mode there is nothing to check against, and scanning serves to put the invoice on record with the AEAT.
• The ability to submit to the AEAT. The system must be able to send its records to the AEAT automatically and securely, whether it works in submission mode or the AEAT requires them.

VERI*FACTU or the retention mode: which suits a restaurant

The regulation allows two ways to comply, and the choice matters because it changes the technical burden on the venue:

For almost any restaurant, the answer is VERI*FACTU. The classic argument against it, the venue's connectivity, is neutralized by the rule itself. If the internet drops you keep invoicing: the system queues the records and resends them with retries at least every hour.

Before switching anything on, bear in mind that testing does not tie you down. Article 16.5 of the regulation says the mode is kept at least until December 31 of the year of the first effective submission. One of the AEAT's FAQs repeats that rule. But the AEAT's information note and another of its FAQs clarify that this lock is not turned yet. Until your obligation date you are in a trial period and you can stop submitting whenever you want. Careful with the word "trial": the invoices you issue in those months are real invoices, with their QR code and their records genuinely submitted. The AEAT's pre-production environment, which really does have no fiscal effect, is a different thing and is meant for developers. And the VERI*FACTU legend on the receipt can only be displayed while you are genuinely submitting.

What VERI*FACTU saves you from keeping is the invoicing records already submitted, not the invoices. Keeping the invoices you issue and receive and the record books is still your obligation, as a general rule four years under tax law and six from the last entry under the Commercial Code. There are cases with longer periods, so treat these as minimums.

The venue's day to day, scene by scene

Generic VeriFactu guides are written for accountancy firms. A restaurant has its own case book, and this is where it gets decided whether the adaptation hurts or goes unnoticed.

The coffee at the bar is a simplified invoice

The everyday receipt is, for the rule, a simplified invoice (type F2). Hospitality has an explicit privilege in the invoicing regulation: it can issue one for up to €3,000 including VAT, against the general limit of €400. With VeriFactu the type of document stays the same, and every receipt, even a €1.50 coffee, generates its chained-hash record at the moment it is issued.

The waiter charges the wrong amount

Charging table 4 twice, slipping a soft drink onto the wrong bill, closing with the wrong total: all of that will keep happening. What changes is how you correct it. The wrong receipt is cancelled with a record that leaves a trace, and the amount is corrected with a corrective invoice. There is a third case that does not touch the invoice. If only the record is wrong (a badly transferred detail when the entry was generated, with the receipt itself fine), the system issues an amendment record that corrects the previous one, with nothing cancelled or rectified. If your current POS fixes mistakes by making the receipt disappear, that gesture is exactly what the rule is after.

Comps and discounts

The comp for the regular and the lunchtime discount stay, but they can no longer be applied by reopening closed bills. The clean practice is to record them as explicit lines before closing the bill, with their reason, and to review with your advisor how comps are treated for VAT. A closed bill is an issued record, and an issued record does not get touched up.

The company dinner asks for an invoice

If the recipient is a business and asks for one, they are entitled to a full invoice. If the receipt is already printed, it stays in the chain and the system issues a full invoice that replaces it, recorded under type F3. Referencing the number, series, and date of the replaced receipt is advisable for traceability, but the AEAT treats it as optional, so a POS does not breach the rule by skipping it. Like any full invoice, the F3 does have to identify the recipient: name or company name, tax ID (NIF), and address. And there is a route that saves the whole swap. If the table says so before the bill is closed, the receipt can be issued from the start with the customer's NIF, address, and itemized VAT amount, and it is born directly as an F1 record, with no swap to handle. Check that your POS handles both during service itself, because the whole of December consists of tables asking for an invoice at midnight.

The till close in the small hours

The Z report remains useful as an internal control: cash count, expected cash, mismatches. The close that cleans things up is gone. VeriFactu records receipt by receipt, and a close that makes operations disappear turns the POS into dual-use software, banned since 2021. The correct order is to reconcile the Z against the system's records, never the other way around.

Terrace, card terminal, and pre-bill

VeriFactu records the issuing of the receipt, and it makes no difference how it is paid: cash, card, or Bizum (Spain's mobile payment system). The card terminal is not part of the invoicing system. The delicate point on the terrace is a different one. The pre-bill carried to the table is not an invoice, and the habit of charging on the proforma without ever issuing the final receipt runs out of room. The real receipt, with its QR, must come out of the system.

Delivery platforms

If you work with delivery platforms, who invoices the end customer depends on the contract. There are models where you invoice the platform and models where the platform invoices on your behalf, and in the latter case those records must comply with the regulation too. It is worth rereading the contract and checking that platform sales enter the system without duplicating the dining room receipts.

Tips

A genuinely voluntary tip, the one the customer decides to give and to quantify, is not consideration for the service: it stays outside the VAT base and, for that reason, does not go into the invoicing record. That is the doctrine of the Dirección General de Tributos. Ruling 2174-03, of 2003, settled it precisely for restaurant tips. V3095-17, of 2017, now binding, fixed the same criterion, and V1808-22, of 2022, reiterated it in a different case, voluntary contributions to a website. A charge imposed by the house is a different matter (cover charge, terrace supplement, "service included"): that is price, it goes on the receipt and is taxed like everything else. From here on comes an operational recommendation of ours, which the regulation does not require. If the tip comes in through the card terminal, do not put it on the receipt and track it in a separate internal control, so the till reconciles against the system's records. Check with your advisor how to share it out and how to treat it in payroll.

Do you have to change your POS for VeriFactu?

You almost never need to change the equipment, because the obligation falls on the program that issues the receipts. The touchscreen, the cash drawer, the thermal printer, and the card terminal are not regulated. If your provider updates your version to a compliant one, you change nothing else.

Since July 29, 2025, anyone selling you invoicing software can only sell it adapted, and no official approval (homologación) exists to vouch for it. The Spanish model relies on a declaración responsable, a formal compliance declaration: the manufacturer declares, under its own responsibility and for each version, that the system meets the regulation, and that declaration must be visible inside the program itself. The sales line "approved by the AEAT" is a warning sign, because that approval does not exist. And the right question for your provider is not "do you comply with VeriFactu?" but "show me the compliance declaration for the version I have installed".

Signs that your current POS is not going to make it to your obligation date:

• The provider gives no adaptation date and shows no compliance declaration.
• The system currently lets you delete or renumber issued receipts.
• It does not distinguish a cancellation from a deletion.
• It cannot issue a substitute invoice from a receipt.
• The company has gone months without publishing an update.

Each one alone is uncomfortable. Together they sketch a forced migration in the worst possible quarter.

Self-employed with a bar: modules, paper receipt books, Excel, and the AEAT app

Four questions keep coming up among self-employed bar owners, and all four have short answers.

Under modules, it depends on how you invoice. As a general rule, under the modules regime (estimación objetiva) you do not have to invoice consumers (article 3.1.c of the invoicing regulation). And if your POS only issues receipts that are not invoices, the Dirección General de Tributos leaves it outside VeriFactu (ruling V0665-26). If your POS prints simplified invoices, or you make invoices with a program even though you are not required to, that system must be adapted by your date, which for the self-employed is before July 1, 2027 according to the BOE. And a business customer must always be given an invoice.

The paper receipt book is still valid. VeriFactu regulates computerized invoicing systems; it does not force you to buy one. The bar that issues every receipt by hand, from a receipt book, sits outside the regulation.

With Excel it depends on the use. Here the AEAT has put in writing where the line is drawn. If the spreadsheet is used only to enter the invoice data, issue and print the invoices, and keep the information, including listings with totals and other calculation rules, the regulation does not affect you. It becomes a computerized invoicing system when you also use it to process that data and generate directly the VAT or personal income tax record books, the accounts, or any other output you use to meet tax obligations. The example the AEAT itself gives is a macro that builds the record book of issued invoices. Once that line is crossed you do have a problem: a spreadsheet cannot sustain the chained hash or the inalterability, and it is time to change tools. In a bar, in any case, what usually decides the matter is the POS the receipts come out of.

And the AEAT's free application is no use for the bar. The AEAT has a free invoicing application, but it requires identifying the recipient on every invoice and, because of that, it does not issue simplified invoices. It says so itself: "Every invoice must include a recipient, so it is not possible to issue simplified invoices (receipts)". It only allows full invoices, corrective invoices, and invoices substituting a simplified one. In a bar, where almost everything going through the till is a receipt, it is left for the occasional full invoice the company in the private room asks for. There is a second reason not to build the business on top of it: the records cannot be exported to another program, so if you start there and later switch, the history stays inside.

Penalties: what is at stake

The penalty regime has two tiers. The new tier is article 201 bis of the Ley General Tributaria (LGT, Spain's General Tax Law), created by the 2021 anti-fraud law. It has to be read in full, because it does not punish "not complying with VeriFactu" in general. The POS manufacturer or reseller risks €150,000 per financial year with sales and per type of system. That is the fine for making or selling software that can hide sales, keep double books, or alter records already issued, or that does not meet the technical specifications. Selling uncertified systems when certification is due costs it €1,000 per unit.

For the restaurant, the fixed fine of €50,000 per financial year punishes a specific case: a system that does not meet what article 29.2.j of the LGT requires and, on top of that, is not duly certified when it should be, or is certified but someone has altered it. Under VeriFactu, certified means the manufacturer has issued the compliance declaration for that version.

The timing nuance matters. The strand tied to the regulation has applied to the manufacturer since July 29, 2025. For the restaurant, the lack of certification can only be penalized from its obligation date, which the BOE currently sets in 2027. The ban on dual-use software, by contrast, has applied since October 2021. A POS that lets you delete sales today is already punishable without waiting for VeriFactu, although manufacturer and business answer for it down different routes. The manufacturer that sells it faces article 201 bis, in force since 2021. The business that uses it to hide sales may face today, among others, the infringements of the classic tier.

The classic tier is article 201 of the LGT, the one already applied every day. Failing to issue or keep receipts and invoices is a serious infringement, with a proportional fine of 2% of the amount of the operations affected (€300 per operation when the amount is unknown). Issuing them with incorrect data costs 1%, and invoices with false data, 75%. When the breach is substantial, the rule itself doubles the fine (paragraph 5 of article 201). This is the route used today to penalize a bar for not handing over a receipt, and it waits for no calendar.

VeriFactu is not B2B electronic invoicing or TicketBAI

Three different rules circulate mixed together in conversations, blogs, and even the odd POS website. Each one regulates a different thing and switches on at a different moment:

The most expensive confusion is the first column against the second. VeriFactu regulates how the receipt is born. Electronic invoicing between businesses (B2B) under Real Decreto 238/2026 regulates how the invoice travels between businesses, in a structured format and with tracking of its acceptance and payment statuses. A restaurant will end up living with both, each at its own pace, and no serious provider will sell them to you as if they were the same thing. The countdown for the second started on October 6, 2026, when Orden HAC/1028/2026 entered into force. According to the AEAT's calculation, the obligation arrives on October 6, 2027 for those who exceeded €8 million in volume of operations in the prior year and on October 6, 2028 for everyone else. The self-employed and comunidades de bienes up to €8 million do not have to report invoice statuses and payments until October 6, 2029. The two calendars, side by side, are in the table of VeriFactu and B2B electronic invoicing dates. The third column has its own foral source: the Bizkaia phases can be checked against the official Batuz implementation calendar.

How to get your restaurant ready before your date, without waiting for December

With the date still ahead, the sector has room to adapt without rushing. These are the seven steps, designed to be done out of season.

1. Find your obligation date

Until another rule is published, your date is the one in the BOE. If the business pays corporate income tax, it must have its system adapted before January 1, 2027; if you are self-employed or a comunidad de bienes, before July 1, 2027. The Ministerio de Hacienda has announced a postponement until October 2028, with no set day and no approved rule, and without clarifying whether it includes companies. Anyone who pays tax under the foral rules of the Basque Country or Navarre is outside VeriFactu: TicketBAI applies in the Basque Country, and in Navarre there is no equivalent system in force today. Anyone in the SII, whether required to be or by voluntary opt-in, is also outside. Write it down and leave yourself some leeway: the company date falls right after the Christmas rush, the worst moment to break in a new POS.

2. Ask your provider for the compliance declaration

Ask for the declaración responsable covering the exact version you have installed and a written commitment to adapt to whatever technical changes come. If your provider does not have it yet, ask for a written date for having it before your obligation date. Remember that since July 2025 they cannot sell you anything else.

3. Check the record types a restaurant uses

The hospitality simplified invoice, the swap to a full invoice without deleting the receipt, corrective invoices, and cancellation with a trace. Ask to see the flow with a real table scenario: the generic office demo does not show the swap from the F2 receipt to the F3 invoice, which is exactly what December puts to the test.

4. Choose your mode: VERI*FACTU unless you're the exception

Submission to the AEAT simplifies signatures, event logs, and retention. On top of that, the regulation presumes that the system meets the technical requirements of its article 8 by design (presumption in article 16.2). That presumption only covers the program, and your taxes stay outside it. Ask how the system behaves when the internet fails and how the manager can see there are records in the queue.

5. Test the real flow at the venue

A QR that scans cleanly on the 58 or 80 millimeter thermal roll, a final receipt issued at the table, comps and discounts as explicit lines. Everything that fails in a quiet Tuesday test will fail multiplied on a Saturday night.

6. Reconcile the till close against the records

Redefine the nightly ritual: the Z report is internal control and the system's records are the fiscal truth. Reconcile what you counted against what was recorded and treat mismatches as that day's incident. If the cash count already lives in the same system as the orders, this step takes minutes.

7. Train the team and debut voluntary submission in the off-season

For the team, two gestures change: cancelling leaves a trace and the business invoice is made from the receipt. For the business, it pays to debut voluntary submission in a quiet month. Until your obligation date you can switch it off if something does not fit. Under the AEAT's specific guidance, only those who start submitting once they are already obligated must keep the mode until December 31.

Download the checklist for the meeting with your provider. VeriFactu checklist for a restaurant POS in CSV (in Spanish). Open it in Excel, Google Sheets, or Numbers: it gathers the questions in this guide with the reason behind each one and the answer you should be getting, ready to tick boxes in the meeting itself.

Want to see how this looks in a system built for restaurants? See Plattio's POS.

How Plattio fits into this flow

Plattio's invoicing is integrated with the Spanish tax agency's system through VeriFactu, in Spain only, and complies with Real Decreto 1007/2023 in the VERI*FACTU mode. It lives in the same system as the orders and the payment, so the receipt is born where the sale is born.

The till close is integrated with Orders and covers cash and card. It includes opening with a float, the shift's movements with their withdrawals, counting by coin and note denomination, expected cash and card with reconciliation against the card terminal's batch close, the shift's mismatch, and a history of closes. It is the order step 6 asks for: what was counted against what was recorded, every night, on the same screen.

And if you are putting the venue's compliance in order more broadly, this guide has a sibling: the guide to digital time tracking in Spanish hospitality, another rule with its own calendar that is best left resolved before the date starts to squeeze.

Practical summary

• Status as of October 15, 2026: the BOE requires the system to be adapted before January 1, 2027 for corporate income tax payers and before July 1, 2027 for everyone else (Royal Decree-Law 15/2025). October 2028 is only a plan by the Ministerio de Hacienda, with no set day and no approved rule, and it does not clarify whether it includes companies.
• The 2026 dates in circulation belong to a replaced calendar. Always demand the rule, its status in the BOE, and the update date.
• The obligation falls on the software: records receipt by receipt, a chained hash, cancellations with a trace, and a tax QR. The hardware almost never changes.
• Since July 29, 2025, your provider may only sell you adapted software, and the document that proves it is the manufacturer's compliance declaration, because official approval does not exist.
• For a restaurant, the VERI*FACTU mode wins: less technical burden, a presumption that the system meets the technical requirements of article 8 by design, and a customer who can check their receipt. According to the AEAT, testing it now does not tie you to the mode until your obligation date.
• VERI*FACTU saves you from keeping the records already submitted. The invoices and the record books are kept just the same: as a general rule four years under tax law and six under the Commercial Code.
• Under modules, VeriFactu only reaches you if you invoice with a program or a POS, and the handwritten receipt book stays outside. With Excel it depends on the use: it only falls under the regulation if it also generates record books or accounts.
• The AEAT's free application does not issue receipts, so it is no substitute for the POS behind the bar.
• The €50,000 per financial year punishes a specific case: a system that breaches article 29.2.j and that also lacks the required certification or is certified but altered. The lack of certification can only be penalized from your obligation date. Making or selling dual-use software has been punishable since 2021; a business that hides sales may face today, among others, the infringements of article 201.
• The months left until your date are the window: adapt in the low season, with voluntary submission tested before the Christmas rush.

Leave your invoicing resolved before the date decides for you

The venues that cope worst with a regulatory change tend to be the ones that start in the last quarter. Adapting your invoicing now, out of season, turns your obligation date into just another day.

See Plattio's POS · See a guided demo