Duda: Sin verifactu y sin QRCODE de un software adaptado ¿Es legal?

[sglorka]

Empezado por CarlosArjonomia

Pero vamos a ver, tu no le puedes poner una pistola en la sien al cliente para obligarlo a que envíe.

Tu le pones el software adaptado que es tu obligación y es el cliente quien tiene que configurar el sistema para que el programa pueda enviar.

Yo tengo clientes que tienen el software adaptado y preparado para enviar y no están metiendo facturas porque no les da la gana. ¿También tengo que ir yo a su casa a mirar si meten o no todas las facturas que deberían?.

Si te refieres a que tu le pones el programa adaptado y el cliente decide cuándo lo va a utilizar para mecanizar facturas entiendo lo que dices.
Si me estás diciendo que tu le pones el programa adaptado y el cliente mete facturas pero él debe activar algo para que las envíe entonces apaga y vámonos

[espinete]

Yo de verdad que no sé cómo no ven que es una contradicción. Creo que estamos mezclando cosas.

- El cliente está en su derecho de NO enviar VeriFactu hasta 2027 si no le da la gana.
- El software tiene que estar adaptado a VeriFactu (no hablo de No-Verifactu porque no me incumbe)
- El cliente compra el programa el 5 de enero de 2026. No quiere enviar a VeriFactu aún.

Qué le digo, que tiene que enviar si o si aunque él no quiera? No
Que compre uno No-Verifactu? Tampoco está obligado No-Verifactu hasta 2027.

Yo cumplo la normativa: programa adaptado.
El cliente cumple la normativa: no envío si no quiero hasta 2027

La culpa no es nuestra por no entenderlo

[jakematespain]

Si tienes un software en verifactu, configuras el software con activar envío o sin activar envío. Controlas que llegada la fecha de obligación se active el envío. Durante el proceso de configuración ya preguntas si es empresa o autónomo. En la declaración esponable indicas todo esto, para que el cliente no se pase de listo y ponga autonomo cuando es empresa. Pones un mensaje cada vez que entra en el programa, pendiente de activar el envío. Con todo esto, tiene el software adaptado y es en cliente cuando quiere activarlo, tu se lo has dejado en verifactu, pero el no está obligado. Que ocurre en este caso.

[Joze]

Creo que esto es lo que hemos entendido la mayoría, y lo que aplicamos.

Excepto los obligados tributarios exentos, sea por el motivo que sea, incluyendo los casos de Navarra y País Vasco por su régimen foral, únicamente se pueden comercializar SIF adaptados al Real Decreto 1007/2023.

Se considera adaptado aquel SIF que funciona exclusivamente en modo Veri*Factu o No-Veri*Factu. Esto implica que, desde su instalación, el sistema solo puede permitir la emisión de facturas en uno de estos dos modos:

1. Veri*Factu, con envío inmediato a la AEAT,
2. No-Veri*Factu, con generación de los XML firmados y todos los registros correspondientes.

Por lo tanto, no es posible adquirir hoy un programa SIF que no implemente alguno de estos dos modos. El sistema tradicional ya no es válido. Si el software permite emitir facturas de otro tipo (sin considerar los casos forales, SIF antiguos o exentos), entonces no cumple el RD 1007/2023 y es sancionable.

Un obligado tributario podrá seguir utilizando su SIF antiguo hasta la fecha límite sin mayor problema. Incluso si adquiere un SIF nuevo adaptado al RD, podrá enviar facturas de prueba, que posteriormente deberá anular, y continuar trabajando con su programa antiguo hasta que decida migrar definitivamente. Pero el SIF nuevo solo puede funcionar en VeriFactu o No-VeriFactu.

Asimismo, es imprescindible que el usuario configure en el SIF adaptado su certificado, salvo que utilice un certificado de colaboración. Sin un certificado válido no debería permitirse emitir facturas, o en su defecto, estas deberían quedar en cola hasta que se configure uno.

En este ámbito no aplica lo que el obligado desee, sino lo que exige la AEAT y el Real Decreto. Por supuesto, el obligado está en su derecho de no trabajar en VeriFactu ni en No-VeriFactu, pero en ese caso deberá seguir utilizando su SIF anterior mientras esté permitido.

