Los IDs no coinciden porque Shopify y Stripe no exportan lo mismo.
Los CSV de pedidos de Shopify describen pedidos. Los CSV de transacciones de Stripe describen pagos, capturas, reembolsos o movimientos de saldo. Si intentas relacionar #1042 de Shopify con ch_3P8x... de Stripe, los archivos no tienen ningún error. Estás comparando un número de pedido con un registro de pago.
Para conciliar IDs de pedidos de Shopify con transacciones de Stripe en CSV, primero tienes que encontrar el campo común entre los dos archivos. Solo después puedes empezar a hacer coincidir filas.
Qué valores pueden realmente coincidir
Antes de limpiar columnas o escribir fórmulas, identifica qué par de campos estás comparando.
| Lo que ves en pantalla | Cómo lo almacena Shopify | Cómo lo almacena Stripe | Resultado al intentar la coincidencia |
|---|---|---|---|
#1042 | Name en el export de pedidos de Shopify | id del tipo ch_3P8x... | Sin coincidencia. El primero es un número de pedido. El segundo es un ID de cargo. |
6721948832513 | Id en el export de pedidos de Shopify o Order en el historial de transacciones | id del tipo ch_3P8x... | Sin coincidencia. El ID interno de pedido de Shopify no es el mismo objeto que un ID de transacción de Stripe. |
c1027508764856.2 | Una entrada dentro de Payment References | La misma referencia de proveedor en un export vinculado a Stripe o en un campo de metadatos | Coincidencia directa, si esa referencia exacta existe en ambos lados. |
1042 | Número de pedido de Shopify limpio desde Name después de quitar el # | metadata[order_number] o campo de metadatos equivalente en Stripe | La coincidencia funciona si los metadatos fueron escritos y exportados. |
$84.20 el mismo día | Total más Paid at | Amount más Created | No es seguro. Los pedidos duplicados, los reintentos, los reembolsos y los cambios de zona horaria generan coincidencias falsas. |
Esa tabla resume el problema en su totalidad.
La mayoría de las conciliaciones fallidas ocurren porque alguien usa la primera fila de esa tabla esperando que se comporte como la tercera o la cuarta.
Shopify tiene más de una referencia por pedido
Shopify exporta varios identificadores, y cada uno cumple una función diferente.
| Campo de Shopify | Qué representa | Cuándo usarlo |
|---|---|---|
Name | El número de pedido visible en Shopify, normalmente con el prefijo # | Úsalo cuando los metadatos de Stripe almacenan el número de pedido, o cuando necesitas una referencia legible |
Id | El ID interno de pedido de Shopify | Úsalo solo si ese mismo ID interno fue incluido en los metadatos de Stripe o en otro campo de enlace |
Payment ID | Un ID del lado del pago enviado por Shopify para pagos exitosos o pendientes | Úsalo cuando tu export de Stripe incluye la misma referencia del lado del pago |
Payment References | Todos los IDs de pago vinculados al pedido, incluidos los pagos fallidos, los reembolsos y las capturas | Úsalo cuando un pedido tiene varios eventos de pago y necesitas el historial completo, no solo el último exitoso |
Por eso dos personas que exportan el mismo pedido desde Shopify pueden obtener resultados de conciliación distintos.
Un export está organizado por pedidos. Otro está organizado por transacciones. El export del historial de transacciones te da una fila por evento de pago capturado, no una fila por pedido. Tampoco cubre todos los estados posibles de la pasarela de pago. Si estás comparando contra autorizaciones, reintentos u otros eventos de pago que no están en ese export, el archivo de Shopify que descargaste puede que no opere al mismo nivel de detalle.
La primera decisión no es "¿Qué fórmula debo usar?" Es "¿Estoy relacionando filas de pedidos con filas de pedidos, o filas de pagos con filas de pagos?"
Si saltas esa pregunta, terminas haciendo el mismo trabajo descrito en por qué conciliar pedidos de Shopify con los pagos de Stripe es tan lento, donde un archivo está agrupado por pedido y el otro por actividad de liquidación.
Stripe exporta el objeto de pago, no el pedido de Shopify
Los CSV de Stripe suelen construirse alrededor de los identificadores propios de Stripe:
- IDs de cargo
- IDs de intento de pago
- IDs de reembolso
- IDs de transacción de saldo
- registros relacionados con pagos
Son IDs válidos. No son IDs de pedidos de Shopify.
Esa distinción importa porque un pedido de Shopify puede generar varios registros en Stripe:
- un intento de pago fallido
- un cargo exitoso
- una captura
- un reembolso
- una disputa o ajuste
Si tu archivo de Shopify tiene una fila de pedido y tu archivo de Stripe tiene tres filas de pago relacionadas con ese pedido, la coincidencia fila por fila va a fallar aunque los datos sean correctos.
Aquí es donde los metadatos se vuelven importantes. Si Stripe tiene un campo de metadatos como shopify_order_id o order_number, ese campo puede actuar como puente de vuelta a Shopify. Pero algunos exports de Stripe no incluyen los metadatos por defecto, así que el valor puede existir en el objeto de Stripe y aun así faltar en el CSV que descargaste.
Eso lleva a una conclusión incorrecta muy común:
"Stripe no tiene la referencia de Shopify."
A veces Stripe sí la tiene. Tu export simplemente no la incluye.
Crea la tabla de enlace antes de empezar a conciliar
Una conciliación confiable necesita una clave común y estable. Sin ella, no estás haciendo coincidir registros. Estás adivinando a partir de montos y fechas.
El flujo correcto es construir primero una pequeña tabla de enlace.
| Columna de trabajo | Fuente | Para qué sirve |
|---|---|---|
shopify_order_number_clean | Campo Name de Shopify sin el # | Permite comparar contra metadatos de Stripe que almacenan 1042 en lugar de #1042 |
shopify_internal_order_id | Campo Id de Shopify o Order del historial de transacciones | Útil solo si ese mismo ID interno existe en el lado de Stripe |
shopify_payment_reference_single | Un valor individual extraído de Payment References | Evita que una celda de Shopify con varias referencias oculte múltiples intentos de pago |
stripe_transaction_id | Campo id de Stripe | El ID nativo del registro de Stripe |
stripe_metadata_order_number | Export de metadatos de Stripe, si está disponible | Suele ser el camino más directo al campo Name de Shopify |
stripe_metadata_shopify_order_id | Export de metadatos de Stripe, si está disponible | Camino directo al ID interno de pedido de Shopify |
amount y timestamp | Ambos archivos | Solo para revisión, nunca como clave de conciliación principal |
Tres reglas hacen que esto funcione.
1. Divide `Payment References` en una referencia por fila.
Si Shopify te da c1027508764856.1 + c1027508764856.2, eso no es una referencia. Son dos. Una puede representar un intento fallido y la otra el pago exitoso. Si las dejas en una sola celda, pierdes la capacidad de hacer coincidir cada evento correctamente.
2. Mantén el número de pedido legible separado de los IDs de pago.
#1042 sirve para revisar. No es la misma clase de identificador que ch_3P8x.... No sobreescribas uno con el otro en una columna "limpia". Conserva ambos.
3. Normaliza el formato sin perder el significado.
Quita el # de los números de pedido de Shopify si los metadatos de Stripe almacenan números sin prefijo. Elimina los espacios sobrantes. Conserva los caracteres iniciales en las referencias de pago. Un valor que empieza con c o ch_ te está diciendo qué sistema lo generó. No lo truncues.
El orden de conciliación que funciona en la práctica
Una vez que tienes la tabla de enlace, concilia en este orden.
1. Haz coincidir referencia de pago con referencia de pago
Si el campo Payment ID de Shopify o un valor individual de Payment References aparece en el lado de Stripe, úsalo primero. Es lo más parecido a una verdadera clave de transacción entre sistemas.
Es el mejor caso posible porque conecta el evento de pago de forma directa y evita adivinar a partir de los totales.
2. Haz coincidir el ID interno de pedido de Shopify con los metadatos de Stripe
Si los metadatos de Stripe contienen el ID interno de pedido de Shopify, haz coincidir el campo Id de Shopify o Order del historial de transacciones con ese campo de metadatos.
Es una coincidencia sólida porque los IDs internos son estables. La limitación: el campo tiene que haber sido escrito en Stripe y estar incluido en el export.
3. Haz coincidir el número de pedido de Shopify con los metadatos de Stripe
Si los metadatos de Stripe almacenan el número de pedido en lugar del ID interno, limpia el campo Name de Shopify para que #1042 y 1042 no fallen solo por diferencias de formato.
Esta vía funciona bien para revisiones y reportes para clientes porque el número de pedido es legible. Es menos confiable que un ID interno cuando distintos sistemas formatean los nombres de pedido de manera diferente.
4. Usa montos y marcas de tiempo solo para revisar lo que queda sin coincidir
Aquí es donde la mayoría de las hojas de cálculo se descarrilan.
Los montos y las fechas no son claves de conciliación seguras en archivos de Shopify y Stripe porque:
- el mismo monto puede aparecer más de una vez en un día
- un pedido puede tener varios intentos de pago
- los reembolsos pueden ocurrir mucho después de la venta original
- la marca de tiempo del pedido y la del pago muchas veces no corresponden al mismo evento
- el manejo de zonas horarias puede desplazar la fecha sin cambiar el pago
Si las fechas forman parte de tu revisión, trátalas como evidencia de apoyo. No las conviertas en la clave de conciliación principal, especialmente si ya estás viendo el patrón detrás de el desfase entre las marcas de tiempo UTC de Stripe y las fechas del estado de cuenta CSV.
Por qué registros correctos parecen no coincidir
Cuando una hoja de cálculo dice que las filas no se alinean, suele ser por una de estas razones.
Relacionaste datos a nivel pedido con datos a nivel pago.
Un pedido de Shopify puede corresponderse con varios registros de Stripe. El archivo no está mal. La granularidad, sí.
El export de Stripe no incluye el campo de enlace.
Los metadatos pueden existir en Stripe, pero el CSV exportado puede omitirlos. Si la clave de enlace no está en el archivo, la conciliación va a fallar aunque el objeto de pago subyacente la contenga.
`Payment References` tiene más de un valor.
Un pedido de Shopify puede llevar varios IDs de pago. Si tratas toda la celda como una sola clave, ninguno de los eventos de pago individuales va a coincidir correctamente.
Usas `Name` porque te resulta familiar.
Es la trampa más común. #1042 es fácil de leer, así que se intenta forzar todo a ese número. Los archivos de transacciones de Stripe no están construidos alrededor de lo que es más fácil de leer. Están construidos alrededor de los objetos de pago.
Los reembolsos se están conciliando con la fila de venta original.
Los reembolsos necesitan su propia lógica de fila. No son copias negativas de la línea de export del pedido original.
Las marcas de tiempo difieren aunque el pago sea el mismo.
La creación del pedido en Shopify, la captura del pago y la creación de la transacción en Stripe pueden ocurrir en momentos distintos. Si exiges una coincidencia exacta de fechas, registros correctos pueden parecer rotos.
Cómo luce un resultado de conciliación confiable
Cuando la conciliación es correcta, tu archivo de trabajo debe poder responder estas preguntas sin buscar manualmente:
| Pregunta | El archivo debe responder con |
|---|---|
| ¿A qué pedido de Shopify pertenece esta transacción de Stripe? | Número de pedido e ID interno de pedido |
| ¿Qué evento de pago de Stripe pertenece a este pedido de Shopify? | ID de transacción o referencia del lado del pago |
| ¿Esta fila es una venta, un reintento, un reembolso o una captura? | Tipo de evento claramente separado |
| ¿La coincidencia se estableció por clave directa o por lógica de revisión? | Columna con el método de conciliación |
| ¿Qué filas siguen sin resolver? | Una lista corta de filas sin coincidir con la razón |
Si tu hoja no puede responder esas cinco preguntas, no está terminada. Puede que tenga la mayoría de las filas alineadas, pero aún no es confiable para reutilizar el mes que viene.
Con poco volumen, puedes mantener esa tabla de enlace a mano.
Con volumen recurrente, el trabajo real deja de ser juicio de conciliación y se convierte en mantenimiento de archivos:
- dividir las referencias de pago con varios valores
- normalizar los números de pedido
- volver a exportar Stripe con los campos correctos
- reconstruir las mismas coincidencias
- revisar los mismos casos sin resolver otra vez
Ese es el punto donde el problema ya no es "¿Qué significa este ID?" sino "¿Por qué sigo haciendo este mapeo de objetos en una hoja de cálculo cada mes?"
