Patrones de UI para pantallas de conciliación que ayudan a los equipos de operaciones a detectar desajustes, revisar evidencias, aplicar correcciones controladas y mantener un registro de auditoría limpio.
Una pantalla de conciliación existe para responder una pregunta práctica: cuando dos fuentes no coinciden, ¿cuál es la verdad que vamos a reportar y sobre la que operaremos?
Normalmente comparas una “fuente” (feed bancario, procesador de pagos, POS, sublibro, sistema de almacén) contra tu “libro de registro” (a menudo el libro mayor). La pantalla no es solo una vista comparativa. Es el lugar donde se toman y registran las decisiones.
Los desajustes ocurren por motivos mundanos, y eso es buena noticia porque la interfaz puede anticiparlos. Verás diferencias causadas por retrasos en contabilizaciones, elementos faltantes, duplicados, problemas de mapeo (cuenta equivocada, cliente, moneda) y coincidencias parciales donde un registro de un lado equivale a varios del otro.
El trabajo del usuario en una buena configuración de pantalla de conciliación es mover cada excepción de “incierta” a “resuelta” sin adivinar. Esa tarea se suele descomponer en acciones repetibles:
El mayor riesgo no es una coincidencia incorrecta, sino un cambio silencioso. Si la pantalla permite editar valores sin mostrar qué cambió, quién lo cambió y qué registros se vieron afectados, se pierde la confianza y se pierde tiempo durante las auditorías.
Diseña la pantalla de modo que cada resolución produzca un resultado rastreable: valores antes/después, registros fuente vinculados, marca temporal, usuario y código de razón. Si se requieren aprobaciones, la UI debe dejar el estado “necesita aprobación” obvio para que el trabajo no desaparezca en una zona gris.
Si más adelante construyes esto en una herramienta como AppMaster, trata el registro de auditoría como un modelo de datos de primera clase, no como una nota al margen. Tu cierre de mes futuro te lo agradecerá.
Una pantalla de conciliación funciona mejor cuando se siente como una lista de verificación tranquila, incluso cuando los datos están desordenados. La forma más fácil de lograrlo es un diseño claro de tres partes: Resumen arriba, Cola de trabajo a la izquierda (o centro) y Detalles a la derecha.
El Resumen responde “¿estamos cerca?”. Muestra totales para cada lado (conteo y monto), luego el delta en ambas unidades. La gente debería ver, de un vistazo, si están desfazados por 3 ítems, $124.18 o ambos. Si puedes, incluye una pequeña tendencia como “delta mejoró desde el último guardado” para que los revisores sepan que su trabajo está moviendo la aguja.
La Cola de trabajo es donde vive la escala. Mantén búsqueda y filtros visibles todo el tiempo para que los usuarios no tengan que abrir paneles extras para hacer trabajo básico. Una lista simple de filas con un chip de estado (Nuevo, En revisión, Corregido, Requiere aprobación) suele ser suficiente.
Aquí hay una estructura clara usada en muchas pantallas de conciliación:
Por defecto, usa la ventana temporal más pequeña útil. Por ejemplo, empieza con los últimos 7 días para mantener la cola corta y rápida, y deja que los usuarios expandan con un clic cuando necesiten el mes completo. Esto reduce ruido y ayuda a los revisores nuevos a ganar confianza.
Si lo construyes en una herramienta como AppMaster, mantiene el diseño consistente entre web y móvil: las mismas tres zonas, solo apiladas en pantallas pequeñas, para que la formación y la memoria muscular se trasladen.
Una buena vista de desajustes responde tres preguntas en segundos: qué está mal, qué gravedad tiene y qué debo hacer a continuación. Si la pantalla obliga a abrir tres modales solo para entender una diferencia, la gente dudará, adivinará o dejará notas para más tarde.
Empieza usando un conjunto pequeño y coherente de tipos de desajuste en todo el producto. Esa consistencia importa más que la formulación perfecta, porque los revisores desarrollan memoria muscular. La mayoría de los equipos cubren el 90% de los casos con cuatro etiquetas: elemento faltante, elemento extra, monto difiere y fecha difiere. Pon el tipo al inicio de la fila para que la gente no lo busque.
La severidad debe ser obvia pero comedida. Prefiere etiquetas simples como “Alta”, “Media”, “Baja” (o “Bloquea cierre”, “Requiere revisión”, “FYI”) con color contenido. Usa el color como pista, no como mensaje. Reserva el rojo fuerte para casos que realmente detienen el cierre del periodo y mantén todo lo demás neutral.
Los revisores también necesitan el “por qué”, pero no en jerga interna. Muestra una línea corta de razón que haga referencia a lo que el sistema encontró, como “Coincidió por referencia, monto difiere” o “No se encontró asiento en el libro mayor para la transacción bancaria”. Si hay reglas involucradas, muestra el nombre de la regla solo si ayuda, e incluye las diferencias clave de campos en términos comprensibles.
Mantén visibles los valores crudos y normalizados juntos. La normalización (redondeo, conversión de moneda, recorte de espacios, cambios de zona horaria) es común, y ocultarla genera desconfianza. Un diseño práctico es una comparación de dos columnas dentro de cada fila de desajuste:
Si lo construyes con una herramienta como AppMaster, modela el tipo de desajuste y la severidad como enums en la capa de datos, para que cada lista, filtro y panel de detalle sea coherente en todo el flujo de revisión.
Cuando el volumen es alto, una cola de conciliación debe comportarse más como una bandeja de entrada que como un informe. Las personas deben entender cada fila en un segundo, decidir qué hacer y seguir avanzando sin perder contexto.
Empieza con columnas que respondan “qué es” antes de “qué significa”. Si puedes, mantén la primera pantalla con lo esencial y lleva los detalles al panel lateral.
El ordenamiento debe coincidir con la forma de pensar de los revisores. Un buen valor por defecto es “mayor delta primero” porque saca a la superficie el mayor riesgo rápidamente. Añade conmutadores rápidos para recientes, pendientes más antiguos y “revisados recientemente” para facilitar los traspasos.
Las vistas guardadas son lo que permite escalar una cola entre roles. Un analista puede querer “abiertos + auto-coincidencia fallida”, un aprobador “solo esperando aprobación” y un auditor “resueltos en este periodo con ediciones manuales”. Mantén las vistas obvias y con nombres claros para que la gente no termine creando sus propias hojas de cálculo.
La selección masiva puede ahorrar mucho tiempo, pero solo si tiene salvaguardas. Deja claros los límites (por ejemplo, máximo 50 ítems), muestra qué campos cambiarán y advierte cuando las acciones sean irreversibles. Un paso de vista previa simple evita errores masivos.
Los indicadores de progreso mantienen al equipo alineado. Muestra conteos por estado arriba y hazlos filtros clicables. Mejor aún, muestra la propiedad (sin asignar vs asignado a mí) para evitar trabajo duplicado.
Estos patrones son sencillos de construir con una herramienta visual como AppMaster: una tabla de cola, filtros guardados por rol y chips de estado dan velocidad a los equipos financieros sin sacrificar control.
Un buen flujo de conciliación trata menos sobre visuales llamativos y más sobre evitar que la gente salte por la pantalla. El objetivo es guiar al revisor desde “¿Qué cambió?” hasta “¿Qué hicimos al respecto?” sin perder contexto.
Comienza haciendo el Paso 1 inevitable: elegir un periodo de conciliación y las fuentes de datos exactas. Colócalos en la parte superior de la página y mantenlos visibles después de la selección (periodo, fuente A, fuente B, última actualización). La mayoría del retrabajo ocurre cuando alguien revisa desajustes contra una extracción equivocada.
El Paso 2 es el escaneo de 30 segundos. Muestra el delta total, el conteo de ítems sin emparejar y las principales categorías de desajuste (transacción faltante, diferencia de monto, desplazamiento de fecha, duplicado). Cada categoría debe ser clicable para filtrar la lista de trabajo.
El Paso 3 es donde importa la velocidad: abre un ítem y compara campos lado a lado. Mantén los campos clave alineados (importe, fecha, referencia, contraparte, moneda, cuenta) y muestra la evidencia ahí mismo: fila de importación cruda, asiento en el libro y cualquier documento adjunto. Evita ocultar evidencia detrás de pestañas extra.
El Paso 4 es el punto de decisión. La UI debe presentar un conjunto pequeño de acciones con resultados claros:
El Paso 5 es responsabilidad. Requiere una nota corta para todo lo que no sea una coincidencia limpia y solo desencadena aprobación cuando las reglas lo indiquen (por ejemplo, bajas por encima de un umbral o cualquier ajuste a un sublibro cerrado). Muestra quién aprobará antes de enviar, para que el revisor no tenga que adivinar.
El Paso 6 cierra el ciclo. Tras enviar, confirma qué cambió (“Emparejado con Asiento #48321”, “Ajuste redactado”) y muestra inmediatamente la entrada de auditoría: marca temporal, usuario, acción, campos antes/después y estado de aprobación. Un revisor nunca debería preguntarse si su clic “surti efecto”.
Las correcciones son donde aparecen errores y riesgos de fraude, por lo que la UI debe hacer que las acciones más seguras sean las más fáciles. Una buena regla: permite avanzar el trabajo sin cambiar balances al principio, y exige más intención cuando sí se altera el dinero.
Comienza con acciones “seguras” que no alteran saldos. Estas reducen idas y vueltas y mantienen las decisiones visibles:
Cuando el usuario necesite crear un ajuste, usa un formulario guiado en lugar de un campo de texto libre. El formulario debe dificultar olvidar lo básico y facilitar la revisión posterior. Aquí es donde también previenes “arreglos rápidos” que crean problemas mayores al cierre de mes.
Mantén las acciones destructivas detrás de permisos y una confirmación clara. Por ejemplo, “Eliminar ajuste” debe ser raro, basado en roles y requerir una razón. Prefiere acciones que creen un nuevo registro en lugar de editar el historial.
La validación debe ocurrir antes de guardar y el mensaje debe explicar cómo corregirlo. Una lista de verificación simple funciona bien:
Haz explícito el comportamiento de deshacer. Los usuarios deben saber si pueden reabrir el ítem, revertir el ajuste o crear una contrapartida. Ejemplo: un revisor vincula la línea bancaria equivocada y luego se da cuenta de que la coincidencia pertenece a otro pago. Un claro “Desvincular” (con nota) es más seguro que editar la transacción original y preserva una historia limpia de lo ocurrido y por qué.
Un registro de auditoría solo ayuda si responde preguntas rápido: quién tocó este ítem, qué cambió y por qué. El truco es hacerlo visible cuando se necesita, pero sin bloquear el flujo normal de revisión.
Añade una línea de tiempo compacta en el panel de detalles del ítem. Cada entrada debe mostrar el actor, la marca temporal, la acción y un resumen corto del cambio. Manténlo escaneable y consistente, para que los revisores detecten el último evento importante (por ejemplo “importe corregido” o “aprobado”) de un solo vistazo.
Cuando un campo se corrige, guarda y muestra ambos valores: antes y después. Muéstralos en línea en la entrada de la línea de tiempo (por ejemplo: “Importe bancario: 1,250.00 -> 1,205.00”) y también en el historial del campo si alguien abre “Detalles de cambio”. Esto evita el error común de conservar solo el valor final.
Para acciones de mayor riesgo (baja, sobrescritura manual, emparejamiento forzado), exige una razón. Usa un menú desplegable corto más una nota opcional, para que el revisor avance rápido pero deje una explicación clara.
El esquema maker-checker funciona mejor cuando es por estados, no por mensajes. Usa estados simples como Borrador, Enviado, Necesita info, Aprobado, Rechazado, Escalado y muestra el estado actual cerca del título del ítem. Mantén la UI de aprobaciones ajustada:
Finalmente, mantiene la evidencia adjunta al propio ítem de conciliación: archivos subidos, referencias de email o chat, IDs externos y notas. Un revisor no debe tener que buscar en otros sistemas para justificar una decisión. En herramientas como AppMaster, esto se mapea naturalmente a un registro “Reconciliation Item” con entidades relacionadas “Evidence” y “Approval Events”, de modo que la UI siga simple y los datos completos.
La mayoría de las pantallas de conciliación funcionan hasta que aparecen datos reales. Los puntos de ruptura son previsibles, por lo que ayuda diseñarlos desde el principio.
Las coincidencias parciales son la primera trampa. Una tabla limpia de uno a uno se desmorona cuando una transferencia bancaria paga tres facturas o cinco liquidaciones con tarjeta se agrupan en un asiento. Trata estos casos como de primera clase: permite a los revisores crear una coincidencia agrupada con un total visible, un indicador de “monto no asignado” y una etiqueta de grupo clara (por ejemplo, “3 ítems -> 1 asiento”). Haz el grupo expandible para que la gente confirme las partes sin perder el resumen.
Los duplicados son la segunda trampa. La gente a menudo “arregla” duplicados emparejando los ítems equivocados. Añade pistas suaves como “posible duplicado” basadas en importe, ventana de fechas y contraparte, pero mantenlo seguro: los revisores deben poder abrir una vista comparativa, elegir el registro correcto y marcar el otro como duplicado con una razón. Si ofreces fusión, que sea reversible y conserva siempre los IDs originales.
Las diferencias de moneda y redondeo son comunes y no deben parecer errores. Muestra el cálculo exacto (tasa, comisión, redondeo) y permite umbrales configurables (por moneda, cuenta o tipo de transacción). La UI debe decir “dentro de tolerancia” vs “requiere acción”, no solo “coincide/no coincide”.
Los asientos realizados fuera de fecha pueden confundir el cierre del periodo. Cuando un ítem se resuelve después del cierre, no reescribas la historia. Muéstralo como “resuelto después del cierre” con la fecha de resolución y exige nota o aprobación si cambia un número de periodo cerrado.
Por último, ocurren caídas y feeds faltantes. Añade estados que faciliten volver más tarde:
Si construyes esto en AppMaster, modela estos estados en el Data Designer y aplica transiciones permitidas en el Business Process Editor, para mantener el manejo de casos límite consistente y auditable.
Es fin de mes. Tu extracto bancario muestra $248,930.12 en actividad para abril, pero tu libro interno totaliza $249,105.12. La pantalla de conciliación se abre con un Resumen que responde tres preguntas rápido: cuántos ítems coinciden, cuántos están desajustados y cuánto dinero queda sin resolver.
En el panel Resumen, el usuario ve: 1,284 ítems emparejados, 3 desajustes y una diferencia no resuelta de $175.00. Un pequeño aviso muestra “2 ítems necesitan acción” porque uno de los desajustes es solo informativo.
La tabla de desajustes agrupa por tipo y hace obvio el siguiente paso:
Cuando el usuario hace clic en una fila, se abre Detalle del Ítem a la derecha. Para la comisión de $25.00, Detalle del Ítem muestra la línea bancaria (fecha, descripción, importe) junto al lado del libro (no se encontró asiento coincidente) más una solución sugerida: “Crear asiento de gasto: Comisiones bancarias.” El usuario selecciona la razón de corrección, añade una nota y adjunta la línea del extracto como evidencia.
Para el pago duplicado de $150.00, Detalle del Ítem muestra dos asientos que están emparejados con un pago bancario. El usuario marca uno de los asientos del libro como duplicado, elige “Reversar asiento” y la pantalla crea una transacción reversa propuesta. Como esto cambia la contabilidad, se envía a aprobación: el estado pasa a “Pendiente de aprobación” y el desajuste deja de contar como “No revisado”.
El retraso de contabilización luce distinto. El banco muestra un pago iniciado el 30 de abril que se liquida el 1 de mayo. El usuario marca la resolución como “Diferencia de timing”, indica la fecha esperada de liquidación y el ítem pasa a “Apertura para periodo siguiente”.
Más tarde, un auditor debe poder confirmar, sin adivinar:
Cerrar un periodo es donde pequeñas fallas en la UI se convierten en grandes dolores después. Una buena lista de cierre debe ser visible en pantalla, fácil de verificar y difícil de saltarse por accidente.
Empieza por los totales. Muestra conteo y monto por fuente para el periodo y deja claro qué cifra provoca el desajuste (por ejemplo, “3 ítems, $1,240.00” en cada lado). Si los totales coinciden pero los conteos no, señálalo claramente para que los revisores no asuman que ya terminaron.
Antes del cierre, cada excepción debe tener un estado final y una razón que alguien más pueda entender semanas después. “Resuelto” no basta sin una nota como “cargo duplicado revertido” o “diferencia de timing, se limpiará el próximo periodo”. Este patrón evita trabajo repetido.
Usa una lista de verificación corta de pre-cierre y bloquea el cierre si falla cualquiera de estas:
La revisión aleatoria es simple pero poderosa. Abre cinco ítems resueltos al azar y verifica tres cosas: la evidencia (línea de estado, recibo, registro del sistema), la acción de corrección (qué cambió) y la nota (por qué fue válida). Si falta alguna, la UI está enseñando el hábito equivocado.
Finalmente, haz el periodo reproducible. Ofrece un “snapshot” que congele totales clave, estados de excepción, notas y aprobaciones. En AppMaster, esto puede ser un registro “Period Close” generado por un Business Process, de modo que la vista de auditoría coincida con lo que los revisores vieron al cerrar.
Empieza por los datos, no por el diseño. Una pantalla de conciliación se complica cuando el sistema no puede explicar claramente qué es un registro y cómo se relaciona con otros. Define un modelo pequeño que puedas ampliar más tarde: tus archivos/feeds fuente, las transacciones individuales, los grupos de coincidencia que conectan ítems entre fuentes y los ajustes que creas para corregir diferencias. Añade campos necesarios para la revisión (importe, moneda, fechas, texto de referencia) además de los aburridos pero críticos (estado, responsable, timestamps).
Luego fija los roles desde temprano. La mayoría de los equipos necesitan al menos tres: un analista que proponga coincidencias y correcciones, un aprobador que firme ajustes y un auditor que pueda ver todo sin modificar nada. Si dejas los permisos para después, terminarás rehaciendo acciones clave (editar, deshacer, reabrir) cuando llegue la primera revisión de controles.
Después, prototipa las tres superficies que impulsan el trabajo real:
Define las transiciones de estado como reglas, no como costumbres. Por ejemplo, un grupo no debería pasar a “Conciliado” a menos que la diferencia restante sea cero (o esté dentro de una tolerancia establecida), todos los campos requeridos estén presentes y las aprobaciones completas. Permite excepciones, pero fuerza un código de razón y un comentario para mantener limpio el registro de auditoría.
Para construir rápido, usa una plataforma no-code como AppMaster: modela la base de datos en Data Designer con PostgreSQL, arma la cola y los paneles con el constructor web y aplica las reglas del flujo en el editor visual de Business Process. Mantén la primera versión estrecha (un par de fuentes, pocos estados), pruébala con casos reales de cierre de mes e itera según los desajustes que tu equipo realmente vea.
21 ene 2026
8 min
20 ene 20268 min
20 ene 20268 minExperimente con AppMaster con plan gratuito.
Cuando esté listo, puede elegir la suscripción adecuada.
