Los archivos de liquidación de Klarna y los registros de venta de Shopify casi nunca difieren porque hayan desaparecido ventas. Difieren porque Klarna liquida las órdenes capturadas según su propio calendario de pagos, mientras que Shopify registra las órdenes en el momento de la compra y les asigna referencias distintas.
Eso significa que un export limpio de Shopify puede verse incorrecto frente a un archivo Klarna igualmente impecable. Una fila puede llevar el nombre de orden de Shopify. La otra puede llevar un order_id de Klarna, un short_order_id, o uno de los campos de referencia del comerciante. Un reembolso puede caer en una liquidación posterior. Una orden enviada parcialmente puede generar más de una captura. Comisiones, retenciones y reversiones pueden reducir el pago sin que exista una fila de ventas coincidente en Shopify.
Si comparas los dos archivos fila por fila desde la primera pestaña que exportaste, las diferencias parecen aleatorias. No lo son. Estás comparando actividad de órdenes, actividad de liquidación y ajustes de pago como si fueran lo mismo.
La solución: primero separa esas capas, elige una clave de cruce y solo entonces compara los montos.
Identifica el tipo de diferencia antes de tocar los datos
La mayoría de las conciliaciones fallidas responden a los mismos patrones. Identifica cuál aplica antes de construir fórmulas o filtrar filas sin conciliar.
| Lo que ves en pantalla | Cómo lo almacena Klarna | Cómo lo almacena Shopify | Qué ocurre si concilias sin verificar |
|---|---|---|---|
#10482 aparece en Shopify pero no hay ningún valor igual en Klarna | order_id = c504a9bb-1948-46d5..., merchant_reference1 = #10482 | Name = #10482 | La orden parece ausente si cruzaste Name de Shopify con order_id de Klarna |
| La fecha de orden coincide, pero la fecha de pago no | sale_date = 2026-05-02T21:18:00Z, payout_date = 2026-05-04T07:45:00Z | Paid at = 2026-05-02 | La orden parece retrasada o ausente cuando en realidad solo se liquidó después |
| Existe una devolución en Klarna pero no bajo la misma fila de captura | type = RETURN, capture_id = "", mismo order_id que la venta original | Devolución registrada en la orden o en el historial de transacciones bajo el nombre de orden original | La devolución parece huérfana si usas capture_id como clave principal |
| Klarna muestra filas negativas que Shopify no tiene | type = FEE, HOLDBACK, CHARGE | Sin fila de orden coincidente en el registro de ventas | La liquidación parece incompleta aunque las ventas estén bien |
| Un total de orden de Shopify da dos filas de venta en Klarna | Dos filas SALE con valores capture_id distintos bajo un mismo order_id | Una fila de orden o un nombre de orden en el registro de ventas | La orden parece duplicada o parcialmente ausente si no la agrupas primero |
Si tus archivos encajan con más de una fila de esta tabla, es normal. Klarna y Shopify rastrean etapas distintas del mismo evento comercial. La conciliación funciona cuando decides qué nivel debe probar cada archivo.
Ubica cada archivo en su nivel correcto
El archivo de liquidación de Klarna prueba qué incluyó Klarna en un pago y por qué ese pago subió o bajó. El registro de venta de Shopify prueba que una orden se creó, se pagó, se devolvió o se ajustó dentro de la tienda. Son registros relacionados, pero no son intercambiables.
Usa el archivo de Klarna para probar la composición de la liquidación, la referencia de pago y si las comisiones se descontaron del pago o se facturaron por separado. Usa el archivo de Shopify para probar qué órdenes se pagaron con Klarna, qué referencia de orden corresponde a cada venta, y si existen devoluciones o filas duplicadas.
| Archivo | Campos a conservar | Para qué sirve | Para qué no sirve |
|---|---|---|---|
| Archivo de liquidación de Klarna | payment_reference, payout_date, type, amount, order_id, short_order_id, merchant_reference1, merchant_reference2, capture_id | Composición de la liquidación y lógica del pago | Probar que cada fila debe tener una venta equivalente en Shopify en uno a uno |
| Registro de venta de Shopify | Nombre/número de orden, medio o pasarela de pago, fecha de pago, fecha de devolución, monto, estado | Actividad de órdenes y transacciones del lado de la tienda | La composición exacta de una liquidación de Klarna |
Aquí es donde muchas conciliaciones se tuercen. El contador espera que el archivo de ventas de Shopify explique las comisiones y las reservas. No puede hacerlo. Luego espera que el archivo de liquidación de Klarna se comporte como un export de órdenes. Tampoco es su función.
Elige la clave de cruce antes que los montos
Los montos son lo último que se compara. Si la clave es incorrecta, montos iguales solo crean una falsa confianza.
La mejor clave de cruce entre los dos sistemas suele ser uno de los campos de referencia del comerciante en Klarna, porque son los valores enviados al crear la orden. Si merchant_reference1 o merchant_reference2 contiene el nombre o el número de orden de Shopify, úsalo primero. Si esos campos están vacíos o son poco fiables, la siguiente mejor opción es la relación entre short_order_id de Klarna y el nombre de orden de Shopify.
El campo order_id de Klarna sigue siendo útil, pero para agrupar toda la actividad de Klarna a lo largo del ciclo de vida de una orden: venta, comisión, devolución, reversión, corrección. No es automáticamente el mejor puente hacia Shopify porque Shopify puede no mostrar ese UUID. Tampoco uses capture_id como clave principal. Las devoluciones y reversiones pueden no tener valor en ese campo, y una orden de Shopify puede producir múltiples capturas si el envío es fraccionado.
| Clave | Mejor uso | Limitación |
|---|---|---|
merchant_reference1 / merchant_reference2 | Cruce directo con el nombre o número de orden de Shopify | A veces vacío o rellenado de forma inconsistente |
short_order_id | Alternativa cuando Klarna y Shopify exponen la misma referencia al cliente | No siempre es igual al nombre interno de orden del comerciante |
order_id | Agrupar todos los eventos Klarna de una orden | Generalmente ausente de los registros de venta de Shopify |
capture_id | Diagnosticar capturas fraccionadas y actividad por envío | Las devoluciones y reversiones pueden no tener valor aquí |
Si ya tienes que vincular órdenes de tienda con archivos de pago en otro punto de tu flujo de trabajo, el problema de fondo es el mismo que se describe en por qué hacer coincidir órdenes de Shopify con archivos de pago se vuelve lento: los datos no fallan porque los montos sean incorrectos, sino porque las referencias y el calendario de eventos divergen entre los exports.
Haz la conciliación en tres etapas
Una vez elegida la clave, trabaja por capas. No empieces por el total del pago.
1. Aísla las filas de Shopify que pertenecen a Klarna
Primero filtra el registro de venta de Shopify por la pasarela de pago correspondiente. Si el archivo contiene pagos con tarjeta, PayPal, tarjetas de regalo u órdenes manuales junto con transacciones de Klarna, todas las comparaciones posteriores serán ruidosas.
Luego reduce el lado de Shopify a una referencia de orden, un monto pagado, una fecha de pago, un monto de devolución si aplica, y un estado de pago. Si tu export de Shopify repite una orden en varias líneas de producto, conviértela en un registro de nivel orden antes de cruzarla con Klarna.
2. Separa las filas de Klarna vinculadas a una orden de las filas exclusivas de liquidación
No todas las filas de Klarna deben coincidir con una fila de venta de Shopify. Separa las filas vinculadas a una orden —SALE, RETURN, REVERSAL, REVERSAL_MERCHANT_PROTECTION, CORRECTION y FEE— de las filas exclusivas de liquidación: HOLDBACK, RELEASE, CHARGE, CREDIT, COMMISSION y FEE_REFUND. Si las mezclas, la conciliación genera excepciones falsas que en realidad son movimientos de reserva o ajustes a nivel de pago.
3. Verifica primero la presencia, luego los montos, luego el impacto en el pago
La presencia es la primera prueba. ¿Existe la orden en ambos lados bajo la clave elegida?
Luego compara la economía de la orden:
- Venta bruta de Shopify contra el total
SALEde Klarna - Devoluciones de Shopify contra los totales
RETURNyREVERSALde Klarna - Filas de comisiones de Klarna por separado, no dentro de la conciliación de la venta bruta
Cuando una orden produjo varias filas SALE por capturas parciales, totalízalas por order_id antes de compararlas con la venta de Shopify:
=SUMAR.SI(Klarna!$F:$F,F2,Klarna!$H:$H)Aquí la columna F es order_id y H el monto de la fila. Compara ese subtotal, no cada línea de captura.
Solo después de que esas verificaciones pasen, vincula la liquidación al monto del pago. Ese paso final es donde corresponden la referencia de pago, la fecha de pago, las retenciones, las liberaciones y los demás ajustes fuera de orden.
Esta es la vista agrupada que buscas:
| Referencia de orden | Registro de venta de Shopify | Vista de liquidación Klarna | Significado |
|---|---|---|---|
#10482 | Pagada 120.00 | SALE 120.00, FEE -3.20 | Orden conciliada; la comisión explica parte del pago neto |
#10483 | Pagada 80.00, luego devuelta 80.00 | SALE 80.00, luego RETURN -80.00 | El momento de la devolución debe rastrearse por separado de la venta original |
#10484 | Pagada 150.00 | Sin fila SALE en la liquidación actual | Probablemente aún no capturada, aún no liquidada, o fuera del rango de fechas |
#10485 | Una fila de orden por 200.00 | Dos filas SALE de 120.00 y 80.00 bajo un mismo order_id | Captura parcial; agrupa antes de verificar los montos |
La pregunta no es: "¿Son idénticos estos dos exports?" No deberían serlo. La pregunta útil es: "¿Puedo explicar cada diferencia en el nivel correcto?"
Separa las liquidaciones diferidas de las diferencias reales
El error más costoso en este flujo de trabajo es tratar una diferencia de tiempo como una venta faltante.
Klarna expone al menos tres fechas que importan en la práctica:
sale_date: cuándo se creó la ordencapture_date: cuándo se registró el evento y, para las filasSALE, cuándo se enviaron los bienes y se realizó la capturapayout_date: cuándo Klarna inició el pago
Los registros de venta de Shopify suelen centrarse en la orden o en el evento de pago. Eso significa que una orden válida puede aparecer en Shopify un día, en las filas de captura de Klarna otro día, y en el pago un día posterior.
Usa esta tabla de decisión cuando una fila parece ausente:
| Patrón | Lo que generalmente significa | Qué hacer |
|---|---|---|
Presente en Shopify, ausente de las filas SALE de Klarna, pago aún pendiente o no capturado | La orden aún no se liquidó | No la marques como faltante; revisa el estado de la captura y la próxima ventana de liquidación |
| Presente en Shopify, ausente de Klarna, pero otras pasarelas aparecen en el mismo export | El filtro de pasarela es incorrecto | Reconstruye el subconjunto de Shopify solo para transacciones de Klarna |
Presente en las filas SALE de Klarna, ausente de la clave de cruce de Shopify | El mapeo de referencias es incorrecto | Revisa merchant_reference1, merchant_reference2 y el formato del nombre de orden |
Presente como RETURN o REVERSAL de Klarna en una liquidación posterior | Una devolución o disputa posterior está reduciendo el pago actual | Vincula con la orden original y clasifica como actividad negativa diferida |
Aquí también empieza la confusión de cierre de mes. Un registro de venta de Shopify de abril puede contener órdenes cuyo impacto en caja llega en una liquidación de Klarna de mayo. No son datos erróneos. Es el calendario de liquidación.
Si tu lista sin resolver aún contiene un bloque grande de filas negativas o sin conciliar después de separar el tiempo de los problemas de presencia, el problema suele ser la estructura de las referencias, no ventas faltantes. El mismo patrón aparece en otras conciliaciones entre plataformas, incluida la búsqueda de ventas sin conciliar entre Shopify y otro export de pago, donde la referencia de orden existe pero no tiene la misma forma en los dos lados.
Trata las filas que no deben forzarse a una coincidencia orden a orden
Algunas filas de Klarna pertenecen a la conciliación pero no a la grilla de cruce por orden.
Las filas FEE importan porque explican por qué las ventas no son iguales al pago. Pero no son evidencia de que falte una orden de Shopify. Son deducciones sobre la actividad de órdenes ya conciliadas.
Las filas HOLDBACK y RELEASE importan porque mueven efectivo sin representar nuevas ventas a clientes. Una retención reduce este pago para cubrir riesgos futuros. Una liberación devuelve fondos retenidos previamente a un pago posterior. Ninguna de las dos debe verificarse contra un monto de orden de Shopify.
Las filas CHARGE, CREDIT y COMMISSION también pertenecen a su propio grupo. Pueden cambiar el total de la liquidación sin que la conciliación a nivel de órdenes haya fallado.
También debes revisar el tipo de liquidación de Klarna. Si el tipo de liquidación del comerciante es NET, las comisiones de Klarna se deducen del pago. Si es GROSS, las comisiones se facturan por separado, por lo que tu conciliación de órdenes puede ser correcta aunque el cálculo del pago difiera de lo esperado en liquidación neta. Ese único campo cambia la lógica del cuadre final de saldos.
Una conciliación limpia produce cuatro resultados, no uno:
| Resultado | Qué incluye |
|---|---|
| Órdenes conciliadas | Ventas y devoluciones que coinciden según la clave de orden elegida |
| Liquidaciones diferidas | Órdenes válidas cuya liquidación o pago cae en una ventana posterior |
| Ajustes exclusivos de liquidación | Comisiones, retenciones, liberaciones, cargos, créditos, comisiones de plataforma |
| Diferencias reales | Filas que siguen sin resolverse después de las verificaciones de referencia y tiempo |
Si esos cuatro grupos están claros, la conciliación está lista. Si todo sigue mezclado en una pestaña de no conciliados, el trabajo no terminó.
Cuando reconstruir la conciliación mensual a mano deja de tener sentido
Este flujo de trabajo funciona. También repite el mismo trabajo cada ciclo: exportar Shopify, exportar Klarna, eliminar las filas que no son de Klarna, elegir la misma clave otra vez, agrupar órdenes con capturas fraccionadas, separar los ajustes de pago y reconstruir la lista de diferencias.
Es manejable cuando el volumen es bajo y la composición de los pagos es estable. Se vuelve costoso cuando cada liquidación tiene devoluciones diferidas, capturas parciales, movimientos de reserva y un nuevo ciclo de limpieza de referencias.
En ese punto, el cuello de botella ya no es el juicio contable. Es la preparación de archivos y la clasificación de diferencias, y esa es la parte que vale la pena sacar de la hoja de cálculo.
