Listado dudas Faqs + respuestas canal
 

Buenos días,
Me gustaría elaborar un listado de todas aquellas explicaciones confusas, retorcidas, ambiguas, incompletas o sesgadas que, en definitiva, no aportan seguridad jurídica y pueden dar lugar a que un inspector interprete la normativa de forma distinta a la nuestra y nos imponga una sanción.

Para ello, os pido vuestra colaboración, ya que identificar y recopilar estos puntos puede ser clave para ganar tranquilidad y claridad en la aplicación de la normativa.

El objetivo final es intentar escalar estas cuestiones a algún organismo con capacidad de interlocución y peso institucional, como la Confederación de Empresarios, el Club de Asesores o la Asociación Española de Asesores Fiscales, para que puedan trasladarlas y exigir aclaraciones formales.

Empiezo yo:

Aclaración de que el error 2004 no requiere subsanación, eliminando los textos en los que se presenta como un error subsanable.

Aclaración de que, habiéndose desarrollado un reglamento técnico para la trazabilidad de las facturas, no existe uno equivalente para el resto de datos informáticos (albaranes, prefacturas, proformas, etc.). O bien se desarrolla un reglamento técnico específico, o bien se deberían evitar referencias a posibles sanciones en estos casos.

Aclaración de que, si durante el año 2026 (o hasta julio 2027, según el caso) mantengo a algún cliente con un software aún no actualizado, pueda intervenir para restaurar el sistema sin que ello suponga una infracción, ya que existen operativas de trabajo que pueden ser más complejas de adaptar al nuevo reglamento y que, en determinadas situaciones, requieren una solución urgente, como una recuperación del sistema o incluso una reinstalación del software que todavía no es el reglamentado, garantizando en todo caso la continuidad del negocio.

Añado:

Aclaración sobre el procedimiento correcto y permitido para emitir una simple devolución, ya que en las FAQs se indica que en las facturas rectificativas debe figurar como fecha de operación la de la factura original, lo que genera dudas relevantes sobre cómo afecta al período de imputación y al período de liquidación.
Esta interpretación resulta, como mínimo, ambigua y difícil de aplicar en el caso de una devolución, y además es complicado equipararla con otras explicaciones de la propia AEAT, como las incluidas en las FAQs de ayuda del modelo 347, donde se indica:

> “Las operaciones se entenderán producidas en el período en el que se deba realizar la anotación registral de la factura que sirva de justificante.”

“En las facturas expedidas deben estar anotadas en el momento en que se realice la liquidación y pago del impuesto correspondiente a dichas operaciones.”

Subo este post...
Colaborad que voy "palante" please.

- Facturas en negativo en devolución en dos pasos, que la primera es una factura normal en negativo y la segunda la rectificativa, lo que contradice la forma natural de hacer el resto de rectificativas.
- Recargo de equivalencia en facturas cualificadas, es decir, que provienen de facturas simplificadas en las que posteriormente el cliente te pide factura completa y aplicación de recargo de equivalencia, ¿cual es el proceso exactamente?. Yo entiendo que es hacer una factura completa rectificativa por sustitución de la factura simplificada, pero no he encontrado documentación que lo justifique. Tampoco si hay obligación de hacerlo y el cliente no lo ha comunicado previamente, así como tampoco la forma en que se tiene que comunicar que se está en recargo de equivalencia para que quede justificación documental. Por último es confuso el tipo de "R" que se tiene que aplicar en Verifactu, ya que hay un R5 para facturas simplificadas, pero aquí la estamos convirtiendo en cualificada/completa
- Lo de las facturas cualificadas y completas con series diferenciadas es otro punto que no tiene sentido. ¿Como diferencias una factura completa de una cualificada una vez impresa?, Por la serie, pero si solo tienes una factura, no sabes si es una completa o una cualificada, excepto porque todos lo ponemos como comentario, lo cual no es obligatorio. ¿Entonces de que vale la obligación de la serie diferenciada más que para marear la perdiz?
- Forma de actuación ante desastres: lo de el desarrollador lo debería haber previsto, como si fuéramos Rapel no es ninguna explicación.
- Aunque a muchos no nos toca, lo de los Excel o cualquier otra "explicación" que remita a lo que decida el inspector en una inspección es inherentemente inseguridad jurídica. Si no pueden explicarlo que no lo apliquen.


Por otro lado yo lo que veo son también muchas cosas que no es que estén confusas, es que no son operativas o directamente no hay por donde pillarlas:
- Lo de no poder enviar con los clientes durante un periodo de tiempo al endpoint de pruebas. Lo que dicen ahora (que no antes) que "estamos en un periodo de pruebas" es un parche como una catedral, manda el mensaje de que ellos mismos ven que esto no es de recibo, y es pura inseguridad jurídica, porque ante un error sigues sin saber cómo se va a evaluar y si puedes tener sanción. Según Hacienda "depende del tipo..." pues que bien... ya podemos dormir más tranquilos...
- Todo el lio que se traen con los SIF, identificación y cambio de código en cualquier tipo de modificación o actualización del software, así como el correspondiente cambio en la declaración responsable. Aparte de confuso, ¿que sentido tiene guardar y exponer de cara al publico decenas o cientos (con el tiempo) de declaraciones responsables de un sistema que probablemente solo se van a diferenciar en el número de versión y la fecha de firma?


Y luego si se me ocurre algo más ya lo pongo...