Reconciliar contra otra fuente y explicar la diferencia

Ya sabes por qué dos números correctos pueden no cuadrar — definiciones distintas, filtros distintos, períodos que no coinciden. Ahora el problema es el siguiente: alguien te pone su cifra delante de la tuya y te pide que DEMUESTRES cuál es la correcta, o que expliques por qué las dos lo son. "Vuestro informe de pedidos de marzo dice 1.247.300 EUR. Mi extracto bancario dice 1.189.650 EUR. Son 57.650 euros de diferencia. Necesito saber cuál es el bueno antes de cerrar el trimestre." No te está acusando de nada — todavía. Pero si no puedes señalar con el dedo DÓNDE se separan las dos cifras, fila por fila, la próxima vez no te pedirán el informe a ti. Demostrar no es recalcular y decir "el mío está bien": es poner las dos listas una al lado de la otra y encontrar la línea exacta donde divergen.

Reconciliar, en el contexto de datos, significa poner tu cifra al lado de otra versión del mismo dato — que puede venir del ERP de Finanzas, del panel de la plataforma de publicidad, del CRM de ventas, o de un extracto bancario — y encontrar DÓNDE difieren, fila por fila si es necesario, hasta poder escribir una frase que diga: "las dos fuentes difieren en X euros; la causa es Y; la fuente correcta para esta decisión es Z." Esa frase es tu entregable.

### La analogía de las cuentas del restaurante

Imagina que llevas un restaurante. Cada noche, tu camarero apunta las mesas que ha cobrado en su libreta. Y cada noche, la caja registradora imprime un cierre con el total del día. La mayoría de los días coinciden. Pero un viernes, la libreta dice 3.400 EUR y la caja dice 3.250 EUR. Son 150 euros de diferencia. ¿Qué haces?

No te pones a discutir con el camarero sobre quién tiene razón. Coges las dos listas — la libreta y el ticket de la caja — y las comparas mesa por mesa. Mesa 1: libreta 120, caja 120, OK. Mesa 2: libreta 85, caja 85, OK. Mesa 7: libreta 150, caja... no aparece. Ahí está. La mesa 7 pagó en efectivo y el camarero lo apuntó, pero nadie lo metió en la caja. Misterio resuelto: no hay error, hay una operación que una fuente registró y la otra no.

Eso es reconciliar. Comparar línea por línea hasta encontrar dónde se separan los caminos. Y luego explicar por qué se separaron.

### Por qué reconciliar es distinto de hacer sanity checks

Un sanity check te dice si TU número tiene sentido. Reconciliar te dice POR QUÉ tu número difiere del de otro. Son herramientas complementarias que se usan en momentos distintos. El sanity check lo haces siempre, antes de enseñar tu cifra. La reconciliación la haces cuando alguien te pone otra cifra delante — o cuando tú mismo detectas que dos fuentes que deberían dar lo mismo no lo dan.

Piensa en la diferencia como la de un reconocimiento médico rutinario frente a una prueba diagnóstica. El sanity check es el reconocimiento anual: rápido, general, detecta problemas obvios. La reconciliación es el TAC que te piden cuando algo no cuadra: lento, detallado, busca la causa exacta.

### Un poco de historia: cómo se reconciliaba antes de SQL

En el siglo XV, la banca Medici tenía sucursales en Roma, Venecia y Brujas, y llevaba su contabilidad por partida doble. Cuadrar los libros de la central con los de cada sucursal era un trabajo lento: había que esperar a que llegaran los asientos, compararlos con los propios y aclarar lo que no encajaba. Podía llevar semanas, porque las cartas viajaban a caballo.

En los años 80, la hoja de cálculo hizo el mismo trabajo en horas en vez de semanas. Los contables importaban el extracto bancario en una columna y sus apuntes en otra, y usaban BUSCARV para emparejarlos. Los que devolvían #N/A eran las diferencias. El proceso se acortó, pero la lógica era idéntica: dos listas, una comparación, y un informe de lo que no casa.

Hoy lo hacemos con SQL y el principio sigue siendo el mismo. Lo que ha cambiado es la escala (miles de filas en vez de docenas) y la velocidad (segundos en vez de horas). Pero el razonamiento es el del contable florentino: empareja, marca, y explica lo que queda suelto.

### El proceso de 4 pasos

Después de reconciliar decenas de veces en mi carrera — contra ERPs de SAP, contra paneles de Google Ads, contra extractos bancarios, contra CRMs de Salesforce — el proceso se reduce siempre a los mismos cuatro pasos. No me los inventé yo: los vi hacer a la primera controller financiera con la que trabajé, una mujer que llevaba veinte años cuadrando balances y que hacía en treinta minutos lo que a mí me costaba un día. Los pasos son:

1. 01.Alinear definiciones: asegurarte de que las dos fuentes miden lo mismo.
2. 02.Alinear periodos: asegurarte de que cubren el mismo rango de tiempo.
3. 03.Comparar totales: ver cuánto difieren a nivel agregado.
4. 04.Bajar al detalle: encontrar fila por fila dónde se concentra la diferencia.

### Paso 1: Alinear definiciones

Antes de comparar un solo número, tienes que asegurarte de que las dos fuentes están midiendo lo mismo. Suena obvio, pero es donde se resuelve la mitad de las reconciliaciones sin escribir una línea de SQL. Preguntas concretas que tienes que hacer:

• ▹¿Las dos fuentes incluyen IVA? ¿O una lo incluye y la otra no?
• ▹¿Las dos fuentes incluyen devoluciones? ¿O una las resta y la otra no?
• ▹¿Las dos fuentes incluyen TODOS los canales? ¿O una excluye marketplace?
• ▹¿Las dos fuentes cuentan el mismo tipo de operación? (pedidos completados vs pedidos creados)
• ▹¿Las dos fuentes usan la misma moneda? (parece absurdo hasta que te pasa con filiales)

Si descubres que una fuente incluye IVA y la otra no, acabas de explicar una diferencia del 21% sin abrir SQL. Si una fuente incluye devoluciones y la otra no, has encontrado la causa sin mirar una sola fila. Este paso es pura conversación: llamas a la persona responsable de la otra fuente y le preguntas qué incluye y qué excluye su número. La mayoría de reconciliaciones se resuelven aquí.

### Paso 2: Alinear periodos

¿Las dos fuentes cubren exactamente el mismo rango de tiempo? Parece trivial, pero la diferencia entre "pedidos de marzo" y "cobros de marzo" puede ser de días. Un pedido hecho el 31 de marzo se cobra el 2 de abril: está en tu fuente de pedidos de marzo, pero NO en el extracto bancario de marzo. Esta sola diferencia de días puede suponer miles de euros.

Trampas habituales con los periodos:

• ▹Zona horaria: tu tabla registra en UTC y la otra fuente en hora local. El 31 de marzo a las 23:30 en Madrid es el 1 de abril en UTC.
• ▹Cierre de día: tu fuente cierra a medianoche, pero el banco cierra a las 17:00 (hora de corte bancaria). Los movimientos de la tarde del último día no están.
• ▹Fin de mes: tu query usa < primer día del mes siguiente, pero la otra fuente usa <= último día del mes. Si hay registros a las 00:00:00 del 1 de abril, una los incluye y la otra no.
• ▹Semanas ISO vs semanas naturales: si comparas por semana, la semana 1 de enero puede incluir días de diciembre según el estándar ISO 8601.

### Paso 3: Comparar totales a distintos niveles

Si las definiciones coinciden y los periodos están alineados, y aun así los totales difieren, necesitas localizar DÓNDE se concentra la diferencia. La técnica es comparar los totales a niveles de agregación cada vez más finos: primero por día, luego por canal, luego por producto, hasta que la diferencia deje de estar "repartida por todas partes" y se concentre en un punto concreto.

Es como buscar una fuga de agua en un edificio. Primero compruebas planta por planta: la primera va bien, la segunda va bien, la tercera pierde presión. Luego compruebas por zona dentro de la tercera planta: la zona A va bien, la zona B pierde. Luego por habitación: la 305 es la que tiene la fuga. Cada nivel de detalle reduce el área de búsqueda hasta que puedes señalar con el dedo.

1-- Comparar totales POR DIA entre mis pedidos y el extracto bancario
2SELECT
3    p.dia,
4    p.total_pedidos,
5    b.total_banco,
6    p.total_pedidos - b.total_banco AS diferencia
7FROM (
8    SELECT DATE_TRUNC('day', fecha) AS dia, SUM(importe) AS total_pedidos
9    FROM pedidos WHERE fecha BETWEEN '2024-03-01' AND '2024-03-31'
10    GROUP BY 1
11) p
12FULL OUTER JOIN (
13    SELECT DATE_TRUNC('day', fecha_valor) AS dia, SUM(importe) AS total_banco
14    FROM extracto_bancario WHERE fecha_valor BETWEEN '2024-03-01' AND '2024-03-31'
15    GROUP BY 1
16) b ON p.dia = b.dia
17ORDER BY COALESCE(p.dia, b.dia);

