RIPS y Factura Electrónica en Colombia: Guía Completa de Validación Única 2026

guia rips 2026

La validación única de RIPS y factura electrónica en Colombia opera a través del Mecanismo Único de Validación (MUV) del Ministerio de Salud, regulado por las Resoluciones 2275 de 2023 y 1884 de 2024. El RIPS en formato JSON es soporte obligatorio de la Factura Electrónica de Venta (FEV) en XML; sin transmisión conjunta al MUV y sin obtener el Código Único de Validación (CUV), la factura no tiene validez de pago en el SGSSS.


Introducción: El fin del RIPS como trámite paralelo a la factura

Durante más de dos décadas, el RIPS (Registro Individual de Prestación de Servicios de Salud) y la factura de salud fueron documentos con vidas paralelas pero desconectadas. La IPS generaba la factura y adjuntaba el RIPS como soporte magnético en archivo plano .txt, sin que existiera un mecanismo de validación automática que cruzara ambos documentos antes del pago.

El resultado fue predecible: inconsistencias sistemáticas entre los servicios facturados y los reportados en el RIPS, glosas técnicas masivas por diagnósticos incoherentes con los procedimientos, y una opacidad estructural que dificultaba el control del sistema. La Resolución 3374 de 2000, que rigió los RIPS durante 23 años, fue diseñada en un entorno tecnológico completamente diferente al actual.

La Resolución 2275 de 2023 eliminó esa desconexión de manera definitiva. El RIPS en formato JSON se convierte en el soporte técnico obligatorio de la Factura Electrónica de Venta (FEV) en XML, y ambos documentos deben transmitirse de forma conjunta al Mecanismo Único de Validación (MUV) del Ministerio. Sin esa validación —y sin el Código Único de Validación (CUV) que certifica su éxito— la factura no puede ser radicada, y sin radicación válida no existe pago.

Este artículo constituye la guía técnica más completa disponible sobre el proceso de validación integrada RIPS-FEV en Colombia, con los requisitos exactos, los errores más frecuentes y la hoja de ruta para que las IPS operen sin rechazos en 2026.


¿Qué es exactamente el Mecanismo Único de Validación (MUV) y quién lo administra?

El Mecanismo Único de Validación (MUV) es la plataforma tecnológica centralizada del Ministerio de Salud y Protección Social que recibe, valida y certifica la consistencia entre el RIPS JSON y la Factura Electrónica de Venta (FEV) de cada prestador de servicios de salud.

El MUV fue regulado mediante la Resolución 1884 de 2024, que desarrolló operativamente el mandato de la Resolución 2275 de 2023 y definió los estándares técnicos de transmisión, los criterios de validación y el proceso de obtención del CUV.

El MUV realiza dos tipos de validación simultánea:

Validación sintáctica: Verifica que el archivo JSON del RIPS y el archivo XML de la FEV cumplen con la estructura técnica definida por el Ministerio: campos obligatorios presentes, tipos de datos correctos, longitudes válidas, sintaxis JSON/XML sin errores. Un error sintáctico genera rechazo inmediato antes de cualquier validación de contenido.

Validación semántica: Verifica que el contenido de ambos documentos es internamente coherente y externamente consistente. El MUV cruza diagnósticos CIE con procedimientos CUPS, verifica que los valores facturados corresponden a los servicios reportados, y compara los datos del prestador y el usuario con los registros del REPS y la BDUA.


¿Cuál es la arquitectura técnica del RIPS JSON bajo la Resolución 2275 de 2023?

El RIPS JSON sustituyó los seis archivos de texto plano del modelo anterior (CT, US, AF, AC, AP, AT) por una estructura de documento JSON jerarquizado y validable automáticamente.

La estructura JSON del RIPS se organiza en los siguientes objetos principales:

Objeto raíz numDocumentIdObligado Identifica al prestador responsable del RIPS. El NIT debe coincidir exactamente con el utilizado en la autenticación ante el MUV.

Objeto listaPrestacionesServiciosSalud Contiene el array principal con todos los registros de atención del período reportado. Cada elemento del array corresponde a un tipo de servicio diferente.

Sub-objetos por tipo de servicio:

  • listaConsultas: atenciones ambulatorias de medicina general, especializada y odontología
  • listaProcedimientos: procedimientos quirúrgicos, diagnósticos y terapéuticos
  • listaUrgencias: atenciones en el servicio de urgencias
  • listaHospitalizacion: episodios de hospitalización
  • listaRecienNacidos: atenciones de recién nacidos durante la hospitalización
  • listaMedicamentos: medicamentos dispensados o administrados con código IUM
  • listaOtrosServicios: servicios que no corresponden a las categorías anteriores