[Jarogo08]

Empezado por espinete

Yo de verdad que no sé cómo no ven que es una contradicción. Creo que estamos mezclando cosas.

- El cliente está en su derecho de NO enviar VeriFactu hasta 2027 si no le da la gana.
- El software tiene que estar adaptado a VeriFactu (no hablo de No-Verifactu porque no me incumbe)
- El cliente compra el programa el 5 de enero de 2026. No quiere enviar a VeriFactu aún.

Qué le digo, que tiene que enviar si o si aunque él no quiera? No
Que compre uno No-Verifactu? Tampoco está obligado No-Verifactu hasta 2027.

Yo cumplo la normativa: programa adaptado.
El cliente cumple la normativa: no envío si no quiero hasta 2027

La culpa no es nuestra por no entenderlo

Si el cliente compra un programa el 5 de enero de 2026 no va a encontrar ninguno en el mercado que no envíe (recuerdo que desde hace medio año no podemos venderlos). Por tanto...
-El cliente está en su derecho de no enviar hasta 2027? -> Te lo compro
-¿Va a encontrar algún programa que le permita no enviar? -> NO. Porque todos nosotros lo hicimos muy bien y nuestro software está adaptado y homologado y con una declaración responsable que dice que cumple la ley.


y vuelvo a insistir por enésima vez: si tu cliente pone tu programa y no envía hasta 2027 significa que tu programa no cumple con la ley (a no ser que lo configures en SII, TicketBay, etc.)

[novatico]

Empezado por Jarogo08

Si el cliente compra un programa el 5 de enero de 2026 no va a encontrar ninguno en el mercado que no envíe (recuerdo que desde hace medio año no podemos venderlos). Por tanto...
-El cliente está en su derecho de no enviar hasta 2027? -> Te lo compro
-¿Va a encontrar algún programa que le permita no enviar? -> NO. Porque todos nosotros lo hicimos muy bien y nuestro software está adaptado y homologado y con una declaración responsable que dice que cumple la ley.


y vuelvo a insistir por enésima vez: si tu cliente pone tu programa y no envía hasta 2027 significa que tu programa no cumple con la ley (a no ser que lo configures en SII, TicketBay, etc.)

Es que, incluso ahora, de hecho desde el 29/07/2025 NO SE PUEDE INSTALAR UN PROGRAMA NO ADAPTADO, BIEN A "VERIFACTU" O BIEN A "NO VERIFACTU", porque los NO SUJETOS, no necesitan hacer nada.
Y en cuanto a los clientes, el único poder de decisión que deberían tener es el de elegir entre una de esas 2 modalidades (VERIFACTU O NO VERIFACTU), y una vez elegida, cumplir completamente con todas las exigencias asociadas.

Ya recordé hace unos días que "lo voluntario" NO ES ENVIAR O NO ENVIAR, es elegir entre las 2 modalidades. La modalidad VERIFACTU exige el envío SI o SI, porque en otro caso, no estas cumpliendo con los Requisitos del Reglamento de Sistemas Informáticos de Facturación (RRSIF). Esta palabrita "voluntario" está creando mucha confusión y malos entendidos, pero en el Reglamento está asociada a la modalidad VERIFACTU, en contraposición a "por requerimiento" de la modalidad NO VERIFACTU.

Como ya he dicho otras veces, tenemos derecho a la pataleta, incluso a saltarnos la Ley, y tambíen a asumir las consecuencias de nuestras decisiones.

[Jarogo08]

Empezado por novatico

Es que, incluso ahora, de hecho desde el 29/07/2025 NO SE PUEDE INSTALAR UN PROGRAMA NO ADAPTADO, BIEN A "VERIFACTU" O BIEN A "NO VERIFACTU", porque los NO SUJETOS, no necesitan hacer nada.

Bueno, un cliente que no está sujeto puede comprar hoy tu programa o el mío. Decían en otro hilo (o no sé si en este) que si el cliente es de Navarra no le afecta Verifactu. Y me parece bien: nuestro programa puede tener las opciones Verifactu, NO Verifactu, SII, TicketBay, Navarra. Y en función de lo que elijas hará una cosa u otra. Pero no hay una última opción (que es lo que me canso de repetir) de "No me envíes que no me apetece hasta finales del 2026".

