Para monitorizar integraciones de NetSuite basta con tres cosas: saber qué registros deberían haber llegado, medir cuántos han llegado de verdad y tener a alguien que reciba el aviso cuando la diferencia no es cero. Las integraciones rara vez se caen con estruendo: lo habitual es que dejen de sincronizar una parte de los datos y nadie se entere hasta que un cliente reclama o el cierre no cuadra. Repasamos los seis fallos silenciosos que más hemos visto en empresas españolas, las herramientas que ofrece NetSuite para detectarlos y un control mínimo que puedes montar esta misma semana.
Una integración entre NetSuite y una tienda online, un CRM, un banco o un sistema logístico se diseña para el caso feliz. Mientras todo va bien, nadie la mira. El problema aparece cuando falla solo una parte: un pedido con un código de impuesto que no existe en NetSuite, un cliente sin NIF, un artículo descatalogado. La integración sigue "funcionando", pero deja atrás esos registros.
Desde la dirección financiera, el síntoma nunca es "la integración ha fallado". Es "las ventas de la tienda no cuadran con las facturas de NetSuite", "falta un cobro en la conciliación" o "el almacén ha enviado un pedido que finanzas no ve". Cuando la causa se localiza, suelen haber pasado semanas. Y con la facturación electrónica a las puertas, el coste de una factura que no se genera o no se certifica ya no es solo de tesorería: Verifactu tiene un calendario legal propio para las sociedades (las fechas vigentes las recogemos en Verifactu en NetSuite), y si tu facturación nace en un sistema externo, esa integración forma parte de tu cumplimiento. Si todavía no has decidido entre Verifactu y SII, empieza por nuestro artículo Verifactu o SII en NetSuite.
Muchas integraciones registran el error y siguen con el siguiente registro. El pedido rechazado queda en una cola de errores o en un log al que nadie entra. Un ejemplo muy habitual: un cliente nuevo de la tienda online llega sin NIF o con un formato que NetSuite no admite, y el pedido no se crea. El cliente lo ha pagado, el almacén no lo ve y finanzas no lo factura.
Qué hacer: decidir de antemano qué ocurre con un registro rechazado. Que se reintente, que se aparque con un estado visible o que avise a una persona concreta. Lo que no puede pasar es que quede en un limbo sin dueño.
NetSuite limita cuántas peticiones simultáneas pueden hacer los servicios web y los RESTlets a una cuenta. Según la documentación de Oracle sobre Concurrency Governance, en REST web services existe un límite de concurrencia por cuenta que suma las peticiones de web services y de RESTlet, y cada petición cuenta contra él. Cuando coinciden varias integraciones y una carga masiva, algunas peticiones se rechazan.
Dónde mirarlo: en Setup > Integration > Integration Management > Integration Governance, donde NetSuite muestra, entre otros datos, Peak Concurrency, Total Requests, Rejected Requests y Rejected Requests Ratio, según la guía de monitorización de Oracle. Si la ratio de rechazadas no es cero de forma sostenida, hay datos que no están llegando o que llegan tarde.
Oracle aclara en su página de límites de concurrencia un matiz importante: el estado Failed del conector de NetSuite no siempre significa que la integración no funcione, solo que la petición de ese momento falló, y el conector sigue intentándolo hasta recibir un estado Finished. Pero advierte de que otras integraciones pueden no hacer lo mismo y detenerse en el primer Failed.
La consecuencia práctica es que conviene saber cómo se comporta cada una de tus integraciones ante un fallo. Si no lo sabes, no sabes si un error puntual se corrige solo o se queda esperando a que alguien lo vea.
Cuando la integración depende de un RESTlet o de un script programado, los errores quedan en el Script Execution Log. Es el primer sitio al que mira un consultor y el último al que mira un usuario. Un script con una excepción no controlada puede dejar un proceso a medias: el pedido se crea, pero no se asocia el pago, o se crea la factura, pero no se actualiza el estado en el sistema de origen.
Un buen soporte revisa estos registros con una frecuencia fija. Si quieres ver qué señales indican que tu cuenta necesita ese seguimiento, las resumimos en 7 señales de que tu empresa necesita soporte NetSuite.
Alguien añade un código de impuesto, cambia un método de pago, renombra un departamento o cancela un artículo. La integración mapeaba el valor antiguo y, desde ese día, los registros que lo usan fallan. Es el fallo más difícil de atribuir, porque ni la integración ni NetSuite han cambiado "oficialmente": ha cambiado un dato maestro.
Qué hacer: tratar el mapeo como parte de la configuración, documentarlo y revisarlo cada vez que se toca un dato maestro del que dependa una integración. En una cuenta española con localización fiscal es especialmente delicado con los códigos de impuesto. Si quieres entender qué papel juega cada pieza fiscal de tu cuenta, tienes la visión general en nuestra página de localización española de NetSuite.
Una credencial caducada, un usuario de integración desactivado o un rol al que le han retirado un permiso pueden dejar una integración sin acceso. A diferencia de los casos anteriores, aquí falla todo, pero a veces de noche o un fin de semana, y nadie lo ve hasta el lunes. Es habitual cuando el usuario de integración es una persona que ha dejado la empresa y su acceso se ha dado de baja siguiendo el procedimiento habitual de salidas.
Qué hacer: usar un usuario y un rol dedicados a cada integración, con los permisos mínimos necesarios, documentados y con un responsable identificado.
No hace falta una herramienta de monitorización sofisticada para dejar de depender de la suerte. Con la configuración estándar de NetSuite se puede empezar así:
Con esto no se evita que las integraciones fallen, pero se pasa de descubrir los fallos al cierre a descubrirlos al día siguiente. Para un director financiero, esa diferencia es la que separa un ajuste puntual de una conciliación de varias semanas.
Si una parte de tu facturación nace fuera de NetSuite, por ejemplo en una tienda online o en un sistema de gestión de pedidos, hay tres preguntas que conviene responder antes de que termine el año. La primera: ¿cada pedido acaba en una factura en NetSuite, y lo sabes por un control y no por confianza? La segunda: ¿qué ocurre con un pedido que no se puede facturar por un dato incorrecto del cliente? La tercera: ¿quién se entera, y cuándo?
Esto enlaza con la preparación para Verifactu. En NetSuite, la certificación de facturas y abonos se hace con la SuiteApp "European Union Electronic Invoicing" a través de Avalara, y exige configurar la ficha de cada cliente. Un cliente creado por una integración sin esos datos es un candidato a fallo el día que Verifactu sea obligatorio. Lo desarrollamos en el artículo sobre Verifactu y NetSuite, y las sanciones por un software no adaptado pueden llegar a 50.000 euros por ejercicio, según el artículo 201 bis de la Ley General Tributaria.
El inventario y el campo de estado los puede montar tu equipo. Donde suele compensar contar con ayuda externa es en tres situaciones: cuando las integraciones las construyó un proveedor que ya no está, cuando hay scripts personalizados que nadie documentó y cuando la revisión periódica se queda siempre para "cuando haya tiempo". Un servicio de soporte NetSuite incluye precisamente esa revisión recurrente, y una implantación bien hecha debería haber dejado el inventario y los controles preparados desde el primer día.
Cómo sé si una integración está fallando sin que nadie me avise
Compara lo que dice el sistema de origen con lo que hay en NetSuite. Si el origen dice haber enviado 200 pedidos y en NetSuite hay 197, faltan tres. Una búsqueda guardada programada con ese cruce es el control más sencillo y el que más fallos detecta.
Dónde veo los errores de un script de integración en NetSuite
En el Script Execution Log, donde quedan los errores de los RESTlets y de los scripts programados. Para los servicios web, Oracle indica que los SOAP Web Services Execution Log y Usage Log contienen información sobre solicitudes rechazadas por superar los límites de concurrencia.
Qué es el límite de concurrencia de NetSuite
Es el número máximo de peticiones simultáneas que una cuenta admite en servicios web y RESTlets. Oracle permite repartir ese límite entre integraciones concretas y ofrece, en la página Integration Governance, datos como el pico de concurrencia y la ratio de peticiones rechazadas.
Somos una consultora 100% NetSuite, con más de 40 proyectos y más de 10 años de experiencia. Trabajamos sobre el estándar de Oracle, y nada te ata a nosotros: lo que dejamos configurado lo puede mantener tu equipo o cualquier otro partner. Si quieres saber qué integraciones de tu cuenta están fallando sin que lo sepas, pide un diagnóstico sin compromiso.
Autor: equipo de Flying Lemons, especialistas en NetSuite. Publicado el 29 de septiembre de 2026. Fuentes: Oracle NetSuite, Concurrency Governance, Oracle NetSuite, monitorización de concurrencia, Oracle NetSuite, límites de concurrencia, Real Decreto-ley 15/2025 (BOE).
Gratuito
