Zoho marca una factura como pagada en el momento en que captura el pago del cliente. El archivo CSV de liquidación de tu pasarela de pago registra cuándo ese pago se agrupó en un lote, se restaron las comisiones y se envió el dinero. No son el mismo evento. Por eso los dos archivos parecen relacionados pero no cuadran línea por línea.

El error es asumir que los dos archivos describen el mismo nivel de actividad. No es así. Uno refleja la facturación. El otro refleja la liquidación. Si los comparas línea por línea sin distinguir esos roles, pagos correctos parecerán ausentes, duplicados o tardíos.

La comparación correcta entre registros de facturas Zoho y archivos CSV de liquidación empieza por dejar de tratar los dos archivos como si fueran el mismo registro. Primero, decide qué evento registra cada archivo. Después, haz la correspondencia al nivel correcto: pago de factura, transacción de pasarela o lote de liquidación.

Cuando haces eso, las discrepancias se vuelven explicables. Puedes demostrar por qué una factura se pagó un día y se liquidó otro, por qué el monto se redujo por comisiones, por qué se agrupó con otros pagos o por qué quedó retenido.

Por qué los dos archivos no coinciden antes de que haya un error

Un registro de facturas Zoho responde típicamente a preguntas como estas:

  • ¿Qué factura se emitió?
  • ¿Qué cliente la pagó?
  • ¿Cuándo se registró el pago?
  • ¿Qué monto bruto se aplicó a la factura?

Un archivo CSV de liquidación de pasarela responde preguntas distintas:

  • ¿Qué transacciones con tarjeta o en línea se procesaron?
  • ¿Cuáles de esas transacciones fueron exitosas, fallidas, reembolsadas o revertidas?
  • ¿Qué comisiones se descontaron?
  • ¿En qué fecha liquidó la pasarela el dinero a tu cuenta bancaria?

Esa diferencia importa porque una sola factura puede generar varios eventos en la pasarela, y varios eventos de pasarela pueden caer en un mismo lote de liquidación.

ArchivoQué representaColumnas clave habitualesQué debe coincidir
Registro de facturas ZohoLa factura y el pago aplicado a ellaNúmero de factura, cliente, fecha de pago, monto recibido, estadoActividad de pago bruto a nivel de factura
Exportación de transacciones de pasarelaEventos individuales de pago con tarjeta o en líneaReferencia del comerciante, ID de transacción de pasarela, fecha de procesamiento, bruto, comisión, estadoEl evento de pago en sí
Exportación de liquidación de pasarelaLo que la pasarela agrupó y transfirióFecha de liquidación, ID de desembolso, ID de transacción, bruto, comisión, netoMovimiento de efectivo e impacto de comisiones

Si tu archivo CSV de pasarela es de nivel transaccional, muchas veces puedes vincular cada pago a una factura o referencia de pago de Zoho. Si tu archivo CSV de pasarela es solo un resumen de liquidación, no puedes forzar una correspondencia factura por línea. En ese caso, comparas totales agrupados y explicas el puente entre las facturas brutas y la liquidación neta.

Es la misma disciplina que aparece en comparar archivos CSV bancarios sin fórmulas: primero haz coincidir el evento correcto con el evento correcto, luego revisa las excepciones que queden.

El problema de referencia que genera la mayoría de las discrepancias falsas

El nombre de los archivos no es el problema real. Las claves de referencia sí lo son.

Zoho y tu pasarela de pago rara vez identifican el mismo pago de la misma manera. Un archivo puede mostrar INV-1048. Otro puede mostrar un número de pago. Otro puede mostrar un ID de procesador que no significa nada hasta que lo rastreas hasta el pago del cliente. Si eliges la clave incorrecta, la comparación falla aunque todos los pagos estén presentes.

La forma más segura de trabajar con los identificadores es separarlos por función:

IdentificadorDónde aparece habitualmenteQué indicaQué no prueba
Número de facturaRegistro de facturas ZohoQué factura se le cobró al clienteQue el dinero se liquidó
Referencia de pago o número de pagoRegistro o exportación de pagos de ZohoQué pago aplicó Zoho a la facturaQue la pasarela lo depositó en el mismo período
ID de transacción de pasarelaArchivo de pasarelaQué evento del procesador ocurrióA qué desembolso bancario pertenece, salvo que el archivo incluya esa información
ID de liquidación o de desembolsoArchivo CSV de liquidación de pasarelaQué lote llegó a liquidación en efectivoA qué factura corresponde cada línea, salvo que haya una referencia del comerciante