Pónselo en modo SII o en modo Navarra (si tu programa tiene esas opciones) y ya no enviará nada. Pero no hagas esa última opción. Así tu programa cumplirá la ley. Eso sí, si el cliente tiene una inspección tendrá que justificar porque tiene el programa configurado en modo SII o Navarra cuando no procede. Pero será responsabilidad del cliente, no del programa.

[CarlosArjonomia]

Ya van varios clientes que sus propias asesorías después de la reculada les están diciendo que no creen que se aplique nunca verifactu.

Sabiendo como se sabe que NO ha sido un problema de logística de la AEAT, si no una cuestión presuntamente política para que Cataluña presuntamente no ceda sus datos fiscales a la hacienda española.

Más difícil todo.

Edito para poner presuntamente ya que en este país hay que tener mucho cuidado con lo que se dice.

[novatico]

Empezado por Jarogo08

Bueno, un cliente que no está sujeto puede comprar hoy tu programa o el mío. Decían en otro hilo (o no sé si en este) que si el cliente es de Navarra no le afecta Verifactu. Y me parece bien: nuestro programa puede tener las opciones Verifactu, NO Verifactu, SII, TicketBay, Navarra. Y en función de lo que elijas hará una cosa u otra. Pero no hay una última opción (que es lo que me canso de repetir) de "No me envíes que no me apetece hasta finales del 2026".

Pónselo en modo SII o en modo Navarra (si tu programa tiene esas opciones) y ya no enviará nada. Pero no hagas esa última opción. Así tu programa cumplirá la ley. Eso sí, si el cliente tiene una inspección tendrá que justificar porque tiene el programa configurado en modo SII o Navarra cuando no procede. Pero será responsabilidad del cliente, no del programa.

Por eso pregunté hace 2 días si alguno contemplaba la posibilidad de que si un cliente que sabes que está SUJETO porque lo conoces, ahora te dice que YA NO ESTA SUJETO, de hacerle firmar un documento en el que certificase ese hecho, para evitarnos posibles sanciones.

[Jarogo08]

Empezado por novatico

Por eso pregunté hace 2 días si alguno contemplaba la posibilidad de que si un cliente que sabes que está SUJETO porque lo conoces, ahora te dice que YA NO ESTA SUJETO, de hacerle firmar un documento en el que certificase ese hecho, para evitarnos posibles sanciones.

A nosotros por ahora no se nos dio el caso, pero si se nos da por supuesto que firmará un papel donde quede constancia de que lo hace él.

[Carlos]

Empezado por novatico

Por eso pregunté hace 2 días si alguno contemplaba la posibilidad de que si un cliente que sabes que está SUJETO porque lo conoces, ahora te dice que YA NO ESTA SUJETO, de hacerle firmar un documento en el que certificase ese hecho, para evitarnos posibles sanciones.

Creo que cualquier documento que te firme será papel mojado.

[Carlos]

Empezado por Jarogo08

Bueno, un cliente que no está sujeto puede comprar hoy tu programa o el mío. Decían en otro hilo (o no sé si en este) que si el cliente es de Navarra no le afecta Verifactu. Y me parece bien: nuestro programa puede tener las opciones Verifactu, NO Verifactu, SII, TicketBay, Navarra. Y en función de lo que elijas hará una cosa u otra. Pero no hay una última opción (que es lo que me canso de repetir) de "No me envíes que no me apetece hasta finales del 2026".

Pónselo en modo SII o en modo Navarra (si tu programa tiene esas opciones) y ya no enviará nada. Pero no hagas esa última opción. Así tu programa cumplirá la ley. Eso sí, si el cliente tiene una inspección tendrá que justificar porque tiene el programa configurado en modo SII o Navarra cuando no procede. Pero será responsabilidad del cliente, no del programa.

