Por qué el dinero que te manda una OTA nunca coincide con el total de la reserva
La reserva dice 480 €. El abono del banco dice 412,37 €. No hay ningún error, y ese es justamente el problema: un sistema que solo conoce el bruto va a dejar ese abono sin conciliar para siempre.
Tres números que se tratan como uno
Una reserva de canal lleva al menos tres magnitudes financieras, y no son intercambiables:
- El bruto. Lo que pagó el huésped, y el único número que guarda la mayoría de los sistemas.
- La comisión. La retención del canal — y cada vez menos un número único, porque algunos canales aplican tipos distintos a tipos de estancia distintos.
- Los gastos de cobro. La comisión de la tarjeta, distinta de la del canal, a veces cargada por el canal y a veces por quien cobró.
Al banco llega el cuarto número: el pago neto, que es el bruto menos la suma de los otros dos. Si solo guardas el bruto, tienes un histórico de reservas que no se puede conciliar con un extracto, y tu facturación real vive en una hoja de cálculo que alguien mantiene a mano.
NULL es un valor real; cero es una afirmación
Esta es la parte que corrompe en silencio los informes. Cuando un canal no comunica su comisión — y muchas integraciones no lo hacen, para ciertos tipos de estancia o ciertas versiones de plan — hay dos formas de guardarla.
Como cero, que es una afirmación: esta reserva no nos costó nada en comisiones. Como NULL, que es otra afirmación: no sabemos cuánto nos costó.
Una reserva directa sí tiene retención cero. Una de canal con la comisión ausente no, y una vez guardadas igual ningún informe vuelve a distinguirlas. En Boris las cuatro columnas de canal admiten NULL a propósito: no es descuido con los valores por defecto, es la única forma de que un margen pueda decir después qué parte de sí mismo es desconocida.
Deduce un lado, nunca los dos
Los proveedores no se ponen de acuerdo en qué cifras enviar. La misma reserva puede llegar con comisión y sin neto, con neto y sin comisión, con las dos o con ninguna — y el campo se llama hostPayout, netAmount, payoutAmount, ownerRevenue o importoNetto según con quién hayas integrado, a veces anidado dentro de un bloque money o financials.
Normalizar eso es trabajo poco agradecido, y hay exactamente una regla que merece enunciarse: puedes calcular el lado que el canal omitió, y no debes calcular los dos.
- Comisión conocida → el neto es bruto menos comisión menos gastos.
- Neto conocido → la comisión es la diferencia, y si esa diferencia redondea a cero se queda desconocida en lugar de convertirse en un seguro 0,00 €.
- Ninguno conocido → los dos se quedan en NULL. La reserva sigue siendo correcta; simplemente no pretende conocer su propio margen.
La conciliación tiene que aceptar dos importes por reserva
Casi toda la lógica de cuadre compara un abono con el saldo pendiente de la reserva. Funciona con las reservas directas y falla con todas las de canal, porque el abono es el neto.
El arreglo es pequeño: al cuadrar una transacción, trata el neto guardado como un segundo importe aceptable para la misma reserva, con un par de céntimos de tolerancia, y marca cuál de los dos hizo match. En Boris esa marca vive en el propio cuadre — un abono cuadrado por el neto es una prueba distinta de uno cuadrado por el bruto, y cuando tienes que explicarle un mes a tu asesor esa distinción es toda la respuesta.
Dos matices que se pagan solos. Limita el cuadre en el tiempo, para que un abono de 412,37 € no se enganche a una estancia de hace ocho meses que casualmente costaba lo mismo. Y salta las reservas que ya tienen factura no anulada, porque ese dinero tiene otro destino.
Los pagos agrupados son el siguiente muro
El neto por reserva resuelve el caso del abono individual. Los canales que remiten cada quince días una sola transferencia por catorce estancias son un problema más difícil, y conviene ser honesto con el orden de las cosas: no se puede desglosar un agregado que no sabes valorar. Guardar el neto previsto por reserva es lo que hace que el agregado sea resoluble, porque entonces es una suma que puedes buscar y no un número que nadie sabe explicar.
Qué exigirle a un informe antes de fiarte
Si un panel te enseña un take rate por canal, hazle dos preguntas:
- ¿Cuántas reservas dentro de esa cifra no comunicaron ninguna comisión?
- ¿La columna del neto usa el neto comunicado, o el bruto donde el neto falta?
El margen por canal de Boris cuenta aparte las filas sin comisión comunicada y muestra ese recuento junto al tipo, que es el motivo por el que a veces lo etiqueta como mínimo. Un informe que no sabe decirte qué parte de sí mismo está estimada no es más exacto que uno que sí lo sabe — solo es más seguro de sí.
Preguntas frecuentes
¿Por qué los pagos de las OTA no se concilian solos?
Porque la conciliación compara un abono bancario con el saldo pendiente de la reserva, y un canal nunca paga el bruto. Booking.com remite el importe menos su comisión, a veces menos los gastos de cobro, a veces agrupando varias estancias. La solución es guardar el neto previsto por reserva y aceptarlo como segundo importe válido para esa misma reserva.
¿Una comisión que falta es lo mismo que una comisión cero?
No, y confundirlas es el error de modelado más caro de todo esto. Una reserva directa no tiene retención. Una reserva de canal cuya comisión nunca se comunicó tiene una retención desconocida. Guardada como cero, infla tu margen y ya nadie puede distinguir qué filas son reales.
¿Se puede calcular la comisión a partir del neto?
Se puede deducir un lado, nunca los dos. Si el canal mandó la comisión, el neto es bruto menos comisión menos gastos. Si mandó el neto, la comisión es la diferencia. Si no mandó nada, el valor honesto es NULL: deducir los dos es inventarse el par y presentarlo como dato.
¿Por qué engaña un take rate sobre datos parciales?
Porque contar las comisiones desconocidas como cero baja la media. Si 40 de 100 reservas no comunicaron retención, el 12 % que ves es un mínimo, no un tipo. Un informe tiene que decir cuántas filas van sin dato, o es un número seguro construido sobre una suposición.