Validador de RIPS gratis

Pega o sube tu RIPS en JSON y te decimos qué rechazaría el validador del Ministerio, en español y con la corrección de cada caso. Revisamos la estructura, los códigos CUPS y CIE-10 y las reglas de consistencia del Documento Técnico 1, versión 003, la especificación vigente de la Resolución 948 de 2026. Sin registro y sin subir nada: todo ocurre en tu navegador.

Arrastra tu archivo RIPS (.json) o pégalo abajo

Tu archivo se procesa en tu navegador. No se sube, no se guarda, no se registra.

No podemos leer tu factura electrónica, así que este dato es opcional. Si lo escribes, comparamos la suma de los vrServicio contra él — la regla RVG08, que es la causa de rechazo más frecuente.

Esta es una prevalidación no oficial. El único validador oficial, y el único que emite el Código Único de Validación (CUV), es el Mecanismo Único de Validación (MUV) del Ministerio de Salud, en SISPRO. No detectar errores aquí no garantiza que el MUV apruebe tu archivo: hay reglas que sólo el Ministerio puede evaluar porque dependen del REPS, de RETHUS, del XML de tu factura o de RUAF-ND.

¿Te pareció útil esta herramienta?

Qué significa validar un RIPS

Desde la Resolución 948 de 2026 el RIPS dejó de ser un reporte que se manda después: es el soporte de la factura electrónica de venta en salud. El artículo 4 lo dice sin rodeos — el RIPS «será generado, validado y enviado como soporte de la factura de venta». En la práctica eso significa que primero validas y sólo después radicas: si el archivo no pasa, el Ministerio no genera el Código Único de Validación, y sin CUV la factura no entra al pagador. El rechazo no es un problema de papeleo, es plata que no se cobra.

La validación mira tres cosas, y conviene separarlas porque se corrigen distinto:

  1. Estructura. Que el archivo sea un JSON con la jerarquía, los tipos y los tamaños que define el documento técnico. Acá se cae el que manda un número entre comillas, el que omite un campo en vez de mandarlo en null, o el que exporta una fecha con formato ISO en lugar de AAAA-MM-DD HH:MM. Si esto falla, el MUV ni siquiera mira el resto.
  2. Contenido. Que los códigos existan de verdad: CUPS en la tabla «CUPSRips», los diagnósticos en la CIE-10, y cada valor de lista controlada (tipo de usuario, finalidad, concepto de recaudo, modalidad) en su tabla de referencia de SISPRO.
  3. Consistencia. Que los datos concuerden entre sí y con la factura: fechas que no estén en el futuro ni antes del nacimiento, el documento acorde a la edad, diagnósticos que no se repitan, pagos moderadores que correspondan al régimen y, la que más rechaza, la suma de los valores contra el total de la factura.

El documento técnico marca cada regla con su efecto: R de rechazo, que impide generar el CUV, y N de notificación, que deja constancia de una no conformidad y obliga a un plan de mejora pero hoy no impide radicar. Esta herramienta respeta esa diferencia: sólo marcamos como error lo que rechaza. Lo que notifica, o lo que depende de datos que no viajan en el JSON, aparece como advertencia. Preferimos no detectar algo antes que asustarte con un archivo que estaba bien.

Errores más comunes de RIPS y cómo corregirlos

Estos son los que más aparecen, con la regla oficial que los detecta y su efecto real. Es el mismo catálogo que usa el validador de arriba: si acá se describe, allá se detecta.

La suma de los servicios no da igual al total de la factura

RechazaRVG08

Es la causa de rechazo más frecuente y la más frustrante, porque el archivo puede estar impecable en todo lo demás. La regla RVG08 exige que la sumatoria de los vrServicio coincida con el valor de la factura electrónica de venta cuando la modalidad de pago es evento. No hay tolerancia: tiene que dar exacto.

Cómo se corrige: Cuadra el archivo antes de radicar. Las tres fuentes habituales de descuadre son los redondeos por servicio, un servicio que quedó fuera del JSON, y los descuentos: la RVC091 aclara que en vrServicio va el valor del servicio ya realizado el descuento, no el valor de lista.

