Cómo validar un RUC contra SUNAT desde tu sistema

Todo sistema peruano que factura acaba necesitando lo mismo: confirmar que el RUC que le acaban de dictar existe, es de quien dice ser y está en condición de recibir un comprobante. Y casi todos lo resuelven igual de mal — consultando a SUNAT por cada tecla que escribe el usuario, y tratando “activo” y “habido” como si fueran el mismo dato. No lo son, y confundirlos se paga en la declaración.

Lo que puedes validar sin preguntarle a nadie

El RUC tiene once dígitos y el último es un dígito verificador que se calcula a partir de los diez primeros. Eso significa que un RUC mal tecleado se detecta en tu propio servidor, en microsegundos y sin gastar una consulta a nadie.

El cálculo es un módulo 11 sobre pesos fijos: cada uno de los diez primeros dígitos se multiplica por su peso —5, 4, 3, 2, 7, 6, 5, 4, 3, 2—, se suman los productos, y el verificador es 11 menos el resto de dividir esa suma entre 11. Con dos excepciones: si el resultado da 10 el dígito es 0, y si da 11 es 1. Así queda con el RUC de la propia SUNAT:

La suma da 94; 94 entre 11 deja resto 6; y 11 − 6 = 5, que es exactamente el último dígito de 20131312955. Comprobamos el algoritmo contra los RUC públicos de SUNAT, RENIEC, SUNARP, la PCM y el MINEDU, y contra esos mismos números con un dígito alterado: los cinco válidos pasan y los cinco corruptos se rechazan.

Lo accionable: esta comprobación va primero, siempre. Filtra los errores de tecleo, que son la mayoría, antes de que lleguen a consumir una consulta o a ensuciar tu base. Lo que no hace es decirte si ese RUC existe de verdad: un número puede ser aritméticamente válido y no corresponder a nadie. Para eso hay que preguntar.

“Activo” y “habido” no son lo mismo

El estado dice si el RUC está de alta —activo, baja de oficio, suspensión temporal—. La condición dice si SUNAT ubica al contribuyente en el domicilio que declaró —habido, no habido, no hallado—. Son dos campos distintos, y un RUC puede estar activo y no habido a la vez.

Aquí está el error que cuesta dinero. Un equipo valida “que el RUC esté activo”, da por bueno el proveedor y sigue. Meses después aparece el problema: los comprobantes emitidos por un contribuyente en condición de no habido tienen un tratamiento distinto, y el sustento del crédito fiscal se complica justo cuando ya no se puede corregir. La regla concreta la fija SUNAT y conviene confirmarla con tu contador — pero la consecuencia de diseño es clara: tu sistema tiene que guardar los dos campos, no uno.

Y tiene que decidir qué hacer con cada combinación. No es lo mismo bloquear la operación que dejarla pasar con un aviso al área contable. Esa decisión es de negocio, no de código, y por eso hay que tomarla en el alcance y no en la semana de salida.

Las cuatro vías para consultar (y cuál aguanta)

Hay cuatro caminos: la consulta web de SUNAT, el padrón descargable, la PIDE para entidades del Estado, y los proveedores externos que envuelven todo eso en una API. Cuál te toca depende menos de tu presupuesto que de quién eres.

Si eres una entidad pública, la vía natural es la PIDE: el mismo punto único por el que ya consumes RENIEC. Si eres una empresa privada, lo habitual acaba siendo un proveedor externo, y ahí conviene tener presente que estás metiendo un intermediario entre tú y el dato — con su disponibilidad, su precio y su política de cambios. Las condiciones y los canales los fija SUNAT y cambian: contrasta cualquier guía —incluida esta— contra la fuente oficial antes de comprometer una arquitectura.

La trampa: consultar en cada tecla

El error de diseño más común es disparar la consulta mientras el usuario escribe. Con once dígitos, eso son hasta once llamadas para un solo RUC — diez de ellas a números incompletos que no existen.

La secuencia correcta es al revés y es barata: espera a tener once dígitos, valida el verificador en tu servidor, y solo entonces consulta. Añade una caché con vencimiento —un RUC no cambia de razón social cada hora— y el volumen de consultas cae a una fracción. En un alta de proveedores con búsqueda en vivo, esa sola decisión es la diferencia entre una integración que escala y una que te tumban por exceso de peticiones.

Qué guardar, y por qué no basta con el número

Guarda una foto del momento: el RUC, la razón social, el estado, la condición y la fecha en que consultaste. No un puntero a “lo que diga SUNAT hoy”, porque esos datos cambian y la factura que emitiste no.

Cuando alguien pregunte —una auditoría, tu contador, el propio cliente— la pregunta nunca será “¿cómo está ese RUC ahora?”, sino “¿cómo estaba el día que emitiste?”. Si tu sistema solo guarda el número y vuelve a consultar, no tienes respuesta. Es el mismo principio de trazabilidad que aplicamos al validar identidad contra RENIEC: lo que vale no es la consulta, es el rastro que deja.

Errores comunes al validar un RUC

Casi ninguno es de código. Son decisiones que nadie tomó: qué campo mirar, cuándo preguntar y qué guardar de la respuesta.

Cómo lo hacemos

Conectamos sistemas con el Estado peruano en producción — RENIEC en tiempo real en la caja de una universidad nacional. La validación de un RUC es la misma disciplina aplicada a las empresas en vez de a las personas.

Trabajamos la integración con el Estado de punta a punta: el trámite que consigue el acceso, la integración que aguanta el volumen y el rastro que te deja responder cuando alguien pregunta. Si tu sistema factura, hablemos.

En resumen

Validar un RUC son dos cosas distintas y conviene no mezclarlas. La primera es aritmética y gratis: el último de los once dígitos es una comprobación de los diez anteriores, así que un número mal tecleado se cae en tu propio servidor sin gastar una consulta. La segunda es preguntarle a SUNAT, y ahí lo que importa es mirar los dos campos — el estado dice si el RUC está de alta, la condición dice si a ese contribuyente se le ubica— y guardar la respuesta como una foto fechada, no como un puntero. Con eso resuelto, validar deja de ser un parche en el formulario y pasa a ser parte de tu contabilidad.