Por eso muchos cierres de mes salen mal. El operador intenta hacer coincidir el número de factura con el ID de liquidación, no obtiene resultados y empieza a corregir datos que no tienen ningún error.

Una jerarquía más confiable:

  1. Haz la correspondencia por factura o referencia del comerciante si los dos archivos la contienen.
  2. Si no, concilia la referencia de pago de Zoho con la referencia de transacción de la pasarela.
  3. Si ningún archivo expone una referencia compartida, usa el monto más una ventana de fechas ajustada y revisa manualmente las filas restantes.
  4. Si el archivo de pasarela es solo un resumen de desembolsos, deja de intentar crear correspondencias a nivel transaccional desde ese archivo. Agrega en su lugar.

Ese último punto ahorra horas. Un resumen de liquidación no omite los números de factura por error. Es un reporte distinto.

Compara los archivos en el orden en que se movió el dinero

No necesitas un modelo complejo para conciliar estas exportaciones. Necesitas que el orden de los eventos se mantenga.

Paso 1: separa la actividad de facturación de la actividad de liquidación

Filtra la exportación de Zoho a los pagos que importan en el período. Buscas facturas con pagos registrados, no todas las facturas emitidas.

Conserva estas columnas si tu exportación las incluye:

Campo de ZohoPor qué importa
Número de facturaReferencia principal del negocio
Nombre o ID del clienteApoyo secundario para la correspondencia
Fecha de facturaContexto útil, no la fecha de liquidación
Fecha de pagoMejor punto de comparación antes de la fecha de liquidación
Monto recibidoMonto bruto aplicado a la factura
Estado del pagoAyuda a aislar elementos fallidos o pendientes
Referencia de pago / referencia de pasarelaMejor puente hacia el archivo de pasarela cuando está disponible

Luego revisa el archivo CSV de pasarela y decide qué es realmente. No asumas nada por el nombre del archivo. Si contiene bruto, comisión, neto, estado, fecha de procesamiento y un ID de transacción por fila, es de nivel transaccional. Si contiene una fila por lote con fecha de desembolso y total neto, es de nivel de liquidación.

Esa distinción determina cómo debe verse una comparación válida.

Paso 2: concilia los pagos exitosos antes de tocar las comisiones

El primer paso más limpio trabaja solo con pagos brutos exitosos.

Ignora las comisiones por ahora. Ignora el agrupamiento en lotes por ahora. Primero haz una sola pregunta:

¿Qué pagos registrados en Zoho aparecen como transacciones exitosas en la pasarela?

Tu primera tabla de correspondencia debería verse así:

Factura/pago ZohoMonto bruto ZohoReferencia de transacción de pasarelaMonto bruto de pasarelaEstado
INV-1048 / ref. de pago250.00tx_7843250.00Conciliado
INV-1051 / ref. de pago400.00tx_7848400.00Conciliado
INV-1057 / ref. de pago125.00Ausente en el archivo de pasarela

Eso separa de inmediato los problemas reales de los desfases en la liquidación. Si el pago existe en Zoho pero no hay una transacción de pasarela exitosa que corresponda, puede que estés viendo:

  • Un pago registrado manualmente en Zoho
  • Una transacción de pasarela fallida o pendiente
  • Un pago cobrado por otro canal
  • Una entrada duplicada o incorrecta en la exportación de Zoho

No mezcles esos problemas con preguntas de fechas de liquidación. Son excepciones distintas.

Paso 3: concilia bruto a neto agrupando las filas correctas

Una vez que los pagos exitosos coincidan, pasa al efecto de la liquidación.

Aquí es donde los operadores suelen perder el hilo. Intentan comparar un pago bruto de Zoho de 400.00 con una línea de liquidación de pasarela de 388.40 y lo marcan como una discrepancia de monto. No es una discrepancia de monto si los 11.60 que faltan son la comisión que descontó la pasarela.