Repetir el diagnóstico principal en un relacionado

RechazaRVC086 y RVC087

RVC086 prohíbe que un diagnóstico relacionado sea igual al principal, y RVC087 que dos relacionados sean iguales entre sí. Las dos están marcadas «R»: rechazan. Antes sólo notificaban, y por eso muchos sistemas siguen generando el archivo así — rellenan los tres campos de relacionado copiando el principal para «no dejarlos vacíos».

Cómo se corrige: No hay que rellenar los tres relacionados. null es un valor válido y esperado. Deja cada diagnóstico una sola vez: el principal en su campo y los demás, si de verdad hubo otros, en los relacionados.

Un código CUPS que ya no existe

NotificaRVC096

La RVC096 pide que el código exista en la tabla de referencia «CUPSRips» de SISPRO. Ojo con el matiz, porque casi nadie lo publica bien: en la versión 003 del documento técnico esta regla está marcada «N», así que hoy notifica y no impide generar el CUV. El dato igual está mal, y el Ministerio avisó que las notificaciones pasarán a rechazo.

Cómo se corrige: Actualiza el tarifario interno a la CUPS vigente (Resolución 2706 de 2025, en vigor desde el 1 de enero de 2026) y revisa los códigos retirados. El caso típico es un maestro de procedimientos que nadie tocó en tres años.

Un código R o Z como diagnóstico principal

NotificaRVC031, RVC032 y RVC033

Acá hay tres reglas distintas y conviene no mezclarlas. La RVC031 dice que el diagnóstico principal «debería ser preferiblemente» de causas de morbilidad y mortalidad (A00–Q99 y S00–T98), y alcanza también a las consultas. La RVC032 (síntomas y signos, R00–R99) y la RVC033 (factores que influyen en el estado de salud, Z00–Z99) se aplican a procedimientos, urgencias, hospitalización y recién nacidos, no al campo de consultas. Las tres están marcadas «N».

Cómo se corrige: Si el episodio ya tiene diagnóstico definitivo, ponlo como principal y deja el síntoma como relacionado. Si de verdad no lo hay, el código R puede ser el correcto: la regla notifica, no bloquea, y forzar un diagnóstico que no se tiene es peor. Los códigos Z sí son los correctos en promoción y mantenimiento — para la finalidad 11 la norma incluso los exige (RVC085).

El tipo de documento no corresponde a la edad

NotificaRVC007

El detalle del campo fechaNacimiento fija bandas para los documentos colombianos: hasta 3 meses y 29 días, registro civil o certificado de nacido vivo; hasta los 7 años, registro civil; de 7 a 18, tarjeta de identidad (se acepta RC hasta los 7 años, 11 meses y 29 días); desde los 18, cédula (se acepta TI hasta los 18 años, 11 meses y 29 días). La regla admite además un margen de tolerancia de un año menos un día.

Cómo se corrige: Casi siempre el dato malo es la fecha de nacimiento, no el documento. Los documentos de extranjeros —pasaporte, cédula de extranjería, PEP, permiso por protección temporal, documento extranjero— no tienen banda de edad y no disparan esta regla.

Un pago moderador donde no corresponde

RechazaRVC084, RVC035 y RVC037

La RVC084 —marcada «R»— exige que en las finalidades de promoción y mantenimiento, protección específica, detección temprana de enfermedad general y la ruta materno perinatal el concepto de recaudo sea «05 No aplica». Aparte, la RVC035 recuerda que la cuota moderadora sólo se cobra a afiliados del régimen contributivo, y la RVC037 que a un usuario del régimen subsidiado no se le informan pagos moderadores de planes voluntarios; esas dos notifican.

Cómo se corrige: Revisa la parametrización de tu software: normalmente el error no es del facturador sino de la regla de negocio que asigna el concepto de recaudo por tipo de servicio. Y verifica el tipoUsuario, que es donde más se confunden los códigos: 01, 02 y 03 son contributivo, 04 es subsidiado y 12 es particular.

El valor del servicio en cero

RechazaRVC034