Cada sub-objeto contiene los campos específicos del tipo de servicio, incluyendo: identificación del usuario, diagnóstico(s) CIE, código CUPS del procedimiento, fechas, valores, datos del profesional y la institución. La omisión de cualquier campo obligatorio genera rechazo en la validación sintáctica del MUV.


¿Cómo funciona la Factura Electrónica de Venta (FEV) en salud y qué la diferencia de la FEV estándar?

La Factura Electrónica de Venta (FEV) en salud sigue el estándar general de facturación electrónica de la DIAN (formato XML UBL 2.1), pero incorpora una extensión sectorial de salud definida por el Ministerio que agrega campos específicos del SGSSS.

Los campos adicionales de la extensión sectorial de salud incluyen:

  • Número del CUFE (Código Único de Factura Electrónica) generado por la DIAN
  • Tipo de cobertura: UPC, SOAT, ECAT, particular, régimen especial, entre otros
  • Datos de la ERP: identificación de la Entidad Responsable de Pago
  • Datos del contrato: referencia al contrato vigente con la ERP
  • Valores discriminados: copagos, cuotas moderadoras, valores a cargo de la ERP
  • Referencia al RIPS: el CUV que vincula la FEV con el RIPS JSON validado

Esta doble estructura —FEV estándar DIAN + extensión de salud— requiere que los sistemas de facturación de las IPS tengan configuradas ambas capas. Un error frecuente es generar la FEV estándar DIAN sin la extensión de salud, lo que genera rechazo en el MUV del Ministerio aunque el documento sea válido ante la DIAN.


¿Cuál es el flujo completo de transmisión RIPS JSON + FEV al MUV paso a paso?

Este es el proceso que toda IPS debe ejecutar correctamente para obtener el CUV y poder radicar la factura:

Pasos:

Paso 1 — Generación del RIPS JSON El HIS o software de facturación genera el archivo JSON con todos los registros de atención del período correspondiente. Antes de transmitir, el sistema debe ejecutar una validación interna contra el esquema JSON publicado por el Ministerio para detectar errores sintácticos antes del envío.

Paso 2 — Generación y envío de la FEV a la DIAN La FEV en XML con extensión sectorial de salud se genera y envía al ambiente de producción de la DIAN para obtener el CUFE (Código Único de Factura Electrónica). Este paso es previo e independiente al MUV, pero el CUFE es un campo requerido en la transmisión al MUV.

Paso 3 — Autenticación en el MUV El software de facturación se autentica en el MUV del Ministerio usando las credenciales del prestador (NIT y credenciales de acceso al SISPRO).

Paso 4 — Transmisión conjunta al MUV El sistema envía en una sola solicitud: el RIPS JSON completo + la FEV XML con el CUFE de la DIAN. El MUV recibe ambos documentos y los procesa de manera integrada.

Paso 5 — Validación del MUV El MUV ejecuta la validación sintáctica y semántica. Si detecta errores:

  • Devuelve un reporte de errores detallado con el código de error, la descripción y la ubicación exacta en el documento
  • La transmisión se rechaza completamente: no se obtiene CUV ni parcial
  • La IPS debe corregir todos los errores y retransmitir desde cero

Paso 6 — Obtención del CUV Si la validación es exitosa, el MUV devuelve el Código Único de Validación (CUV): identificador alfanumérico único que certifica que el RIPS y la FEV fueron validados y son consistentes entre sí.

Paso 7 — Radicación de la factura con CUV ante la ERP La IPS radica la factura ante la ERP incluyendo el CUV. Sin CUV, la ERP puede rechazar la radicación. El SIIFA registra la factura radicada bajo el CUCON del contrato correspondiente.


Tabla comparativa: Modelo antiguo (Resolución 3374/2000) vs. modelo actual (Resolución 2275/2023)

