Sí: tener una «empresa de pruebas», una sociedad de demostración o cualquier entidad ficticia dentro del entorno de producción de un programa de facturación es contrario al artículo 8 del Real Decreto 1007/2023. Lo ha resuelto la Dirección General de Tributos en la consulta vinculante V1042-26, de 13 de mayo de 2026, respondiendo a un fabricante de ERP: la mera existencia de esas entidades «no permitiría garantizar la integridad, conservación, accesibilidad, legibilidad, trazabilidad e inalterabilidad de los registros de facturación». Y da igual que no emitan facturas con validez fiscal, que nadie las remita a la AEAT o que solo se usen para formar al equipo. La misma consulta deja abierta la salida legítima: esas entidades sí caben «en situaciones previas a dicho entorno de producción, por ejemplo, en un entorno de pruebas durante los procesos de elaboración de los programas».
Hasta aquí, la noticia. Lo que casi nadie ha contado —y es lo que convierte esto en un asunto de tu despacho y no de un blog de desarrolladores— es el segundo hallazgo de la consulta. La DGT recuerda, con fecha exacta, que el productor de software debía tener su producto plenamente adaptado al reglamento «como máximo hasta el 29 de julio de 2025». Es decir: hoy, 29 de julio de 2026, hace exactamente un año que venció el plazo de tu proveedor. El aplazamiento aprobado por el Real Decreto-ley 15/2025 movió las fechas de tus clientes al 1 de enero y al 1 de julio de 2027, pero no tocó el plazo del fabricante.
La consecuencia práctica es directa y poco intuitiva: aunque tu cliente todavía no esté obligado a emitir bajo VeriFactu, tú puedes exigir hoy mismo la conformidad del software. El artículo 13.3 del RD 1007/2023 te reconoce ese derecho de forma expresa: la declaración responsable «podrá ser solicitada por el cliente». Y no hay que esperar a 2027 para ejercerlo.
Este artículo hace tres cosas. Primero, desmonta la consulta pieza a pieza con sus literales, para que sepas exactamente qué dice y qué no dice (spoiler: no habla de sanciones ni fija plazo de limpieza alguno; quien mezcla ambas cosas está construyendo, como haremos nosotros más adelante, un análisis propio). Segundo, separa de una vez los cuatro entornos que el mercado confunde a diario —producción, pruebas del fabricante, entorno externo de pruebas de la AEAT y modalidad no VeriFactu—, porque de ahí nace la mitad de los errores. Y tercero, te deja una guía de auditoría aplicable el lunes por la mañana: qué mirar en tu propio parque de software, qué preguntar a cada proveedor y qué hacer con las entidades ficticias que ya existan, sin caer en la tentación de borrarlas a lo bruto.
Una advertencia de método, porque marca el tono de todo lo que sigue: no hay estadística pública sobre cuántos programas de facturación llevan una empresa de demostración preinstalada, y no la vamos a inventar. Lo que sí hay es doctrina vinculante, texto reglamentario y un plazo vencido. Con eso basta.
La pregunta que un fabricante de ERP le hizo a Hacienda
La consulta V1042-26 no nace de una inspección ni de una denuncia. Nace de un desarrollador que hace lo que hay que hacer: preguntar antes. La entidad consultante es, según la propia descripción de hechos, «proveedor y desarrollador de un software de gestión integral tipo ERP, que incluye módulos de facturación, gestión contable y otros procesos administrativos», compatible tanto con el Suministro Inmediato de Información como con el reglamento VeriFactu.
El escenario que describe es tan común que probablemente lo tengas delante ahora mismo en alguna instalación. Lo transcribo tal cual porque conviene reconocerse en él:
«no corresponden a entidades reales con actividad económica efectiva; son entidades ficticias creadas exclusivamente con fines de prueba y control dentro del software pero se encuentran en entornos de producción; no emiten facturas con validez fiscal; no realizan operaciones reales sujetas a tributación; se utilizan exclusivamente para simulaciones internas, pruebas de funcionamiento y validaciones técnicas, sin que la información generada se comunique a la AEAT ni se utilice para el cumplimiento de obligaciones tributarias reales.»
Fíjate en el cuidado con que está redactado. El consultante se anticipa a todas las objeciones: no son reales, no facturan de verdad, no se envía nada a la AEAT, están perfectamente identificadas y separadas de las entidades reales. Es un planteamiento honesto y, sobre el papel, razonable. Sobre esa base formula dos preguntas.
Pregunta uno: ¿molesta que estén ahí?
«¿Existe algún problema o inconveniente desde el punto de vista normativo por la mera existencia de estas sociedades ficticias en entornos de producción, aunque no realicen operaciones fiscales reales, ni generen facturación con validez tributaria?»
Pregunta dos: ¿el reglamento solo mira a los obligados reales?
La segunda cuestión es la creencia extendida que este artículo viene a corregir: si el RD 1007/2023 existe para garantizar la factura con efectos fiscales, ¿no debería ser indiferente lo que ocurra con entidades que jamás tendrán esos efectos? Es exactamente la tesis que la DGT rechaza.
La respuesta
El apartado TERCERO de la contestación no deja lugar a dudas:
«De lo anterior se deduce que la eventual introducción de entidades o sociedades ficticias o no reales en un software de facturación operativo en un entorno de producción sería contraria al mencionado artículo pues no permitiría garantizar la integridad, conservación, accesibilidad, legibilidad, trazabilidad e inalterabilidad de los registros de facturación del sistema informático de facturación.»
Y acto seguido, la vía de escape, que es tan importante como la prohibición:
«Lo dispuesto anteriormente, no obsta para que la introducción de entidades o sociedades ficticias o no reales se pueda realizar en situaciones previas a dicho entorno de producción, por ejemplo, en un entorno de pruebas durante los procesos de elaboración de los programas.»
La contestación se cierra con la fórmula del artículo 89.1 de la Ley 58/2003, General Tributaria: «Lo que comunico a Vd. con efectos vinculantes». Es doctrina vinculante para los órganos de la Administración tributaria, y la propia DGT la declara conforme con su pronunciamiento anterior, la consulta V0080-26, de 20 de enero de 2026, dictada a propósito de un software de facturación desarrollado internamente por un grupo empresarial. Ese detalle importa: cierra de antemano la escapatoria de «es que el programa nos lo hemos hecho nosotros».
Ficha de la consulta
| Número | V1042-26 |
|---|---|
| Órgano | Subdirección General de Tributos |
| Fecha de salida | 13 de mayo de 2026 |
| Normativa invocada | Art. 29.2.j) LGT y Real Decreto 1007/2023, de 5 de diciembre |
| Carácter | Vinculante (art. 89.1 LGT) |
| Doctrina concordante | V0080-26, de 20 de enero de 2026 |
| Consulta pública | Base de doctrina PETETE (Hacienda) |
Antes de auditar el software de tus clientes, ordena el tuyo
CopilotGestoria se integra con los programas contables que ya usa el despacho —no los sustituye— y emite facturas con huella encadenada y QR conforme a la Orden HAC/1177/2024, sin entidades de demostración conviviendo con las reales.
Probar gratis 30 días Ver cómo funcionaPor qué el artículo 8 lo impide: el argumento en tres pasos
El razonamiento de la DGT es corto y encadenado. Merece la pena reproducirlo porque es el que tendrás que explicarle a más de un proveedor por teléfono.
Paso 1 — La obligación matriz alcanza a tres sujetos, no a uno
El artículo 29.2.j) de la Ley 58/2003 impone la obligación «por parte de los productores, comercializadores y usuarios» de que los sistemas informáticos que soportan los procesos de facturación garanticen «la integridad, conservación, accesibilidad, legibilidad, trazabilidad e inalterabilidad de los registros, sin interpolaciones, omisiones o alteraciones de las que no quede la debida anotación en los sistemas mismos». Tres sujetos distintos, tres responsabilidades distintas. Volveremos sobre esto al hablar de sanciones.
Paso 2 — El reglamento se aplica también al fabricante
El artículo 3.2 del RD 1007/2023 extiende la aplicación del reglamento «a los productores y comercializadores de los sistemas informáticos». Por eso la DGT puede responderle a un fabricante que le afecta directamente: no está regulando por reflejo a través de su cliente, le está aplicando la norma a él.
Paso 3 — Y el artículo 8 ya calificaba de alteración los registros simulados
Aquí está la pieza que cierra el caso y que casi nadie ha usado. Cuando la DGT reproduce el artículo 8.2.a) del reglamento, aparece esto:
«Se entenderá por alteración de los registros de facturación la ocultación o eliminación de cualquier registro de facturación originalmente generado y registrado por el sistema informático, o la ocultación o modificación, total o parcial, de los datos de cualquier registro de facturación originalmente generado y registrado por el sistema informático, o la adición de registros de facturación, simulados o falsos, distintos a los originalmente generados y registrados por el sistema informático.»
Léelo despacio. El reglamento, desde diciembre de 2023, ya define como «alteración» la adición de registros simulados. Una factura emitida por una empresa de pruebas dentro del entorno de producción es, literalmente, un registro de facturación simulado añadido al sistema. V1042-26 no está inventando un criterio nuevo: está aplicando una definición que llevaba dos años y medio escrita en el BOE y que la mayoría del sector había leído pensando únicamente en el software de doble uso.
El mismo artículo 8, en su letra b), remata por el lado de la trazabilidad: los registros «deberán estar encadenados de manera que pueda verificarse su rastro siguiendo su secuencia de creación desde el primero al último», y añade que «cualquier funcionalidad o mecanismo que permita alterar u ocultar el rastro de las operaciones supone un incumplimiento de este requisito».
Por qué esto no es una formalidad: el encadenamiento se contamina de verdad
Que el problema es real, y no teórico, lo demuestra un hilo público del foro oficial de Odoo sobre la huella de pruebas y producción. Un usuario pregunta si, al desactivar el modo de pruebas y emitir la primera factura real, la cadena de huellas arranca de cero. La respuesta aceptada, basada en experiencia directa, es que la primera factura del entorno real se encadenó con la última del entorno de pruebas, sin dar error. El mismo hilo recoge que, para iniciar una cadena nueva, hay que variar los datos que identifican al sistema —por ejemplo el número de instalación— y marcar el siguiente registro como primer registro, porque el encadenamiento se realiza por sistema informático de facturación, identificado por NIF, identificador del sistema y número de instalación.
Traducido: sin separación real de entornos, las pruebas entran en la cadena de producción. Eso es exactamente lo que el artículo 8 quiere evitar, y explica por qué la DGT contesta lo que contesta.
«Pero si no tienen efectos fiscales»: por qué ese argumento no funciona
Es la objeción natural, y la consulta la desactiva con un párrafo que conviene tener a mano. Antes de entrar en el fondo, la DGT ordena las obligaciones formales y las declara separadas:
«se puede afirmar que las dos obligaciones formales señaladas, básicamente, facturación y la de los requisitos de los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación, deben calificarse como obligaciones distintas y diferentes, aunque relacionadas»
De ahí sale el argumento demoledor. La obligación de expedir factura la desarrolla el Reglamento de facturación (Real Decreto 1619/2012). La obligación relativa a los sistemas informáticos la desarrolla el RD 1007/2023. Y la de llevanza de libros, dice la propia consulta, es todavía una tercera obligación distinta.
Cuando el consultante alega que sus sociedades ficticias «no emiten facturas con validez fiscal», está defendiéndose frente a la primera obligación. Pero el incumplimiento que la DGT aprecia está en la segunda: no en facturar, sino en cómo se comporta el sistema. Un sistema informático de facturación que admite entidades ficticias en producción no garantiza la inalterabilidad de sus registros, tengan esos registros efectos fiscales o no.
Los cuatro entornos que todo el mundo mezcla
Si este artículo solo pudiera dejarte una cosa, sería esta tabla. La mayor parte de la confusión del mercado nace de meter en el mismo saco cuatro conceptos que no tienen nada que ver entre sí. Cuando un proveedor te diga «tranquilo, eso es el entorno de pruebas», necesitas saber a cuál de los cuatro se refiere.
| Concepto | Qué es exactamente | ¿Caben entidades ficticias? | Base |
|---|---|---|---|
| Entorno de producción | La instalación con la que se factura de verdad, la que tiene los datos reales de los clientes y genera los registros que cuentan. | NO | V1042-26 + art. 8 RD 1007/2023 |
| Entorno de pruebas del fabricante o del despacho | Una instalación o base de datos distinta y previa a producción, para desarrollo, control de calidad, demostraciones y formación del equipo. | SÍ | V1042-26: «en situaciones previas a dicho entorno de producción» |
| Entorno externo de pruebas de la AEAT (preproducción) | Un servicio de la propia Agencia que recibe registros de facturación sin efectos legales, para que el fabricante valide su integración. Es un destino, no un lugar donde vivan las entidades. | No aplica — no legitima tener empresas ficticias en producción | Sede electrónica de la AEAT, entorno de preproducción |
| Modalidad «no VeriFactu» | La modalidad del reglamento en la que el sistema no remite los registros a la AEAT de forma continuada, pero sigue obligado a huella, encadenamiento, registro de eventos y conservación. | NO | RD 1007/2023, art. 8 (aplica igualmente) |
El error más caro: confundir el entorno de pruebas de la AEAT con el del programa
Son dos cosas que ni siquiera están en la misma capa. El entorno externo de pruebas de la AEAT resuelve la pregunta «¿mi sistema envía bien los registros?». El entorno de pruebas del programa resuelve «¿dónde practico sin ensuciar los datos reales?». Que un fabricante haya validado su integración contra la preproducción de la AEAT no dice absolutamente nada sobre si tiene una sociedad de demostración conviviendo con las reales en las instalaciones de sus clientes.
El segundo error: creer que «no VeriFactu» significa «no me aplica»
El reglamento contempla dos modalidades. En la de sistemas de emisión de facturas verificables, los registros se remiten a la AEAT de forma continuada. En la otra, no se remiten, pero el sistema debe conservar los registros con huella, encadenamiento, registro de eventos y disponibilidad para la Administración. El artículo 8 se aplica exactamente igual en ambas. Elegir la modalidad no remitente no es una salida del reglamento: es una forma de estar dentro.
Guía descargable: VeriFactu 2026 para gestorías
Reúne el calendario vigente, las obligaciones por tipo de obligado y la lista de comprobación previa que puedes pasar cliente a cliente. En PDF, para consultar entre visitas.
La declaración responsable: qué es, quién la firma y por qué no existe el «software homologado»
Es probablemente el punto donde más ruido hay en el mercado, y donde tienes más margen para actuar de inmediato. La consulta reproduce el artículo 13 del RD 1007/2023 completo. Sus cuatro apartados dicen, en resumen, cuatro cosas que conviene fijar.
1. La firma el productor, no tú
«Corresponderá a la persona o entidad productora del sistema informático certificar, mediante una declaración responsable, que el sistema informático cumple con lo dispuesto en el artículo 29.2.j) de la Ley 58/2003». El sujeto obligado a emitirla es el fabricante. Ni el comercializador que te lo vendió, ni tu despacho.
2. Va por versión, no por producto
El apartado 2 exige que conste «por escrito y de modo visible en el propio sistema informático en cada una de sus versiones». No es un sello perpetuo que se gana una vez y vale para siempre: acompaña a cada versión concreta. Si el fabricante publica una actualización que reintroduce entidades de demostración en producción, es esa versión la que queda en entredicho, no una abstracción llamada «el programa».
3. Tienes derecho expreso a pedirla
El apartado 3 es tu palanca práctica: «Esta declaración responsable podrá ser solicitada por el cliente o por la Administración tributaria a la persona o entidad productora o comercializadora del sistema informático, que deberá guardar y conservar las declaraciones responsables de todas las versiones». No estás pidiendo un favor. Estás ejerciendo un derecho reglamentario, y el proveedor tiene obligación de conservar el documento.
4. No es una homologación de la AEAT — y esto hay que decirlo claro
En España no existe homologación administrativa de software de facturación. La AEAT no certifica programas, no emite sellos y no publica una lista oficial de software autorizado. El mecanismo del reglamento es una autodeclaración del productor bajo su responsabilidad. Cuando un anuncio te dice «software homologado por Hacienda», está usando una etiqueta que la normativa no contempla. Lo correcto es preguntar por la declaración responsable del artículo 13 y por la versión concreta a la que corresponde.
Quién paga la multa: el análisis del régimen sancionador
Dicho esto, el marco existe. El artículo 201 bis de la Ley 58/2003 fue añadido por el artículo 13.21 de la Ley 11/2021, de 9 de julio, y está en vigor desde el 11 de octubre de 2021. Su rúbrica ya es reveladora, porque no habla de «uso» sino de tenencia: «Infracción tributaria por fabricación, producción, comercialización y tenencia de sistemas informáticos que no cumplan las especificaciones exigidas por la normativa aplicable».
| Sujeto | Conducta tipificada | Precepto | Sanción |
|---|---|---|---|
| Fabricante, productor o comercializador | Fabricar, producir o comercializar un sistema que incurra en alguno de los supuestos a) a e) — entre ellos, no cumplir las especificaciones de integridad, trazabilidad e inalterabilidad del art. 29.2.j) | Art. 201 bis.1 y .4 LGT | 150.000 € por cada ejercicio con ventas y por cada tipo distinto de sistema |
| Fabricante o comercializador | No certificar mediante declaración responsable, estando obligado a ello | Art. 201 bis.1.f) y .4 LGT | 1.000 € por cada sistema o programa comercializado sin certificado |
| Usuario (empresa, autónomo y también tu propio despacho) | Tenencia de sistemas no ajustados al art. 29.2.j) únicamente en dos supuestos: (a) que no estén debidamente certificados debiendo estarlo, o (b) que se hayan alterado o modificado dispositivos certificados | Art. 201 bis.2 y .4 LGT | 50.000 € por cada ejercicio |
| — | Regla que evita la doble sanción: quien ya fue sancionado por el apartado 1 no puede serlo por el apartado 2 | Art. 201 bis.2, párrafo segundo | — |
Todas las infracciones del artículo se califican como graves por su apartado 3.
Tres matices que casi todo el sector cuenta mal
Primero: la multa al usuario es por tenencia, no por uso. La rúbrica y el apartado 2 emplean ese término. No hace falta emitir ni una factura con el sistema para incurrir en el supuesto.
Segundo: no es una multa genérica de 50.000 € «por incumplir VeriFactu». Este es el error más repetido. El apartado 2 está acotado a dos causas tasadas: que el sistema no esté debidamente certificado debiendo estarlo, o que se haya alterado o modificado un dispositivo certificado. Fuera de esos dos supuestos, el tipo no se activa. Cualquier titular que prometa «50.000 € por tener un programa antiguo» está simplificando de más.
Tercero, y aquí conviene ser especialmente prudente: es defendible sostener que, si un software venía certificado por su fabricante y en el despacho o en casa del cliente se han añadido entidades ficticias con capacidad de generar registros de facturación dentro de producción, estaríamos ante un «dispositivo certificado alterado o modificado» a los efectos del apartado 2. Es un razonamiento coherente con el artículo 8.2.a) del reglamento, que califica de alteración la adición de registros simulados. Pero es una interpretación nuestra: no existe pronunciamiento expreso de la DGT ni de los tribunales sobre este punto concreto, y así hay que trasladárselo al cliente. Tampoco hay evidencia pública de que la AEAT esté sancionando hoy por este motivo.
El matiz de la AEAT sobre la tenencia que cambia el enfoque práctico
Las preguntas frecuentes de la sede electrónica de la AEAT precisan que la tenencia hay que entenderla vinculada a la funcionalidad de facturar. En sus términos, tener un sistema antiguo no adaptado al reglamento estaría permitido si y solo si puede acreditarse que con él ya no se pueden expedir facturas; lo habitual es desinstalarlo, aunque también cabe modificarlo para impedir la emisión a partir de una fecha, y si la base de datos se conserva únicamente para consultar el histórico, no habría incumplimiento.
Ese criterio es oro puro para el apartado práctico, porque reorienta la solución: el objetivo no es borrar datos, es acreditar que esa entidad ya no puede facturar.
La conversación con el cliente es más fácil con los datos delante
El panel de cumplimiento de CopilotGestoria reúne el estado de cada cliente, los vencimientos y las incidencias detectadas, para que llegues a la reunión con el expediente hecho en lugar de reconstruirlo la noche anterior.
Solicitar una demostración Ver planes y preciosEl dato que nadie te ha contado: el plazo de tu proveedor venció hace un año
Aquí está, para mi gusto, el hallazgo más útil de toda la consulta, y el que puedes convertir en acción esta misma semana.
Cuando en diciembre de 2025 se publicó el Real Decreto-ley 15/2025, de 2 de diciembre (BOE-A-2025-24446, BOE de 3 de diciembre, en vigor desde el 4 de diciembre), el sector entero leyó el titular: «VeriFactu se aplaza a 2027». Y es cierto, pero solo para dos de los tres sujetos obligados. La disposición final cuarta del RD 1007/2023, en su redacción vigente, distingue plazos que la propia V1042-26 reproduce ya actualizados:
| Obligado | Fecha límite | Precepto |
|---|---|---|
| Contribuyentes del Impuesto sobre Sociedades (art. 3.1.a del reglamento) | Antes del 1 de enero de 2027 | DF 4ª RD 1007/2023, redacción del RDL 15/2025 |
| Resto de obligados del art. 3.1 (IRPF con actividad económica, IRNR con establecimiento permanente, entidades en atribución de rentas) | Antes del 1 de julio de 2027 | DF 4ª RD 1007/2023, redacción del RDL 15/2025 |
| Productores y comercializadores de software (art. 3.2) | 29 de julio de 2025 — vencido | DF 4ª: nueve meses desde la entrada en vigor de la Orden HAC/1177/2024 |
| Sistemas incluidos en contratos de mantenimiento plurianuales contratados antes de esa fecha | Antes del 1 de julio de 2027 | DF 4ª, inciso final |
Y la DGT lo dice con todas las letras, con la fecha calculada:
«Por tanto, la entidad consultante, como productor y/o comercializador de los sistemas informáticos a que se refiere el artículo 1 del mencionado Reglamento estará obligado a ofrecer los productos adaptados totalmente a dicho Reglamento en el plazo máximo de nueve meses desde la entrada en vigor de la Orden HAC/1177/2024, es decir, como máximo hasta el 29 de julio de 2025, si bien este plazo máximo no impide que la comercialización de sistemas informáticos de facturación adaptados pueda iniciarse con mayor antelación; además, en relación con sistemas informáticos incluidos en los contratos de mantenimiento de carácter plurianual contratados antes de este último plazo, deberán estar adaptados al contenido del reglamento con anterioridad al 1 de julio de 2027.»
Lee la fecha de nuevo: 29 de julio de 2025. Este artículo se publica el 29 de julio de 2026. Hace exactamente un año. El aplazamiento del RDL 15/2025, que movió a tus clientes a 2027, no tocó ese plazo. Y la consulta es de mayo de 2026, con el aplazamiento ya en vigor: la DGT lo confirma con el nuevo calendario delante.
¿Qué significa esto en la práctica del despacho? Que la respuesta «ya lo miraremos en 2027» es de tu cliente, no de su proveedor. Puedes escribir hoy a cada fabricante y pedirle la declaración responsable del artículo 13, porque su obligación de ofrecer producto adaptado se cumplió —o se incumplió— hace doce meses. Con la única salvedad de los sistemas incluidos en contratos de mantenimiento plurianuales anteriores, que tienen hasta el 1 de julio de 2027.
Si quieres profundizar en cómo comunicar el calendario a tu cartera sin generar alarma, lo desarrollamos en el análisis del aplazamiento con las fechas oficiales. Y para el marco general del reglamento, la referencia es la guía completa de VeriFactu para gestorías.
Cómo auditar tu despacho y el parque de software de tus clientes
Vamos a la parte accionable. Esto es lo que puedes hacer sin esperar a nadie, ordenado por esfuerzo creciente.
Paso 1 — Empieza por tu propia casa
El despacho es, a la vez, usuario de software de facturación y —si emite facturas a sus clientes— obligado del artículo 3.1. Antes de auditar a nadie, revisa: qué programa emite las facturas de la gestoría, en qué versión, si esa versión tiene visible la declaración responsable dentro del propio programa (el artículo 13.2 obliga a que conste «de modo visible en el propio sistema informático»), y si en esa instalación hay alguna empresa que no corresponda a un cliente real. Muchos programas se instalan con una sociedad de demostración incluida y ahí sigue, años después, porque nadie la miró.
Paso 2 — Inventaría el parque de tus clientes
No hay atajo. Necesitas una tabla con una fila por cliente y, como mínimo, estas columnas: programa de facturación, fabricante, versión, modalidad prevista (remitente o no remitente), si el proveedor ha confirmado la conformidad y si has recibido la declaración responsable. Encontrarás de todo: clientes con soluciones profesionales al día, clientes con programas descatalogados sin soporte y clientes facturando con hojas de cálculo o con documentos de texto. Los tres casos requieren respuestas distintas y ninguno se resuelve por defecto.
Paso 3 — Busca el patrón concreto
Dentro de cada instalación en producción, lo que buscas es cualquier entidad que no se corresponda con un obligado tributario real: empresas llamadas «Demo», «Pruebas», «Empresa 999», «Test» o el nombre del propio fabricante. El patrón está documentado públicamente por el propio sector. Un ejemplo de fabricante que lo explica con transparencia en su documentación de ayuda: «En el caso de que estés editando la empresa de pruebas que viene activada en el programa por omisión, recuerda que ésta sólo permite facturar en un entorno "de pruebas", es decir, ficticio». Lo citamos como muestra de que el patrón existe en el mercado y de que hay fabricantes que lo documentan bien, no como señalamiento de incumplimiento de nadie.
Paso 4 — Escribe al proveedor
Cuatro preguntas, en un correo corto, con el artículo delante. Puedes copiar este esquema:
Asunto: Solicitud de declaración responsable — art. 13.3 del RD 1007/2023
Estimados señores:
En mi condición de cliente, y al amparo del artículo 13.3 del Real Decreto 1007/2023, les solicito la declaración responsable correspondiente a la versión [indicar versión] de [nombre del programa] instalada en [cliente/instalación].
Asimismo, les agradecería que me confirmasen por escrito: (1) si la instalación entregada incluye alguna entidad o sociedad de demostración o de pruebas dentro del entorno de producción; (2) en caso afirmativo, el procedimiento previsto por ustedes para retirarle la capacidad de expedir facturas sin afectar al encadenamiento de los registros; y (3) si su producto dispone de un entorno de pruebas separado del de producción para formación y validaciones.
Quedo a la espera de su respuesta. Un cordial saludo.
Paso 5 — Documenta y archiva
Guarda las respuestas. Ante una eventual comprobación, la diferencia entre un despacho diligente y uno que no lo fue es un expediente con fechas: cuándo preguntaste, qué te contestaron, qué hiciste después. No es burocracia por gusto: es la prueba de la diligencia.
Lista de verificación complementaria
Los errores que la AEAT detecta con más frecuencia y cómo anticiparlos, en un documento de diez puntos que puedes usar como guion de revisión trimestral.
Qué hacer con las entidades ficticias que ya existen
Esta es la pregunta que nadie ha respondido por escrito, y la respuesta intuitiva —«pues las borro»— es probablemente la peor de todas.
Por qué borrar no es la solución
El artículo 8.2.a) del reglamento define como alteración, además de la adición de registros simulados, «la ocultación o eliminación de cualquier registro de facturación originalmente generado y registrado por el sistema informático». Y añade que «cualquier necesidad de corrección o anulación de los datos registrados deberá ser realizada mediante al menos un registro de facturación adicional posterior, de forma que se conserven inalterables los datos originalmente registrados». Borrar a lo bruto los registros de una empresa de pruebas puede, según cómo lo haga el programa, romper el encadenamiento de huellas de toda la instalación. Recuerda el hilo de Odoo: las cadenas se contaminan con facilidad y arreglarlas mal es peor que dejarlas.
El criterio correcto: quitarle la capacidad de facturar y acreditarlo
El razonamiento que sostiene la AEAT en sus preguntas frecuentes para los sistemas antiguos —tener el sistema es admisible si se acredita que ya no puede expedir facturas— traslada bien a este caso. El objetivo no es que desaparezca el rastro, sino que esa entidad deje de ser capaz de generar registros de facturación y que puedas demostrarlo. En orden:
- Documenta el estado actual antes de tocar nada: qué entidades ficticias hay, desde cuándo, qué registros han generado.
- Pregunta al fabricante cuál es su procedimiento previsto. Es su producto y su responsabilidad del artículo 8; que sea él quien indique el camino, por escrito.
- Retírale la capacidad de emitir: bloqueo del alta de facturas, desactivación de series, revocación de permisos de usuario. Lo que el programa permita, según la indicación del proveedor.
- Conserva el histórico si el sistema lo requiere para no romper el encadenamiento. Un histórico consultable que no puede facturar encaja en el criterio de la AEAT.
- Deja constancia: fecha, actuación, instrucción recibida del proveedor y responsable. Ese es tu expediente.
«¿Y entonces cómo formo a mi equipo y hago demostraciones?»
Es la pregunta que queda flotando, y la consulta la responde sin querer. Recuerda que la formación de usuarios era uno de los usos alegados por el consultante —«pruebas internas, validaciones técnicas, formación de usuarios y controles de calidad»— y que la DGT lo rechaza igual mientras esté en producción. La salida no es dejar de formar: es formar en el sitio correcto.
En la práctica, eso significa una instalación o base de datos separada de la de producción, con sus propios datos, sus propias series y —este punto es el que se olvida— sin que sus registros compartan el encadenamiento con los reales. Si tu programa no ofrece esa separación, es exactamente la pregunta número tres del correo del apartado anterior. Un fabricante que en 2026 no puede darte un entorno de pruebas separado te está diciendo algo relevante sobre su producto.
Formar al equipo sin ensuciar los datos reales
CopilotGestoria se conecta con el software contable que ya utiliza el despacho —Sage 50, ContaPlus y formatos universales— en lugar de reemplazarlo, y mantiene separado lo que se prueba de lo que se factura. Treinta días gratis, sin permanencia.
Crear cuenta gratis Ver integracionesSeis ideas equivocadas que circulan sobre esto
| Lo que se dice | Lo que dice la norma |
|---|---|
| «Puedes probar dentro del programa con una empresa ficticia.» | Solo fuera de producción. En producción es contrario al art. 8 del RD 1007/2023 (V1042-26). |
| «Mi software está homologado por la AEAT.» | No existe homologación administrativa. Existe la declaración responsable del productor (art. 13). |
| «Son 50.000 € por incumplir VeriFactu.» | El art. 201 bis.2 LGT exige que el sistema no esté certificado debiendo estarlo, o que se haya alterado un dispositivo certificado. No es una multa genérica. |
| «Todo se aplazó a 2027.» | Para los obligados del art. 3.1, sí. Para productores y comercializadores, el plazo venció el 29 de julio de 2025. |
| «Si no tiene efectos fiscales, no pasa nada.» | Es literalmente la tesis que la DGT rechaza: facturar y cumplir los requisitos del sistema son obligaciones formales distintas. |
| «El entorno de pruebas de la AEAT me cubre.» | Es un destino de envío para validar la integración, no un lugar donde puedan vivir entidades ficticias en producción. |
Si te interesa el mapa completo de confusiones normativas del momento, la más frecuente en las reuniones con clientes sigue siendo la de VeriFactu frente a la Ley Crea y Crece, que son dos obligaciones distintas con dos calendarios distintos. Y para revisar el resto del frente fiscal, tienes los diez errores más habituales del despacho en 2026.
Preguntas frecuentes
En el entorno de producción, no. La consulta vinculante V1042-26 de la Dirección General de Tributos concluye que introducir entidades o sociedades ficticias en un software de facturación operativo en producción es contrario al artículo 8 del RD 1007/2023. Sí es admisible en un entorno de pruebas previo y separado, que es la excepción que la propia consulta recoge de forma expresa.
El entorno de producción es la instalación con la que se factura de verdad y que genera los registros con valor tributario. El entorno de pruebas es una instalación o base de datos distinta, previa a producción, destinada a desarrollo, validaciones y formación. La separación relevante no es solo de nombre: los registros del entorno de pruebas no deben compartir el encadenamiento de huellas con los de producción.
Son dos infracciones distintas con dos sujetos distintos. El artículo 201 bis.1 de la LGT sanciona al fabricante, productor o comercializador con 150.000 € por ejercicio con ventas y por tipo de sistema. El artículo 201 bis.2 sanciona al usuario con 50.000 € por ejercicio, pero solo por la tenencia de sistemas no certificados debiendo estarlo o de dispositivos certificados que se hayan alterado. Quien ya haya sido sancionado por el apartado 1 no puede serlo por el apartado 2.
No. En España no hay homologación administrativa de software de facturación ni lista oficial de programas autorizados. El mecanismo previsto por el artículo 13 del RD 1007/2023 es una declaración responsable que emite el propio productor, por cada versión del sistema, y que el cliente puede solicitarle en cualquier momento.
Porque son plazos distintos. El aplazamiento del RDL 15/2025 movió a los obligados del artículo 3.1 al 1 de enero y al 1 de julio de 2027, pero no alteró el plazo de productores y comercializadores del artículo 3.2, que venció el 29 de julio de 2025 según confirma la propia DGT en V1042-26. La única salvedad son los sistemas incluidos en contratos de mantenimiento plurianuales anteriores, que tienen hasta el 1 de julio de 2027.
No es lo recomendable. El artículo 8.2.a) del RD 1007/2023 considera alteración la eliminación de registros de facturación ya generados, y exige que las correcciones se realicen mediante registros adicionales posteriores conservando inalterables los originales. El criterio operativo más seguro, alineado con las preguntas frecuentes de la AEAT sobre sistemas antiguos, es retirarle a esa entidad la capacidad de expedir facturas, conservar el histórico y documentar la actuación, siempre siguiendo la indicación escrita del fabricante.
El reglamento no distingue por origen del programa: el artículo 1 se refiere a cualquier sistema informático utilizado por quienes desarrollen actividades económicas cuando soporte los procesos de facturación. La propia V1042-26 se declara conforme con la consulta V0080-26, planteada precisamente por un grupo empresarial con software de facturación desarrollado internamente. Sí conviene recordar que el artículo 3.3 excluye a los contribuyentes que llevan los libros registro en los términos del artículo 62.6 del Reglamento del IVA, es decir, los acogidos al SII.
Conclusión: tres cosas que hacer esta semana
La consulta V1042-26 no cambia la norma. Aplica una definición que estaba en el BOE desde diciembre de 2023 y que el sector había leído mirando hacia otro lado: el artículo 8.2.a) del RD 1007/2023 ya calificaba de alteración la adición de registros de facturación «simulados o falsos». Lo que aporta la DGT es la conclusión explícita de que una empresa de pruebas dentro del entorno de producción entra en esa categoría, por muy bien identificada que esté y aunque nadie mande sus datos a la AEAT.
Con eso en la mano, tres actuaciones concretas:
Una. Revisa el programa con el que factura tu propio despacho y comprueba si conserva la sociedad de demostración con la que se instaló. Es el caso más frecuente y el más fácil de resolver.
Dos. Escribe a los fabricantes pidiendo la declaración responsable del artículo 13.3, indicando la versión concreta. No estás pidiendo un favor: su plazo de adaptación venció el 29 de julio de 2025, hace exactamente un año, y el aplazamiento a 2027 no le afectó.
Tres. Antes de tocar ninguna entidad ficticia existente, documenta lo que hay y pide por escrito al proveedor su procedimiento. El objetivo es retirarle la capacidad de facturar, no hacer desaparecer el rastro. Borrar mal puede convertir un problema pequeño en uno grande.
Y una última cautela, porque este artículo se ha construido sobre la precisión: la consulta no habla de sanciones. El análisis del artículo 201 bis que hemos desarrollado es marco legal aplicable e interpretación razonada, no doctrina de la DGT, y no hay evidencia pública de que la AEAT esté sancionando hoy por este motivo. La razón para actuar no es el miedo a una multa: es que dentro de doce meses el primer bloque de tus clientes tiene que estar operativo bajo el reglamento, y llegar a esa fecha con el parque de software inventariado y las declaraciones responsables archivadas es la diferencia entre un trimestre tranquilo y uno que no lo será.
Llega a 2027 con el trabajo hecho
CopilotGestoria automatiza el procesamiento de facturas, los modelos de la AEAT y el seguimiento del cumplimiento de tu cartera, integrándose con las herramientas que ya usa el despacho. Treinta días gratis, sin tarjeta y sin permanencia.
Probar gratis 30 días Hablar con un expertoTabla de vigencia de los datos de este artículo
| Dato | Valor | Norma o fuente | Verificado |
|---|---|---|---|
| Fecha de la consulta V1042-26 | 13/05/2026 | PETETE, Dirección General de Tributos | 29-jul-2026 |
| Entidades ficticias prohibidas en producción | Criterio vigente | Art. 8 RD 1007/2023 · V1042-26 | 29-jul-2026 |
| Admisibles en entorno de pruebas previo | Criterio vigente | V1042-26, apartado TERCERO | 29-jul-2026 |
| Plazo Impuesto sobre Sociedades | antes del 1-ene-2027 | DF 4ª RD 1007/2023 (red. RDL 15/2025) | 29-jul-2026 |
| Plazo resto de obligados | antes del 1-jul-2027 | DF 4ª RD 1007/2023 (red. RDL 15/2025) | 29-jul-2026 |
| Plazo productores y comercializadores | 29-jul-2025 (vencido) | DF 4ª + DF única Orden HAC/1177/2024 | 29-jul-2026 |
| Contratos de mantenimiento plurianuales previos | antes del 1-jul-2027 | DF 4ª, inciso final | 29-jul-2026 |
| Sanción a productor o comercializador | 150.000 € por ejercicio y tipo de sistema | Art. 201 bis.1 y .4 LGT | 29-jul-2026 |
| Sanción por falta de certificado | 1.000 € por sistema comercializado | Art. 201 bis.1.f) y .4 LGT | 29-jul-2026 |
| Sanción al usuario por tenencia | 50.000 € por ejercicio | Art. 201 bis.2 y .4 LGT | 29-jul-2026 |
| Calificación de las infracciones | Graves | Art. 201 bis.3 LGT | 29-jul-2026 |
| Vigencia del art. 201 bis | desde 11-oct-2021 | Ley 11/2021, de 9 de julio | 29-jul-2026 |
| Declaración responsable: del productor y por versión | Vigente | Art. 13 RD 1007/2023 | 29-jul-2026 |
| Sistema antiguo: tenencia admisible si no puede facturar | Criterio administrativo | Preguntas frecuentes, sede AEAT | 29-jul-2026 |
| RDL 15/2025 en vigor | desde 4-dic-2025 | BOE-A-2025-24446 | 29-jul-2026 |
Fuentes consultadas
- Dirección General de Tributos, consulta vinculante V1042-26, de 13 de mayo de 2026 — base de doctrina PETETE
- Dirección General de Tributos, consulta vinculante V0080-26, de 20 de enero de 2026 (doctrina concordante invocada por la anterior)
- Ley 58/2003, de 17 de diciembre, General Tributaria — arts. 29.2.j), 89.1 y 201 bis — texto consolidado en el BOE
- Real Decreto 1007/2023, de 5 de diciembre — arts. 1, 2, 3, 8 y 13 y disposición final cuarta — BOE
- Orden HAC/1177/2024, de 17 de octubre (BOE de 28 de octubre de 2024)
- Real Decreto-ley 15/2025, de 2 de diciembre — BOE-A-2025-24446
- Real Decreto 1619/2012, de 30 de noviembre, Reglamento de obligaciones de facturación
- Preguntas frecuentes sobre VERI*FACTU — sede electrónica de la AEAT
- Foro público de la comunidad Odoo, hilo sobre encadenamiento de huella entre pruebas y producción (fuente secundaria, citada como testimonio técnico público)
Sobre este artículo. Redactado por el equipo de CopilotGestoria con la revisión de asesores fiscales colegiados. Las citas de la consulta V1042-26 proceden del texto íntegro publicado en la base de doctrina PETETE de la Dirección General de Tributos; las citas normativas, del texto consolidado del BOE.
Este contenido tiene finalidad informativa y no sustituye al asesoramiento profesional sobre un caso concreto. Antes de aplicar cualquiera de estos criterios a una instalación en producción, contrasta con el fabricante del software y con la normativa vigente en la fecha de aplicación.
