Verifactu for your online store: WooCommerce, Shopify, PrestaShop and Stripe

Your shop issues the invoice, not Stripe, PayPal or Redsys

The duty to invoice belongs to the seller. Article 2.1 of the Reglamento de facturación (the invoicing regulation, RD 1619/2012) requires every business owner or professional to issue an invoice for the goods and services they supply in their activity, and also for advance payments. If the product is yours and you sell it, the invoice is yours.

Payment gateways collect: they receive the customer's money, keep a fee and settle the rest with you. They invoice you for that service, and it is an expense of yours. The receipt Stripe or PayPal sends the buyer proves a payment, not your sale for IVA (VAT) purposes. How gross sales, fees and net payouts are booked is explained in the guide on accounting for an online store.

There is only one named exception, and it belongs to marketplaces, not to gateways: the two cases in article 8 bis of the IVA law in which the platform is treated as the seller. It is covered in selling through a marketplace. Outside those cases, even if a third party generates the document in your name, article 6 of RD 1007/2023 makes it clear that delegating does not release you: you remain responsible for compliance.

Verifactu on WooCommerce, Shopify and PrestaShop: which document comes out by default

An e-commerce platform is built to sell: catalogue, cart, payment and shipping. What it stores for each sale is an order, and what it usually sends the customer is a confirmation or a receipt. That document is not, by itself, an invoice with a chained billing record, a hash and a QR code. Many platforms let you add invoicing through extensions, and some generate a PDF they call an invoice out of the box: the name of the document says nothing about whether the system meets the regulation.

The AEAT (the Spanish tax agency) is clear in its frequently asked questions: online shops are affected, because it makes no difference whether the sale is physical or virtual. And article 1.2 of RD 1007/2023 defines the computerised invoicing system as the set of hardware and software used to issue invoices, accepting the information "by any method". If your shop, or something installed in it, produces the invoice, that is your invoicing system and it is the one that must comply.

Hence the question that organises everything else: which program issues the invoice for each order? Look at your real setup. It may be the platform itself with a module, an external invoicing application, or nobody, because right now only the order exists. The dates by which that program must be adapted are the usual ones: before 1 January 2027 if you sell as an SL (limited company) and before 1 July 2027 if you are an autónomo (self-employed), under Royal Decree-law 15/2025. The detail is in what Verifactu is.

The three ways to comply

1. Invoice from an adapted program that receives the orders. The shop keeps selling and the invoicing program receives each order, by API or CSV file, and issues the invoice with its chained record and its QR. The shop stops issuing its own invoices. It is the cleanest route if you sell through several channels, because all invoices come out of a single system with a single numbering.
2. A compliant platform module or plugin. The invoice is generated inside the shop, with an extension that creates the record, the hash and the QR. It works if the extension's producer publishes its declaración responsable and keeps it up to date with every version. This guide neither recommends nor rules out any specific module: the check is yours, and the list of questions is further down.
3. Invoice manually in an adapted program. If you sell few orders a month, you can copy each sale into a compliant invoicing program. It works, but it carries a risk: article 11.1 of the Reglamento de facturación requires the invoice to be issued at the time of the transaction when the buyer is a private individual, so you cannot accumulate orders and invoice them at month end. The AEAT's free application requires an identified recipient on every invoice, which makes it fall short for sales to consumers.

What you cannot do is mix them without control: if the shop issues its own invoice PDF and your program also invoices the same order, you have two invoices for one sale and two numberings. Decide which one issues and switch the other off.

Simplified invoice to the consumer, full invoice to the business

The type of invoice does not change with Verifactu: the system that issues it does. A private individual can be given a factura simplificada (simplified invoice) within the limits of article 4 of the Reglamento de facturación (400 euros including IVA in general, 3,000 in retail sales), with the prohibitions that same article places on certain intra-EU sales. The amounts and their exceptions are explained in invoicing in an online store.