DimensiónModelo anterior (Res. 3374/2000)Modelo actual (Res. 2275/2023 + 1884/2024)
Formato del RIPSArchivos planos .txt (6 archivos separados)Archivo JSON único estructurado
Vinculación con la facturaSoporte magnético adjunto sin validación automáticaSoporte obligatorio validado simultáneamente con la FEV
Mecanismo de validaciónValidación posterior por la ERP (auditoría manual)MUV centralizado del Ministerio (validación previa al pago)
Código de certificaciónNo existíaCUV (Código Único de Validación): requisito de radicación
Diagnósticos aceptadosSolo CIE-10CIE-10 (vigente) y CIE-11 (implementación progresiva)
MedicamentosSin código estandarizado específicoCódigo IUM (Resolución 3166 de 2015) obligatorio
TransmisiónEntrega física o digital sin validación en tiempo realAPI REST en tiempo real con respuesta inmediata del MUV
Plazo de envío30 días hábiles post-atenciónMáximo 5 días hábiles post-cierre del mes
Rechazo de facturasSolo por auditoría posterior de la ERPAntes de la radicación: sin CUV no hay factura válida
TrazabilidadFragmentada entre IPS y ERPCentralizada: SIIFA + MUV + DIAN en tiempo real

¿Cuáles son los errores más frecuentes en la validación del MUV y cómo evitarlos?

El análisis de los reportes de rechazo del MUV desde su entrada en operación revela patrones de error consistentes y prevenibles:

Sintácticos (generan rechazo inmediato)

  • JSON malformado: una coma después del último elemento de un array, una llave sin cerrar o comillas mal balanceadas invalidan todo el archivo. Herramienta de prevención: validador de sintaxis JSON antes del envío (JSONLint o validador integrado en el HIS).
  • Campo obligatorio ausente: el RIPS JSON tiene campos de presencia obligatoria para cada tipo de servicio. La omisión de un campo requerido —incluso si el valor sería vacío— genera error sintáctico. La documentación técnica del Ministerio especifica qué campos son obligatorios y cuáles son condicionales.
  • Tipo de dato incorrecto: un campo que espera un número entero con valor en formato texto (ej. «1» en vez de 1) genera error de tipo.

Errores semánticos (generan rechazo tras validación de contenido)

  • Inconsistencia diagnóstico CIE – procedimiento CUPS: el MUV cruza el diagnóstico con el procedimiento para verificar coherencia clínica. Un procedimiento de cesárea con diagnóstico de hipertensión sin diagnóstico de embarazo generará un rechazo semántico.
  • NIT del prestador inconsistente: el NIT en el RIPS JSON debe coincidir exactamente con el NIT de autenticación en el MUV y el NIT de la FEV. Una sola discrepancia genera rechazo.
  • Código CUPS inexistente en la tabla vigente: el CUPS usado debe corresponder a un código activo en la versión vigente de la clasificación. Códigos obsoletos o mal escritos generan error semántico.
  • Código IUM inválido: el medicamento reportado en listaMedicamentos debe tener un IUM válido registrado en el sistema del INVIMA. Un nombre genérico sin IUM o un IUM desactualizado genera rechazo.
  • Fechas fuera de rango: las fechas de atención deben estar dentro del período reportado y ser coherentes entre sí (la fecha de egreso no puede ser anterior a la de ingreso hospitalario).
  • Valores facturados inconsistentes: la suma de los valores del RIPS debe ser consistente con el valor total de la FEV. Una diferencia de un peso genera rechazo semántico.

Errores de integración FEV-RIPS

  • CUFE ausente o inválido en la FEV de salud: la extensión sectorial requiere el CUFE obtenido de la DIAN. Si la FEV se envía al MUV antes de obtener el CUFE, o con un CUFE de otra factura, el MUV rechaza la transmisión.
  • FEV sin extensión sectorial de salud: la FEV enviada al MUV debe tener la extensión específica del sector salud. Una FEV estándar DIAN sin esa extensión es rechazada por el MUV aunque sea válida para la DIAN.

¿Cuáles son los plazos de transmisión al MUV y qué pasa si se incumplen?

La Resolución 2275 de 2023 establece que el RIPS debe transmitirse al MUV dentro de los cinco (5) días hábiles siguientes al cierre del mes en que se realizaron las atenciones.

Las consecuencias del incumplimiento son múltiples y escalonadas:

Consecuencia inmediata — Imposibilidad de facturar: Sin CUV, la IPS no puede radicar la factura ante la ERP. La factura sin CUV puede ser rechazada en la radicación, lo que retrasa el inicio del ciclo de pago y afecta directamente la liquidez.

Consecuencia normativa: La Superintendencia Nacional de Salud tiene acceso a los datos de transmisión al MUV. Una IPS que sistemáticamente transmite fuera de plazo puede ser objeto de inspección y medidas correctivas.

Consecuencia sobre el SIIFA: El Módulo 2 del SIIFA registra las facturas radicadas con su CUV. Una factura radicada fuera del plazo de transmisión queda registrada con esa información, lo que puede afectar los indicadores de oportunidad de la IPS ante la ERP y los entes de control.

