Verifactu across multiple restaurants: what you manage and what your POS should handle

With one restaurant, your invoicing setup barely registers. Then you open a second, then a third, and suddenly new questions come up. Does each site need its own invoice series? Can they all start from the same number? What happens when invoices come from several POS terminals? And who looks after Verifactu, Spain's new system for verifiable invoicing?

The good news is that most of the technical complexity won't land on you, so you can breathe a little easier. If you use compliant invoicing software, that work belongs to the system. It has to generate the records correctly and keep them intact and traceable. When it runs in Verifactu mode, it also sends them to the Agencia Tributaria, Spain's tax agency.

With several sites, your job is somewhere else: choosing software that's ready, getting each venue's invoicing set up properly, and keeping a consistent structure as you grow.

Let's take the two one at a time.

What the software is responsible for

Verifactu puts a fair amount of technology behind every invoice. That doesn't mean whoever runs the restaurant has to learn how to manage it.

The regulation requires invoicing software systems (known in Spain as SIF) to guarantee that invoicing records are intact, stored, accessible, legible, traceable and unalterable. They also have to be able to send those records electronically to the Agencia Tributaria.

In restaurant terms: you shouldn't be generating records, hashes or invoice chains by hand.

Your provider has to make sure the system gets things like these right:

• Generating the required invoicing records.
• Keeping them intact and traceable.
• Stopping them from being deleted or changed without leaving a trace.
• Handling the technical side of chaining records together.
• Building the required technical elements into invoices and receipts.
• And, if it runs in Verifactu mode, sending the records to the AEAT.

On top of that, the software producer must have a statement of compliance (declaración responsable) for the system and its version, confirming it meets the regulatory requirements. The Agencia Tributaria itself says that the user of a properly certified system isn't liable when something goes wrong because of the software. That responsibility lies with the producer.

That doesn't mean the restaurant has no responsibilities left. That would be nice, I know. It means the responsibilities are different.

What's still in the restaurant's hands

Your POS can keep a perfectly consecutive numbering sequence. What it can't do is decide for you how five restaurants should be structured, for tax or for operations.

The restaurant still has to make sure the data and settings the system works with match how the business actually runs. When you run several sites, four questions matter most:

Who invoices at each venue?

You need to be clear on which person or company issues the invoices at each site.

Which series will you use?

You can use different series when you have several venues. Within each series, numbering has to be consecutive. The regulation explicitly lists having different venues as a reason to split series.

What types of invoice does each site issue?

Standard, simplified and corrective invoices don't always follow the same structure. Corrective invoices, for example, have to be issued under their own series.

How do these rules get into the software?

Once you've decided, it has to be set up correctly in the POS, and kept that way as you add new locations.

In other words, you decide how your operation works; the software's job is to run that structure correctly.

I have several restaurants. Do I need a different series for each one?

Not necessarily, though it can make a lot of sense. The Agencia Tributaria says different series can be created when there's good reason, and specifically mentions businesses with several venues. Each series then keeps its own consecutive numbering.

For example, a group could work like this:

Madrid being on invoice 154 while Barcelona is on 83 isn't a problem. They're different series.

Your POS should assign the next available number in each series automatically. You shouldn't be checking by hand which number comes next after every service.

The decision you do have to make is whether that split fits your structure.

What is an invoice series?

A series is a way to group and separate invoices within one company. It's usually a few letters or a code in front of the invoice number.

For example:

• MAD-00125
• BCN-00084
• RECT-00012

Here, MAD, BCN and RECT are the series, and 00125, 00084 and 00012 are the invoice numbers.

Each series keeps its own consecutive numbering. So MAD-00125 should be followed by MAD-00126, but it doesn't need to line up with anything in the BCN series.

Series let you separate invoicing that follows different logic. In a restaurant group, for example, you can use them to tell each site apart. In some cases the regulation requires a specific series, as it does for corrective invoices.

The key is not to think of a series as "a different kind of invoice". Think of it as a separate numbering folder within your invoicing.

Don't create series just because you can

Once new sites start opening, it's easy to swing the other way and create a series for absolutely everything.

One per venue. Another per device. Another for the terrace. Another for delivery. Another because someone set one up three years ago and nobody quite remembers why. Two years later, nobody understands the structure. Series should follow a clear, stable logic.

If splitting Madrid, Barcelona and Valencia makes it easier to see each restaurant's invoicing, great. If several terminals are part of the same operation and there's no tax or operational reason to separate them, extra structure can add more noise than control.

The regulation itself also requires some separations. Corrective invoices, for example, use their own series. And when you issue both full and simplified invoices in the same calendar year, there are specific rules on keeping them apart too. That's where your software helps you get the structure right.

Several POS terminals don't necessarily mean several separate invoicing setups

This one matters a lot in hospitality. Having four terminals in a restaurant doesn't necessarily mean having four separate invoicing systems.

In the same way, having five restaurants in one organisation doesn't necessarily mean everything should run as one giant till.

Invoicing software can handle different invoicing streams and different sites. The AEAT's technical documentation explicitly covers systems that manage separate invoicing for independent sites, including different venues belonging to the same company.

As a restaurant operator, you don't need to define the technical architecture behind it. But you should be able to answer a much simpler question: Does my software correctly understand what belongs to each site?

That means being able to see which venue generated an invoice, which series it belongs to, which entity is invoicing, and how the system should behave when you add a new location.

What to check when you set up a second site

When you open a new location, try not to copy your first restaurant's invoicing setup across on autopilot.

