Planteamiento y alcance
Un sistema de órdenes produce 200 millones de transacciones por día. El libro mayor interno registra órdenes, pagos, reembolsos y comisiones; el proveedor de pagos suministra reportes de lotes de liquidación; el banco suministra depósitos reales. Diseña un pipeline T+1 que finalice el día anterior antes de las 06:00, identifique diferencias por datos faltantes, duplicados, montos, comisiones y monedas, y admita reejecuciones, revisión humana, reembolsos, múltiples monedas y pistas de auditoría.
Asume que el libro mayor interno es la fuente de verdad del negocio, mientras que el proveedor y el banco son fuentes de verdad externas. La conciliación no debe sobrescribir el libro mayor ni ocultar diferencias a nivel de fila solo porque los totales coinciden. El monto, la moneda, la fecha de liquidación, el lote y la evidencia deben permanecer rastreables.
Qué está evaluando el entrevistador
Primero, ¿puedes definir hechos, tiempo e invariantes antes de elegir herramientas? Distingue entre fecha de transacción, fecha de contabilización, fecha de liquidación y fecha valor del banco. Almacena el dinero en unidades menores, exige la moneda y haz que las importaciones repetidas sean seguras.
Segundo, ¿puedes hacer que la coincidencia sea una estrategia por capas en lugar de una unión de tabla completa? Comienza con los ID de transacción del proveedor y los ID de lote, luego utiliza combinaciones restringidas de ID de orden, monto, moneda y ventana de tiempo. Las coincidencias difusas deben enviarse a revisión en lugar de confirmarse silenciosamente.
Tercero, ¿puedes cerrar el ciclo de discrepancias? Cada discrepancia necesita un tipo, severidad, evidencia, responsable, estado, fecha límite y acción correctiva. Una solución crea una nueva versión de conciliación mientras preserva la discrepancia original.
Preguntas a aclarar antes de responder
- ¿Qué está dentro del alcance? ¿Autorización, captura, reembolsos, comisiones, pagos, depósitos bancarios o todos ellos?
- ¿Qué zona horaria define las 06:00? ¿La liquidación y la generación de reportes pueden cruzar cambios de horario de verano o días festivos?
- ¿Se pueden obtener los reportes externos de forma incremental? ¿Son estables los nombres de archivo, cursores, versiones y descargas reintentables?
- ¿El pipeline puede ajustar automáticamente el libro mayor? Asume que crea propuestas de ajuste que un flujo de trabajo autorizado aprueba.
- ¿Qué política de FX aplica? Mantén las monedas de transacción, de liquidación y bancarias, y define la fuente del tipo de cambio y su precisión.
- ¿Cuál es el SLA de resolución? Define el escalamiento para discrepancias de alto valor, regulatorias y con impacto en el cliente.
Un marco de respuesta en 30 segundos
“Primero preservaría las tres fuentes en capas sin procesar inmutables, y luego normalizaría monto, moneda, tiempo e IDs externos. Las importaciones son idempotentes por versión de reporte; las claves fuertes coinciden primero, las claves compuestas restringidas en segundo lugar y los resultados inciertos entran a una cola de revisión. Cada lote obtiene controles a nivel de fila, agrupados y de totales. Las discrepancias utilizan una máquina de estados auditable y se solucionan mediante asientos de ajuste aprobados. Programo hacia atrás desde la fecha límite, monitoreo completitud de archivos, latencia, tasa de coincidencia, monto abierto y reejecuciones, y pongo a prueba archivos duplicados, reembolsos tardíos, liquidaciones parciales y cambios de FX”.
Análisis detallado paso a paso
Paso 1: Definir el modelo de hechos y la ventana contable
Crea hechos inmutables internal_entry, provider_entry y bank_entry. Conserva el hash del archivo de origen, el número de fila, el origen, la hora de ingesta, la versión del reporte, la fecha de negocio y la fecha de liquidación. Almacena el dinero como unidades menores enteras, nunca en punto flotante, y exige la moneda. Separa el estado de la orden del estado de los fondos para que “pago exitoso” no se trate como “efectivo recibido”.
Paso 2: Ingerir de forma idempotente por versión de origen
Escribe primero las descargas en el almacenamiento de objetos, luego valida el tamaño, el hash, la firma y el recuento de filas esperado. Usa source + report_id + version + row_number como clave única. Una descarga duplicada añade un registro de ingesta, pero no puede contabilizar dinero dos veces. Conserva las versiones antiguas del proveedor y registra relaciones de reemplazo en lugar de sobrescribir archivos.
unique_key = source + report_id + version + row_number
if unique_key already exists: record_duplicate_download()
else: persist_raw_row()Paso 3: Construir una capa de normalización reejecutable
Mapea estado, signo del monto, zona horaria, tipo de comisión e IDs externos mediante diccionarios versionados. Cada transformación escribe un normalization_run_id; una instantánea de entrada fija y la versión de reglas hacen que las reejecuciones sean deterministas. Los estados desconocidos, las semánticas de montos negativos y las monedas van a cuarentena en lugar de convertirse en cero por defecto.
Paso 4: Usar coincidencia por capas
La capa uno usa IDs estables de transacción, reembolso y pago del proveedor. La capa dos usa el ID de orden, el monto y una ventana de tiempo permitida dentro del mismo comercio, moneda y fecha de liquidación. La capa tres produce solo candidatos; montos iguales en diferentes monedas, un elemento interno dividido entre varias filas externas y una fila externa dividida entre liquidaciones requieren revisión.
Paso 5: Probar resultados con tres controles
Los controles de fila verifican que cada hecho se coincida a lo sumo una vez. Los controles de grupo comparan recuento y monto por lote, moneda, fecha de liquidación y tipo de comisión. Los controles de totales comparan saldo inicial, entradas, salidas, comisiones, reembolsos y saldo final a través del libro mayor, el reporte del proveedor y los depósitos bancarios. Conserva evidencia para cada capa cuando no coincidan; no muestres una única bandera de “aprobado”.
Paso 6: Convertir las discrepancias en una máquina de estados
Como mínimo, clasifica faltantes, duplicados, discrepancia de montos, discrepancia de comisiones, discrepancia de moneda o FX, desplazamiento de fecha y estado externo desconocido. Los estados pueden ser open, investigating, adjustment_pending, resolved y accepted, con actor, motivo, evidencia y marca de tiempo en cada transición. Las discrepancias de alto valor o normativas necesitan aprobación de dos personas; la automatización solo puede crear una propuesta.
Paso 7: Manejar datos tardíos, reembolsos y liquidación parcial
Cuando un reporte se retrasa, cierra solo el alcance recibido y mantén el lote incompleto. No conviertas una ausencia temporal en un registro faltante permanente. Los reembolsos y las disputas pueden llegar después de la fecha de la transacción, por lo que debes registrar la fecha del evento y la fecha de liquidación por separado. Conserva las relaciones de uno a muchos cuando una transacción se divide entre varios desembolsos; un saldo igual no borra filas no conciliadas.
Paso 8: Planificar recuperación, reejecuciones y auditoría
Guarda los manifiestos de archivos de entrada, la hora de la instantánea, la versión de reglas, los resultados de coincidencia y las discrepancias de salida para cada ejecución. Reinicia desde la última etapa exitosa, aísla la salida de la reejecución por ID de ejecución y combina por claves únicas. Conserva archivos sin procesar, hashes, versiones de reportes, decisiones humanas y comprobantes de ajuste para trazabilidad por lote, transacción o discrepancia. Stripe también separa saldos, transacciones y desembolsos y recomienda usar un ID de desembolso para recuperar sus transacciones de saldo, demostrando por qué un lote de liquidación externo no puede reducirse a un único total.
Compensaciones y límites
Compensación 1: Claves fuertes o mayor tasa de coincidencia
La automatización basada en claves fuertes puede coincidir menos filas, pero su costo de falsos positivos está controlado. Ventanas de monto y tiempo más amplias mejoran la cobertura mientras aumentan la probabilidad de fusionar transacciones similares. Versiona umbrales, ventanas y alternativas de reserva; envía cada resultado no determinista a revisión.
Compensación 2: Lote diario o casi en tiempo real
Los lotes T+1 son más fáciles de reproducir y auditar. Los flujos casi en tiempo real detectan problemas de alto valor más temprano, pero deben manejar versiones de reportes, datos tardíos y eventos duplicados. Utiliza el lote como la conclusión contable y el flujo como una capa de alertas.
Compensación 3: Ajuste automático o aprobación humana
Las diferencias pequeñas, explícitas y reversibles pueden utilizar automatización restringida. Las diferencias de alto valor, de moneda, de cargos duplicados y normativas requieren aprobación humana. Ambas vías preservan los hechos originales y los comprobantes de ajuste en lugar de editar el historial.
Simulacros de fallas y plan de evolución
Simulacro 1: Archivos y filas duplicados
Entrega el mismo reporte tres veces y verifica que el hash del archivo, la versión del reporte y las claves de fila eviten la contabilización duplicada. Coloca una transacción en dos versiones y verifica que la relación de versiones y la regla de selección sean explicables.
Simulacro 2: Reembolso tardío y liquidación parcial
Entrega un reembolso dos días después de la liquidación y divide una orden entre dos desembolsos. Verifica que las fechas de transacción, liquidación y depósito permanezcan separadas, y que una nueva ejecución cierre la discrepancia sin alterar las ejecuciones históricas.
Simulacro 3: Página faltante y tipo de cambio incorrecto
Elimina una página del reporte o reemplaza la tabla de tipos de cambio. Los controles de recuento de filas, hash, totales y moneda deben bloquear la publicación y marcar el lote como pendiente de completitud en lugar de declararlo conciliado.
Errores comunes y preguntas de seguimiento
Error 1: Comparar solo tres totales
Totales iguales pueden ocultar una fila faltante y una duplicada. Mantén coincidencias a nivel de fila, controles agrupados y controles de totales.
Error 2: Almacenar dinero como punto flotante
El error de punto flotante crea falsas diferencias. Utiliza unidades menores enteras o decimal fijo y almacena siempre la moneda.
Error 3: Sobrescribir reportes antiguos
Sobrescribir destruye la evidencia de auditoría y reejecución. Almacena reportes de forma inmutable y expresa las correcciones como versiones.
Error 4: Contabilizar automáticamente coincidencias difusas
Monto igual y tiempo cercano no prueban identidad. Pon los resultados difusos en revisión con evidencia de candidatos.
Error 5: Tratar el éxito del pago como un depósito bancario
El estado del pago, la liquidación del proveedor y el depósito bancario son hechos diferentes. Modélalos por separado y conéctalos mediante relaciones de lote.
Error 6: Ignorar la generación de reportes y la zona horaria
Los reportes pueden estar disponibles después de la liquidación; la zona horaria y los días festivos generan falsos registros faltantes. Programa a partir de los compromisos de disponibilidad de la fuente y almacena la zona horaria explícitamente.
Error 7: Editar filas históricas del libro mayor para solucionar un problema
Las ediciones directas eliminan la evidencia original. Utiliza un asiento de ajuste aprobado vinculado a la discrepancia y a la nueva ejecución.