When the buyer is a business owner or professional acting as such, article 2.2.a) requires an invoice in every case, and normally it will be a full one, with their NIF (tax ID) and address. The regulation also requires separate series if in the same year you issue both simplified and full invoices (article 7.1.a of the Reglamento de facturación). Your system has to tell the two cases apart before generating the document: a NIF field in the checkout solves most of it.

For Verifactu, both are invoices. Article 1.2 of RD 1007/2023 expressly says that the term invoice includes the full and the simplified one, so every ticket to a private individual generates its record and carries its QR just like an invoice to a company. If a customer asks for the full invoice afterwards, it is issued in place of the simplified one, with nothing to correct (article 15.6 of the Reglamento de facturación). Returns, by contrast, go with a factura rectificativa (corrective invoice), which also leaves its record.

The typical mistake: the refund leaves the gateway and nobody invoices

Under Verifactu, the chain of records only grows: nothing is deleted. That is why the most frequent failure of an online store becomes more visible. The customer returns the product, customer service issues the refund from the Stripe or PayPal dashboard and the money goes back, but no corrective invoice is issued in the invoicing system. The original invoice stays registered for the full amount and the IVA you declare is overstated.

The same happens with orders cancelled before shipping if the invoice for the advance payment had already been issued. A refund or cancellation after a valid invoice goes with a factura rectificativa (article 15.2 of the Reglamento de facturación); the cancellation record only applies if the invoice was issued by mistake (article 11.1 of RD 1007/2023). The practical rule is that every movement of money with the customer is reflected in the program that invoices, and that this program, not the gateway, generates it. If you use a module, ask its provider how it handles partial and full refunds; if you invoice from outside the shop, make sure the refunds also travel through the API or the CSV.

What to ask the provider of a module or plugin

Before installing an invoicing extension in your shop, get written answers to these questions:

• Where is your declaración responsable? It is the document in article 15 of Order HAC/1177/2024 and it must be visible inside the system itself. If they talk about an "AEAT certificate", be wary: it does not exist.
• Who is the producer? The statement identifies the producer by its NIF and the version of the system. If the module depends on an external service, ask who is responsible for each part.
• Which mode does it work in? VERI*FACTU, with automatic submission to the AEAT, or non-VERI*FACTU, with each record signed. The difference is in what Verifactu is.
• Does it generate full and simplified invoices in separate series? And the full invoice that replaces a simplified one?
• How does it handle refunds, cancellations and partial returns? They must end up as a corrective invoice; cancellation only applies if the invoice was issued by mistake.
• Does the QR appear on the PDF and in the email to the customer?
• What happens if the connection to the AEAT goes down? The Order provides that records are queued and resent.
• What happens when the platform is updated or the module is dropped? You must be able to export and keep the records; if you change system, the new one opens its own chain.

If any answer is vague, that is the data point. The fine for the user is 50,000 euros per year for having a non-compliant or altered system (article 201 bis, paragraphs 2 and 4, of the Ley General Tributaria, the general tax law), and the user is you, not the plugin developer.

How to choose between the three routes

Three questions are enough to choose:

• How many channels do you have? If you sell only through your shop, a compliant module may be enough. If you also sell in a physical shop, through a marketplace or on social media, centralising invoicing in a program that receives the orders from all of them avoids several chains and several numberings that later have to be reconciled.
• How many orders a month? Invoicing manually is reasonable with few orders and almost always to businesses. With daily sales to private individuals, the duty to invoice at the time makes it unworkable.
• Who keeps your accounts? The system that invoices and the one that does the bookkeeping can be different, but the invoices must reach the billing record and the issued invoices ledger intact. If every month you export and import by hand, that is where mismatches will appear.

Decide it in 2026, with room to test with real orders before your date. If you are an autónomo, your specific calendar is in Verifactu for autónomos. And if you also have a premises with a POS terminal, the guide on Verifactu in bars, restaurants and shops with a POS covers the in-person side.

Frequently asked questions

Keep reading