El export de Stripe muestra un lote de pagos, el extracto bancario refleja un solo depósito, y tu hoja de pedidos lista cientos de cobros de clientes. Estos archivos describen el mismo movimiento de dinero, pero ninguno usa la misma estructura de filas.
Ahí es donde los equipos de finanzas de startups suelen atascarse. Los números parecen relacionados, pero la diferencia es suficiente para no poder cerrar el mes. El ingeniero que podría escribir la consulta SQL está ocupado. El data warehouse tiene campos faltantes. El reporte de liquidación ya está en la carpeta de Descargas.
La auditoría no tiene que empezar con código. Necesita un flujo de trabajo basado en archivos que demuestre tres cosas: qué liquidación llegó al banco, qué pedidos o cargos componen esa liquidación, y qué diferencias se explican por comisiones, reembolsos, timing o registros faltantes.
En la práctica, los equipos de startups auditan las hojas de liquidaciones de pasarela sin ingenieros de datos convirtiendo el trabajo en una revisión por capas sobre archivos — no en una tarea de programación.
Empieza por la liquidación, no por la lista de pedidos
El depósito bancario es el evento de caja. Esa es la línea que el equipo de finanzas tiene que justificar.
Si el extracto bancario dice STRIPE PAYOUT 2026-05-10 por 18,742.60, la auditoría empieza ahí. No empieces sumando todos los pedidos del día. Las liquidaciones de pasarela se agrupan en lotes, se calculan netas de comisiones y tienen retrasos. El total de pedidos de un día calendario casi nunca coincide con la liquidación que llega al banco.
Usa la liquidación como ancla:
| Archivo | La pregunta que responde |
|---|---|
| Extracto bancario (CSV) | ¿Qué dinero llegó al banco? |
| Hoja de liquidaciones de pasarela | ¿Qué liquidación generó ese depósito? |
| Export de transacciones o saldo de la pasarela | ¿Qué cargos, comisiones, reembolsos y ajustes componen la liquidación? |
| Hoja de pedidos o ventas | ¿Qué pedidos de clientes deben conectarse con esas transacciones? |
Esto importa porque cada archivo trabaja con una base de importes diferente.
La hoja de pedidos suele mostrar el valor bruto del cliente. El archivo de transacciones de pasarela puede mostrar bruto, comisión y neto en columnas separadas. El archivo de liquidaciones muestra el importe neto enviado al banco. El extracto bancario muestra el depósito contabilizado, a veces con un retraso de procesamiento.
Comparar todos esos totales al mismo tiempo genera diferencias falsas. La auditoría funciona solo cuando cada capa tiene su propia prueba.
Identifica qué dice realmente cada archivo
Antes de comparar filas, define el rol de cada archivo. El nombre del archivo no basta. Un export de liquidaciones, un export de pagos y un export de transacciones de saldo pueden venir todos de la misma pasarela, pero sirven para cosas distintas.
| Archivo | Columnas comunes | Cómo usarlo |
|---|---|---|
| Resumen de liquidaciones | payout_id, arrival_date, amount, currency, status | Relacionar el lote de liquidaciones con el depósito bancario |
| Transacciones de saldo | transaction_id, type, gross, fee, net, payout_id | Explicar qué compone la liquidación |
| Export de pedidos | order_id, customer, payment_reference, order_total, created_at | Relacionar pedidos con la actividad de pago |
| Extracto bancario | date, description, amount, reference | Verificar el dinero recibido |
Un equipo de startup sin ingeniero de datos suele tener estos archivos como exports CSV o Excel, no como tablas unidas. Eso está bien. La auditoría no necesita un warehouse si los archivos tienen un vínculo utilizable entre ellos.
Ese vínculo suele ser uno de estos campos:
| Lado pasarela | Lado pedidos | Solidez |
|---|---|---|
payment_intent o charge_id | Referencia de pago | Fuerte |
metadata.order_id | ID de pedido | Fuerte |
| Descripción que contiene el número de pedido | ID de pedido | Fuerte si el formato es consistente |
| Email del cliente + importe | Email del cliente + total del pedido | Útil, insuficiente solo |
| Importe + ventana de fechas | Total del pedido + fecha del pedido | Solo coincidencia candidata |
| ID de liquidación | Generalmente ausente del archivo de pedidos | Útil para agrupar lotes, no para conciliar pedidos |
Si el archivo de pedidos no tiene referencia de pago, la auditoría se debilita. Puedes crear coincidencias candidatas usando email, importe y fecha, pero esas candidatas necesitan revisión. No las marques como conciliadas hasta tener suficiente evidencia.
Crea una copia de trabajo sin modificar los archivos originales
Mantén los exports originales sin cambios. La auditoría necesita preservar lo que vino de la pasarela, el banco y el sistema de pedidos.
Crea una copia de trabajo con columnas auxiliares que hagan comparables los archivos:
| Columna auxiliar | Qué corrige |
|---|---|
normalized_reference | Elimina espacios, diferencias de mayúsculas, prefijos y puntuación |
normalized_order_id | Alinea #1048, 1048 y ORD-1048 |
signed_amount | Unifica la convención de signo para cargos, reembolsos y comisiones |
amount_basis | Etiqueta bruto, comisión, neto, reembolso, ajuste o liquidación |
local_date | Convierte campos de timestamp a la fecha usada en la revisión |
date_window | Permite diferencias de uno o dos días por timing esperado |
currency_key | Bloquea coincidencias entre monedas distintas |
Este paso no es limpiar los datos para crear una nueva fuente de verdad. Es crear una capa de comparación. Las filas originales quedan intactas para que el reporte final pueda apuntar al registro exacto que causó el problema.
Por ejemplo, el archivo de pasarela puede mostrar:
| Field | Value |
|---|---|
transaction_id | ch_1001 |
created | 2026-05-07 22:41:19 UTC |
description | Order #8214 |
gross | 250.00 |
fee | -7.55 |
net | 242.45 |
payout_id | po_9007 |
La hoja de pedidos puede mostrar:
| Field | Value |
|---|---|
order_id | 8214 |
created_at | 2026-05-08 |
customer_email | buyer@example.com |
order_total | 250.00 |
payment_reference | ch_1001 |
Esas filas coinciden por referencia de pago e importe bruto. No coinciden por fecha exacta porque el timestamp de la pasarela está en UTC y el archivo de pedidos usa una fecha local. No coinciden por importe neto porque ya se dedujo la comisión de la pasarela.
La conclusión correcta no es "diferencia de fecha" o "diferencia de importe". Es: misma transacción, importe bruto coincide, fecha difiere por el manejo del timestamp, e importe neto de la liquidación es menor por la comisión de la pasarela.
Concilia por capas para no perder el hilo
La forma más rápida de perder el hilo es ejecutar una sola búsqueda esperando que responda todo. Una auditoría de liquidaciones de pasarela tiene al menos tres capas.
Primera capa: conciliar la liquidación con el banco.
| Línea bancaria | Liquidación de pasarela | Resultado esperado |
|---|---|---|
| Importe del depósito bancario | Importe neto de la liquidación | Debe coincidir o tener una explicación del lado del banco |
| Fecha bancaria | Fecha de llegada de la liquidación | Puede diferir por retraso de procesamiento |
| Descripción bancaria | Referencia de la liquidación o texto del proveedor | Debe vincular el depósito con la liquidación |
Segunda capa: conciliar las transacciones dentro de la liquidación.
| Transacción de pasarela | Qué verificar |
|---|---|
| Cargo | Debe conectarse con un pedido o línea de ventas |
| Comisión | Debe explicar la reducción de bruto a neto |
| Reembolso | Debe conectarse con un pedido reembolsado o ajuste |
| Disputa | Debe etiquetarse por separado de la actividad normal de reembolsos |
| Ajuste | Debe revisarse, no enterrarse en el total de la liquidación |
Tercera capa: comparar las transacciones de pasarela con la hoja de pedidos.
| Prueba de conciliación | Para qué usarla |
|---|---|
| Referencia de pago contra referencia de pago | Coincidencia directa fuerte |
| ID de pedido en metadatos de pasarela contra ID de pedido | Coincidencia directa fuerte |
| Email + importe bruto + ventana de fechas | Coincidencia candidata cuando faltan referencias |
| Comparación solo por importe | Clasificación de excepciones, no prueba final |
Este enfoque por capas es la diferencia entre una auditoría y una búsqueda en hojas de cálculo. Una sola búsqueda puede decirte que ch_1001 aparece en ambos archivos. No puede decirte si la liquidación llegó al banco, si la comisión explica la diferencia neta, o si un reembolso revirtió el pedido más adelante.
El equipo de finanzas es el que toma ese juicio. El flujo de trabajo tiene que hacerlo visible.
Si el problema inmediato está en la capa liquidación-banco, el flujo de trabajo relacionado para conciliar un CSV de liquidación de Stripe con tu extracto bancario es el lugar indicado para afinar esa parte del proceso. Para esta auditoría, mantén las tres capas visibles para que la respuesta final explique el movimiento completo desde el pedido hasta el efectivo.
Trabaja un ejemplo concreto de liquidación
Supón que el extracto bancario muestra:
| Bank date | Description | Amount |
|---|---|---|
| 2026-05-10 | STRIPE PAYOUT | 735.85 |
La hoja de liquidaciones muestra:
| Payout ID | Arrival date | Net payout |
|---|---|---|
po_9007 | 2026-05-10 | 735.85 |
Esa capa está limpia. La liquidación llegó al banco.
Ahora abre las transacciones dentro de po_9007:
| Transaction | Type | Reference | Gross | Fee | Net |
|---|---|---|---|---|---|
ch_1001 | Charge | Order #8214 | 250.00 | -7.55 | 242.45 |
ch_1002 | Charge | Order #8215 | 300.00 | -9.05 | 290.95 |
ch_1003 | Charge | Order #8216 | 220.00 | -6.55 | 213.45 |
re_2001 | Refund | Order #8202 | -10.00 | 0.00 | -10.00 |
| Total | 760.00 | -23.15 | 735.85 |
La hoja de pedidos muestra:
| Order ID | Payment reference | Order date | Order total | Status |
|---|---|---|---|---|
8214 | ch_1001 | 2026-05-08 | 250.00 | Paid |
8215 | ch_1002 | 2026-05-08 | 300.00 | Paid |
8216 | 2026-05-08 | 220.00 | Paid | |
8202 | ch_0990 | 2026-05-03 | 110.00 | Refunded |
El resultado de la auditoría no debe ser un total. Debe ser una tabla de estado:
| Fila | Resultado | Motivo |
|---|---|---|
ch_1001 / 8214 | Conciliado | Referencia de pago e importe bruto coinciden |
ch_1002 / 8215 | Conciliado | Referencia de pago e importe bruto coinciden |
ch_1003 / 8216 | Coincidencia candidata | Importe bruto y referencia de pedido coinciden, pero la referencia de pago no está en el archivo de pedidos |
re_2001 / 8202 | Reembolso explicado | El reembolso existe en la pasarela y el pedido está marcado como reembolsado |
po_9007 / depósito bancario | Conciliado | El importe neto de la liquidación coincide con el depósito bancario |
Ahora el equipo sabe qué corregir. El pedido 8216 necesita que se complete o documente la referencia de pago faltante. La liquidación en sí no está mal. Al banco no le falta dinero. La diferencia entre 760.00 bruto y 735.85 en efectivo se explica completamente por 23.15 de comisiones y 10.00 de reembolso.
Ese es el estándar para los equipos de startups que auditan liquidaciones de pasarela sin ingenieros de datos: cada línea está conciliada, explicada o registrada como excepción nombrada.
Etiqueta las excepciones en lugar de dejar filas sin conciliar
"Sin conciliar" no es un estado final. Es una cola de trabajo.
Usa etiquetas de excepción que le digan a la siguiente persona exactamente qué acción se necesita:
| Etiqueta de excepción | Significado | Acción |
|---|---|---|
| Referencia de pago faltante | El pedido existe, el cargo de pasarela probablemente existe, pero el archivo de pedidos no tiene la clave compartida | Revisar los campos de pago o metadatos en el sistema de pedidos |
| Cargo solo en pasarela | El cargo existe en la pasarela pero no coincide ninguna fila de pedidos | Buscar pedido faltante, cargo manual o filtro de fechas incorrecto |
| Fila de pedido pagado sin cargo en pasarela | El pedido está marcado como pagado pero no coincide ningún cargo de pasarela | Verificar otra vía de pago, cambio manual de estado o export fallido |
| Explicación de comisión | El total bruto del pedido coincide, pero el importe neto de la liquidación es menor | Verificar el registro de la comisión o su tratamiento contable |
| Timing de reembolso | El reembolso aparece en una liquidación posterior al pedido original | Vincular el reembolso al pedido original y anotar el timing |
| Diferencia de fechas | Misma transacción, fecha difiere por zona horaria esperada o retraso de liquidación | Anotar el timing, no tratar como faltante |
| Diferencia de importe | Misma referencia, importe diferente | Verificar captura parcial, descuento, impuesto, moneda o ajuste |
Aquí es donde las auditorías sin código suelen ser más confiables que las solicitudes ad hoc al área de ingeniería. Una consulta puede encontrar filas que no se unen. No decide automáticamente si una diferencia es un problema de timing de reembolso, un campo de metadatos faltante o un pedido realmente ausente.
El equipo de finanzas es el dueño de ese juicio. El flujo de trabajo debe hacerlo visible.
Genera un resultado que alguien pueda revisar
El resultado final de la auditoría debe ser más pequeño que los archivos originales y más claro que la hoja de trabajo.
Necesita cuatro secciones.
1. Resumen de liquidación
| Concepto | Importe |
|---|---|
| Depósito bancario | 735.85 |
| Liquidación de pasarela | 735.85 |
| Diferencia | 0.00 |
2. Composición de la liquidación
| Categoría | Importe |
|---|---|
| Cargos brutos | 770.00 |
| Comisiones | -23.15 |
| Reembolsos | -10.00 |
| Importe neto de la liquidación | 735.85 |
3. Comparación de pedidos
| Estado | Cantidad | Importe |
|---|---|---|
| Pedidos conciliados | 2 | 550.00 |
| Coincidencias candidatas | 1 | 220.00 |
| Cargos solo en pasarela | 0 | 0.00 |
| Filas de pedido pagado sin cargo en pasarela | 0 | 0.00 |
| Reembolsos explicados | 1 | -10.00 |
4. Lista de acciones
| Registro | Problema | Acción |
|---|---|---|
8216 | Referencia de pago faltante en el archivo de pedidos | Confirmar ch_1003 y actualizar el registro del pedido o documentar la coincidencia |
Este formato le da al operador, fundador, contador o controller la respuesta que necesita. La liquidación concilia con el banco. Las transacciones dentro de la liquidación concilian con los pedidos, excepto por una coincidencia candidata documentada. El trabajo pendiente es específico.
Una hoja de cálculo con colores y filtros no logra eso. Deja al revisor redescubriendo la lógica desde cero.
Decide cuándo es suficiente una auditoría sin código
Una auditoría de liquidación sin código es suficiente cuando los archivos tienen referencias estables, el volumen de liquidaciones es manejable, y el equipo necesita un reporte defendible más que un pipeline de datos permanente.
No es suficiente cuando los mismos campos faltantes siguen apareciendo cada mes y nadie corrige el sistema origen. Tampoco es suficiente cuando la lógica de liquidación depende de datos que no están en los exports. Si la pasarela nunca exporta el ID de pedido, y el sistema de pedidos nunca guarda la referencia de pago, cada auditoría dependerá de coincidencias candidatas más débiles.
La solución práctica es mejorar el vínculo entre archivos:
- Guarda los IDs de pago de la pasarela en el sistema de pedidos.
- Pasa los IDs de pedido a los metadatos de la pasarela.
- Exporta las transacciones de saldo, no solo los resúmenes de liquidación.
- Mantén los registros de reembolso en la misma revisión que el pedido original.
- Guarda el extracto bancario, el export de liquidaciones y el export de pedidos usados en cada cierre.
Esos cambios no requieren un ingeniero de datos. Requieren decidir qué campos prueban la conciliación y asegurarse de que esos campos aparezcan en los archivos que finanzas ya exporta.
Para flujos de trabajo recurrentes sin código, las herramientas de conciliación de transacciones sin configuración inicial pueden ayudar cuando el equipo necesita hacer la misma comparación cada mes sin querer construir ni mantener una capa de consultas.
Cuando la auditoría se convierte en un proceso mensual
La primera auditoría de liquidación sirve para encontrar la diferencia. La segunda sirve para evitar la misma investigación.
Mantén una plantilla mensual para la revisión, pero no fijes las posiciones de columnas. Los exports de pasarela cambian. Los sistemas de pedidos agregan campos. Las descripciones del extracto bancario varían. Construye el proceso alrededor del significado de los campos: ID de liquidación, ID de transacción, ID de pedido, importe bruto, comisión, importe neto, depósito bancario, reembolso, estado.
Antes de cerrar la auditoría, verifica:
| Verificación | Hecho |
|---|---|
| El importe neto de la liquidación coincide con el depósito bancario | ☐ |
| El ID de liquidación o referencia de pasarela está registrado | ☐ |
| Los cargos dentro de la liquidación están conciliados con pedidos | ☐ |
| Las comisiones explican la diferencia entre bruto y neto | ☐ |
| Los reembolsos y disputas están etiquetados por separado | ☐ |
| Las coincidencias candidatas no se tratan como conciliadas | ☐ |
| Cada excepción tiene un responsable | ☐ |
| El resultado final se puede revisar sin abrir cada archivo original | ☐ |
El objetivo no es convertir al equipo de finanzas en un equipo de datos. El objetivo es demostrar qué pasó con el dinero usando los archivos que ya tienes: extracto bancario, export de liquidaciones, detalle de transacciones y hoja de pedidos. Una vez que concilias esos archivos por capas, la auditoría deja de ser una búsqueda en filas y se convierte en un reporte que el equipo puede cerrar.
