Fecha de entrada en vigor de VeriFactu

[novatico]

Con fecha 04.11.2024, la AEAT sometió a Consulta Pública, durante 14 días, un documento para la modificación de la fecha de entrada en vigor de VERI*FACTU.

En concreto, este documento establece la entrada en vigor para Sociedades el 01.01.2026, y para el resto (autónomos) el 01.07.2026, permaneciendo sin cambios la fecha de entrada en vigor para los desarrolladores, 9 meses a partir de la publicación de la OM, es decir 29.07.2025.

El siguiente paso debería ser la publicación en el BOE de dicho documento, pero hasta ahora no ha sido así. Envié una consulta a VERI*FACTU, pero no he recibido respuesta, aunque trabajo pensando que estos plazos terminarán siendo los definitivos.

[keno_71]

Buenas tardes, hoy he hecho la consulta y efectivamente es como dice el compañero, aquí la respuesta:

Actualmente se encuentra en tramitación la modificación de la entrada en vigor del reglamento. Puede consultarlo en https://www.hacienda.gob.es/SGT/Norm...ica-Previa.pdf

Debido a ello, la entrada en vigor de la obligación para los usuarios (empresarios), se desplaza hasta el 1 de enero de 2026 para las personas jurídicas, y hasta el 1 de julio de 2026 para las personas físicas. Sin embargo, la obligación que concierne a los fabricantes y desarrolladores de programas y sistemas informáticos de facturación (SIF) de comercializar sus productos adaptados a la normativa vence a los nueve meses de la publicación en el BOE de la orden ministerial, es decir, el 29 de julio de 2025. A partir de esa fecha, todos los productos que se comercialicen deberán estar adaptados a la nueva normativa.

Por otro lado, la Agencia Tributaria previsiblemente pondrá a disposición de todos los usuarios sus sistemas completos y aceptará los registros de facturación en modalidad VERI*FACTU antes del 1 de julio de 2025, de modo que cualquier sistema (SIF) que se comercialice adaptado a las obligaciones de la modalidad Veri*factu podrá ser utilizado, con toda validez legal, meses antes de que llegue la fecha límite de adaptación de todos los empresarios. Más aún, en la improbable hipótesis de que transitoriamente no estuvieran adaptados los sistemas de la Agencia Tributaria, la expedición de facturas, generando los correspondientes registros de facturación encadenados y con QR (tal y como establece el RRSIF) sería perfectamente válida, aunque no se realizara la remisión de los mismos a la Sede Electrónica de la AEAT y el servicio de cotejo no estuviera abierto.

[ermendalenda]

Empezado por keno_71

Buenas tardes, hoy he hecho la consulta y efectivamente es como dice el compañero, aquí la respuesta:

Si permittieran generar los registros y el QR sin tener activos los servicios ocurririan un par de situaciones "extrañas" que tendran que aclarar, para los que desarrollen en No verifactu, ok, pero para el resto, generariamos un QR que si el cliente lo lee le daria que no está remitido (a no ser que cambiaran el mensaje en ese periodo), la otra situacion es que el software hiria acumulando registros para enviarlos como incidiencia(eso nos tocaria resolverlo con un nuevo parametro)

[josejava]

Sin embargo, la obligación que concierne a los fabricantes y desarrolladores de programas y sistemas informáticos de facturación (SIF) de comercializar sus productos adaptados a la normativa vence a los nueve meses de la publicación en el BOE de la orden ministerial, es decir, el 29 de julio de 2025. A partir de esa fecha, todos los productos que se comercialicen deberán estar adaptados a la nueva normativa.

¿Por "comercializar" se refieren a nuevas ventas de un SIF? O sea ¿si un SIF ya está actualmente funcionando en un comercio tiene que ser actualizado antes del 29 de julio de este año a Verifactu?

Es que me parece un poco raro que obliguen a los programas a estar listos para Verifactu medio año o un año antes antes de que los comerciantes tengan la obligación de adaptarse a Verifactu. Ese tiempo intermedio de vacío no tiene ningún sentido a mi modo de ver.

[jlmoli_67]

Buenas,
se refiere a que a partir de esa fecha todo software que se venda debe de estar preparado para cumplir con las norma.

