VeriFactu for your online shop. Which system issues the invoice?

A customer buys two products for €120. The next day, she returns one. You refund €45, the payment gateway confirms it and you close the order.

Later, when you check the invoicing software, all you can find is the €120 invoice. That invoice should still be there. The question is what happened to the €45: did the return reach the invoicing software, and did it issue the corrective invoice required for that return? Spanish invoicing regulations, Article 15

That’s a good place to start preparing your shop for VeriFactu. Before you choose a plugin or ask your provider for an update, find out what issues your invoices today and how it knows what happens to each order.

Open one of yesterday’s invoices

Pick an order you’ve already shipped and find its invoice. In a WooCommerce shop, it could have been issued by a WordPress plugin, the software you use to run the rest of the business, or an external service connected to your site.

Do the same with an order that included a return. The shop shows which product came back. The payment gateway tells you whether the money went back to the customer. The invoicing software shows how the transaction was documented. If your team handles any of this manually, look at who tells the invoicing team about the return and how they know it’s been dealt with. It’s worth getting that clear before you automate the process.

In WooCommerce, for example, selecting Manual refund records the refund on the order, but you still have to return the money separately. With an automatic refund and a compatible gateway, WooCommerce submits the refund through the gateway. In Shopify, PrestaShop or a custom-built shop, the buttons and integrations will differ. Your tax obligations depend on your business circumstances, whichever platform you sell through. Refunds in WooCommerce, Who the rules apply to, according to Spain’s Tax Agency

VeriFactu in 2027 or 2028. Which date applies?

Checked against Spain’s Official State Gazette (BOE) on 3 November 2026

• 1 January 2027. The current deadline for corporate income tax taxpayers covered by the rules, including Spanish limited companies (SLs) to which they apply.
• 1 July 2027. The current deadline for other taxpayers covered by the rules, including self-employed people to whom they apply.
• October 2028. The postponement announced by Spain’s Ministry of Finance on 5 October. The amendment has yet to be published.

Current deadlines in the BOE, Ministry of Finance announcement

The Ministry wants to align the work on invoicing software with the introduction of mandatory electronic invoicing between businesses and professionals. For those whose turnover for VAT purposes is no more than €8 million, the published date for issuing and receiving those invoices is 6 October 2028. Aligning the dates would let businesses plan both changes together. Each has its own requirements. Electronic invoicing timetable

What if the postponement isn’t approved in time? Spain’s general election is on 29 November and the new Parliament first meets on 23 December. That leaves nine days until 1 January, and forming a government is a separate step. The change could still be approved sooner. While Parliament is dissolved, for instance, Congress’s Standing Committee can ratify a royal decree-law. If the first deadline arrives without a new rule changing it, the affected companies must have adapted their systems by 1 January 2027. The current deadline for the other taxpayers covered is still 1 July 2027. Election decree, Congress’s ratification procedure

What the invoicing software has to do

If the rules apply to your business, the software must create a traceable record when it issues an invoice. In VERI*FACTU mode, it sends that record to Spain’s Tax Agency, the AEAT. In the other mode, it keeps the record with additional safeguards. One practical check is to ask your provider for the declaration of compliance for the software version you’ll use. If your business uses Spain’s SII VAT reporting system or falls under a regional tax regime with its own rules, check which requirements apply with your tax adviser. Modes explained by the AEAT, Software declaration of compliance, Scope of the rules

Three tests I’d run before touching the live shop

1. A normal purchase. Place a test order for two items and check that payment is confirmed. When it’s time to issue the invoice, check that it’s issued once, with the right details and amount. Note the order number and the invoice number. The next time someone asks about that sale, your team needs to be able to find the invoice for that order.
2. A partial return. Process the return of one item. Check that the gateway confirms the €45 refund and that the return reaches the invoicing software for the same amount. If a corrective invoice is required, check that you can identify the original invoice it refers to.
3. An order that fails to reach invoicing. Simulate an order coming in while the invoicing software is unavailable. Once it’s back online, see whether your team can find the order, work out if the invoice was issued and finish the job without duplicating it. A test purchase that goes smoothly from start to finish won’t show you that.

I’d run these tests on a copy of the shop, with fictional data and services in test mode. That gives you room to trigger the failure and repeat the test while the live shop carries on selling. Why use staging before publishing

There’s another time you’ll be glad you know where each system stores its data. Restore the shop from last night’s backup and the gateway and invoicing software may still hold this morning’s payments and invoices. Before processing a recovered order again, check what has already happened outside the website. Could you restore your website without losing today’s orders?

If you’d like to check how this works in your business, tell me what platform you use and which software issues your invoices. We can follow a sale and a return through your shop and see where the integration needs work. Tell me how your shop handles invoicing.