Verifactu ERP connected to PrestaShop: what data flows and in which direction

The Spanish regulation on invoicing software (Real Decreto 1007/2023, the Royal Decree known as Verifactu, which sets the requirements for computerised invoicing systems) has forced many stores to ask a question they never used to ask: which program actually issues my invoices? If it is PrestaShop, the store is the invoicing system and has to comply. If it is an ERP, the ERP is the one that complies, and PrestaShop becomes a data source.

This article is about that second case: an ERP with Verifactu connected to the store. What it needs to receive, what can come back and where things usually break.

What the regulation requires, as far as integration is concerned

Without going into every detail, there are three ideas in the regulation that determine how the store connects to the ERP:

• Every invoice generates an invoicing record chained to the previous one, which cannot be altered without leaving a trace.
• The invoice carries a QR code that the recipient can use to verify it.
• The system that issues the invoice is the one responsible. It is not enough for one program to comply if the real invoices come out of another.

The practical consequence is that an issued invoice is final. If it goes out with the VAT wrong, it is not fixed by editing it: it is corrected with a corrective invoice (in Spain, a factura rectificativa, which cancels or adjusts the original), and that is also recorded. That is why the quality of the data coming from the store matters more than before.

A single source of invoices

The first integration mistake is not technical: it is having two systems issuing invoices for the same sale. PrestaShop generates its invoice PDF when the order moves to a configured status, and the ERP generates its own. The customer receives one, the accountant sees another and the numbering does not match.

If the ERP invoices, decide what PrestaShop does with its document: stop generating it, or let the customer download the ERP invoice instead of the native one. What must not happen is two different invoices circulating for the same sale.

From the store to the ERP

What the ERP needs from each order to invoice correctly:

• Customer: name or company name, NIF (Spanish tax ID) when there is one, billing address (not the delivery address) and country.
• Lines: reference, quantity, unit price excluding tax, VAT rate applied and line discount.
• Shipping and order-level discounts, each with its own VAT rate. A voucher that deducts a fixed amount from a cart with products at several rates is a classic source of mismatches.
• Total charged, which is the figure everything above has to add up to.
• Payment status and method, to know when to invoice and how to reconcile the payment.

The rounding problem

PrestaShop calculates taxes with its own rounding logic (per line, per product or on the total, depending on the configuration), and with some combinations of quantities, prices and discounts the sum of tax bases plus tax amounts does not match what was charged to the cent. If the ERP recalculates on its own, a one-cent difference appears; if it copies the amounts as they are, the invoice may show a tax amount that is not exactly the percentage of the base. Both end in manual work. The integration has to choose one rule and always apply it: the usual one is to respect the total paid and adjust the base so that it adds up.

From the ERP to the store

The reverse direction is optional and depends on each business:

• Invoices and corrective invoices so the customer can download them from their account.
• Order status if the ERP manages shipping.
• Stock and prices if the ERP is in charge of the catalogue.

For each piece of data, define who owns it. If stock can be changed on both sides, sooner or later they will overwrite each other. One piece of data, one owner, and the other system only reads it.

Returns and corrective invoices

This is where most integrations fail. A partial refund, a product exchange or a shipping refund in PrestaShop generates (or not) a credit slip in the store, but what has tax value is the corrective invoice issued by the ERP, linked to the original invoice. Before putting the integration live, test at least these cases with real orders in a test environment:

1. An order with several VAT rates and a fixed-amount voucher.
2. A return of one of several units in a line.
3. A return with and without shipping costs.
4. An order cancelled before invoicing and after invoicing.
5. A customer who asks for an invoice with their NIF after having bought.

How to start without surprises

Changing invoicing system is one of those things best done at a quiet time and with a clean cut-over:

1. Set a cut-off date. Until that day the previous system invoices; from that day, only the ERP. No running both “for a few weeks”.
2. Close the previous numbering and decide the new series with your accountant.
3. Review the orders still open on the cut-off date: will the ones paid afterwards be invoiced by the ERP?
4. Keep an eye on the first few weeks by comparing paid orders and issued invoices every day. Any difference shows up immediately and is fixed before it piles up.

Common mistakes

• Invoicing when the order is created instead of when it is paid: orders with failed payments generate invoices that then have to be corrected.
• Using the delivery address as the tax address.
• Integrations that retry without control and create two invoices for the same order.
• Several stores, a single configuration, without distinguishing which company invoices each store.
• An outdated store with old payment or tax modules that change amounts without the ERP knowing. Before integrating, it is advisable to have PrestaShop and its modules on supported versions.

How to handle it in PrestaShop

CoreGest is the ERP we develop at Rekire. It connects to PrestaShop, downloads the orders and registers each invoice in Verifactu without any typing. It corrects VAT rounding by adjusting the bases to the total paid, with at most one cent of deviation, and manages corrective invoices from the ERP itself. It supports several stores and several companies in a single account. The CoreGest ERP · Verifactu con PrestaShop plan includes what you need to comply with Verifactu from the store; CoreGest ERP completo adds the rest of the ERP modules: advanced POS, AI with your company's data, accounting, treasury and direct debit batches.