El seguimiento facturas SIIFA exige que la IPS pueda relacionar cada FEV con su radicación, devoluciones, glosas, respuestas, reiteraciones, subsanaciones y decisión final. El manual de interoperabilidad 1.0.2, publicado por el Ministerio en agosto de 2026, define servicios REST, mensajes JSON, autenticación y gestión de errores. La preparación debe unir proceso jurídico, calidad del dato, integración tecnológica, plazos y evidencia auditable.
El seguimiento a una factura de salud ya no puede depender de correos aislados, hojas de cálculo y notas sin una referencia común. El Sistema Integral de Información Financiera y Asistencial (SIIFA) está diseñado para consolidar información financiera, administrativa y asistencial y dar trazabilidad a las transacciones entre agentes del sector.
El 14 de agosto de 2026, el Ministerio publicó en su micrositio el Manual Funcional de Seguimiento a Facturas, versión 1.0.2, y el Manual de Interoperabilidad del mismo módulo, versión 1.0.2. El cambio técnico más concreto del manual de interoperabilidad fue la depuración de las estructuras de los nuevos endpoints para objeciones de devoluciones y objeciones. La documentación oficial de SIIFA permite comprobar las versiones y fechas disponibles.
Para una IPS, la novedad no significa que una API resuelva por sí sola la cartera. Significa que facturación, auditoría, jurídica, cartera y tecnología deben compartir identificadores, estados, plazos y evidencias. Este artículo traduce el manual a una arquitectura operativa, señalando como análisis técnico las recomendaciones que no son mandatos literales de la norma.
¿Qué es el seguimiento facturas SIIFA?
Es el registro interoperable de los eventos que permiten conocer qué ocurrió con una factura electrónica de venta en salud después de su emisión y radicación: auditoría, devolución, glosa, respuesta, reiteración, subsanación y decisión final, según corresponda.
El micrositio de SIIFA explica que el sistema tiene cuatro módulos:
- registro de contratación de servicios y tecnologías;
- FEV en salud y RIPS;
- seguimiento a facturas;
- seguimiento a pagos.
El módulo 3 registra la radicación de la FEV, el proceso de auditoría y su resultado. El módulo 4 registra pagos efectuados por entidades responsables de pago, ADRES y otros pagadores, incluidos anticipos y amortizaciones. Esta separación importa: seguimiento facturas SIIFA describe el trámite y estado de la cuenta; no equivale automáticamente a la recepción ni conciliación del dinero.
¿A quién aplica el módulo de seguimiento a facturas?
El Manual de Interoperabilidad 1.0.2 incluye a Entidades Responsables de Pago (ERP), Prestadores de Servicios de Salud (PSS), Proveedores de Tecnologías en Salud (PTS) y otros pagadores, entre ellos compañías SOAT y entidades que ofrecen planes voluntarios de salud. El ámbito concreto depende de las fases y grupos de implementación previstos en la Resolución 1962 de 2025.
La Resolución 1962 de 2025 desarrolla la estructura de SIIFA, define la información a registrar y establece responsabilidades. La resolución señala que los actores deben reportar de forma interoperable información sobre contratos, facturas, notas, devoluciones, glosas, respuestas, pagos y saldos en discusión, según su rol y la gradualidad aplicable.
Por tanto, una IPS no debería interpretar la publicación del manual como una fecha universal aislada. Debe identificar su grupo, cronograma, rol y canal de reporte en la regulación vigente, y confirmar cualquier cambio posterior en el micrositio oficial.
¿Qué cambió en la versión 1.0.2 de agosto de 2026?
El control de versiones del manual indica dos depuraciones frente a la versión 1.0.1:
| Sección actualizada | Cambio oficial reportado | Impacto técnico para la IPS |
|---|---|---|
| Objeciones de devoluciones | Depuración de la estructura de datos de nuevos endpoints | Revisar modelos JSON, validaciones y pruebas para flujos SOAT o planes voluntarios cuando apliquen |
| Objeciones | Depuración de la estructura de datos de nuevos endpoints | Alinear el conector y el historial de mensajes con la especificación vigente |
| Publicación documental | Manual funcional e interoperabilidad 1.0.2 publicados el 14 de agosto de 2026 | Controlar versiones y evitar desarrollar contra documentación anterior |
| Alcance | La fase II se encuentra en actualización | No asumir funciones futuras como disponibles; verificar el alcance operativo antes de desplegar |
El impacto señalado en las dos últimas columnas es un análisis técnico derivado del manual. El texto oficial no ordena una arquitectura interna específica, pero sí define estructuras y servicios que el sistema consumidor debe implementar correctamente.
¿Cómo funciona la arquitectura de seguimiento facturas SIIFA?
El manual define una API REST sobre HTTPS, intercambio en JSON, especificación OpenAPI 3.0, autenticación mediante JWT o token portador, validación de esquema y respuestas con códigos HTTP estándar. Esto permite que un sistema institucional registre y consulte eventos sin depender exclusivamente de captura manual.
En términos operativos, el flujo puede representarse así:
- La factura y sus soportes siguen el proceso de emisión, validación y radicación aplicable.
- El pagador ejecuta la auditoría y registra el evento correspondiente.
- La IPS consulta o recibe el estado y vincula el evento con la factura correcta.
- El responsable analiza la causa y prepara la respuesta dentro del término aplicable.
- El sistema registra respuesta, reiteración, subsanación o decisión final según el caso.
- El expediente conserva la secuencia completa, los valores y la evidencia.
- Cartera usa el resultado para actualizar saldos, notas y acciones de cobro, sin confundir trámite con pago.
La página principal de Software Médico muestra un ecosistema que conecta historia clínica, RIPS y facturación. Al evaluar esa u otra plataforma, la IPS debe probar que el identificador de la factura y sus eventos se mantenga sin ruptura desde el proceso clínico hasta cartera.
¿Qué métodos expone la API para devoluciones?
Para ERP, PSS y PTS, el manual describe métodos que permiten consultar un seguimiento por identificador, listar devoluciones asociadas a una factura y obtener un resumen consolidado. También contempla crear devoluciones de forma individual o masiva y agregar respuestas o reiteraciones.
Una lectura funcional de los métodos es:
| Operación | Método general | Uso operativo | Control recomendado |
|---|---|---|---|
| Consultar detalle | GET | Recuperar un evento por identificador | Verificar pertenencia a la factura y pagador |
| Consultar por factura | GET | Listar eventos asociados a una FEV | Conciliar cantidad, estado y valores |
| Consultar resumen | GET | Obtener consolidado de devoluciones | Comparar con tablero interno |
| Crear evento | POST | Registrar una devolución | Evitar duplicidad mediante llave idempotente interna |
| Crear masivo | POST | Registrar múltiples seguimientos | Validar lote, rechazos parciales y reintentos |
| Responder | PUT | Añadir respuesta a un seguimiento | Adjuntar responsable, fecha y soporte interno |
| Reiterar | PUT | Registrar reiteración | Mantener vínculo con evento original |
El nombre exacto, ruta y esquema de cada endpoint debe tomarse de la versión vigente de Redoc u OpenAPI. No es prudente programar a partir de una tabla editorial, porque la especificación oficial es el contrato técnico.
¿Cómo se registran y consultan las glosas?
El manual ofrece consultas por identificador, por factura y por resumen; también permite crear glosas individual o masivamente, agregar respuestas, registrar reiteraciones, incorporar respuesta a la reiteración como subsanación y registrar la decisión final.
Esta secuencia hace visible algo que una hoja de cálculo suele perder: una glosa no es un estado único. Es una conversación regulada con fechas, códigos, valores y decisiones. El sistema interno debe preservar cada transición sin sobrescribir la anterior.
El manual reproduce los términos del artículo 57 de la Ley 1438 de 2011: la ERP formula y comunica glosas dentro de los veinte días hábiles siguientes a la presentación de la factura con soportes; el prestador responde dentro de quince días hábiles; y la ERP decide dentro de diez días hábiles después de recibir la respuesta. También contempla el término para subsanar y el pago de valores levantados. El Manual de Interoperabilidad 1.0.2 es la fuente directa para verificar el flujo y su referencia normativa.
La institución debe validar la aplicación concreta de los términos con su equipo jurídico y la norma vigente; una integración tecnológica no reemplaza el análisis contractual o legal.
¿Qué diferencia existe entre devolución, glosa y objeción?
Una devolución impide tramitar la factura por una causal definida y sigue el procedimiento del Manual Único de Devoluciones, Glosas y Respuestas. Una glosa controvierte total o parcialmente el reconocimiento de la factura por causas codificadas. En los flujos específicos de SOAT y planes voluntarios, el manual 1.0.2 incorpora endpoints de objeciones de devoluciones y objeciones, con historiales de mensajes.
El manual refiere la Resolución 2284 de 2023 para el procedimiento de devolución: el pagador puede comunicarla una sola vez dentro de los cinco días hábiles siguientes a la radicación; el prestador o proveedor puede responder una devolución que considere injustificada dentro de cinco días hábiles; y el pagador tiene cinco días hábiles para aceptar la respuesta o reiterar. El portal oficial sobre relaciones entre prestadores y pagadores identifica la Resolución 2284 de 2023 como reglamentación aplicable.
Confundir estas categorías genera reglas, plazos y mensajes incorrectos. Un glosario actualizado de RIPS puede ayudar a alinear vocabulario interno, pero la fuente de obligatoriedad continúa siendo la documentación oficial vigente.
¿Qué datos debe gobernar la IPS de extremo a extremo?
El manual define el intercambio; la IPS debe gobernar el origen. Como mínimo, conviene establecer propietarios y validaciones para:
- identificador interno y oficial de la factura;
- emisor, pagador, contrato y modalidad de pago;
- fecha de emisión, validación y radicación;
- identificador, causal, código y valor del evento;
- fecha de recepción y vencimiento calculado;
- usuario o servicio que registró cada acción;
- respuesta, soporte y resultado;
- nota crédito o débito relacionada cuando proceda;
- saldo inicial, controvertido, aceptado, levantado y pendiente;
- estado de sincronización con SIIFA.
La guía de modalidades de pago en FEV ofrece contexto sobre configuración contractual y facturación. Para el proyecto SIIFA, el dato debe validarse contra contrato, FEV y fuentes oficiales, no copiarse de forma independiente en cada módulo.
¿Cómo debe tratar la integración los errores técnicos?
La API usa códigos HTTP comunes: 200 para una operación procesada, 400 para estructura o parámetros inválidos, 401 para credenciales ausentes o inválidas, 403 para permisos insuficientes, 404 para recursos no encontrados y 500 para un error interno del servidor.
La aplicación práctica exige respuestas distintas:
| Código | Lectura operativa | Acción segura |
|---|---|---|
| 200 | Solicitud procesada | Guardar identificador, fecha y respuesta; evitar reenvío duplicado |
| 400 | Dato o estructura inválida | Corregir la causa; no reintentar el mismo contenido en bucle |
| 401 | Token inválido o vencido | Renovar autenticación y registrar el incidente técnico |
| 403 | Rol sin permiso | Revisar autorización; no ampliar privilegios automáticamente |
| 404 | Recurso no localizado | Confirmar identificadores y sincronización previa |
| 500 | Falla interna | Aplicar reintento controlado con espera y escalar si persiste |
El análisis técnico recomienda una cola transaccional: cada envío conserva un identificador, huella del contenido, número de intento, respuesta y estado final. Así se diferencia entre “pendiente de enviar”, “rechazado por dato”, “falló por infraestructura” y “confirmado”. Sin esta separación, un reintento puede crear duplicados o una falla temporal puede convertirse en pérdida silenciosa.
¿Qué controles necesita el seguimiento facturas SIIFA?
El control debe cubrir proceso, dato y seguridad:
- Versionamiento: registrar manual, OpenAPI y catálogos usados en cada despliegue.
- Idempotencia: impedir que el mismo evento se cree dos veces por un reintento.
- Integridad referencial: no aceptar respuesta, reiteración o decisión sin evento previo válido.
- Segregación: separar creación, aprobación y reversión según el riesgo.
- Reloj normativo: calcular vencimientos con reglas verificadas y calendario laboral controlado.
- Bitácora: conservar actor, fecha, contenido, resultado y cambio de estado.
- Alertas: priorizar eventos próximos a vencer, fallas recurrentes y desbalances de valor.
- Protección: gestionar secretos, tokens y datos con mínimo privilegio y canales seguros.
El software para IPS en Colombia puede evaluarse mediante una prueba de trazabilidad: seleccionar una factura con devolución, otra con glosa parcial y una con varios mensajes; luego comprobar que el sistema reconstruya la historia y concilie sus valores.
¿Cómo preparar la implementación sin detener la facturación?
Una ruta de implementación por etapas reduce riesgo:
- Definir alcance: identificar actores, grupo, cronograma y flujos aplicables.
- Levantar el proceso actual: documentar canales, plazos, responsables, formatos y excepciones.
- Mapear datos: relacionar cada campo oficial con su fuente interna y regla de calidad.
- Diseñar integración: autenticación, colas, reintentos, logs, monitoreo y contingencia.
- Configurar pruebas: incluir eventos normales, masivos, duplicados, fuera de secuencia y con errores.
- Conciliar resultados: comparar SIIFA, sistema de facturación y cartera factura por factura.
- Capacitar por rol: enseñar decisiones y evidencias, no solo navegación.
- Desplegar gradualmente: iniciar con un pagador o flujo controlado cuando el marco lo permita.
- Monitorear: revisar latencia, rechazos, vencimientos y diferencias de valor.
El micrositio oficial informa que el Ministerio ofrece capacitaciones y mesa de ayuda durante la implementación. Los canales y horarios deben comprobarse allí al momento de requerir soporte, porque pueden cambiar.
¿Qué debe preguntar la gerencia al equipo del proyecto?
La dirección puede gobernar el proyecto con preguntas concretas:
- ¿Qué versión oficial está en producción y quién vigila cambios?
- ¿Qué porcentaje de facturas puede rastrearse sin búsquedas manuales?
- ¿Cuántos eventos están próximos a vencer y por qué?
- ¿Qué diferencias existen entre el saldo contable y el saldo del expediente?
- ¿Cuántas transacciones fallaron por datos, permisos o infraestructura?
- ¿Cómo se evita duplicar eventos en reintentos?
- ¿Quién puede corregir información y qué evidencia queda?
- ¿Cómo se opera durante una indisponibilidad?
Estas preguntas conectan tecnología con liquidez y cumplimiento. El objetivo de seguimiento facturas SIIFA no es aumentar reportes, sino hacer visible la historia de cada cuenta y reducir disputas alimentadas por datos incompletos.
¿Qué indicadores sirven para controlar el módulo?
Como recomendación de gestión, la IPS puede medir:
- facturas con trazabilidad completa sobre el total radicado;
- eventos recibidos y procesados dentro del término interno;
- rechazos técnicos por cada mil transacciones;
- reintentos y duplicados prevenidos;
- diferencias de valor entre facturación, seguimiento y cartera;
- devoluciones y glosas por causal, pagador y contrato;
- tiempo hasta respuesta y decisión final;
- saldos en discusión por antigüedad;
- incidentes de acceso o exposición de datos.
Cada indicador necesita definición y fuente. No debe mezclarse el tiempo técnico de la API con el tiempo de gestión humana, ni una aceptación de transacción con la aceptación jurídica o financiera del evento.
¿Cuál es la conclusión para el seguimiento facturas SIIFA?
El seguimiento facturas SIIFA convierte el ciclo de auditoría en una secuencia interoperable y verificable. La versión 1.0.2 aporta estructuras depuradas para objeciones y mantiene servicios REST para devoluciones, glosas, respuestas, reiteraciones, subsanaciones y decisiones. Su valor depende de que la IPS conserve identidad, plazos, valores, evidencias y estados desde la FEV hasta cartera.
El próximo paso responsable es confirmar el grupo y cronograma aplicable, descargar la especificación vigente, inventariar los campos internos y ejecutar pruebas de extremo a extremo. Las áreas de facturación, auditoría, cartera, jurídica, seguridad y tecnología deben aprobar conjuntamente el flujo. Ante dudas sobre vigencia o interpretación, corresponde validar con el Ministerio, la autoridad competente o asesoría jurídica especializada.
Fuentes oficiales consultadas
- Ministerio de Salud y Protección Social. “Sistema Integral de Información Financiera y Asistencial”. Versiones de seguimiento a facturas 1.0.2 publicadas el 14 de agosto de 2026.
- Ministerio de Salud y Protección Social. “Manual de interoperabilidad del módulo de seguimiento a facturación”, versión 1.0.2, julio de 2026; publicado el 14 de agosto de 2026.
- Ministerio de Salud y Protección Social. “Resolución 1962 de 2025”, 23 de septiembre de 2025.
- Ministerio de Salud y Protección Social. “Relaciones entre entidades prestadoras y pagadoras de servicios de salud”. Consultada el 3 de septiembre de 2026.