Hay empresas que llevan años preparando el modelo 347 de forma manual sin saber que están exentas de presentarlo. Otras confían en que NetSuite lo genere correctamente y obtienen un informe incompleto porque la instancia no está configurada para ello. Antes de entrar en el proceso, conviene entender qué hace NetSuite de forma nativa y bajo qué condiciones funciona bien.
La Agencia Tributaria lo recoge expresamente en la lista de excluidos (art. 32 del RGAT): los obligados tributarios sujetos o acogidos al SII están exentos de presentar esta declaración. La razón es lógica: el SII ya proporciona a la AEAT el detalle de todas las facturas en tiempo casi real, así que la declaración anual de operaciones con terceros sería redundante.
El SII es obligatorio para empresas con facturación anual superior a 6 millones de euros y para los grupos del IVA. También es de adhesión voluntaria para cualquier empresa que quiera acogerse.
Hay un matiz relevante para el primer año de inscripción en el SII: la exención aplica a quienes hayan estado sujetos al SII durante todo el ejercicio. Si una empresa superó el umbral de facturación a mitad de año y se incorporó al SII en ese momento, puede que no quede exenta para ese ejercicio completo. A partir del año siguiente, la exención es total.
Esto tiene una implicación directa para muchos usuarios de NetSuite en España: si vuestra empresa lleva uno o más ejercicios completos en el SII —y tenemos configurado NetSuite para ello, como explicamos en el artículo sobre el SII y NetSuite— esta declaración ya no es una obligación. Es un proceso que puede eliminarse del calendario fiscal.
No es un detalle menor. En equipos financieros que llevan años extrayendo datos y preparando la declaración manualmente, descubrir que no era necesario es una liberación de tiempo real.
Para las empresas que sí están obligadas a presentarlo, la localización española de NetSuite —basada en SuiteTax y disponible a través de la Spain Localization SuiteApp— incluye un módulo nativo para esta declaración. No hace falta construir nada desde cero ni recurrir a herramientas externas para la generación del informe.
La documentación oficial de Oracle NetSuite describe el funcionamiento: el módulo genera el informe para el ejercicio fiscal seleccionado, aplica automáticamente el umbral de 3.005,06 €, desglosa los importes por trimestre, y permite exportar el fichero en formato TXT para su presentación ante la AEAT. Cubre operaciones nacionales, intracomunitarias y de importación/exportación.
El módulo existe, tiene recorrido en producción y, cuando la instancia está bien configurada, funciona.
El matiz relevante está en esa última frase.
La documentación oficial recoge una lista de condiciones técnicas que deben cumplirse para que el módulo produzca datos correctos. No son opcionales ni están sujetas a interpretación: si no se cumplen, el informe puede estar incompleto o ser incorrecto, y NetSuite no siempre avisa de ello.
Sin entrar en el detalle de cada condición —que varía según la configuración de cada instancia—, los factores que más frecuentemente causan problemas en proyectos reales son los relativos a la configuración de los tax codes, el estado de los datos maestros de terceros, la coherencia del campo de fecha fiscal en las transacciones, y el modo en que se han registrado históricos previos.
Instancias que vienen de una configuración anterior a SuiteTax, que han incorporado tax codes personalizados, o que han recibido una migración de datos de otro ERP son especialmente propensas a que alguna de estas condiciones no esté correctamente cubierta.
El problema no es que el módulo falle de forma visible. Es que genera el informe sin errores pero con datos incompletos.
Antes de ser consultores, hemos sido usuarios de NetSuite en empresas con estas mismas obligaciones. Eso nos ha dado perspectiva sobre cómo se acumula la deuda de configuración: decisiones tomadas durante la implantación que parecían menores y que años después condicionan la fiabilidad de los informes fiscales.
En las auditorías que hemos realizado sobre instancias en producción, el patrón más frecuente no es un error evidente sino una divergencia silenciosa: el informe genera una cifra, el equipo financiero la acepta porque parece razonable, y nadie cruza los datos contra la información real de la AEAT hasta que aparece una discrepancia.
Los orígenes de esa divergencia son siempre de configuración, no de capacidad del módulo. El módulo funciona. El problema está en lo que hay debajo.
No detallamos aquí cómo se diagnostica y corrige cada caso porque la casuística es específica de cada instancia y el riesgo de aplicar una solución genérica a un problema concreto es mayor que el de no hacer nada.
Este es el punto que más sorprende a los equipos financieros cuando lo ven por primera vez: NetSuite no lanza ninguna alerta cuando excluye transacciones de este informe por problemas de configuración. El sistema aplica las condiciones que tiene definidas, genera el informe con los datos que encuentra, y lo presenta como completo.
Si hay terceros con el número de identificación fiscal vacío o mal informado en su ficha, esas operaciones quedan fuera sin aviso. Si hay transacciones con tipos de impuesto que el módulo no reconoce como válidos para este informe, tampoco aparecen. Si hay histórico migrado que no comparte la misma estructura de datos que las transacciones nativas de NetSuite, el resultado puede no recoger parte del ejercicio.
El informe es técnicamente correcto —en el sentido de que no contiene datos erróneos— pero puede estar omitiendo operaciones que deberían estar declaradas.
Para la AEAT, la diferencia entre un informe incompleto y uno incorrecto no siempre es relevante desde el punto de vista sancionador.
No, siempre que hayan estado en el SII durante todo el ejercicio. La AEAT recoge expresamente esta exención en el artículo 32 del RGAT: los obligados tributarios sujetos o acogidos al SII no presentan el modelo 347. Aplica tanto al SII obligatorio (facturación superior a 6 millones de euros, grupos del IVA) como al voluntario. El único matiz es el primer ejercicio de inscripción: si la incorporación al SII se produjo a mitad de año, puede que la exención no cubra ese ejercicio completo y haya que verificarlo.
Sí. La Spain Localization SuiteApp de NetSuite incluye un módulo específico que genera el informe anual y permite exportarlo en formato TXT para presentarlo ante la AEAT. Sin embargo, el informe solo es fiable cuando la instancia cumple una serie de condiciones de configuración que deben verificarse. No es un módulo que funcione correctamente en cualquier instancia sin una revisión previa.
Depende de cómo estén configurados y de si el módulo los reconoce como válidos para el informe. La documentación oficial de NetSuite establece que el módulo requiere el uso de los tax codes predefinidos de SuiteTax España. Los tax codes personalizados o los que provienen de configuraciones anteriores a SuiteTax pueden quedar fuera del alcance del informe sin que el sistema lo indique. Este es uno de los puntos que conviene revisar antes de dar por bueno el resultado.
La forma más directa es contrastar el importe total del informe con los saldos contables de las cuentas de proveedores y clientes para el mismo período. Si hay diferencias significativas y no hay una explicación clara (exclusiones justificadas, operaciones en SII, etc.), hay algo en la configuración que merece revisión. Nosotros realizamos este tipo de auditoría como parte del servicio de soporte y localización española de NetSuite.
¿Queréis saber si vuestra instancia de NetSuite está generando esta declaración de forma fiable, o si directamente estáis exentos de presentarla? Contáctanos y lo revisamos.
Gratuito
