Cómo resolver diferencias en la conciliación de pagos
6 min de lectura
Una conciliación gobernada fortalece el control financiero cuando convierte cada diferencia en una excepción explicable con código estable, evidencia, responsable y cierre verificable, no cuando oculta la decisión dentro de un matcher autónomo. La tasa de coincidencia puede subir mientras el control empeora si nadie puede explicar qué tolerancia se aplicó, por qué un caso fue aceptado o qué ocurrió con el saldo no conciliado.
Resumir con IA
Matching y control son problemas distintos
Este artículo desarrolla un control específico del proceso de conciliación automatizada: conserva separadas la venta, la liquidación y la confirmación del abono.
El matching propone relaciones entre registros. El control determina si esa relación puede aceptarse, quién puede aprobarla y qué evidencia debe quedar. Una coincidencia exacta por identificador, moneda y monto puede pasar por una política determinística; una diferencia tolerada requiere la versión de la regla; múltiples candidatos o una fuente ausente deben convertirse en trabajo visible.
La decisión no debería ser un porcentaje de confianza sin contexto. Debe producir una clase de resultado y un código de razón. Esa salida permite que finanzas agregue, asigne, escale y aprenda sin releer explicaciones libres.
El ciclo de control en siete transiciones
- Ingerir: identificar fuente, corte, versión y completitud.
- Normalizar: alinear identidad, moneda, signo, zona temporal y catálogo.
- Comparar: aplicar niveles de matching en orden controlado.
- Decidir: aceptar por política o abrir excepción con razón estable.
- Resolver: asignar dueño, evidencia requerida y acción permitida.
- Verificar: confirmar el cambio en el sistema de registro y el efecto contable.
- Aprender: proponer ajustes de regla, separados de su aprobación y despliegue.
El último paso no autoriza al agente a editar tolerancias por sí mismo. Un patrón repetido puede generar una propuesta; el dueño del control evalúa materialidad, efecto y pruebas antes de versionar la política.
Una diferencia de 20.000 COP necesita una causa, no un ajuste automático
Ejemplo ilustrativo: ventas por 1.000.000 COP, comisión informada de 20.000 COP y neto liquidado de 980.000 COP. El banco muestra un abono de 960.000 COP. Los primeros 20.000 COP corresponden a la comisión informada; los otros 20.000 COP siguen sin explicar. Sumarlos como una sola comisión haría desaparecer la diferencia sin demostrar su origen.
Antes de reclamar, verifica que el abono pertenezca al mismo lote y moneda. Un banco puede agrupar varios lotes, y un lote puede pagarse en más de un movimiento. Después revisa devoluciones, contracargos, reservas u otros conceptos incluidos en los soportes. Ninguno de esos conceptos debe inventarse para hacer cuadrar el total.
Si falta el detalle de liquidación, el caso es información insuficiente. Si el detalle explica el descuento, pero contradice la tarifa acordada, el caso es una comisión por validar. Si el neto esperado está sustentado y el abono vencido sigue incompleto, corresponde investigar la diferencia de recaudo. Cada clasificación cambia el responsable y el soporte que debe conseguir.
El cierre debe registrar la causa comprobada, el resultado económico y la referencia de la evidencia. Un correo que dice “resuelto” no acredita que entró dinero. Si hubo recuperación, vincula el abono posterior; si hubo un ajuste autorizado, conserva su aprobación y registro. El historial debe permitir ver qué cambió respecto del corte original.
Un contrato de cola, no una bandeja de mensajes
| Campo | Función de control |
|---|---|
| exception_id y reconciliation_run | identidad y corte reproducible |
| object_refs | partidas y documentos candidatos |
| reason_code/version | causa normalizada y catálogo vigente |
| amount, currency y materiality_band | exposición y política aplicable |
| evidence_refs | fuente, versión y artefactos permitidos |
| proposed_resolution | acción sugerida, nunca autoridad implícita |
| owner y due_at | responsabilidad y reloj de excepción |
| approval_policy | quién puede aceptar, ajustar o escalar |
| status y state_history | abierta, en revisión, resuelta, reabierta |
| resolution_code y outcome_ref | forma de cierre y confirmación posterior |
La cola necesita filtros por razón, antigüedad, exposición, fuente y responsable. “Pendiente” no es una categoría suficiente. Tampoco lo es un comentario que diga “parece correcto”.
Razones estables, explicaciones variables
Un catálogo inicial puede distinguir coincidencia exacta, dentro de tolerancia, referencia ausente, fuente tardía, duplicado, reverso, diferencia de monto, diferencia de moneda y candidatos múltiples. El código debe ser estable; la explicación puede incorporar detalles del caso.
La autoridad de registro de ISO 20022 publica conjuntos de códigos externos que pueden evolucionar sin cambiar el esquema del mensaje. La lección operativa es conservar la versión del catálogo y mapear códigos externos a razones internas gobernadas. No dependa del texto que un proveedor cambie sin aviso.
Una razón no es una causa raíz automática. “Referencia ausente” describe por qué no se concilió; la causa raíz puede ser una integración, una conducta del comercio o una regla de captura. Mantenga ambos niveles separados.
Niveles de matching con límites visibles
El primer nivel usa claves exactas y reglas invariantes. El segundo acepta transformaciones aprobadas, como formatos o alias versionados. El tercero aplica tolerancias explícitas por población. El cuarto propone candidatos ambiguos para revisión. No coloque todos los casos en un único modelo y luego traduzca su puntuación a “aprobado”.
Cada nivel registra entradas, versión, candidatos descartados y regla de salida. Si una fuente llega después del corte, el caso conserva el reason_code de fuente tardía y puede reanudarse; no debe desaparecer de la medición como si nunca hubiera existido.
Ejemplo ilustrativo: liquidación sin referencia
Este ejemplo es ilustrativo. Un abono bancario llega sin la referencia esperada. El matcher encuentra dos ventas del mismo monto. Como hay candidatos múltiples, la política impide publicación automática y abre una excepción con ambas evidencias.
El analista obtiene un archivo del adquirente, vincula el identificador correcto y selecciona la resolución “evidencia posterior”. El sistema confirma la publicación y cierra con outcome_ref. Si otro caso igual aparece, el agente puede sugerir una mejora de integración, pero no convertir la coincidencia ambigua en una regla silenciosa.
La historia permite responder qué se sabía al abrir, quién resolvió, qué nueva evidencia cambió la decisión y cuál asiento terminó publicado.
Evidencia para control y auditoría
El Green Book de GAO organiza el control interno alrededor de objetivos, riesgos, actividades de control, información, comunicación y monitoreo. La cola implementa esa lógica de forma operativa: aplica una actividad, comunica la deficiencia y conserva su remediación.
La familia de auditoría de NIST SP 800-53 Rev. 5 pide que los registros incluyan contenido como tipo de evento, momento, fuente, resultado e identidad asociada. Aunque no es una norma contable, esos campos ayudan a evitar expedientes sin actor o sin resultado.
No copie credenciales ni payloads sensibles a cada evento. Use referencias con control de acceso e integridad.
Métricas que revelan salud del control
Mida población elegible, partidas abiertas, valor no conciliado, antigüedad por razón, tiempo hasta asignación, tiempo hasta evidencia, reaperturas, ajustes posteriores y excepciones sin dueño. Separe coincidencias directas, aceptadas por tolerancia y revisadas.
Una tasa agregada de match no muestra si creció la exposición de la cola ni si el cierre requirió ajustes. La tendencia por reason_code señala dónde reparar datos, contratos o integración.
El contrapunto: formalizar excepciones añade fricción
Administrar un catálogo de razones y una cola formal parece más lento que aceptar coincidencias automáticas; sin embargo, el costo debe concentrarse en excepciones materiales y permitir procesamiento directo solo bajo reglas aprobadas. Automatice clasificación, búsqueda de evidencia y preparación; preserve autoridad donde la consecuencia lo exige.
Un catálogo excesivo también fragmenta la lectura. Fusione códigos que lleven al mismo control y conserve detalles como atributos, no como una razón nueva para cada caso.
Cuándo no usar este ciclo
No lo construya para una población pequeña y totalmente determinística que un sistema de registro ya concilia con evidencia suficiente. Enlace ese registro en vez de duplicarlo. No use IA para sustituir una regla exacta y estable, ni para aprobar diferencias que la política no ha definido.
Si las fuentes no tienen cortes, identidad o completitud verificables, resuelva primero el contrato de datos. Una cola sofisticada no corrige una población desconocida.
La prueba de control
Seleccione una partida resuelta y reproduzca el corte, los candidatos, la regla, la razón, la autoridad y el resultado. Luego agregue todas las excepciones con la misma razón y encuentre su dueño de mejora. Si solo puede ver que el modelo “hizo match”, existe automatización; todavía no existe un ciclo de control financiero.
- Relacionar lote y abono
- Obtener causa y soporte
- Confirmar resultado del cierre
