NO HABIDO: uno de cada siete contribuyentes
El padrón de SUNAT es un fichero público que cualquiera puede descargar, y dentro hay una variable que decide operaciones. Vale la pena entender qué significa exactamente y por qué no conviene filtrarla de la base.
Hay dos campos en el padrón de SUNAT que deciden operaciones antes que cualquier modelo de riesgo: el estado y la condición del contribuyente.
El estado dice si el RUC está activo, de baja o suspendido. La condición dice otra cosa, y es la que importa: si SUNAT encuentra a esa empresa en el domicilio fiscal que declaró. Habido significa que sí. No habido significa que fue a buscarla y no estaba.
Cuando importamos el padrón en septiembre de 2026, los no habidos eran el 13,5 % de las personas jurídicas registradas. Uno de cada siete.
Por qué es un corte y no un aviso
Un factoring compra el derecho a cobrar una factura. Si la operación sale mal —el deudor no paga, la factura estaba pagada, la cesión se discute— lo que queda es un procedimiento contra alguien, y ese alguien tiene que estar en algún sitio.
Una empresa que SUNAT no localiza en su domicilio fiscal no es una empresa con mal historial. Es una empresa que no sabes dónde está. No es un dato de riesgo crediticio, es un dato de existencia, y por eso no admite matices ni umbrales: o está o no está.
Es de las pocas reglas que merecen ser fuertes: no hay analista que, con toda la información delante, apruebe una operación contra un contribuyente no habido. Lo mismo vale para el cedente, y por la misma razón: ceder una factura a nombre de alguien a quien SUNAT no encuentra es exactamente el riesgo que nadie quiere explicar después.
El padrón es público, y eso cambia el diseño
Mucha gente construye esto scrapeando el portal de consulta de RUC. No hace falta, y además ese portal está detrás de un cortafuegos de aplicación que rechaza tanto una petición de línea de comandos como un navegador automatizado. Es una pelea que se puede dar —hay empresas que venden justo eso, con proxies rotatorios— pero es un producto en sí mismo, no una integración.
Lo que sí se puede es descargar el padrón reducido: un fichero estático, actualizado a diario, que se baja sin ninguna pelea. Son más de 2,3 millones de personas jurídicas. Y si algún día hacen falta las personas naturales con negocio, están en el mismo sitio: son quince millones y pico más, así que conviene decidir a conciencia si se importan.
Dos advertencias de quien ya lo ha hecho:
- El formato separa campos por
|sin comillas, y hay campos que contienen un|literal —los hay en el número de piso—. Esas filas desplazan todo lo que viene detrás y hay que descartarlas, no importarlas corruptas. En nuestra importación fueron cinco de dos millones y pico, todas de empresas dadas de baja. - El estado y la condición son un puñado de valores que se repiten millones de veces. Sacarlos a un catálogo en vez de guardarlos como texto ahorra decenas de megas sin perder un solo dato.
No filtres los no habidos al importar
La tentación es obvia: si un no habido se rechaza siempre, ¿para qué guardarlo?
Porque el rechazo tiene que estar explicado. Si esa empresa no está en tu base, tu motor no puede decir rechazado porque el contribuyente figura como no habido; solo puede decir no encontrado, que es una respuesta distinta y mucho peor. El cliente que recibe un “no encontrado” llama por teléfono. El que recibe la razón, no.
Un no habido no es un registro que sobre. Es una variable del motor.
El padrón no lo sabe todo
Conviene tener claro qué trae y qué no, porque es la causa de la mitad de los huecos en un expediente.
El padrón trae identidad, estado, condición y domicilio fiscal. Nada más. No trae sector, ni actividad económica, ni antigüedad, ni ventas.
Eso llega por otra puerta: el reporte tributario para terceros, que la propia empresa descarga con su Clave SOL y entrega. Son dos fuentes complementarias, y si tu modelo de datos deja esos cinco campos nulos al consultar el padrón, no es un hueco que rellenar con una estimación: es información que todavía no ha llegado.