Las fechas no están mal. Stripe registra cada transacción en UTC; tu estado de cuenta bancario CSV registra el día en que los fondos se acreditaron en hora local. Cuando un pago cae cerca de la medianoche, eso produce dos días de calendario distintos. Y cuando Stripe agrupa varias transacciones en una sola transferencia, la comparación fila a fila falla todavía más rápido.
Por eso puedes ver un cargo de Stripe del 31 de mayo, una línea bancaria del 1 de junio, y estar mirando el mismo movimiento de dinero. La discrepancia casi nunca es dinero faltante. Es una combinación de diferencia horaria, tiempos de liquidación y el hecho de que las filas de transacciones de Stripe no son lo mismo que las líneas de un estado de cuenta bancario.
Primer diagnóstico: ¿qué tipo de discrepancia de fechas tienes?
Antes de cambiar formatos en Excel, identifica cuál es tu caso. La misma discrepancia puede venir de varias causas distintas, y solo algunas son problemas puros de UTC.
| Lo que ves en pantalla | Cómo lo registra Stripe | Cómo lo registra el otro archivo | Qué significa |
|---|---|---|---|
2026-05-31 23:47:18 UTC en Stripe y 2026-06-01 en el estado de cuenta bancario CSV | Cargo creado al final del día UTC | El acreditamiento bancario en hora local cae después de la medianoche | El mismo evento puede aparecer un día más tarde tras la conversión |
2026-05-01 00:12:44 UTC en Stripe y 2026-04-30 en el estado de cuenta bancario CSV | Cargo creado justo después de la medianoche UTC | La zona horaria al oeste de UTC todavía muestra la noche anterior | El mismo evento puede aparecer un día antes tras la conversión |
2026-05-15 en un export de transferencia de Stripe y 2026-05-17 en el estado de cuenta bancario CSV | Fondos disponibles o transferencia creada en una fecha | El banco acreditó el depósito dos días hábiles después | Esto es tiempo de liquidación, no un error de zona horaria |
01/05/2026 en el estado de cuenta bancario CSV y 2026-05-01 09:14:02 UTC en Stripe | Marca de tiempo ISO con hora | Fecha en texto con orden día/mes ambiguo | No puedes comparar hasta normalizar la fecha bancaria |
| Doce filas de Stripe (ventas, reembolsos y comisiones) contra una sola línea bancaria por el depósito neto | Actividad al nivel de la transacción | Evento de efectivo al nivel del depósito | Nivel de comparación incorrecto, aunque las fechas fueran idénticas |
Solo las dos primeras filas son desplazamientos reales de zona horaria. La tercera es tiempo de liquidación. La cuarta es un problema de importación de fecha como texto. La quinta es la que hace perder más tiempo porque parece un problema de fechas cuando en realidad es un problema de estructura de archivo.
¿Qué fecha de Stripe estás comparando?
Los exports de Stripe no usan una única "fecha de transacción". Stripe expone varias fechas que describen momentos distintos en el ciclo de vida de la transferencia. Si comparas la equivocada con el estado de cuenta bancario, creas la discrepancia antes de que Excel haga nada.
| Campo de Stripe | Qué representa | Para qué usarlo |
|---|---|---|
created | Cuándo se creó la balance transaction en Stripe | Conciliación del historial de transacciones, no del acreditamiento bancario final |
charge_created | Cuándo ocurrió el cargo original | Conciliación de ventas o pedidos, no de depósitos bancarios |
available_on | Cuándo los fondos netos quedan disponibles en el saldo de Stripe | Explicar los tiempos de liquidación dentro de Stripe |
automatic_payout_effective_at | Cuándo Stripe espera que la transferencia llegue al banco | Conciliar un export de transferencia con un depósito bancario |
| Fecha de recepción bancaria | Cuándo el banco confirma el acreditamiento de los fondos | Conciliación final de efectivo |
Este es el paso que muchas guías omiten. Una línea del estado de cuenta bancario es un evento de efectivo. Un export de transacciones de Stripe es un evento de transacción. Un export de conciliación de transferencias se ubica entre los dos. Si exportas un CSV de transacciones de Stripe, tomas la columna created y la comparas directamente con la fecha del estado de cuenta bancario, estás comparando el momento en que el cargo entró en Stripe con el día en que los fondos llegaron al banco. Son dos eventos distintos, incluso antes de considerar UTC.
Por eso el orden correcto es:
- Concilia el depósito bancario con la transferencia de Stripe.
- Concilia el contenido de la transferencia con las transacciones subyacentes de Stripe.
- Concilia esas transacciones con pedidos, facturas o líneas del libro mayor si necesitas justificación al nivel de la transacción.
Si omites la capa intermedia, el problema de zona horaria parece más grande de lo que es.
Convierte la marca de tiempo de Stripe antes de comparar cualquier cosa
Una vez que sabes cuál es el campo correcto del lado de Stripe, conviértelo aplicando la misma lógica de fecha que el archivo bancario. No empieces por el formato. Primero verifica si Excel importó el valor como una fecha-hora real o como texto.
Usa =TIPO(A2) en la celda que contiene la fecha de Stripe.
1significa que Excel reconoce un número de serie de fecha-hora.2significa que Excel ve texto: necesitas analizarlo antes de que cualquier comparación funcione.
Si el valor de Stripe en A2 es texto con el patrón 2026-05-01 23:47:18 UTC, construye la fecha-hora UTC explícitamente:
=FECHA(IZQUIERDA(A2,4),EXTRAE(A2,6,2),EXTRAE(A2,9,2))+TIEMPO(EXTRAE(A2,12,2),EXTRAE(A2,15,2),EXTRAE(A2,18,2))Eso te da la marca de tiempo UTC como valor de fecha-hora de Excel. Luego conviértelo a hora local aplicando el desfase del cuenta. Si tu vista contable es UTC-4, resta cuatro horas:
=FECHA(IZQUIERDA(A2,4),EXTRAE(A2,6,2),EXTRAE(A2,9,2))+TIEMPO(EXTRAE(A2,12,2),EXTRAE(A2,15,2),EXTRAE(A2,18,2))-TIEMPO(4,0,0)Si tu zona horaria de reporte local es UTC+2, suma dos horas:
=FECHA(IZQUIERDA(A2,4),EXTRAE(A2,6,2),EXTRAE(A2,9,2))+TIEMPO(EXTRAE(A2,12,2),EXTRAE(A2,15,2),EXTRAE(A2,18,2))+TIEMPO(2,0,0)Una vez que la marca de tiempo local es correcta, redúcela a la fecha de calendario si el estado de cuenta bancario CSV solo te da una fecha:
=ENTERO(B2)Dale formato de fecha a ese resultado. Ahora estás comparando el día local que implica la marca de tiempo de Stripe, no el día UTC sin procesar.
Si la fecha de Stripe ya es un valor de fecha-hora real de Excel en A2, no la analices de nuevo. Aplica el desfase directamente:
=A2-TIEMPO(4,0,0)El archivo bancario requiere el mismo cuidado. Si el estado de cuenta bancario CSV importó 01/05/2026 como texto, determina si la fuente usa dd/mm/yyyy o mm/dd/yyyy antes de convertirlo.
Si el banco usa dd/mm/yyyy:
=FECHA(DERECHA(C2,4),EXTRAE(C2,4,2),IZQUIERDA(C2,2))Si el banco usa mm/dd/yyyy:
=FECHA(DERECHA(C2,4),IZQUIERDA(C2,2),EXTRAE(C2,4,2))No recurras a FECHANUMERO hasta que sepas qué formato exportó el banco. Un valor como 01/05/2026 no es diagnóstico por sí solo. Puede ser el 1 de mayo o el 5 de enero según el sistema fuente y la configuración regional de Excel.
Una advertencia merece más atención de la que la mayoría de guías le dan: un desfase fijo de -TIEMPO(4,0,0) o -TIEMPO(5,0,0) solo es seguro si el rango de fechas se mantiene dentro de un único período de horario de verano. Si el export cruza el cambio de horario, un solo desfase puede corregir la mitad del archivo y romper la otra. En ese caso, divide el archivo por período o usa un reporte de Stripe que ya exponga la columna de zona horaria de la cuenta, y conserva la versión _utc solo como referencia de auditoría.
Concilia la transferencia con el banco antes de tocar los cargos individuales
Una vez normalizadas las marcas de tiempo, la siguiente decisión es el nivel de conciliación. Si el estado de cuenta bancario CSV contiene un solo depósito neto y el archivo de Stripe contiene cargos individuales, reembolsos y comisiones, todavía no tienes una coincidencia fila a fila. Tienes una relación de uno a varios.
La línea bancaria debe conciliarse primero con un reporte de transferencia de Stripe. Luego, las transacciones dentro de esa transferencia explican el monto.
| Paso | Archivo que usas | Lo que pruebas |
|---|---|---|
| 1 | Estado de cuenta bancario CSV | Qué monto llegó al banco y en qué fecha de acreditamiento |
| 2 | Export de transferencia o de conciliación de transferencia de Stripe | Qué transferencia produjo ese depósito |
| 3 | Filas detalladas dentro de esa transferencia | Qué cargos, reembolsos, disputas y comisiones componen el monto neto |
| 4 | Export de pedidos, facturas o libro mayor | Si la actividad subyacente está registrada correctamente en otro lugar |
Supón que tu estado de cuenta bancario CSV muestra esta línea:
| Date | Description | Amount |
|---|---|---|
| 2026-06-01 | STRIPE PAYOUT | 4,820.25 |
Tu export de transacciones de Stripe puede tener treinta y siete filas creadas entre 2026-05-31 21:00:00 UTC y 2026-06-01 03:00:00 UTC. Si comparas esas fechas de transacciones directamente con la línea bancaria del 1 de junio, concluirás que muchas filas están "desfasadas un día". Algunas lo están. Pero lo más importante es que ninguna de esas filas debería coincidir individualmente con la línea bancaria. Pertenecen a un lote de transferencia.
La justificación correcta es esta:
- El export de transferencia de Stripe muestra una transferencia neta de
4,820.25. - El campo de la transferencia que representa la llegada esperada al banco se alinea con la ventana de acreditamiento bancario.
- Las transacciones detalladas dentro de esa transferencia suman el mismo monto neto después de comisiones, reembolsos y disputas.
En ese punto, el problema de fechas recupera su verdadera dimensión. Es un paso de normalización, no la conciliación completa.
Si necesitas profundizar en el lado de las transferencias, conciliar un CSV de transferencias de Stripe con tu estado de cuenta bancario y conciliar un estado de cuenta bancario con las transferencias de Stripe cuando las fechas difieren cubren el flujo del depósito desde el otro extremo.
Los casos límite que siguen generando discrepancias falsas después de la conversión
Convertir Stripe a hora local resuelve la primera capa. No resuelve todas. Varios casos siguen generando aparentes rupturas de fechas aunque el cálculo de zona horaria sea correcto.
Filtrado de fin de mes
Este atrapa a equipos competentes porque la hoja parece limpia. Exportas el estado de cuenta bancario de mayo. Luego exportas Stripe para mayo en UTC. Las transacciones locales de finales de la noche del 31 de mayo pueden aparecer como 1 de junio en Stripe, lo que las deja fuera del filtro de Stripe aunque pertenezcan a tu cierre de mayo en hora local. Agrega un día de margen a cada lado del período de Stripe, convierte a fecha local y luego filtra la columna de fecha convertida por el mes que estás cerrando.
Acreditamiento en fin de semana o festivo
Una transferencia puede ser efectiva el viernes y llegar al banco el lunes. No es un campo de fecha incorrecto. Es el procesamiento bancario. Si el monto de la transferencia y el patrón de referencia coinciden, trata la diferencia de fechas como tiempo de liquidación, a menos que el efectivo siga faltando después de la ventana bancaria normal.
Reembolsos y disputas que llegan después
El cargo original puede estar en una transferencia, mientras que el reembolso o la disputa llega en una transferencia posterior. Cuando alguien intenta conciliar el estado de cuenta contra fechas de creación de cargos únicamente, esas reducciones posteriores parecen discrepancias inexplicadas. No lo son. Pertenecen a un lote de transferencia posterior y deben rastrearse allí.
Columnas de zona horaria mezcladas
Algunos exports de Stripe pueden mostrar versiones en hora local y versiones _utc del mismo campo. Si construyes fórmulas contra una columna este mes y contra la otra el siguiente, el libro de trabajo producirá inconsistencias que parecerán errores en los datos fuente. Elige un estándar y mantenlo durante toda la conciliación.
Daño por copiar y pegar
Si alguien pega filas de Stripe en una hoja en lugar de importar el CSV, Excel puede eliminar silenciosamente el contexto de zona horaria, convertir las marcas de tiempo a valores de visualización locales o almacenarlos como texto. Cuando la fórmula empieza a fallar solo después de pegar, el archivo fuente puede estar bien y lo que cambió es la copia en la hoja.
Cuando el trabajo en la hoja de cálculo se convierte en el verdadero problema
Esta discrepancia es manejable cuando estás trazando una sola transferencia. Se vuelve costosa cuando cada mes exige la misma limpieza: analizar la marca de tiempo de Stripe, convertirla a hora local, agregar márgenes al período, separar fechas de transferencia de fechas de transacción y explicar por qué un depósito contiene docenas de filas subyacentes.
El estándar que necesitas no es "cada fecha de Stripe debe ser igual a la fecha bancaria". El estándar es que cada depósito bancario esté vinculado a la transferencia de Stripe correcta, que cada transferencia esté explicada por las transacciones que la componen, y que cualquier diferencia de fechas restante esté clasificada como conversión de zona horaria, tiempo de liquidación, o una excepción real que necesita corrección.