Agrupa las filas de la pasarela por lote de liquidación o fecha de desembolso y calcula:

Vista por lote de pasarelaQué totalizar
Transacciones liquidadas brutasSuma de los montos de pagos exitosos
Comisiones de procesamientoSuma de las comisiones de pasarela
Reembolsos o reversiones dentro del loteSuma por separado
Liquidación netaBruto menos comisiones y descuentos

Construye ese total por lote con SUMAR.SI.CONJUNTO antes de comparar al nivel correcto:

Fórmula
=SUMAR.SI.CONJUNTO(Pasarela!$C:$C,Pasarela!$E:$E,B2,Pasarela!$D:$D,"Exitoso")

La columna C es el monto bruto, la columna E es la fecha de desembolso o el ID del lote, B2 es la fecha en tu fila de resumen, la columna D es el estado de la transacción. Si el archivo usa un ID de desembolso en lugar de una fecha, reemplaza los criterios de fecha por esa columna y su valor.

Ahora compara al nivel correcto:

  • El registro de facturas Zoho explica los pagos brutos de los clientes.
  • El archivo CSV de liquidación de pasarela explica cómo esos pagos brutos se convirtieron en efectivo neto.

Si la pasarela agrupa varios pagos de clientes en un solo desembolso, tu conciliación tiene que hacer lo mismo. La correspondencia uno a uno se detiene en el nivel transaccional. La liquidación en efectivo suele ser de uno a varios.

Paso 4: usa ventanas de fechas que reflejen el tiempo de liquidación

La fecha de pago en Zoho suele ser la fecha en que el cliente pagó. La fecha de liquidación en el archivo CSV de pasarela es cuando el procesador liberó los fondos. Esas fechas muchas veces difieren entre uno y varios días hábiles.

No es ruido. Es el proceso.

Si comparas un pago Zoho del 31 de marzo con una liquidación del 1 de abril y los fuerzas al mismo bloque diario, las excepciones de cierre de mes se van a multiplicar sin motivo. Usa la fecha de pago para confirmar que la transacción ocurrió. Usa la fecha de liquidación para confirmar cuándo se movió el efectivo.

Es el mismo patrón que aparece en conciliar exportaciones de facturas con estados de cuenta bancarios mensuales: la fecha de actividad y la fecha de efectivo están relacionadas, pero no son intercambiables.

Qué significan realmente las discrepancias más comunes

La mayoría de las diferencias sin explicación caen en una lista corta. El valor no está en encontrarlas. El valor está en clasificarlas correctamente para dejar de perseguir falsos problemas.

Lo que vesLo que suele significarQué hacer
Pago Zoho presente, sin correspondencia en pasarelaPago manual, cargo fallido, período incorrecto o duplicado en ZohoVerifica el método de pago, el estado y el filtro de período
Transacción de pasarela presente, sin pago en ZohoPago capturado pero no aplicado en Zoho, o importado tardeRevisa los pagos sin aplicar y el proceso de registro
Bruto coincide, neto no coincideComisión de pasarela descontadaConcilia la columna de comisiones por separado
Línea de liquidación menor a lo esperadoReembolso, contracargo, retención de reserva o comisión descontada dentro del loteDesglosa la liquidación en sus componentes antes de comparar
Una línea de pasarela cubre varias facturasLote de pasarela o desembolso combinadoAgrega los pagos Zoho al mismo nivel de lote
Las fechas difieren entre uno y tres días hábilesDesfase de liquidación normalClasifica como diferencia de tiempo, no como pago faltante
El mismo monto aparece dos veces en ZohoPago duplicado o aplicación doble de facturaRevisa los IDs de pago y el historial de estados

Los reembolsos merecen atención especial porque rompen la lógica en los dos sentidos. Un reembolso puede reducir una liquidación posterior aunque la factura original se haya pagado y conciliado antes. Si solo comparas las facturas del período actual con las liquidaciones del mismo período, el reembolso parece un faltante sin explicación. No lo es. Es un evento posterior que impacta una venta anterior.

Los contracargos y las reversiones se comportan igual. Forman parte de la conciliación, pero no prueban que el registro original de la factura fuera incorrecto.