### Paso 4: Bajar al detalle con FULL OUTER JOIN

Una vez que sabes en qué día (o canal, o producto) se concentra la diferencia, necesitas ver las filas concretas. Aquí es donde entra la herramienta más potente de la reconciliación: el FULL OUTER JOIN. Este tipo de JOIN te devuelve TODAS las filas de ambas tablas, tanto las que emparejan como las que solo existen en un lado. Es el equivalente SQL de poner las dos listas del restaurante una al lado de la otra y marcar las que no tienen pareja.

El FULL OUTER JOIN produce tres tipos de filas que necesitas distinguir:

• ▹Filas que están EN AMBAS fuentes y coinciden: no hay problema, se ignoran.
• ▹Filas que están EN AMBAS fuentes pero con importes distintos: hay una discrepancia de valor.
• ▹Filas que solo están en TU fuente: tú las cuentas y la otra fuente no. Tu total es mayor.
• ▹Filas que solo están en LA OTRA fuente: ellos las cuentan y tú no. Tu total es menor.

1-- FULL OUTER JOIN para encontrar las diferencias fila por fila
2SELECT
3    COALESCE(p.pedido_id, b.referencia) AS id_operacion,
4    p.importe AS importe_pedidos,
5    b.importe AS importe_banco,
6    CASE
7        WHEN p.pedido_id IS NULL THEN 'SOLO EN BANCO'
8        WHEN b.referencia IS NULL THEN 'SOLO EN PEDIDOS'
9        WHEN p.importe != b.importe THEN 'IMPORTE DISTINTO'
10        ELSE 'OK'
11    END AS estado
12FROM pedidos p
13FULL OUTER JOIN extracto_bancario b
14    ON p.pedido_id = b.referencia
15    AND p.fecha = b.fecha_valor
16WHERE p.pedido_id IS NULL
17   OR b.referencia IS NULL
18   OR p.importe != b.importe;

### La técnica de EXCEPT para ver diferencias rápidas

Cuando las dos fuentes tienen la misma estructura (o puedes proyectarlas a las mismas columnas), EXCEPT es un atajo potente. EXCEPT te devuelve las filas que están en la primera consulta pero NO en la segunda. Es como restar un conjunto al otro: lo que queda son las diferencias.

1-- Pedidos que estan en MI fuente pero NO en la del banco
2SELECT pedido_id, importe
3FROM pedidos
4WHERE fecha BETWEEN '2024-03-01' AND '2024-03-31'
5
6EXCEPT
7
8SELECT referencia, importe
9FROM extracto_bancario
10WHERE fecha_valor BETWEEN '2024-03-01' AND '2024-03-31';
11
12-- Y al reves: cobros en el banco que no estan en mis pedidos
13SELECT referencia, importe
14FROM extracto_bancario
15WHERE fecha_valor BETWEEN '2024-03-01' AND '2024-03-31'
16
17EXCEPT
18
19SELECT pedido_id, importe
20FROM pedidos
21WHERE fecha BETWEEN '2024-03-01' AND '2024-03-31';

### El informe de reconciliación

La reconciliación no termina cuando encuentras la diferencia. Termina cuando la EXPLICAS de forma que quien te lo pidió pueda tomar una decisión. Tu entregable no es un fichero SQL con 200 líneas: es un documento breve — puede ser un correo de cinco párrafos o una página — que responde tres preguntas:

1. 01.¿CUÁNTO difieren las dos fuentes? (la cifra, en la misma unidad que te pidieron)
2. 02.¿POR QUÉ difieren? (la causa raíz, explicada sin jerga técnica)
3. 03.¿CUÁL es la fuente correcta para la decisión que hay encima de la mesa? (y por qué)

El formato más limpio que he usado en mi carrera — y que me enseñó aquella controller financiera — es una tabla con tres columnas: concepto, tu fuente, la otra fuente. Arriba los totales. Debajo, las partidas que explican la diferencia, una por fila. Y al pie, una conclusión de una frase.