La RVC034 exige un valor mayor que cero cuando la modalidad de pago es «pago por evento», y exactamente cero en las demás modalidades. Es una regla de rechazo, pero la modalidad de pago no viaja en el RIPS: está en la factura electrónica. Por eso ningún validador que sólo lea el JSON puede decidirla — el nuestro tampoco, y por eso avisa en vez de marcarla como error.

Cómo se corrige: Si facturas por evento, informa el valor con los descuentos ya aplicados. Si es cápita, pago global prospectivo o grupo relacionado de diagnóstico, el cero es lo correcto.

Fechas imposibles o fuera del período de facturación

RechazaRVC013 y RVC014

La RVC013 rechaza cualquier atención con fecha posterior a la de validación, y la RVC014 la que quede fuera del período de facturación de la factura electrónica. La causa técnica más común no es un error de digitación: es la zona horaria. Un servidor que exporta en UTC manda al día siguiente toda atención posterior a las 19:00 de Bogotá, y eso mueve consultas de un período de facturación a otro.

Cómo se corrige: Genera fechaInicioAtencion en hora de Colombia (UTC-5), explícitamente, y no con la hora local del servidor. Si tu software corre en la nube, casi con seguridad el runtime está en UTC.

Consecutivos repetidos o con saltos

Validación general

Tanto el consecutivo del usuario como el de cada objeto de servicio deben, en palabras del documento técnico, «iniciar con el número uno (1) incrementando de uno en uno», y no puede haber números idénticos repetidos. Es lo primero que se rompe cuando el software concatena dos lotes o reintenta un envío fallido.

Cómo se corrige: Renumera después de filtrar, nunca antes. Si excluyes un registro al armar el archivo, los consecutivos hay que recalcularlos.

El municipio sin el cero del departamento

Validación general

El código DIVIPOLA del DANE son cinco caracteres: dos de departamento y tres de municipio. Cuando el municipio se guarda como número entero en la base de datos, el cero inicial de Antioquia, Atlántico, Bolívar, Boyacá, Caldas, Caquetá, Cauca y Cesar se pierde: 05001 sale como 5001.

Cómo se corrige: Guarda el código como texto, no como número, y rellena con ceros a la izquierda al exportar. El campo es obligatorio cuando el país de residencia es 170 (Colombia), igual que la zona territorial.

Qué cambió con la Resolución 948 de 2026

Expedida el 14 de mayo de 2026 y vigente desde ese mismo día. Casi todo el contenido que circula sobre RIPS todavía cita la norma anterior, así que vale la pena tener claro qué rige hoy.

El RIPS pasó a ser soporte de la factura electrónica
El artículo 4 de la Resolución 948 de 2026 dice que el RIPS «será generado, validado y enviado como soporte de la factura de venta por parte de los facturadores electrónicos del sector salud». El cambio de fondo es ese: el RIPS se valida electrónicamente antes de poder radicar, y sin el Código Único de Validación la factura no entra al pagador.
Derogó la 2275 de 2023 y sus dos modificatorias
El artículo 23 rige desde la expedición —14 de mayo de 2026— y deroga las Resoluciones 2275 de 2023 y 558 y 1884 de 2024. Casi todo el contenido que circula sobre RIPS sigue citando la 2275. Y la 3374 de 2000, la de los archivos planos AF, US y AC, no revivió al derogarse la norma que la había derogado: el artículo 14 de la Ley 153 de 1887 lo impide. El formato vigente es JSON.
Los anexos técnicos salieron del cuerpo de la norma
El artículo 1 adopta dos documentos técnicos que se publican en la web del Ministerio, y el parágrafo del artículo 10 ordena publicarlos versionados. La consecuencia práctica incomoda: las especificaciones cambian sin que cambie el número de la resolución. Hoy rige el Documento Técnico 1 versión 003, del 15 de julio de 2026. Cuidado con el PDF llamado «anexo-tecnico1-resolucion-948-de-2026», que es el que devuelven los buscadores: corresponde a la versión 001 y está superado.
Dos fechas de gradualidad, no tres
El parágrafo transitorio del artículo 23 fija exactamente dos hitos: el 1 de junio de 2026 entraron en vigor las reglas de validación que pasaron de notificación a rechazo, y el 1 de julio de 2026 quedaron exigibles los ajustes de versión de software de carácter estructural. Las dos fechas ya pasaron: no queda período de gracia. La resolución no dice cuántas reglas cambiaron de efecto ni fija ninguna otra fecha.
Sólo el MUV emite el CUV
El Código Único de Validación es una cadena alfanumérica que genera el Mecanismo Único de Validación del Ministerio. Ningún tercero lo emite. Los prestadores tienen veintidós (22) días hábiles desde la expedición de la factura para radicarla junto con el RIPS aprobado (artículo 15).

