El Documento Técnico 2 (julio 2026) define 5 tipos de reglas de validación que el Mecanismo Único de Validación (MUV) aplica a cada FEV en salud: validaciones de archivos, por estructura, sobre los datos, en el almacenamiento y de consistencia de archivos. Solo cuando la factura supera exitosamente todas estas validaciones, el Ministerio genera el Código Único de Validación (CUV), indispensable para radicar la factura ante la ERP o pagador.
¿Por qué las reglas de validación determinan el flujo de caja de su IPS?
Sin CUV, la factura no puede radicarse. Si NO HAY radicación, no hay plazo de pago. Sin plazo de pago, el flujo de caja se detiene. Esta cadena directa hace de las reglas de validación del MUV el eslabón técnico más crítico del proceso de facturación en salud en Colombia.
El Documento Técnico 2 establece explícitamente: solo una vez se confirma la transmisión de la información en la base de datos de almacenamiento en los servidores del Ministerio y su procesamiento exitoso, se generará el Código Único de Validación – CUV.
Las validaciones se dividen en Rechazos (impiden la generación del CUV) y Notificaciones (advierten sin bloquear). Conocer el catálogo completo es condición necesaria para operar sin interrupciones.
¿Cuáles son los 5 niveles de validación?
Nivel 1: Validaciones de Archivos
Son las validaciones previas al procesamiento del contenido. Verifican condiciones técnicas básicas de los archivos XML y JSON transmitidos:
| Código | Tipo | Descripción |
|---|---|---|
| GI008 | RECHAZO | El tamaño del archivo XML es mayor a 16 MB |
| GI005 | RECHAZO | Solo se admiten archivos con extensión XML para FEV, ND, NC |
| GI006 | RECHAZO | El archivo XML está vacío |
| VPQ004 | RECHAZO | Falta el archivo XML en la carpeta |
| VPQ005 | RECHAZO | Falta el archivo JSON en la carpeta |
Nivel 2: Validaciones por Estructura
Se realizan una vez la DIAN ha emitido su aprobación y la factura va a ser expedida al adquiriente. Verifican que el facturador electrónico del sector salud conformó correctamente el contenedor electrónico XML (esquema UBL 2.1) que será soportado con el RIPS.
Las más críticas para el sector salud son:
| Código | Tipo | Descripción |
|---|---|---|
| FED001 | RECHAZO | CustomizationID no existe o no tiene valor en el XML |
| FED060 | RECHAZO | Invoice.UBLExtensions.CustomTagGeneral no existe en el XML |
| FED061 | RECHAZO | PrepaidPayment debe informarse una única vez por concepto |
| CCV001 | RECHAZO | El CUV suministrado NO está validado por el Ministerio |
| CCV000 | RECHAZO | Los archivos XML/JSON adjuntos no concuerdan con el CUV consultado |
Nivel 3: Validaciones sobre los Datos
Verifican la precisión y coherencia del contenido de los datos declarados en el XML, según el esquema UBL, la Resolución 0165 de 2023 de la DIAN y la normativa del Ministerio de Salud vigente. Estas validaciones no afectan el contenido ya aprobado por la DIAN; solo validan el relacionamiento entre RIPS y FEV.
Ejemplos de reglas críticas del sector salud:
| Código | Tipo | Descripción |
|---|---|---|
| VFE003 | RECHAZO | El CustomizationID no es válido del sector salud o está vacío |
| VFE020 | RECHAZO | InvoicePeriod.StartDate: no reportó la fecha de inicio del periodo |
| VFE021 | RECHAZO | InvoicePeriod.EndDate: no reportó la fecha final del periodo |
| VFE022 | RECHAZO | La ERP informada no corresponde a la cobertura o plan de beneficio declarado |
| PFP001 | RECHAZO | El número de FEV no corresponde al reportado por RIPS |
| RCG018 | RECHAZO | El periodo de facturación (inicio y fin) es anterior al 2023-01-01 |
| RVG018 | RECHAZO | El periodo de facturación es anterior al 2024-10-01 (para notas) o al inicio del periodo de operación del grupo (Res. 1884/2024) |
Nivel 4: Validaciones en el Almacenamiento
Son errores técnicos de transmisión, no de contenido. Ocurren por fallas en la conexión a la base de datos del Ministerio:
| Código | Tipo | Descripción |
|---|---|---|
| CFR001 | RECHAZO | Hubo errores al almacenar los datos; intente transmitir nuevamente |
Estas validaciones no implican error en la factura: es un problema del canal de comunicación. La acción correcta es reintentar la transmisión.
Nivel 5: Validaciones de Consistencia de Archivos
Se generan al transmitir desde la solución tecnológica del facturador al interior del Ministerio. Validan la consistencia de los datos XML-JSON desde su origen hasta el almacenamiento:
| Código | Tipo | Descripción |
|---|---|---|
| VDI001 | RECHAZO | El directorio seleccionado con los archivos a validar no es válido |
| PFR001 | RECHAZO | El CUV generado por el MSPS no corresponde a los datos enviados en XML y JSON |
¿Cuáles son las reglas de extensión del sector salud más frecuentes?
Las reglas con prefijo DND, FED y CND (para notas débito, facturas y notas crédito respectivamente) que más afectan la operación diaria del sector salud son las relacionadas con los campos de la extensión:
| Familia de reglas | Campo afectado | Tipo |
|---|---|---|
| FED124/CND124/DND124 | CODIGO_PRESTADOR ausente en extensión salud | RECHAZO |
| FED133/CND133/DND133 | MODALIDAD_PAGO con valor inválido o vacío | RECHAZO |
| FED134/CND134/DND134 | COBERTURA_PLAN_BENEFICIOS con valor inválido | RECHAZO |
| FED130/CND130/DND130 | NUMERO_CONTRATO ausente en extensión salud | RECHAZO |
| FED136 | FACTURA_SIN_CONTRATO.SchemeId ausente | NOTIFICACIÓN |
| DND123/CND123/FED123 | CODIGO_PRESTADOR.Value ausente | NOTIFICACIÓN |
¿Qué diferencia hay entre Rechazo y Notificación en la práctica?
Un Rechazo impide totalmente la generación del CUV. La factura debe corregirse y retransmitirse antes de poder radicarse ante el pagador.
Una Notificación advierte de una inconsistencia menor pero permite que el CUV se genere. Sin embargo, el Ministerio puede usar estos registros de notificación para análisis de calidad del dato y auditorías futuras. El campo FACTURA_SIN_CONTRATO inicia como Notificación, pero su tolerancia no debe interpretarse como irrelevancia.
Conclusión: Próximos pasos para reducir el índice de rechazo al mínimo
- Implementar un validador previo (pre-validación local) en el software de facturación que verifique las reglas de estructura y datos antes de transmitir al MUV. Esto reduce el ciclo de corrección de días a minutos.
- Monitorear el catálogo de rechazos por familia (FED para facturas, CND para notas crédito, DND para notas débito) y establecer alertas automáticas en el sistema cuando se supere un umbral de error por regla específica.
- Nunca modificar el XML después de que la DIAN lo haya aprobado. La regla es explícita en el Documento Técnico 2: en la conformación del contenedor electrónico de la FEV en salud que será soportada con el RIPS, para el emisor de la factura no es dable realizar ninguna modificación sobre la información validada y aprobada por la DIAN.
- Establecer un protocolo de retransmisión para errores CFR001 (almacenamiento): reintentar en un máximo de 2 horas antes de escalar al soporte técnico del Ministerio.
Fuente oficial: Documento Técnico 2, Versión 001, Julio 1 de 2026. Ministerio de Salud. Sección 11 «Reglas de Validación» (pp. 45–58).
https://www.sispro.gov.co/central-financiamiento/Pages/facturacion-electronica.aspx