Esa es nuestra solución.
Si alguien quiere saltarse la norma allá él, pero que no nos arrastre a nosotros.
Le dejo la hoja con las multas/sanciones, le dejo en pantalla que opción escoger para no estar obligado a enviar, que llame a su gestor se lo comente y use ÉL el ratón, yo mientras habla con su gestor me voy al bar a desayunar.
Otra opción puede ser tu ruina.

[Jarogo08]

Empezado por Carlos

Esa es nuestra solución.
Si alguien quiere saltarse la norma allá él, pero que no nos arrastre a nosotros.
Le dejo la hoja con las multas/sanciones, le dejo en pantalla que opción escoger para no estar obligado a enviar, que llame a su gestor se lo comente y use ÉL el ratón, yo mientras habla con su gestor me voy al bar a desayunar.
Otra opción puede ser tu ruina.

Vaya... por fin nos entendemos!

Que se salte la norma y no envíe poniendo el programa en modo SII, por ejemplo. Nosotros ahí no tenemos ninguna responsabilidad.
Pero que no se salte la norma poniendo en el programa en un modo que el programa no debe tener porque entonces no cumpliría la ley y por tanto no estaría homologado

[ermendalenda]

El que está interpretando los detalles de los softwares no homologados para que el canal nos informe se lo tiene que estar pasando pipa con una cerveza en la mano y con los colegas en el bar.
No veis que por mucho que pregunteis nos enredan por que no tienen interes en que lo entendamos.
Está claro que un proveedor no puede instalar un software antiguo ni lo puedd vender ni mantener, pero si lo hace el cliente creeis que pasa algo? Venga hombre, van a controlar a millones de usuarios que si en este periodo se les jode el disco que no puedan reinstalar ellos desde sus copias, ¿en serio lo veis viable? En que cabeza cabe?
Hasta que no haya obligacion plena no pueden controlar esta historia.
La estrategia del canal es clara, ruido a los desarrolladores. Esa información no llega a los asesores ppr que se lia parda, no paran de enredarnos y yo he llegado a mi limite de hacer el gilipollas, no les pregunto más, ni siquiera responden a lo que no les interesa.

[emailesc]

Empezado por ermendalenda

El que está interpretando los detalles de los softwares no homologados para que el canal nos informe se lo tiene que estar pasando pipa con una cdrveza en la mano y con los colegas en el bar.
No veis que por mucho que pregubteis nos enredan por que no tienen interes en que lo entendamos.
Está claro que un proveedor no puede instalar un software antiguo ni lo puedd vender ni mantener, pero si lo hace el cliente creeis que pasa algo? Venga hombre, van a xontrolar a millones de ususeios que si en este periodo se les jode el disco que no puedan reinstalar ellos desde sus copias, ¿en serio lo veis viable?

Es que solo hay una cosa que entender e interiorizar: están usando a los desarrolladores como martillo para meter Verifactu a martillazos, y si algo falla, el culpable es el martillo. Lo llevan haciendo desde el inicio. Y cómo obligan al martillo ??? con multas de 150.000. Todo esto no es más que un chantaje al estilo el padrino y lo saben desde el inicio. Por eso pocas explicaciones lógicas pueden dar: su misión no es ayudar a nadie, sino asegurarse que el martillo siga dando golpes

[ermendalenda]

Empezado por emailesc

Es que solo hay una cosa que entender e interiorizar: están usando a los desarrolladores como martillo para meter Verifactu a martillazos, y si algo falla, el culpable es el martillo. Lo llevan haciendo desde el inicio. Y cómo obligan al martillo ??? con multas de 150.000. Todo esto no es más que un chantaje al estilo el padrino y lo saben desde el inicio. Por eso pocas explicaciones lógicas pueden dar: su misión no es ayudar a nadie, sino asegurarse que el martillo siga dando golpes