Otro problema frecuente es la liquidación parcial. El cliente paga una factura completa. La pasarela liquida una parte ahora y otra después por reglas de retención de reserva, calendario de desembolsos o cortes de procesamiento. En ese caso, la factura está totalmente pagada desde el punto de vista de Zoho, mientras que el movimiento de efectivo queda dividido entre varias líneas de liquidación. La comparación de archivos tiene que preservar esa distinción.

Un proceso mensual práctico que produce una respuesta defendible

Si esta conciliación se repite cada mes, usa siempre la misma secuencia. El objetivo no es una hoja de cálculo ingeniosa. Es un reporte que puedes explicar sin tener que reabrir los archivos originales.

1. Construye un conjunto de pagos Zoho limpio

Exporta solo el período relevante y conserva una fila por evento de pago cuando sea posible. Elimina las facturas abiertas sin actividad de pago. Conserva el número de factura, la fecha de pago, el monto, el cliente y todos los campos de referencia de pago.

2. Construye un conjunto de datos de pasarela limpio

Separa los datos de la pasarela en vistas transaccional y de liquidación si ambas existen. Si solo tienes un archivo, identifica cuál es y no le pidas que responda la pregunta equivocada.

3. Concilia la actividad de pago bruto

Usa la mejor referencia compartida disponible. Si falta una clave directa, compara por monto, cliente y una ventana de fechas de procesamiento ajustada. Revisa manualmente las filas restantes en lugar de ampliar la regla hasta que pasen correspondencias incorrectas.

4. Explica el puente de bruto a neto

Crea un resumen corto como este:

Elemento del puenteMonto
Pagos brutos Zoho conciliados12,450.00
Comisiones de pasarela-362.10
Reembolsos en el período de liquidación-180.00
Contracargo / reversión-95.00
Neto liquidado a efectivo11,812.90

Ese resumen es lo que convierte una comparación confusa en una conciliación defendible.

5. Lista las verdaderas excepciones por separado

No las entierres en los totales. Muéstralas línea por línea:

ReferenciaProblemaAcción
INV-1057Pago registrado en Zoho, no encontrado en la pasarelaVerifica el método de pago o el error de registro
tx_7910Pago de pasarela encontrado, no aplicado en ZohoRevisa el cobro sin aplicar
Batch 2026-03-31Neto inferior al bruto por reembolsoConfirma el registro del reembolso

En ese punto tienes una respuesta estructurada:

  • Qué pagos de facturas se conciliaron
  • Qué elementos son diferencias de tiempo
  • Qué descuentos explican el paso de bruto a neto
  • Qué excepciones requieren corrección

Eso es suficiente para un cierre de mes, un reporte a clientes o un respaldo de auditoría. Una hoja de cálculo con colores y la mitad de las filas resaltadas no lo es.

Qué debe probar la conciliación terminada

Una conciliación entre registros de facturas Zoho y archivos CSV de liquidación de pasarela debe probar cuatro cosas:

  1. Los pagos de clientes registrados en Zoho son transacciones reales de pasarela o están marcados intencionalmente como otro método de pago.
  2. Las transacciones de pasarela fueron liquidadas, reembolsadas, revertidas o siguen pendientes.
  3. Las comisiones y descuentos explican la diferencia entre los pagos brutos de facturas y el efectivo neto.
  4. Las filas sin conciliar que quedan son pocas, revisables individualmente y resolvibles con una acción específica.

Si tu resultado no puede mostrar esas cuatro respuestas, la conciliación está incompleta.

La mayoría de los equipos se atascan porque intentan que una sola tabla sirva para todo. No puede. Los registros de facturas prueban la facturación y la aplicación de pagos. Los datos de transacciones de pasarela prueban la actividad del procesador. Los archivos CSV de liquidación prueban cómo esa actividad se convirtió en efectivo. Una vez que cada archivo tiene una función, la conciliación deja de pelear contigo.

Cuándo esta conciliación mensual debería salir de la hoja de cálculo

Este proceso funciona a mano cuando los archivos son pequeños y las excepciones son pocas. Se vuelve costoso cuando cada cierre implica exportar los datos de Zoho de nuevo, reconstruir las claves de correspondencia, separar las comisiones de los pagos brutos y reescribir las mismas notas de excepciones.