A few things are worth checking one by one.

1. Who issues the invoices

Check which legal entity invoices from that venue. Two restaurants can belong to the same company or to different ones. The software has to be set up to match that real structure, not just the trading name over the door.

2. The right series

Decide whether the new venue will share an existing structure or use its own series. If you use one series per site, pick a naming system that still makes sense when you have ten restaurants, not just two.

MAD, BCN or stable internal codes are usually far easier to manage than making up a different name every time you open somewhere new.

3. Invoice types

Check how the system handles simplified, full and corrective invoices. You shouldn't have to keep their numbering in sequence by hand, but you should know which series exist and what each one is for.

4. The devices that will invoice

Define which POS systems, terminals or devices belong to the venue. It's worth checking they're still linked to the right site, especially when a group installs new hardware, replaces terminals or moves devices between restaurants.

5. Permissions

Not everyone should be able to change the tax settings. If you run several restaurants and each site can create new series or change invoicing settings without a shared structure, you'll end up with five different setups fairly quickly.

Decide who manages these changes and apply the same rules at every venue.

What good multi-site software should let you do

This is where running several restaurants starts to show the difference between a POS built just to take payments and a system built to run a growing operation.

You don't need to see all the technical complexity, but you do need control. At the very least, check that you can:

• Clearly see which series each venue uses.
• Manage several sites without mixing up their settings.
• Link devices and POS terminals to the right location.
• Work with different legal entities when the group's structure calls for it.
• Control who can change the invoicing settings.
• View each site's invoicing separately.
• Pull the whole group's figures together when you need the full picture.

The question isn't just whether the software "is Verifactu compliant". It's whether it can stay compliant without turning every new opening into a separate project.

And if there's a mistake, don't try to fix the numbering by hand

The technical side of correcting mistakes should also stay inside the software.

Systems covered by the RRSIF, Spain's regulation on invoicing software, are designed precisely so that original records can't be changed or disappear without a trace. The system has to preserve their traceability.

So if an invoice has already gone out with a mistake in it, the answer isn't to go into the settings and make it disappear, or to try to reuse its number.

Depending on the case, you'll need to make the appropriate correction or issue a corrective invoice. The restaurant needs to know what went wrong and how to fix it through the correction flow the software provides. The POS takes care of the technical side.

Who's responsible for what

Here's the simplest way to look at it:

There's a small but important distinction here.

The restaurant is still responsible for meeting its invoicing obligations, but it doesn't have to take on technical responsibility for a fault caused by a properly certified system. The AEAT puts responsibility for that fault on the producer.

That's why choosing the right software is part of getting ready, too.

The question isn't how to manage Verifactu by hand

This is probably the most important shift in perspective.

If you run several restaurants, you shouldn't be building an operation where someone has to check every night whether Barcelona's invoice 458 squares with Madrid's 932, or whether each terminal has built its records correctly.

That's the system's job.

Your job is to build a structure the system can run correctly: knowing who invoices, from where, under which series and under what rules.

And that matters more the bigger you get.

With one site, you can keep pretty much the whole setup in your head. With five, you start relying on processes. With twenty, you need those processes built into the system.

Opening another restaurant should mean adding a location, not adding another way to invoice.

Before anything else, ask your provider about Verifactu

If you still don't know how your POS will handle the new rules, that's probably the first thing to check. You don't need a twenty-page explanation of hashes or XML records, either. You need clear answers.

Ask whether their system will be adapted to the RRSIF in time for the relevant deadlines, whether they have the statement of compliance for the version you'll be using, and which operating mode they'll offer.

If it runs in Verifactu mode, you should also know how activation will work and what you'll need to do.

For many restaurants set up as companies and covered by the regulation, the general date that matters is 1 January 2027. For everyone else within the scope of the RRSIF, the general deadline is 1 July 2027.

There's not much point reaching those dates only to find out you need to change processes, update equipment or switch systems.

Verifactu in Last.app

Last.app has already built its Verifactu integration and is rolling it out so that this compliance layer is part of the system itself.

That's exactly the idea: the restaurant shouldn't need a second tool to sort out invoicing, or have to understand all the technical architecture behind every record.

If you already use Last.app, the thing to do is check availability and activation for your sites as the rollout progresses.

Frequently asked questions

I have two restaurants. Do I need two invoice series?

Not necessarily. The regulation allows different series when there are several venues, but it doesn't generally require one series per site. If it makes your invoicing easier to separate and control, it can be a sensible way to set things up.

Can two sites both have invoice number 100?

Yes, if they belong to different series. MAD-100 and BCN-100 are different identifiers. Numbering only has to be consecutive within each series.

Do I have to send every invoice to the Agencia Tributaria myself?

If you use invoicing software (SIF) running in Verifactu mode, the system itself sends the invoicing records to the Agencia Tributaria.

Do I have to keep track of the record chaining myself?

It shouldn't be a manual task for the restaurant. Generating the records, keeping them intact and traceable, and handling them technically are all part of the requirements the invoicing software has to meet.

How do I know if my POS is ready?

Ask your provider whether the system has been adapted to the RRSIF, and ask for the statement of compliance for the specific version you use. If it's going to run in Verifactu mode, also confirm when that will be available and what you'll need to do to activate it.

When does my system need to be adapted?

As a general rule, businesses that pay Spanish corporation tax (Impuesto sobre Sociedades) and fall within the scope of the RRSIF must have adapted systems in place before 1 January 2027. For everyone else affected, the general deadline is 1 July 2027.