1-- No es SQL: es el formato del informe (texto plano)
2--
3-- RECONCILIACION: Pedidos vs Extracto Bancario — Marzo 2024
4-- =========================================================
5--
6-- Concepto                  | Pedidos     | Banco       | Diferencia
7-- --------------------------+-------------+-------------+-----------
8-- Total marzo               | 1.247.300   | 1.189.650   | +57.650
9--
10-- Desglose de la diferencia:
11-- 3 pedidos aun no cobrados  | +38.200     |     —       | +38.200
12-- (enviados el 30-31 marzo, cobro previsto 2-3 abril)
13-- 1 devolucion registrada    |     —       |  -12.450    | +12.450
14-- solo en banco
15-- Comisiones pasarela pago   |     —       |   -7.000    |  +7.000
16-- (el banco las descuenta, nosotros no las registramos)
17--                            |             |     TOTAL   | +57.650
18--
19-- CONCLUSION: La diferencia de 57.650 EUR se explica por
20-- (a) 3 pedidos pendientes de cobro, (b) 1 devolucion que no
21-- hemos registrado, y (c) comisiones de pasarela. Para cerrar
22-- el trimestre, la cifra correcta es la del banco (1.189.650)
23-- porque refleja el dinero REALMENTE cobrado.

### Cuándo reconciliar

No reconcilias todo el rato: sería insostenible. Pero hay tres situaciones donde es obligatorio:

• ▹Cuando un stakeholder cuestiona tu número. Es la situación más frecuente y la más urgente. Alguien pone otra cifra encima de la mesa y necesitas explicar la diferencia ANTES de la próxima reunión.
• ▹Cuando cambias de fuente. Si pasas de leer datos del CRM a leer datos del almacén, reconcilia las dos fuentes durante un par de semanas para asegurarte de que dan lo mismo. Si difieren, tienes que saber por qué ANTES del cambio, no después.
• ▹Periódicamente, como mantenimiento. La controller financiera con la que trabajaba reconciliaba el cierre mensual CADA MES, aunque nadie se lo pidiera. Tardaba una hora y detectaba problemas antes de que nadie los viera. Es la versión de datos de "pasar la ITV": no esperas a que el coche se pare en la autopista.

### Caso práctico completo: pedidos contra extracto bancario

Vamos a recorrer los cuatro pasos con el caso del correo de la directora financiera. Tenemos dos tablas: tu tabla de pedidos (la fuente de Marketing/Producto) y el extracto bancario que te ha pasado Finanzas. Trabajaremos con datos simplificados para que veas el razonamiento sin perderte en mil filas, pero la técnica es idéntica con cien mil.

1-- Tus pedidos de marzo (fuente: tu base de datos)
2CREATE OR REPLACE TABLE pedidos AS
3SELECT * FROM (VALUES
4    ('P001', '2024-03-02', 1200.00, 'web'),
5    ('P002', '2024-03-05', 850.00, 'app'),
6    ('P003', '2024-03-07', 3200.00, 'web'),
7    ('P004', '2024-03-12', 475.00, 'tienda'),
8    ('P005', '2024-03-15', 2100.00, 'web'),
9    ('P006', '2024-03-20', 960.00, 'app'),
10    ('P007', '2024-03-25', 1580.00, 'web'),
11    ('P008', '2024-03-28', 3400.00, 'web'),
12    ('P009', '2024-03-30', 2250.00, 'app'),
13    ('P010', '2024-03-31', 1750.00, 'web')
14) AS t(pedido_id, fecha, importe, canal);
15
16-- Extracto bancario de marzo (fuente: Finanzas)
17CREATE OR REPLACE TABLE extracto_banco AS
18SELECT * FROM (VALUES
19    ('P001', '2024-03-03', 1200.00),
20    ('P002', '2024-03-06', 850.00),
21    ('P003', '2024-03-08', 3200.00),
22    ('P004', '2024-03-13', 475.00),
23    ('P005', '2024-03-16', 2100.00),
24    ('P006', '2024-03-21', 960.00),
25    ('P007', '2024-03-26', 1580.00),
26    ('P008', '2024-03-29', 3400.00),
27    ('DEV-003', '2024-03-22', -3200.00),
28    ('COM-MAR', '2024-03-31', -580.00)
29) AS t(referencia, fecha_valor, importe);

Paso 1 — Definiciones: preguntamos a Finanzas. Nos confirman que su extracto es dinero realmente cobrado (neto de comisiones y devoluciones). Nuestros pedidos son brutos (lo que el cliente pagó, sin descontar nada). Ya sabemos que no medimos exactamente lo mismo, pero queremos cuantificar la diferencia.

Paso 2 — Periodos: ambas fuentes cubren del 1 al 31 de marzo. Pero el banco registra por fecha de cobro (1-2 días después del pedido). Los pedidos del 30-31 de marzo no se cobrarán hasta abril. Eso explica parte de la diferencia.

Paso 3 — Totales: mi suma de pedidos es 17.765 EUR. La suma del banco es 9.985 EUR. Diferencia: 7.780 EUR. Necesito desglosarla.