Fuentes: texto oficial de la Resolución 948 de 2026, Documento Técnico 1, versión 003 (15 de julio de 2026) y el micrositio FEV-RIPS de SISPRO, que es la fuente canónica porque los documentos técnicos se actualizan sin cambiar el número de la resolución. Las tablas de referencia con las que compara el validador se copiaron de SISPRO el 2026-09-08. Contenido revisado el 2026-09-08: información de referencia, verifica siempre la vigencia antes de radicar.

Preguntas frecuentes

No. El Código Único de Validación lo genera únicamente el Mecanismo Único de Validación (MUV) del Ministerio de Salud y Protección Social, en SISPRO. Esta herramienta es una prevalidación no oficial: te muestra antes lo que probablemente te va a rechazar el MUV, para que llegues allá con el archivo limpio. Sin CUV la factura no se puede radicar ante el pagador.

Sí, y sin registro. No pedimos correo, no hay cupo de validaciones y el resultado completo se ve sin crear cuenta. Es una de las herramientas gratuitas de Cliini, como los buscadores de CUPS y CIE-10.

No. Tu archivo se procesa en tu navegador: no se sube, no se guarda, no se registra. La validación entera corre en tu computador con JavaScript. Lo único que se descarga son los catálogos públicos de CUPS y CIE-10, que viajan hacia ti, no al revés. Puedes comprobarlo abriendo la pestaña Red de las herramientas de desarrollador: no verás ninguna petición que lleve el contenido del RIPS.

Sí. Las reglas están escritas contra la Resolución 948 de 2026, expedida el 14 de mayo de 2026, y contra el Documento Técnico 1 versión 003 del 15 de julio de 2026, que es la especificación vigente. Las listas de valores se tomaron de las tablas de referencia de SISPRO, no de una versión anterior del anexo técnico.

No, y no debería. Hay reglas que sólo el Ministerio puede evaluar porque necesitan datos que no están en el JSON: que el prestador esté en el REPS, que el profesional esté en RETHUS, que los valores coincidan con el XML de la factura electrónica, o el cruce con RUAF-ND y SIRAS. Valida siempre en el MUV antes de radicar; esto te ahorra las vueltas, no el trámite.

La misma que hace el documento técnico. Las reglas marcadas «R» son de rechazo: impiden generar el CUV. Las marcadas «N» son de notificación: dejan constancia de una no conformidad y obligan a un plan de mejora, pero hoy no impiden radicar la factura. Nosotros mostramos como error sólo lo primero, y como advertencia lo segundo y aquello que depende de datos que no están en tu archivo. El Ministerio avisó que las notificaciones pasarán a rechazo «en las fechas que determine», sin publicar cuáles.

La estructura es la misma y todas las validaciones de estructura, códigos y consistencia aplican igual. Lo que cambia es el carril: el profesional independiente no obligado a facturar electrónicamente (por debajo del umbral DIAN de 3.500 UVT) reporta por el módulo de RIPS sin factura, con numFactura en null y tipoNota «RS». Las reglas que comparan contra la factura electrónica, como RVG08, no le aplican.

No. El Registro Individual de Prestación de Servicios de Salud es exclusivo del sistema de salud colombiano y lo definen resoluciones del Ministerio de Salud y Protección Social. Otros países tienen sus propios reportes de prestación.

¿Necesitas corregir un código? Buscador de CUPS · Buscador de CIE-10 · Guía de RIPS para profesionales independientes