Ya, eso lo tenemos clsro, pero insisto, si un usuario instala un software antiguo no he visto repercusiones, y eso no lp van a decir, tiene el instalador, el cliente no compra nada, no paga nada ningun proveedor le ayuda.. y a parte quien coj. Se va a enterar.
Mira te pongo montones de ejemplos:
chiringuito abre en junio- factura nunero 1, software antiguo.
Tpv con verifactu roto, saco dl del almacen para sustituirlo, software antiguo(permitido)
-eventos de ferias y otras epocas estivales que solo usan tpv en esas fechas, antiguo(esto permitido, eah, por que sí)
Y el cliente que abra las puertas un domingo y tenga un problema que no le puedes atender, restaura copia antigua, MUYYY MALLL, a la carcel. Guardia siví,...
En serio crees que pueden perseguir eso en 2026?
Ademss es lo que estan difundiendo a todos, obligacion hasta2027 no es obligatorio, por muy pesados que os pongais con los clientes.es nadar contracorriente
En conclusion
Hasta 2027 el cliente que haga lo que le de la gana.

[emailesc]

Empezado por ermendalenda

Ya, eso lo tenemos clsro, pero insisto, si un usuario instala un software antiguo no he visto repercusiones, y eso no lp van a decir, tiene el instalador, el cliente no compra nada, no paga nada ningun proveedor le ayuda.. y a parte quien coj. Se va a enterar.
Mura te pongo montones de ejemplos:
chiringuito abre en junio- factura nunero 1, software antiguo.
Tpv con verifactu roto, saco dl del almacen para sustituirlo, software antiguo.
-eventos de ferias y otras epocas estivales que solo usan tpv en esas fechas, antiguo(esto permitido, eah, por que sí)
Y el cliente que abra las puertas un domingo y tenga un problema que no le puedes atender, restaura copia antigua.
En serio crees que pueden perseguir eso en 2026?

Algunos de los ejemplos que pones son legales y otros no. ¿los van a perseguir? ni idea, pero no creo. Pero no soy yo el que dicta las normas y el que te coloca en posición de que algunas cosas te salpiquen aun sin quererlo, es Hacienda. ¿Que está mal? pues claro, ya lo estoy diciendo yo también...

[Neftali [Germán.Estévez]]

Empezado por espinete

- El cliente está en su derecho de NO enviar VeriFactu hasta 2027 si no le da la gana.
- El software tiene que estar adaptado a VeriFactu (no hablo de No-Verifactu porque no me incumbe)
- El cliente compra el programa el 5 de enero de 2026. No quiere enviar a VeriFactu aún.

Mi duda y creo que el follón viene por la primera afirmación:

- El cliente está en su derecho de NO enviar VeriFactu hasta 2027 si no le da la gana.

Los hay que entendemos o creemos que así es incorrecta, que la correcta sería:

- El cliente está en su derecho de no actualizarse hasta 2027 si no le da la gana.

Que esa es la única opción del cliente ahora. Si no se actualiza puede seguir "no activo", pero si se actualiza, debe marcar en qué modalidad (si el programa lo permite) o alguno de los casos de exclusión (SII, TicketBAI, Navarra,...)
Al final la cosa está en que no acaban de ser claros en las explicaciones. Tampoco cuesta tanto, creo yo.
Explicar los casos y las opciones de cada uno.

[CarlosArjonomia]

Empezado por Neftali [Germán.Estévez]

Mi duda y creo que el follón viene por la primera afirmación:

- El cliente está en su derecho de NO enviar VeriFactu hasta 2027 si no le da la gana.

Los hay que entendemos o creemos que así es incorrecta, que la correcta sería:

- El cliente está en su derecho de no actualizarse hasta 2027 si no le da la gana.

Que esa es la única opción del cliente ahora.

El problema es que tiene que haber actualizaciones por infinidad de situaciones, como nuevas funcionalidades, parches, bugs, etc, que nada tienen que ver con verifactu.

[Neftali [Germán.Estévez]]

Empezado por CarlosArjonomia

El problema es que tiene que haber actualizaciones por infinidad de situaciones, como nuevas funcionalidades, parches, bugs, etc, que nada tienen que ver con verifactu.

No veo el problema.
Si actualizas tu programa después del 1/1/2026 debe estar preparado para veri*factu/noveri*factu. O si tienes versiones específicas para el SII, TicketBAI, Navarra,... podrás actualizarlas, pero "creo" que no puedes actualizar una versión que no esté en ninguna de las situaciones anteriores.
Yo creo que eso está claro desde el principio.

¿Cuál es la situación concreta de la duda, para no generalizar?