[josejava]

Sí, yo me refería a si los software que ahora mismo ya están funcionando en las tiendas y que aún no cumplen con Verifactu se les pueden realizar actualizaciones sin que todavía cumplan con Verifactu después del 29 de julio de este año.

Es que puede haber casos de necesidad de actualización del programa. Como por ejemplo un fallo en la copia de seguridad de la base de datos del programa y se lanza una actualización para solucionar ese problema más allá del 29 de julio de 2025. Yo creo que medio año o un año de tiempo intermedio "muerto" es demasiado tiempo y puede que el programa necesite actualizaciones de otros temas que no sean Verifactu.

[gcqZW]

Efectivamente, se supone que a partir del 29 de julio ya no podrás actualizar ningún programa sin añadirle verifactu.

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

Empezado por josejava

Sí, yo me refería a si los software que ahora mismo ya están funcionando en las tiendas y que aún no cumplen con Verifactu se les pueden realizar actualizaciones sin que todavía cumplan con Verifactu después del 29 de julio de este año.

Es que puede haber casos de necesidad de actualización del programa. Como por ejemplo un fallo en la copia de seguridad de la base de datos del programa y se lanza una actualización para solucionar ese problema más allá del 29 de julio de 2025. Yo creo que medio año o un año de tiempo intermedio "muerto" es demasiado tiempo y puede que el programa necesite actualizaciones de otros temas que no sean Verifactu.

Yo creo que "oficialmente" no puedes dar soporte ni actualizaciones a partir de esa fecha.

[Rja750]

Empezado por gcqZW

Efectivamente, se supone que a partir del 29 de julio ya no podrás actualizar ningún programa sin añadirle verifactu.

Hay un detalle que no me queda claro. Entonces si tengo a partir de la fecha en la calle un SIF que no cumple, no podre actualizarlo a no ser que esa modificacion se realice sobre el SIF que si cumple con Veri*factu pero si no lo actualizo y el SIF del cliente es el que le puse cuando este contrató mis servicios ¿puedo seguir cobrando la mensualidad?

[[newtron]]

Empezado por Rja750

Hay un detalle que no me queda claro. Entonces si tengo a partir de la fecha en la calle un SIF que no cumple, no podre actualizarlo a no ser que esa modificacion se realice sobre el SIF que si cumple con Veri*factu pero si no lo actualizo y el SIF del cliente es el que le puse cuando este contrató mis servicios ¿puedo seguir cobrando la mensualidad?

Yo entiendo que si no puedes dar soporte a programas no actualizados no deberías de cobrar cuotas de mantenimiento. Quien corresponda puede entender que si estás cobrando es a cambio de algo, que en este caso sería soporte.

[Faneka]

Justo, y yo creo que algunos clientes que dejaron de pagar el mto por diversas causas si siguen usando el programa ahora cuando se enteren del verifactu vendran corriendo para volver a contratarlo, eso va a ser la risa, lo veo venir.

[[newtron]]

Empezado por Faneka

Justo, y yo creo que algunos clientes que dejaron de pagar el mto por diversas causas si siguen usando el programa ahora cuando se enteren del verifactu vendran corriendo para volver a contratarlo, eso va a ser la risa, lo veo venir.

Si... esto va a dar muuuuuuuuuuuuuuuuuuuuucho gustito.

[Rja750]

Empezado por Faneka

Justo, y yo creo que algunos clientes que dejaron de pagar el mto por diversas causas si siguen usando el programa ahora cuando se enteren del verifactu vendran corriendo para volver a contratarlo, eso va a ser la risa, lo veo venir.

Cuando mi SIF atacaba a BD's en local me paso algun que otro caso que se quedaron sin pagar y con el programa instalado sin poder hacer nada. Como vengan ahora me van a pagar los atrasos

[Rja750]

Empezado por newtron

Yo entiendo que si no puedes dar soporte a programas no actualizados no deberías de cobrar cuotas de mantenimiento. Quien corresponda puede entender que si estás cobrando es a cambio de algo, que en este caso sería soporte.

Pues si. Pensándolo bien tiene toda la lógica