Un caso especial: si los errores en el RIPS impiden obtener el CUV dentro del plazo de 5 días hábiles, la IPS debe gestionar con urgencia la corrección y retransmisión. Los sistemas más eficientes implementan alertas automáticas que notifican al área de facturación cuando hay transmisiones rechazadas con 48 horas de anticipación al vencimiento del plazo.


¿Cómo se integra la validación RIPS-FEV con el SIIFA y el ecosistema digital completo?

La validación MUV es el primer eslabón de una cadena de trazabilidad que continúa en el SIIFA (Resolución 1962 de 2025):

  1. MUV: valida la coherencia RIPS JSON + FEV → emite el CUV
  2. SIIFA Módulo 2: la factura con CUV se registra bajo el CUCON del contrato correspondiente → documenta la radicación
  3. SIIFA Módulo 3: registra las glosas formuladas por la ERP y las respuestas del prestador → trazabilidad del proceso de auditoría
  4. SIIFA Módulo 4: registra los pagos realizados por la ERP, vinculados a cada factura específica → cierre del ciclo financiero

El CUCON (Código Único de Contrato del SIIFA) es el hilo conductor que vincula el contrato, las facturas radicadas con CUV, las glosas y los pagos en un registro centralizado, visible para el Ministerio y la Superintendencia en tiempo real.

Para las IPS con integración IHCE activa, hay una dimensión adicional: el diagnóstico registrado en el RDA (Resumen Digital de Atención) debe ser coherente con el diagnóstico CIE reportado en el RIPS JSON. Una inconsistencia entre ambos puede ser detectada en auditorías cruzadas del Ministerio, dado que ambas plataformas (IHCE y MUV/SISPRO) están articuladas en el ecosistema digital del Ministerio.


¿Qué herramientas oficiales del Ministerio facilitan la validación del RIPS JSON?

El Ministerio de Salud ha publicado instrumentos técnicos de soporte para la validación del RIPS JSON:

Convertidor JSON oficial El Ministerio publicó un Manual de usuario del Convertidor JSON para la Resolución 2275 de 2023, que describe las herramientas disponibles para que las IPS que venían operando con archivos planos de la Resolución 3374 puedan convertir sus datos al nuevo formato JSON.

Esquema JSON de validación (JSON Schema) El Ministerio publicó el esquema formal de validación del RIPS JSON, que puede ser utilizado por los proveedores de software para implementar validación automática en el HIS antes de la transmisión al MUV. Este esquema define los campos obligatorios, los tipos de datos permitidos y las restricciones de formato para cada objeto del RIPS.

Ambiente de pruebas del MUV El Ministerio provee un ambiente de desarrollo donde los prestadores pueden transmitir RIPS JSON de prueba y verificar que sus archivos son validados correctamente antes de activar en producción.

Portal SISPRO — Facturación Electrónica El portal SISPRO centraliza la documentación técnica, los lineamientos operativos, los manuales de usuario y las actualizaciones normativas relacionadas con el RIPS JSON y la FEV en salud.


¿Qué responsabilidades específicas tienen los proveedores de software de facturación?

El análisis técnico demuestra que la mayoría de los rechazos del MUV no se originan en errores del personal de facturación de la IPS, sino en limitaciones o bugs del software de facturación. Los proveedores de software tienen responsabilidades concretas que deben estar reflejadas en los contratos con las IPS:

  • Actualización del esquema JSON: cuando el Ministerio actualiza el esquema de validación del RIPS o la estructura de la extensión sectorial de la FEV, el proveedor debe publicar la actualización del software en un plazo máximo definido contractualmente (recomendado: 15 días hábiles desde la publicación oficial)
  • Validador interno pre-MUV: el software debe incluir un validador interno que ejecute las mismas reglas del MUV antes de permitir la transmisión, para que los errores se detecten internamente antes de generar un rechazo en el Ministerio
  • Actualización de tablas de referencia: CIE-10/CIE-11, CUPS e IUM tienen actualizaciones periódicas. El software debe mantener estas tablas actualizadas automáticamente
  • Log de transmisiones: el software debe mantener un registro completo de todas las transmisiones al MUV con su resultado (CUV obtenido o reporte de errores) para auditoría interna
  • Soporte en el período de vencimiento: los cinco días hábiles de plazo son el período de mayor criticidad. El proveedor debe garantizar soporte técnico disponible durante ese período

Conclusión: Checklist operativo de validación RIPS-FEV para su IPS en 2026

