A conversa adoita comezar igual. Alguén escríbenos dicindo «nós non somos un programa de facturación, somos un software de xestión de talleres —ou de clínicas, ou de academias— que ademais saca facturas».
E aí está o problema: a efectos do RD 1007/2023 iso é exactamente un sistema informático de facturación. Non importa que sexa o 5 % do teu produto nin que o pedise un cliente hai oito anos. Se o teu programa produce a factura, o teu programa é un SIF.
Que asinas cando es o produtor
A peza que sorprende é a declaración responsable. O artigo 13.2 do RD 1007/2023 obriga a que o sistema leve unha declaración, asinada polo seu produtor, que diga que cumpre o regulamento. Non a asina quen o usa: asínaa quen o fai.
E non é un papel solto. Para poder asinala, o programa ten que facer todo isto:
- Unha pegada encadeada por factura, que enlaza cada rexistro co anterior — de xeito que borrar unha do medio se note.
- Un QR co formato exacto que publica a Axencia Tributaria, impreso na factura.
- A remisión en tempo real á AEAT, con certificado, e o tratamento das súas respostas e dos seus rexeitamentos.
- Un rexistro de eventos propio do sistema.
- Numeración sen ocos, conservación, e mais a imposibilidade de modificar ou borrar o xa emitido.
- E a declaración responsable enriba, dispoñible dentro do propio programa de xeito «rápido, doado e intuitivo» — iso dío o art. 15.3 da Orde HAC/1177/2024, con esas palabras.
Nada diso é imposible. O que pasa é que non é o teu produto. É un proxecto enteiro, con normativa que cambia, cun interlocutor que é a Axencia Tributaria, e cunha responsabilidade que asinas ti e responde a túa empresa.
A túa data non é a dos teus clientes
Esta parte calcúlase mal a miúdo. As datas de VeriFactu son 1 de xaneiro de 2027 para os contribuíntes do Imposto sobre Sociedades e 1 de xullo de 2027 para o resto.
Pero esas son as datas nas que os teus clientes teñen que estar emitindo ben. Para que eles cheguen, o teu software ten que estar listo, probado e despregado antes. Se tes clientes que son sociedades —e case todo o software vertical os ten—, o teu prazo real non é xaneiro de 2027: é o outono de 2026, con marxe para que eles o proben.
Dito doutro xeito: o tempo que queda non é un ano e pico. Son uns meses.
As tres saídas
Non hai moitas máis, e convén miralas cos números diante.
1 · Construílo ti
É lexítimo e hai quen o fará. Conta coa cadea de pegadas, o QR, o cliente SOAP contra a AEAT, a xestión de certificados, os reintentos, o rexistro de eventos, e mais o seguimento de cada cambio normativo a partir de agora. Máis a declaración responsable co teu nome.
Se facturar é o corazón do teu produto, probablemente sexa o camiño. Se é unha lapela, estás montando unha empresa dentro da túa empresa.
2 · Deixar de emitir
Quitar a facturación do teu programa e que o cliente a faga noutro sitio. É a saída máis barata en desenvolvemento e a máis cara en produto: estáslle pedindo ao teu usuario que saia do teu software, e unha vez fóra pode non volver.
3 · Chamar a unha API homologada
O teu programa segue sendo o teu programa e fai unha chamada cando toca emitir. A numeración, a pegada encadeada, o QR e mais a remisión á AEAT ponas o sistema homologado, e a declaración responsable asínaa o seu produtor — que nese caso non es ti.
Iso é Motor API. Unha chamada:
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 }
E a resposta trae o número de serie, a pegada, o URL do QR e mais a ruta do PDF. O que tarda a AEAT en contestar vai por detrás, e cando contesta avisámoste por webhook: o 201 só di «recollido e encolado», e sondar factura a factura non o fai ninguén.
O que non che imos contar na portada
Como no resto deste blog, a parte incómoda vai escrita.
O sandbox pídese por correo
É de balde e non caduca, pero aínda non é autoservizo: escríbesnos e dámosche o acceso. O mesmo coa alta do plan: hoxe faise falando, non cun botón. Preferimos dicilo a que alguén busque un formulario que non existe.
Un NIF só pode estar dado de alta unha vez
A cadea de pegadas dun obrigado tributario é unha soa. Se un cliente teu xa está emitindo por outro sistema con ese NIF, non pode estar ademais no teu á vez: hai que decidir cal emite. Non é unha limitación nosa, é como funciona o encadeamento.
Os datos dos teus clientes non son teus nin nosos
O obrigado tributario é o emisor, e as súas facturas son súas. Nós somos o sistema e ti o integrador, pero o titular deses datos é el. Iso ten consecuencias no contrato que convén mirar antes de asinar, non despois.
E unha que é das dúas partes
O reparto de responsabilidades do RD 1007/2023 neste modelo —nós produtores do sistema, ti comercializador— é a lectura que facemos da norma e a que sostén o produto. É coherente e é a habitual no software como servizo, pero se a túa asesoría xurídica o quere revisar antes de integrarse, parécenos ben e axudámoste. É a túa responsabilidade a que estás movendo; mirala dúas veces é o sensato.
Págase por obrigados, non por facturas
Que é como medra o teu negocio: por clientes, non por documentos. Un obrigado que emite mil facturas ao mes custa o mesmo ca un que emite tres.
| Obrigados | Custo ao mes | Por obrigado |
|---|---|---|
| 10 | 129 € | 12,90 € |
| 25 | 189 € | 7,56 € |
| 50 | 269 € | 5,38 € |
| 100 | 399 € | 3,99 € |
Sen permanencia. E o sandbox, de balde e sen límite de tempo: podes integrarte enteiro antes de pagar nada.
Resumindo
- Se o teu programa emite facturas, é un sistema informático de facturación, aínda que non lle chames así.
- A declaración responsable asínaa o produtor do sistema. Hoxe, ti.
- O teu prazo é antes có dos teus clientes: eles entran en xaneiro e xullo de 2027, ti tes que estar listo antes.
- Hai tres saídas: construílo, deixar de emitir, ou chamar a unha API homologada e que a declaración a asine outro.
Se tes un software que factura e queres ver como quedaría cunha chamada, pídenos acceso ao sandbox. É de balde, non caduca, e non hai que falar con comerciais para probalo.