[Rja750]

Empezado por newtron

Yo entiendo que si no puedes dar soporte a programas no actualizados no deberías de cobrar cuotas de mantenimiento. Quien corresponda puede entender que si estás cobrando es a cambio de algo, que en este caso sería soporte.

Lo que me obliga a actualizar a mis clientes con SIF Verifactu a partir de Julio de 2025 si quiero seguir cobrando la mensualidad, aunque no sea aun obligatorio (para los obligados tributarios hasta 1-1-2026) tener el SIF con la normativa Verifactu. Solo yo podre seguir facturando a mis clientes sin SIF verifactu hasta 2026. Curioso!

[ermendalenda]

Empezado por Rja750

Lo que me obliga a actualizar a mis clientes con SIF Verifactu a partir de Julio de 2025 si quiero seguir cobrando la mensualidad, aunque no sea aun obligatorio (para los obligados tributarios hasta 1-1-2026) tener el SIF con la normativa Verifactu. Solo yo podre seguir facturando a mis clientes sin SIF verifactu hasta 2026. Curioso!

Sí, dentro de su lógica es normal, los clientes que lo deseen pueden ir enviando verifactu a partir de esa fecha y así tienen una entrada progresiva. Y a mi no me desagrada esto, ya que si me dicen que todos los client3s empiecen a enviar el día 1/1/26 es una putada, aunque lo automatice ya se sabe que puede surgir alguna historia que no se haya tenido en cuenta, prefiero hacerlo progresivamente y que para el día 1 estén todos

[xevi]

A vr como veis mi planteamiento para cumplir con VERIFACTU y poder seguir con los mantenimientos de mis programas de Gestión/Facturación.

Para los clientes que ya estan o quieran voluntariamente estar en SII, no voy a tener problemas, no tengo que tocar nada, ya que funciona de hace unos 3 añitos y bien, de momento.

Para resto de clientes, SOLO voy a emitir una factura después de recibir la respuesta "Correcta" o "Aceptada con errores" del envio del xml a AEAT. Entiendo que es solamente en estos casos cuando Hacienda guarda el registro. Los demás, por contener errores, aunque se los puede "guardar", no creo que intervengan o sean "sospechosos" ya que seran registros invalidados.

Si un envio responde con algun otro mensaje de error que no sea "Correcto" o "Aceptada con errores" NO voy a dejar imprimir la factura... y si el cliente quiere, pues que haga una proforma, presupuesto, albaran. Que revise bien los datos y que la vuelva a enviar hasta que reciba un mensaje Ok.

Para facturas que mi programa no sea capaz de enviar correctamente a hacienda, sintiendolo mucho, pueden utilizar otro SIF, como bien puede ser el que va a poner a disposición AEAT.

Otra cosa que no veo si és de obligatoriedad para el desarrollador... Si hay un envio de un registro Aceptada co errores, ¿Se podrá "reparar" subsanar el error por el portal?, bien como se hace con el SII.


Con esto, ¿Estoy cumpliendo con VERIFACTU y limitando mis responsabilidades???

[ermendalenda]

Empezado por xevi

A vr como veis mi planteamiento para cumplir con VERIFACTU y poder seguir con los mantenimientos de mis programas de Gestión/Facturación.

Para los clientes que ya estan o quieran voluntariamente estar en SII, no voy a tener problemas, no tengo que tocar nada, ya que funciona de hace unos 3 añitos y bien, de momento.

Para resto de clientes, SOLO voy a emitir una factura después de recibir la respuesta "Correcta" o "Aceptada con errores" del envio del xml a AEAT. Entiendo que es solamente en estos casos cuando Hacienda guarda el registro. Los demás, por contener errores, aunque se los puede "guardar", no creo que intervengan o sean "sospechosos" ya que seran registros invalidados.

Si un envio responde con algun otro mensaje de error que no sea "Correcto" o "Aceptada con errores" NO voy a dejar imprimir la factura... y si el cliente quiere, pues que haga una proforma, presupuesto, albaran. Que revise bien los datos y que la vuelva a enviar hasta que reciba un mensaje Ok.