La validación integrada de RIPS y factura electrónica en Colombia es en 2026 el requisito de acceso al ciclo de pago del SGSSS. Sin CUV no hay radicación válida; sin radicación válida no hay pago. La siguiente lista de verificación permite a cualquier equipo de facturación auditar su proceso antes de la fecha límite mensual:

Checklist de validación RIPS-FEV:

  1. Tablas de referencia actualizadas: CIE-10/CIE-11, CUPS e IUM están en la versión vigente en el software de facturación
  2. Validación interna pre-transmisión: el software ejecuta el validador JSON interno antes de permitir el envío al MUV, con resultado sin errores
  3. CUFE obtenido de la DIAN: la FEV fue enviada y aceptada por la DIAN y el CUFE está disponible antes de transmitir al MUV
  4. NIT consistente: el NIT del prestador en el RIPS JSON, en la FEV y en las credenciales de autenticación del MUV son idénticos
  5. Coherencia diagnóstico-procedimiento: la combinación CIE-CUPS de cada registro es clínicamente plausible y está dentro de las reglas semánticas del MUV
  6. IUM válidos en medicamentos: todos los medicamentos del objeto listaMedicamentos tienen IUM activos en la tabla INVIMA vigente
  7. Valores consistentes: la suma de valores del RIPS coincide con el total de la FEV hasta el último centavo
  8. Extensión sectorial en la FEV: la FEV enviada al MUV incluye la extensión sectorial de salud completa, no solo el formato DIAN estándar
  9. Transmisión dentro del plazo: el envío al MUV se realiza antes del día 5 hábil del mes siguiente al de las atenciones
  10. CUV registrado en SIIFA: el CUV obtenido se incluye en la radicación de la factura ante la ERP y queda registrado en el Módulo 2 del SIIFA bajo el CUCON correspondiente

Referencias Oficiales

  1. Resolución 2275 de 2023 — Ministerio de Salud y Protección Social. RIPS JSON como soporte obligatorio de la FEV en salud. https://www.minsalud.gov.co/sites/rid/Lists/BibliotecaDigital/RIDE/DE/DIJ/resolucion-2275-de-2023.pdf
  2. Resolución 1884 de 2024 — Ministerio de Salud y Protección Social. Reglamenta el MUV, el CUV y los estándares técnicos de transmisión integrada RIPS-FEV. https://www.sispro.gov.co/central-financiamiento/Pages/facturacion-electronica.aspx
  3. Resolución 3374 de 2000 — Ministerio de Salud (derogada en sus Normas Técnicas). Modelo anterior de RIPS en archivos planos .txt. https://www.minsalud.gov.co/sites/rid/Lists/BibliotecaDigital/RIDE/DE/DIJ/Resolucion_3374_de_2000.pdf
  4. Resolución 1962 de 2025 — Ministerio de Salud. SIIFA: Módulo 2 (FEV y RIPS) y Módulo 3 (seguimiento a facturas y glosas). https://www.minsalud.gov.co/Normatividad_Nuevo/Resolucion%20No%201962%20de%202025.pdf
  5. Lineamientos para la generación, validación y envío del RIPS como soporte de la FEV — Ministerio de Salud. https://www.minsalud.gov.co/sites/rid/Lists/BibliotecaDigital/RIDE/DE/OT/lineamientos-generacion-validacion-rips-factura-electronica-fev-doc-electronicos.pdf
  6. Manual de usuario Convertidor JSON — Resolución 2275 de 2023 — Ministerio de Salud. https://www.minsalud.gov.co/sites/rid/Lists/BibliotecaDigital/RIDE/DE/OT/manual-usuario-convertidor-json-resolucion-2275-de-2023.pdf
  7. SISPRO — Facturación Electrónica en Salud — Ministerio de Salud. Portal técnico del MUV, documentación y ambiente de pruebas. https://www.sispro.gov.co/central-financiamiento/Pages/facturacion-electronica.aspx
  8. Resolución 3166 de 2015 — Ministerio de Salud. Define el Identificador Único de Medicamentos (IUM) requerido en listaMedicamentos del RIPS JSON. https://www.minsalud.gov.co
  9. Resolución 1442 de 2024 — Ministerio de Salud. Adopción de CIE-11 en Colombia; impacto en el campo de diagnóstico del RIPS JSON. https://www.minsalud.gov.co/Normatividad_Nuevo/Resolucion%20No%201442%20de%202024.pdf
  10. DIAN — Facturación Electrónica — Dirección de Impuestos y Aduanas Nacionales. Estándar XML UBL 2.1 para la FEV y obtención del CUFE. https://www.dian.gov.co/impuestos/factura-electronica/Paginas/default.aspx