El CSV de disputas de Stripe no pierde tus pedidos. Los describe mediante los IDs de disputa y cargo propios de Stripe, mientras tu hoja de pedidos suele organizarse en torno a un número de pedido interno. Si intentas cruzar directamente las filas dp_ con los IDs de pedido, cada línea parece rota aunque todos los registros estén ahí.
Para cruzar un CSV de disputas de Stripe con tu hoja de pedidos, necesitas el cargo como puente. Una fila de disputa pertenece primero a un cargo y luego a un pedido. Una vez que usas esa cadena, puedes identificar qué venta fue disputada, si el monto disputado equivale al pedido completo o solo a una parte, y qué registros todavía necesitas para armar el expediente.
Lo que te dice realmente la fila de disputa
Antes de empezar a cruzar, identifica con qué referencia estás trabajando realmente. Las exportaciones de disputas de Stripe y las de pedidos raramente comparten un nombre de columna común.
| Lo que ves en el CSV de disputas | Lo que Stripe quiere decir con eso | Lo que suele tener tu archivo de pedidos | Qué pasa si lo cruzas directamente |
|---|---|---|---|
dp_1... en la columna id | El ID del caso de disputa | #10482 o ORD-10482 | Sin coincidencia. Son tipos de objetos diferentes. |
ch_1... en una columna de cargo | El cargo original exitoso | stripe_charge_id, payment ref, o una columna de pasarela | Es el mejor puente directo si tu exportación de pedidos lo conservó. |
pi_3... o una referencia de payment intent | El flujo de pago vinculado al cargo | payment_intent, datos de sesión de checkout, o una referencia de pasarela | Buen puente si el ID de cargo no está almacenado en la fila del pedido. |
| Monto de la disputa menor que el total del pedido | Una disputa parcial sobre el pago original | Valor total del pedido en la hoja de ventas | Parece una coincidencia de monto incorrecta, a menos que compares por separado el cargo original y la porción disputada. |
| Disputa creada días o semanas después de la venta | La fecha en que se abrió el contracargo | La fecha original del pedido | Parece el pedido equivocado si cruzas solo por fecha. |
Si tu primer intento fue BUSCARV(dispute_id; orders; ...), la hoja de cálculo hizo exactamente lo que debía. Los valores son diferentes. El problema es la clave de cruce, no la fórmula.
Consigue los archivos que crean el puente
Dos archivos no siempre son suficientes. Para este trabajo normalmente necesitas tres.
| Archivo | Función | Columnas que necesitas |
|---|---|---|
| CSV de disputas de Stripe | Define el caso de disputa | ID de disputa, ID de cargo, monto, motivo, fecha de creación, estado |
| Exportación de cargos o pagos de Stripe | Conecta los datos de disputa con el pago original | ID de cargo, payment intent, correo del cliente, fecha de pago, monto original, campos de metadatos o referencia |
| Exportación de pedidos | Identifica la venta afectada en tu propio sistema | ID de pedido, fecha de pedido, monto bruto, correo del cliente, referencia de pago, campos de envío o factura |
El archivo del medio es el que la mayoría omite. Por eso falla el cruce.
El CSV de disputas te dice qué pago fue cuestionado. El archivo de pedidos te dice qué venta te importa internamente. La exportación de cargos o pagos hace de intermediario entre ambos. Si tu sistema de pedidos ya guarda el ID de cargo de Stripe en cada fila, el puente es corto. Si no, el archivo intermedio se vuelve indispensable.
Conserva los exportados sin tocar. No empieces por ordenar, eliminar columnas ni pegar un archivo en otra hoja. Cruzar disputas es ya un proceso de varios pasos. En cuanto las filas originales se mueven, añades un segundo problema encima del primero.
Cruza en este orden, no a ojo
Un cruce limpio empieza por el identificador más sólido y solo recurre a otro si ese falta.
1. ID de cargo con ID de cargo
Si el archivo de pedidos tiene un campo stripe_charge_id, gateway_reference, o similar, empieza por ahí. Es el camino más corto de la disputa al pedido.
| CSV de disputas | Exportación de cargos | Exportación de pedidos | Resultado |
|---|---|---|---|
charge = ch_3N8... | charge_id = ch_3N8... | stripe_charge_id = ch_3N8... | Coincidencia directa con el pedido afectado |
En este punto, añade el ID de pedido junto al ID de disputa. No te quedes en "coincidencia encontrada". Trae también la fecha del pedido, el correo del cliente, el monto original del pedido y el estado actual de envío. Esos son los campos que normalmente necesitas cuando alguien pregunta si la disputa es legítima o si el pedido ya fue entregado.
2. Payment intent o referencia de checkout
Algunas hojas de pedidos guardan el payment intent pero no el ID de cargo final. En ese caso, usa la exportación de pagos para conectar el cargo de la disputa con el payment intent, y luego el payment intent con el pedido.
Es habitual cuando el sistema de comercio escribe una referencia de pasarela al hacer el pago y nunca actualiza la fila del pedido con el objeto de cargo final. El pedido sigue siendo trazable. No puedes ir directamente del archivo de disputas al archivo de pedidos.
3. Metadatos o referencia de pago transferida al pedido
Si la exportación de cargos incluye metadatos como un número de pedido interno, número de factura o referencia de checkout, úsalos primero. Suele ser la vía de recuperación más clara cuando la exportación de pedidos no expone IDs de Stripe en columnas visibles.
Lo clave aquí es emparejar un objeto de pago con un objeto de pedido. No comprimas la lógica a "mismo monto, misma venta". El monto es una señal de apoyo. No es el puente.
4. Monto, cliente y fecha como último recurso controlado
Si ninguno de los dos archivos conservó los IDs de Stripe, aún puedes recuperar el pedido, pero ahora estás haciendo una investigación en lugar de un cruce directo.
Usa una ventana de candidatos reducida:
- Mismo correo del cliente o nombre del titular de la tarjeta
- Monto del cargo original cercano al monto disputado
- Pedido realizado cerca de la fecha de creación del cargo
- Una sola fila de pago exitoso, no un intento fallido ni una autorización duplicada
Este reposo es donde los equipos competentes pierden el tiempo. Buscan el monto disputado en la hoja de pedidos, ven cinco filas con el mismo valor y eligen la equivocada. Cruzar solo por monto es débil: muchas tiendas venden a precios repetidos. Antes de fiarte de una coincidencia por monto, cuenta cuántos pedidos lo comparten:
=CONTAR.SI(Pedidos!$D:$D,D2)Si el resultado es mayor que 1, el monto no es único. Filtra por cliente y fecha del cargo antes de elegir una fila.
Si el cargo disputado sigue sin aparecer, trátalo como un problema de registro faltante y trabájalo como cualquier otra comparación defectuosa entre dos archivos. Encontrar una transacción faltante entre dos archivos financieros rápido es el flujo de trabajo correcto a seguir en ese punto.
Arma una tabla de revisión de disputas que responda la pregunta real
La pregunta real no es "¿puedo hacer que las filas coincidan?". Es "¿qué pedidos están afectados y qué necesito hacer a continuación?".
Eso significa que la hoja de salida debe parecerse más a una tabla de auditoría que a un bloc de fórmulas.
| Columna de salida | Por qué pertenece a la tabla de revisión |
|---|---|
| ID de disputa | Identifica el caso al que estás respondiendo |
| ID de cargo | Ancla la disputa al pago original |
| ID de pedido | Le dice al negocio qué venta está afectada |
| Fecha del pedido | Distingue la fecha de la venta de la fecha de apertura de la disputa |
| Fecha de creación de la disputa | Muestra cuándo se abrió el contracargo |
| Monto del cargo original | Confirma el valor total del pago |
| Monto disputado | Señala inmediatamente las disputas parciales |
| Correo o nombre del cliente | Ayuda a confirmar la identidad del pedido |
| Motivo o categoría | Indica qué camino de evidencia es probable que necesites |
| Estado de coincidencia | Coincidencia directa por ID, mapeada vía exportación de pagos, coincidencia probable, o sin resolver |
Esas etiquetas de estado importan. Evitan que trates cada fila como igualmente confiable.
Una buena estructura de primer pase:
Coincidencia directa por IDCruzada vía exportación de pagosCoincidencia probable: revisión manualPedido no encontrado
Ahora la hoja te dice dónde realmente hace falta trabajo. Los dos primeros grupos pueden pasar rápido a recopilar evidencia. El tercero necesita revisión humana. El cuarto normalmente significa una de tres cosas: se exportó un rango de fechas incorrecto, el cargo exitoso no está en el archivo puente, o el sistema de pedidos nunca guardó la referencia del lado de Stripe.
Si también necesitas rastrear cómo el pago disputado afectó la caja, cruzar un CSV de pago de Stripe con tu estado de cuenta bancario cubre el lado de los pagos de la misma investigación.
Los casos borde que generan falsas no-coincidencias
Aquí es donde los artículos superficiales se detienen. La coincidencia directa es solo la mitad del trabajo. Los casos difíciles son los que hacen que el cruce tarde.
El monto disputado no es el monto total del pedido.
Un contracargo puede ser parcial. Cuando el total del pedido es 120.00 y el monto disputado es 40.00, la fila no está mal. Te está diciendo que solo se cuestiona una parte del pago original. Conserva ambos montos en la tabla de revisión.
La fecha de la disputa no es la fecha del pedido.
El cargo puede haberse hecho en enero y la disputa abrirse en marzo. Cruzar por fecha de creación de la disputa te enviará a la ventana de pedidos equivocada.
Un cliente realizó varios pedidos similares.
Mismo cliente. Mismo mes. Mismo total de pedido. Si no te anclas en el cargo o la referencia de pago, la hoja de cálculo puede apuntarte al pedido equivocado con total confianza.
El primer intento de pago falló pero el segundo fue exitoso.
Los sistemas de pedidos suelen conservar el registro del pedido mientras Stripe muestra varios eventos de pago alrededor. Solo cuenta el cargo exitoso vinculado a la disputa. Los intentos fallidos y las autorizaciones duplicadas generan ruido, no evidencia.
La exportación de pedidos guarda totales netos o por artículo mientras Stripe guarda el monto total cobrado.
El IVA, el envío, los descuentos y el manejo de divisas pueden hacer que el total de la hoja de pedidos y el monto del cargo parezcan distintos aunque pertenezcan a la misma venta. Cuando el identificador coincide, confía en el identificador por encima de la comparación aproximada de montos.
El archivo de disputas está bien, pero tu hoja perdió la clave.
Esto pasa cuando alguien exporta los datos correctos y luego reconstruye la hoja manualmente. Las columnas ocultas desaparecen. Las columnas de referencia se renombran. El cruce falla porque el campo puente nunca llegó al archivo de trabajo.
Qué hacer cuando no existe ninguna referencia de pedido clara
A veces el sistema de pedidos nunca escribió el ID de cargo de Stripe, el payment intent ni ninguna referencia de pago reutilizable en una exportación. Eso no hace imposible rastrear la disputa, pero cambia el trabajo.
En ese caso:
- Parte del ID de cargo en la exportación de disputas.
- Obtén los detalles del pago del lado de Stripe para ese cargo.
- Incorpora el identificador del cliente, el monto del pago y el timestamp del pago.
- Filtra los pedidos candidatos primero por cliente, luego por ventana de tiempo, luego por monto.
- Marca el resultado como coincidencia probable hasta que un campo adicional del negocio lo confirme.
El campo de confirmación puede ser el código postal de envío, el número de factura, el paquete de productos, la referencia de suscripción o el token interno de checkout. Lo importante es no tratar una coincidencia aproximada como una coincidencia firme.
Aquí es también donde los equipos descubren que su exportación de pedidos no está diseñada para manejar disputas. Está diseñada para reportes de ventas. No son el mismo trabajo. Un reporte de ventas puede tolerar una columna de monto limpia y una fecha. El manejo de disputas necesita un enlace recuperable hacia el objeto de pago.
Cuando el método archivo por archivo cuesta más que la disputa
Una disputa puntual se puede manejar a mano. El proceso se vuelve costoso cuando reconstruyes el mismo puente una y otra vez: exportar disputas, exportar cargos, exportar pedidos, recuperar la referencia común, señalar los montos parciales, y luego separar las filas confirmadas de las que todavía necesitan revisión.
El cruce está completo cuando cada fila de disputa resuelve a uno de cuatro resultados: coincidencia con un pedido específico, coincidencia a través de un archivo puente, reducida a un pequeño conjunto para revisión manual, o confirmada como ausente de los registros de pedidos. Una vez que tienes esa estructura, sabes qué ventas están afectadas y qué casos todavía necesitan trabajo de evidencia. Ese es el punto de la hoja de cálculo. No un muro de fórmulas. Una respuesta defendible.
