Cuando el CSV de origen se edita mientras la conciliación ya está en marcha, todos los resultados de cruce posteriores quedan en duda.
El problema no es solo la edición visible. Es la pérdida de una referencia confiable.
Puede que se haya eliminado una fila. Puede que Excel haya reinterpretado una fecha. Puede que un ID de transacción haya perdido su cero a la izquierda. Puede que una fila en blanco haya desplazado la importación. Puede que un filtro haya ocultado registros antes de guardar el archivo. La conciliación puede seguir produciendo un resultado, pero ese resultado ya no prueba lo que dice probar.
No repares el archivo editado primero. Fija el estado actual, recupera o vuelve a exportar el CSV de origen sin cambios, compara las dos versiones estructuralmente y vuelve a ejecutar la conciliación desde la referencia limpia.
Esa es la forma más segura de recuperar una conciliación cuando el CSV de origen se editó durante el proceso, sin arrastrar un cambio de datos oculto al informe final.
Clasifica el error antes de cambiar cualquier cosa
Lo primero es determinar si la conciliación falló por una diferencia financiera real o porque el archivo de origen cambió por debajo del proceso.
Revisa esta tabla antes de tocar fórmulas, mapeos, filtros o notas de cruce manual.
| Síntoma | Tipo probable | Primer control | Corregir o conservar |
|---|---|---|---|
| El recuento de coincidencias cambió después de guardar el CSV | Archivo de origen editado | Compara el recuento de filas y referencias con la exportación original | Corregir restaurando la referencia de base |
| Los totales cambiaron pero el recuento de filas es el mismo | Monto incorrecto o signo invertido | Compara los totales de la columna de montos y los valores negativos | Corregir antes de volver a ejecutar |
| Las mismas transacciones aparecen en fechas distintas | Fecha incorrecta | Compara la fecha más antigua, la más reciente y el formato de fecha | Corregir si la fecha fue alterada; conservar solo diferencias de timing reales |
| Algunas referencias ahora muestran valores más cortos | Archivo de origen editado | Verifica ceros a la izquierda e IDs largos | Corregir reexportando, no tipeando los IDs de nuevo |
| La conciliación excluye filas que antes sí incluía | Error de alcance o de filtro | Revisa filtros, filas ocultas y rango de fechas | Corregir el límite del archivo de origen |
| Una transacción aparece dos veces después de la edición | Registro duplicado | Cuenta claves duplicadas y pares monto-fecha duplicados | Corregir antes de volver a ejecutar |
| Falta una transacción esperada | Registro faltante | Busca primero por referencia, luego por monto y fecha cercana | Corregir si fue omitida; conservar solo si queda fuera del alcance |
Esta distinción importa porque las diferencias de timing y las ediciones en los datos no se manejan de la misma manera.
Una diferencia de timing se puede conservar. Un depósito en tránsito, una liquidación de tarjeta pendiente o un pago que llega un día después puede quedarse en la conciliación como diferencia justificada.
Un archivo de origen editado no se puede conservar como explicación. Hay que corregirlo o reemplazarlo antes de confiar en el resultado de la conciliación.
Fija los archivos tal como están ahora
Antes de recuperar cualquier cosa, preserva el estado del trabajo.
Haz una copia de:
- El CSV de origen editado
- El segundo archivo usado en la comparación
- El libro de trabajo de conciliación o el archivo de trabajo
- Cualquier exportación generada desde la conciliación
- Cualquier nota de cruce manual o de excepciones
Renombra el CSV editado para que no se pueda confundir con la exportación de origen. Un nombre de archivo descriptivo es suficiente:
| Archivo | Propósito |
|---|---|
bank-export-edited-do-not-use.csv | Muestra el archivo modificado que causó el problema |
ledger-export-working-copy.csv | Muestra el otro lado de la conciliación |
reconciliation-before-recovery.xlsx | Conserva fórmulas, filtros y notas de revisión manual |
El archivo editado es evidencia. Puede estar mal, pero explica por qué la conciliación actual dejó de ser confiable.
No lo sobreescribas. No sigas trabajando dentro de él. No guardes otra versión encima.
En este punto, el objetivo no es terminar la conciliación rápido. Es detener el movimiento de los datos mientras demuestras qué cambió.
Reconstruye la referencia desde el origen
El camino de recuperación limpio es obtener una exportación nueva sin modificaciones desde el sistema de origen.
Si el CSV vino de un banco, vuelve a descargar la exportación del estado de cuenta para la misma cuenta y el mismo período. Si vino de un procesador de pagos, vuelve a exportar el mismo reporte con los mismos filtros. Si vino de un software contable, exporta el mismo libro mayor o el mismo reporte de transacciones con el mismo rango de fechas, la misma base, la misma moneda y el mismo alcance de cuenta.
La nueva exportación solo se convierte en la referencia de recuperación si coincide con el límite de la comparación original.
Verifica estos campos antes de usarla:
| Control de referencia | Qué comparar | Por qué importa |
|---|---|---|
| Cuenta u origen | Misma cuenta bancaria, libro mayor, plataforma o reporte | Evita comparar el conjunto de datos equivocado |
| Período | Misma fecha de inicio y fin | Evita que diferencias de corte parezcan ediciones |
| Recuento de filas | Total de filas de transacciones, sin encabezados | Detecta filas eliminadas, insertadas o filtradas |
| Recuento de referencias | Referencias de transacciones no vacías | Detecta claves de cruce rotas |
| Rango de fechas | Fecha de transacción más antigua y más reciente | Detecta cambios de alcance o fechas reinterpretadas |
| Total de montos | Movimiento neto o total de la columna de montos relevante | Detecta signos modificados, filas eliminadas o valores editados |
| Recuento de duplicados | IDs de referencia duplicados o combinaciones monto-fecha-referencia duplicadas | Detecta filas copiadas o duplicación en la importación |
| Recuento de filas sin referencia | Filas sin la referencia esperada | Detecta filas que no se pueden cruzar de forma confiable |
Si el sistema de origen cambió desde la primera exportación, el archivo nuevo puede no ser idéntico. Eso no lo hace inútil. Significa que hay que separar los cambios del sistema de las ediciones del archivo.
Por ejemplo, un reporte de procesador de pagos puede incluir ahora un ajuste tardío que no estaba disponible en el momento de la primera exportación. Eso no es lo mismo que alguien editando una celda del CSV. Es un nuevo registro del origen. Márcalo como diferencia de alcance y luego decide si el período de conciliación debe incluirlo.
La referencia es confiable solo cuando puedes justificar su límite: mismo origen, mismo período, mismos parámetros de reporte, mismas columnas y mismo total financiero o cambio justificado.
Compara el CSV editado contra la referencia
Una vez que tengas la exportación limpia, compárala contra el CSV editado antes de volver a ejecutar la conciliación.
No empieces comparando fila por fila. Empieza con los controles estructurales. Son más rápidos y descartan categorías enteras de errores.
| Control | Referencia limpia | CSV editado | Qué significa una diferencia |
|---|---|---|---|
| Filas de transacciones | 4,812 | 4,809 | Se eliminaron, filtraron o perdieron filas |
| Referencias no vacías | 4,812 | 4,780 | Se alteraron o borraron claves de cruce |
| Referencias duplicadas | 0 | 3 | Se copiaron filas o se dañaron IDs |
| Fecha más antigua | 2026-05-01 | 2026-05-02 | Faltan o están filtrados los registros del primer día |
| Fecha más reciente | 2026-05-31 | 2026-05-31 | El límite final parece intacto |
| Monto neto | 184,229.10 | 184,010.55 | Uno o más montos cambiaron o faltan filas |
Esta tabla indica dónde buscar a continuación.
Si el recuento de filas cambió, busca filas faltantes o insertadas. Si el recuento de referencias cambió, inspecciona la columna de referencia. Si los totales cambiaron, compara la columna de montos. Si el rango de fechas cambió, verifica si Excel convirtió las fechas o si un filtro eliminó las fechas límite.
Las ediciones comunes en un CSV son silenciosas:
- Los IDs numéricos largos se convierten a notación científica
- Los ceros a la izquierda se eliminan de las referencias
- Las fechas cambian entre el formato día-mes y mes-día
- Los montos almacenados como texto se convierten a números
- Los signos negativos pasan de una columna de débito separada a una sola columna de monto
- Se insertan filas en blanco encima del encabezado
- Los filtros ocultos se guardan en el archivo de trabajo
- Se escriben notas adicionales en una columna que la importación usa para el cruce
- Las filas se ordenan sin seleccionar el conjunto de datos completo
Esta última es especialmente destructiva. Si se ordena una sola columna de forma independiente, las fechas, las referencias y los montos pueden quedar asociados a las filas incorrectas. El archivo puede seguir pareciendo completo. El recuento de filas y el total pueden incluso mantenerse cercanos. Pero las relaciones entre transacciones están rotas.
Si encuentras ese tipo de edición, no intentes reparar el CSV manualmente. Reexporta y vuelve a ejecutar.
Ubica las filas exactamente modificadas, solo después de estabilizar la estructura
La comparación fila por fila viene después de que los controles estructurales estén satisfechos.
Usa el identificador más sólido primero:
- ID de transacción o referencia del origen
- Monto exacto más fecha exacta
- Monto exacto más fecha cercana
- Descripción o concepto
- Posición entre las filas circundantes
La referencia es la mejor clave cuando está intacta. Monto más fecha es útil cuando las referencias faltan o están dañadas, pero es una clave más débil. Dos transacciones pueden compartir el mismo monto en la misma fecha. El concepto es aún más débil porque los bancos y los procesadores reescriben las descripciones entre exportaciones.
Arma una tabla de comparación como esta:
| Referencia | Monto de referencia | Monto editado | Fecha de referencia | Fecha editada | Estado |
|---|---|---|---|---|---|
| TXN-10481 | 242.18 | 242.18 | 2026-05-08 | 2026-05-08 | Sin cambios |
| TXN-10482 | 119.00 | 119.00 | 2026-05-08 | 2026-08-05 | Fecha cambiada |
| TXN-10483 | 84.50 | 48.50 | 2026-05-09 | 2026-05-09 | Monto cambiado |
| TXN-10484 | 300.00 | Faltante | 2026-05-09 | Faltante | Faltante en el archivo editado |
Con eso, el trabajo de recuperación se vuelve preciso.
Ya no dices «El CSV fue editado.» Dices: «La versión editada cambió una fecha, cambió un monto y eliminó una fila.» Ese es el nivel de detalle necesario antes de decidir si se puede salvar la conciliación anterior.
Si el problema se reduce a un registro faltante entre dos archivos financieros, usa el mismo orden de búsqueda descrito en cómo encontrar una transacción faltante entre dos archivos financieros rápidamente: referencia primero, luego monto y fecha exactos, luego fechas cercanas, luego duplicados o problemas de alcance.
Decide si la conciliación anterior sigue siendo válida
La mayoría de las veces, una conciliación debe tratarse como inválida después de una edición en el CSV de origen.
Hay excepciones, pero son estrechas.
| Qué cambió | ¿La conciliación anterior es confiable? | Acción de recuperación |
|---|---|---|
| Solo el nombre del archivo | Generalmente sí | Confirma el hash o los controles estructurales y continúa |
| Solo el orden de las filas, con todas las columnas mantenidas juntas | A veces | Vuelve a ejecutar el cruce si se usó la posición de fila en algún lugar |
| Filtro oculto aplicado, filas del origen sin cambios | No | Elimina el filtro o reexporta, luego vuelve a ejecutar |
| Una columna de notas agregada fuera del rango de cruce | A veces | Confirma que el mapeo de importación no se desplazó |
| Monto, fecha o referencia editados | No | Reexporta y vuelve a ejecutar |
| Filas eliminadas o insertadas | No | Reexporta y vuelve a ejecutar |
| Columnas renombradas o movidas | No hasta verificar el mapeo | Remapea y vuelve a ejecutar desde la referencia |
| IDs reformateados por Excel | No | Reexporta con los IDs preservados como texto |
La pregunta clave es si la edición tocó algún campo usado para el cruce, el alcance o el cálculo de totales.
Esos son los campos de control:
- ID de transacción
- Referencia
- Fecha
- Monto
- Moneda
- Cuenta
- ID de cliente o proveedor
- Indicador de débito o crédito
- Estado
- Período del reporte
Si cambió alguno de estos campos, el resultado de la conciliación anterior no puede sostenerse. El resultado puede seguir siendo cercano, pero cercano no es lo mismo que listo para auditoría.
Si la conciliación ya produjo un resultado incorrecto y necesitas identificar el punto de quiebre, aplica la misma lógica de referencia primero descrita en por qué tu conciliación estaba mal y cómo encontrar dónde se rompió. Parte del último estado confiable y prueba qué cambió después de ese punto.
Vuelve a ejecutar desde la referencia limpia
Una vez que tengas el CSV de origen limpio, vuelve a ejecutar la conciliación desde el principio.
Usa el mismo segundo archivo que antes, a menos que ese archivo también haya cambiado. Si ambos lados cambiaron, fija las dos versiones editadas y reexporta las dos referencias. No mezcles un archivo limpio con un archivo de trabajo sin verificar.
La nueva ejecución debe seguir este orden:
| Paso | Acción | Control |
|---|---|---|
| 1 | Carga el CSV de origen limpio | Confirma el recuento de filas, el rango de fechas y el total de montos |
| 2 | Carga el archivo de comparación | Confirma los mismos controles en el segundo archivo |
| 3 | Confirma las claves de cruce | Usa la referencia primero donde esté disponible |
| 4 | Ejecuta el cruce | Mantén separados los estados: coincidencias, faltantes, duplicados y diferencias de monto |
| 5 | Compara el resultado con la ejecución fallida | Explica cada diferencia material |
| 6 | Guarda el reporte recuperado | Mantenlo separado de la versión fallida |
No copies las decisiones de cruce manual de la ejecución fallida a menos que cada decisión siga siendo válida contra la referencia limpia.
Las notas manuales son evidencia útil, pero no son prueba. Una nota que decía «cruzado por monto y fecha» pudo haber sido verdadera contra el archivo editado y falsa contra el archivo limpio. Reverifica cualquier ajuste manual que haya afectado el resultado final.
El reporte recuperado debe mostrar:
- El archivo CSV de origen limpio utilizado
- El archivo de comparación utilizado
- El recuento de filas de ambos archivos
- El rango de fechas de ambos archivos
- El monto total o el movimiento neto de ambos archivos
- Filas conciliadas
- Filas faltantes
- Duplicados
- Diferencias de monto
- Diferencias de fecha
- Cualquier diferencia de timing real conservada
- Cualquier error corregido antes del cierre
Este resultado es más sólido que la conciliación original porque documenta el camino de recuperación. No oculta el error. Prueba cómo se contuvo.
No corrijas el CSV editado a menos que no haya fuente para reexportar
A veces no hay exportación limpia disponible. El portal bancario puede ya no ofrecer el mismo archivo. El sistema de origen puede haber cambiado. El cliente puede haber enviado un CSV sin ruta de descarga directa.
Si no hay fuente para reexportar, trata el CSV editado como evidencia dañada, no como un archivo de trabajo normal.
Usa todos los registros independientes disponibles:
- Estado de cuenta bancario en PDF
- Reporte de transacciones de la plataforma
- Exportación del libro mayor contable
- Copia del CSV guardada anteriormente
- Archivo adjunto de correo electrónico
- Historial de descargas
- Resultado de la conciliación desde la última ejecución confiable
- Archivo original enviado por el cliente, si está disponible
Luego reconstruye un archivo de origen controlado a partir de la evidencia. Márcalo claramente como reconstruido. No lo presentes como la exportación original.
El archivo reconstruido necesita un registro de revisión:
| Elemento reconstruido | Evidencia utilizada | Cambio realizado | Nota del revisor |
|---|---|---|---|
| Fecha de TXN-10482 | Estado de cuenta PDF y exportación del libro mayor | Fecha restaurada al 2026-05-08 | El CSV editado mostraba 2026-08-05 |
| Monto de TXN-10483 | Reporte del procesador | Monto restaurado a 84.50 | El CSV editado mostraba 48.50 |
| Fila TXN-10484 | Archivo adjunto de exportación previa | Fila faltante reinsertada | Fila ausente en el CSV editado |
Esto es más lento que reexportar. Debe ser el último recurso, no el camino por defecto.
Qué documentar antes de cerrar la recuperación
La nota de cierre de la recuperación debe ser breve y específica.
Debe responder cinco preguntas:
| Pregunta | Respuesta a documentar |
|---|---|
| ¿Qué cambió? | El CSV de origen fue editado después de iniciar el trabajo de conciliación |
| ¿Cómo se detectó? | El recuento de filas, de referencias, el rango de fechas, los totales o la comparación de filas mostró diferencias |
| ¿Qué referencia se usó? | La reexportación sin modificaciones o el archivo de origen reconstruido |
| ¿Qué se volvió a ejecutar? | La conciliación completa desde la referencia verificada |
| ¿Qué queda abierto? | Solo diferencias de timing reales o excepciones sin resolver |
No escribas un diario de cada intento. La nota de cierre debe ayudar a alguien a confiar en el resultado recuperado.
Una buena nota se lee así:
El CSV bancario original fue editado durante la conciliación. El archivo editado tenía tres filas menos, un monto cambiado y una fecha cambiada en comparación con el estado de cuenta bancario reexportado. La conciliación se volvió a ejecutar usando el CSV de origen reexportado para la misma cuenta y el mismo período. El reporte final separa las filas conciliadas, los registros faltantes y las diferencias de timing. Ningún resultado del CSV editado se trasladó al reporte recuperado sin reverificación.
Eso es suficiente.
El lector puede ver el quiebre, la referencia de recuperación y el control final.
Dónde termina la recuperación
La recuperación está completa cuando la conciliación final puede trazarse hasta un archivo de origen confiable.
Eso significa:
- El CSV editado está preservado pero no se usa como referencia final
- La exportación limpia o el archivo reconstruido están claramente identificados
- El recuento de filas, de referencias, el rango de fechas, los totales, los duplicados y las filas sin referencia están verificados
- La conciliación se volvió a ejecutar desde la referencia verificada
- Las diferencias de timing están separadas de los errores
- Los ajustes manuales de la ejecución fallida están reverificados
- El reporte final explica qué cambió y qué sigue sin resolver
Detente ahí.
No sigas ajustando el archivo antiguo hasta que los totales coincidan. No fuerces una línea de ajuste porque la diferencia es pequeña. No cierres desde un archivo cuyo historial de origen no es claro.
El CSV editado causó un problema de integridad de datos. La recuperación no está terminada cuando los números se ven cercanos. Está terminada cuando el origen, el alcance y la nueva ejecución se pueden defender.