Para facturas que mi programa no sea capaz de enviar correctamente a hacienda, sintiendolo mucho, pueden utilizar otro SIF, como bien puede ser el que va a poner a disposición AEAT.

Otra cosa que no veo si és de obligatoriedad para el desarrollador... Si hay un envio de un registro Aceptada co errores, ¿Se podrá "reparar" subsanar el error por el portal?, bien como se hace con el SII.


Con esto, ¿Estoy cumpliendo con VERIFACTU y limitando mis responsabilidades???

Bufff me he perdido, creo que no has entendido bien algunos conceptos del control de flujos.
se envía después de emitir con lo cual no puedes saber que puedes imprimir o no según el error que te devuelva cerifactu, además hay momentos que tienes que esperar un tiempo antes de volver a enviar, no puedes dejar esperando al cliente. Lo de "SOLO.... " no entiendo nada, posiblemente por que estés malinterpretado wl control de flujos. Repasa la normativa

[xevi]

Control de flujos... bien, bien puede ser que no lo haga correctamente, pero tampoco creo que haga nada mal.

Preparo un albaran para emitir factura
Pulso a imprimir/generar factura (bloqueo para que nadie emita otra factura, ya que tengo asignado el numero para esta que està en proceso)
Calculo y compruebo datos
Genero el xml
Envio a AEAT (todavia no hay ningun registro mio interno de factura y la factura física no existe)
Respuesta erronea... (desbloqueo base de datos para que se pueda generar otra factura y no hago nada más, solo mostrar el error de envio)
Respuesta correcta... (grabo nuevo registro de factura, desbloqueo base de datos, guardo xmls, imprimo, hago asiento contable...)

Creo que el flujo sería lo bastante "correcto"... ¿no???
Hasta que no tengo la factura generada correctamente, no estoy emitiendo ninguna factura.
Se trata de clientes que hacen pocas facturas, igual el que más 4 o 5 al día. No les supone ningún quebradero de cabeza esperar a recibir respuesta, igual van a tener que esperar esos 60 segundos entre envios... no les vendrà ese tiempo de demora, total, se està "verificando" la factura con VERI*FACTU, jejeje (voy a mostrar ese mensaje de espera)

Gracias.

[[newtron]]

Empezado por xevi

Control de flujos... bien, bien puede ser que no lo haga correctamente, pero tampoco creo que haga nada mal.

Preparo un albaran para emitir factura
Pulso a imprimir/generar factura (bloqueo para que nadie emita otra factura, ya que tengo asignado el numero para esta que està en proceso)
Calculo y compruebo datos
Genero el xml
Envio a AEAT (todavia no hay ningun registro mio interno de factura y la factura física no existe)
Respuesta erronea... (desbloqueo base de datos para que se pueda generar otra factura y no hago nada más, solo mostrar el error de envio)
Respuesta correcta... (grabo nuevo registro de factura, desbloqueo base de datos, guardo xmls, imprimo, hago asiento contable...)

Creo que el flujo sería lo bastante "correcto"... ¿no???
Hasta que no tengo la factura generada correctamente, no estoy emitiendo ninguna factura.
Se trata de clientes que hacen pocas facturas, igual el que más 4 o 5 al día. No les supone ningún quebradero de cabeza esperar a recibir respuesta, igual van a tener que esperar esos 60 segundos entre envios... no les vendrà ese tiempo de demora, total, se està "verificando" la factura con VERI*FACTU, jejeje (voy a mostrar ese mensaje de espera)

Gracias.

Yo entiendo que en el momento en el que intentas el envío esa factura ya está emitida y "va a misa", otra cosa es que dé errores o no. Si no da error estupendo pero si da error tienes que distinguir si es un error que afecte a la ley de facturación con lo cual deberías de generar una rectificativa sobre esa factura y si no afecta a la ley de facturación (error en el encadenamiento, qr, y cosas así) podrias enviar una subsanación de la misma factura. Básicamente la historia está en que entiendo que no puedes "olvidar" una factura porque haya venido rechazada, la factura está emitida y emitida se queda y luego ya actúas según se rechace o no.



Yo en particular creo que esto lo tengo bastante claro después de mucho debate sobre estos temas.


Saludos.