El Suministro Inmediato de Información lleva vigente desde 2017 y muchas empresas siguen encontrando avisos de error en la sede electrónica de la AEAT. La causa casi nunca es NetSuite en sí — es la configuración. Esta guía explica cómo funciona la integración, qué errores aparecen con más frecuencia y cómo validar que vuestros registros están llegando correctamente antes de que llegue una comprobación.
El SII obliga a llevar los libros de registro del IVA — facturas emitidas, facturas recibidas, bienes de inversión y determinadas operaciones intracomunitarias — a través de la sede electrónica de la AEAT, con un plazo máximo de cuatro días naturales desde la fecha de expedición o recepción de la factura, excluidos sábados, domingos y festivos nacionales.
Están obligadas desde el 1 de julio de 2017 las empresas con volumen de operaciones superior a 6 millones de euros anuales, los grupos de IVA, las empresas acogidas al régimen de devolución mensual (REDEME) y los declarantes del modelo 303 mensual. Cualquier otra empresa puede acogerse voluntariamente y, una vez dentro, no puede salir salvo en casos muy concretos.
Si vuestra empresa está dentro de este perímetro y usa NetSuite como ERP, el envío de registros al SII tiene que funcionar sin fisuras. Una incidencia de envío no es solo un problema técnico: puede desencadenar un requerimiento formal de la AEAT y retrasar devoluciones de IVA que el departamento financiero lleva semanas esperando.
NetSuite incluye localización española con soporte para el SII desde hace varios años. El módulo gestiona la generación del XML requerido por la AEAT y su envío mediante webservices, pero hay que distinguir entre lo que la plataforma hace por defecto y lo que depende de la configuración concreta de cada implementación.
El flujo estándar es el siguiente: NetSuite detecta la factura publicada → genera el XML en el esquema que corresponde (libro de facturas emitidas o recibidas) → lo envía vía SOAP a los webservices de la AEAT → recibe un CSV de respuesta con el estado del envío.
El punto donde más fallan las implementaciones no es el envío en sí, sino la calidad del dato en el momento en que NetSuite genera el XML. Si el NIF de un cliente no está correctamente informado en el registro maestro, si la clave de tipo de operación no se ha configurado o si el campo de régimen especial está vacío cuando debería tener un valor, el XML que se genera es técnicamente sintáctico pero informacionalmente incorrecto. La AEAT lo acepta en primera instancia y lo devuelve como error en el CSV de respuesta — que, como veremos, pocos equipos monitorizan de forma sistemática.
Por cada factura emitida, NetSuite envía al SII: NIF del emisor, NIF del receptor, número de serie y correlativo de la factura, fecha de expedición, tipo de factura (F1 para ordinarias; R1 a R5 para rectificativas), base imponible, tipo impositivo, cuota y clave de tipo de operación (S1, S2, N1, N2, E1...).
Para facturas recibidas, el esquema es diferente: se informa del NIF del proveedor, número de factura del proveedor, fecha de operación, fecha de registro contable, base imponible deducible y cuota deducible, entre otros campos que varían si hay bienes de inversión o prorrata.
Cada uno de esos campos tiene sus propias validaciones en la AEAT. Cuando uno no es coherente con el esquema, el registro vuelve con estado "incorrecto" o "aceptado con errores" — y la diferencia entre ambos estados es relevante: el segundo implica que el registro ha entrado en el libro pero con datos potencialmente erróneos.
Después de revisar implementaciones que han llegado a nuestro equipo para soporte — con los libros de IVA abiertos y los CSV de respuesta encima de la mesa —, hay cinco errores que aparecen con una frecuencia que ya deja de sorprender.
El SII exige que el NIF (o el VAT ID en transacciones intracomunitarias) tenga formato correcto y sea identificable en el censo de la AEAT. NetSuite no valida automáticamente que el NIF de un cliente o proveedor exista y esté activo — solo comprueba el formato en determinados contextos.
El resultado habitual: el XML se genera, se envía y la AEAT devuelve error 3000 ("NIF no identificado en el censo"). En entornos de producción con volumen de facturación, esto puede afectar a decenas de registros antes de que alguien detecte el patrón.
La corrección técnica pasa por activar la validación de NIF en el formulario de terceros y, cuando el volumen de registros lo justifica, por una saved search que filtre todos los clientes y proveedores con NIF vacío o con formato no válido:
Esa lista es el punto de partida para una limpieza de maestro antes de activar el SII o antes de migrar datos desde otro sistema.
Las claves de tipo de operación clasifican si la operación está sujeta y no exenta (S1), sujeta y exenta (E1), no sujeta por reglas de localización (N1 y N2) o acogida a regímenes especiales (S2 para criterio de caja, por ejemplo). NetSuite asigna S1 por defecto en la mayoría de casos, pero las exportaciones, las operaciones intracomunitarias y las operaciones con regímenes especiales requieren claves distintas.
Si todas las facturas llevan S1 cuando algunas deberían llevar E1, N1 o S2, el Libro de Facturas Emitidas no refleja la realidad fiscal de la empresa. La AEAT puede no rechazar el registro en el momento, pero genera inconsistencias con el modelo 303 que en una comprobación posterior son difíciles de justificar.
Las facturas rectificativas — abonos, anulaciones, correcciones de factura — tienen su propio esquema en el SII: se envían como tipo R1 a R5 según el motivo y la naturaleza de la rectificación. R1 es la más habitual (error fundado en derecho o artículo 80 Uno, Dos y Seis de la Ley del IVA). R4 es la que genera más problemas porque implica que la factura rectificada pertenecía a una operación bajo régimen especial de criterio de caja.
NetSuite trata las credit memos como transacciones vinculadas a la factura original, pero la clave de tipo de rectificativa y la referencia explícita a la factura que se rectifica tienen que estar configuradas. En instalaciones donde esto no se ha revisado, las rectificativas llegan al SII como facturas ordinarias tipo F1 — lo que genera un libro de facturas emitidas con abonos que no identifica a qué factura corrigen.
El SII tiene un plazo máximo de cuatro días naturales para facturas emitidas (excluidos sábados, domingos y festivos nacionales) y ocho días para facturas recibidas. Las facturas del mes de diciembre tienen plazo ampliado hasta el 15 de enero del año siguiente.
Si el proceso de facturación en NetSuite incluye flujos de aprobación, validaciones previas o envíos por lotes nocturnos, puede ocurrir que una factura generada el lunes llegue al SII el viernes siguiente — fuera de plazo. La AEAT registra el envío extemporáneo, lo que técnicamente no impide el registro pero puede generar sanciones formales por presentación fuera de plazo conforme al artículo 200 de la Ley General Tributaria.
El diagnóstico requiere revisar la configuración del script o scheduled task que dispara los envíos al SII, y comprobar si hay facturas con más de cuatro días de diferencia entre la fecha de expedición y la fecha de envío registrada en NetSuite.
La AEAT devuelve un CSV por cada XML enviado. Ese CSV incluye el estado (correcto, incorrecto, aceptado con errores) y el detalle de los errores si los hay. Si nadie revisa esas respuestas de forma sistemática, los errores se acumulan silenciosamente durante semanas o meses.
NetSuite almacena las respuestas en el registro de cada transacción (pestaña de localización española), pero hay que ir a buscarlas. Una saved search sencilla con las columnas "fecha de envío SII", "estado SII" y "código de error AEAT", filtrada por estado distinto de "Correcto" en los últimos siete días, da visibilidad inmediata sobre el estado real del cumplimiento. Sin esa visibilidad, el equipo financiero asume que todo va bien hasta que llega un requerimiento.
Si todavía no tenéis el SII activo, o si habéis pasado por una migración o un upgrade de NetSuite, el proceso de validación antes de la activación debería incluir al menos estos pasos:
Para empresas que ya tienen el SII activo y quieren revisar el estado de sus envíos históricos, la AEAT pone a disposición un servicio de consulta de registros enviados accesible desde su sede electrónica.
Cuando un registro vuelve con estado "incorrecto", hay que corregir el dato en NetSuite y reenviar. La plataforma permite reenvíos individuales desde la pestaña de localización española de cada factura. Para errores masivos existe la opción de reenvío por lotes desde la pantalla de administración de la localización.
Los errores más frecuentes y su causa habitual en NetSuite:
Antes de reenviar de forma masiva, conviene corregir el registro maestro o la configuración que genera el error, no solo el dato puntual de la factura. De lo contrario, el próximo ciclo de facturación generará los mismos errores.
No es obligatorio, pero sí recomendable si el equipo interno no tiene experiencia previa con la localización española. La configuración requiere conocimiento del esquema XML del SII, del modelo de impuestos de NetSuite y de los procesos de facturación propios de la empresa. Los errores en la configuración inicial generan registros incorrectos en la AEAT que luego hay que corregir y reenviar — y cuanto más tiempo pase sin revisarlos, mayor es el volumen a depurar.
La AEAT las registra con marca de "extemporáneo". El registro entra en el libro de IVA pero queda flagged. El artículo 200 de la Ley General Tributaria contempla sanciones formales por presentación fuera de plazo de declaraciones informativas, aunque la práctica sancionadora en el SII ha sido hasta ahora más orientada a la subsanación que a la imposición de multas en primera instancia.
Sí. La localización española de NetSuite incluye soporte para el Régimen Especial del Criterio de Caja (RECC). Las facturas emitidas bajo RECC se envían al SII con clave de tipo de operación S2 y el XML incluye los campos específicos del cobro: fecha de cobro, importe cobrado e identificación de la cuenta bancaria o medio de cobro.
Sí. NetSuite admite configuraciones multi-subsidiary, y cada subsidiary puede tener su propia configuración de localización española con sus propias credenciales de envío al SII — incluyendo el certificado digital de la AEAT correspondiente. La clave está en que cada subsidiary tenga correctamente configurado su NIF, su régimen de IVA y sus tipos de operación de forma independiente.
Oracle NetSuite incluye las actualizaciones normativas en las versiones semestrales de la plataforma. Cuando la AEAT modifica el esquema o añade nuevas claves de operación, la actualización llega vía bundle de localización española. Es importante aplicar esos bundles antes de los cambios normativos del ejercicio — dejar una versión de bundle sin aplicar puede generar incompatibilidades con el esquema vigente de la AEAT.
Si tenéis el SII activo y queréis revisar el estado real de vuestros envíos — o si vais a activarlo y preferís no encontraros con cientos de registros incorrectos después de los primeros días de facturación —, nuestro equipo puede hacer una revisión de configuración. Llevamos años trabajando con la localización española de NetSuite, y hemos visto estos mismos errores en implementaciones de empresas de muy distinto tamaño y sector. Cuéntanos tu caso.
Gratuito