Paso 4 — Detalle: emparejar por pedido_id / referencia y clasificar las diferencias.

1-- Reconciliacion fila por fila
2SELECT
3    COALESCE(p.pedido_id, b.referencia) AS id,
4    p.importe AS mi_importe,
5    b.importe AS banco_importe,
6    CASE
7        WHEN p.pedido_id IS NULL THEN 'SOLO EN BANCO'
8        WHEN b.referencia IS NULL THEN 'SOLO EN MIS PEDIDOS'
9        WHEN p.importe != b.importe THEN 'IMPORTE DISTINTO'
10        ELSE 'CUADRA'
11    END AS estado
12FROM pedidos p
13FULL OUTER JOIN extracto_banco b
14    ON p.pedido_id = b.referencia
15ORDER BY COALESCE(p.fecha, b.fecha_valor);

### Esto te lo van a preguntar en la entrevista

Una pregunta clásica en pruebas técnicas para analista es: "Tu informe dice 4,2 millones, pero el director financiero tiene 4,4 millones. ¿Qué haces?" La respuesta que esperan NO es "reviso mi query". La respuesta que esperan es un proceso: (1) pregunto qué definición usa cada número, (2) compruebo que cubren el mismo periodo, (3) si aún difieren, bajo al detalle para localizar dónde. Y si puedes añadir que el entregable es un informe breve que cuantifica cada causa, has demostrado que sabes cerrar el ciclo, no solo abrirlo.

En una entrevista real me preguntaron exactamente esto. Mi respuesta fue: "Lo primero que hago es NO defender mi número. Lo segundo es preguntar qué incluye el suyo. Lo tercero es sentarme con las dos fuentes y hacer un FULL OUTER JOIN por el campo que emparejen. En mi experiencia, la mayoría de las veces la diferencia es de definiciones, luego de periodos, y solo en una minoría de casos hay un error real de datos." Me dijeron que era la primera persona que no había empezado por "reviso mi query".

### Errores habituales al reconciliar

• ▹Asumir que TU fuente es la correcta y la otra la incorrecta. Ambas pueden ser correctas para su propósito. La pregunta no es cuál está bien, sino cuál es la adecuada para la decisión concreta.
• ▹Empezar por el detalle sin alinear definiciones. Si no has comprobado que miden lo mismo, vas a buscar filas que expliquen una diferencia que ya estaba explicada por el IVA.
• ▹No cuantificar cada causa. "La diferencia se debe a devoluciones y comisiones" no vale. Necesitas: "2.450 EUR son devoluciones y 580 EUR son comisiones". Sin las cifras, la conclusión no es verificable.
• ▹Reconciliar a mano cuando hay más de 50 filas. Si la diferencia está en tres filas de diez, la puedes encontrar a ojo. Si está en tres filas de diez mil, necesitas SQL. El umbral para dejar la hoja de cálculo está en pocas decenas de filas.
• ▹Olvidar que el FULL OUTER JOIN necesita un campo de emparejamiento fiable. Si emparejas por importe + fecha, dos pedidos del mismo día y mismo importe se confunden. Siempre que puedas, empareja por un identificador único.

### La hoja de cálculo como herramienta de reconciliación

No todo requiere SQL. Si la directora financiera te pasa un Excel con 40 filas y tú tienes otro Excel con 45 filas, la reconciliación puede hacerse perfectamente en una hoja de cálculo. Un BUSCARV (o XLOOKUP en versiones modernas) que busque cada id de tu lista en la suya, y los que devuelvan #N/A son los que no casan. Es rápido, visual, y no necesitas montar un entorno.

La hoja de cálculo se rompe cuando tienes miles de filas, cuando necesitas repetir la reconciliación cada semana, o cuando las dos fuentes no te llegan en formato tabular limpio. Ahí es cuando SQL es la herramienta correcta: escribes la query una vez, la guardas, y la ejecutas cada cierre. Pero para la primera reconciliación de urgencia con el correo de la directora financiera un viernes por la tarde, una hoja de cálculo con BUSCARV es una respuesta perfectamente válida.

### Resumen

Reconciliar es el proceso de poner tu número al lado de otra versión del mismo dato y encontrar DÓNDE difieren, hasta poder escribir una frase que explique la causa y recomiende la fuente correcta. Se hace en cuatro pasos (definiciones, periodos, totales, detalle) y produce un informe breve que cierra la discusión. Las herramientas principales son el FULL OUTER JOIN (para emparejar fila por fila) y EXCEPT (para ver diferencias rápidas). El entregable no es la query: es la frase que dice cuánto, por qué, y cuál usar.