For software vendors26 August 2026

If your program issues invoices, you are the one signing the responsible declaration

Almost everything written about VeriFactu is aimed at whoever issues the invoice. But the rules have a second addressee who gets talked about far less: whoever builds the program. If your ERP, your point-of-sale system or your vertical software issues an invoice, this reaches you, and not far off.

The conversation usually starts the same way. Somebody writes to us saying “we are not invoicing software, we are garage management software —or clinic, or training-centre software— that also produces invoices”.

And there is the problem: for the purposes of Royal Decree 1007/2023 that is precisely an invoicing software system. It does not matter that it is 5 % of your product or that a client asked for it eight years ago. If your program produces the invoice, your program is a SIF.

What you sign when you are the producer

The part that surprises people is the responsible declaration. Article 13.2 of Royal Decree 1007/2023 requires the system to carry a declaration, signed by its producer, stating that it complies with the regulations. It is not signed by whoever uses it: it is signed by whoever makes it.

And it is not a loose sheet of paper. To be able to sign it, the program has to do all of this:

None of that is impossible. The point is that it is not your product. It is a whole project, with rules that change, with the tax office as your counterpart, and with a liability you sign for and your company answers for.

Your deadline is not your clients' deadline

This part often gets miscalculated. The VeriFactu dates are 1 January 2027 for corporation-tax payers and 1 July 2027 for everyone else.

But those are the dates by which your clients have to be issuing correctly. For them to get there, your software has to be ready, tested and deployed beforehand. If you have clients that are limited companies —and almost all vertical software does— your real deadline is not January 2027: it is the autumn of 2026, with room for them to test it.

Put another way: the time left is not a year and a bit. It is a few months.

The three ways out

There are not many more, and it is worth looking at them with the figures in front of you.

1 · Build it yourself

It is legitimate and some will do it. Budget for the hash chain, the QR code, the SOAP client against the AEAT, certificate management, retries, the event log, and tracking every regulatory change from now on. Plus the responsible declaration with your name on it.

If invoicing is the heart of your product, it is probably the way to go. If it is one tab, you are setting up a company inside your company.

2 · Stop issuing

Take invoicing out of your program and let the client do it somewhere else. It is the cheapest way out in development terms and the most expensive in product terms: you are asking your user to leave your software, and once they are out they may not come back.

3 · Call a certified API

Your program is still your program and makes a call when it is time to issue. The numbering, the chained hash, the QR code and the filing with the AEAT are supplied by the certified system, and the responsible declaration is signed by its producer — who in that case is not you.

That is Motor API. One call:

POST https://api.factuza.com/facturas
X-Api-Key: …
Idempotency-Key: pedido-8842

{ "nifEmisor": "B12345674",
  "destinatario": { "nif": "12345678Z", "nombre": "Ana Ruiz" },
  "base": 1250.00, "tipoIva": 21 }

And the response carries the series number, the hash, the QR URL and the path to the PDF. However long the AEAT takes to answer happens in the background, and when it does answer we notify you by webhook: the 201 only says “received and queued”, and nobody polls invoice by invoice.

What we are not going to tell you on the front page

As in the rest of this blog, the uncomfortable part gets written down.

The sandbox is requested by email

It is free and never expires, but it is not self-service yet: you write to us and we give you access. The same goes for signing up to a plan: today it happens by talking, not with a button. We would rather say so than have somebody looking for a form that does not exist.

A tax number can only be registered once

A taxpayer's hash chain is a single chain. If a client of yours is already issuing through another system with that tax number, they cannot also be in yours at the same time: somebody has to decide which one issues. It is not a limitation of ours, it is how chaining works.

Your clients' data is neither yours nor ours

The taxpayer is the issuer, and their invoices are theirs. We are the system and you are the integrator, but the owner of that data is them. That has consequences in the contract which are worth looking at before signing, not after.

And one that belongs to both sides

The split of responsibilities under Royal Decree 1007/2023 in this model —us as producers of the system, you as distributor— is our reading of the rules and the one the product rests on. It is coherent and it is the usual arrangement in software as a service, but if your legal advisers want to review it before you integrate, that is fine with us and we will help. It is your liability you are moving; looking at it twice is the sensible thing.

You pay per taxpayer, not per invoice

Which is how your business grows: by clients, not by documents. A taxpayer issuing a thousand invoices a month costs the same as one issuing three.

TaxpayersCost per monthPer taxpayer
10129 €12,90 €
25189 €7,56 €
50269 €5,38 €
100399 €3,99 €

No lock-in. And the sandbox is free with no time limit: you can integrate completely before paying anything.

In short

If you have software that invoices and want to see how it would look with one call, ask us for sandbox access. It is free, it never expires, and you do not have to talk to a salesperson to try it.

See Motor API The documentation