El total de una reserva, el importe que corresponde al proveedor del vehículo y el dinero que llega a una cuenta bancaria responden a preguntas distintas. Compararlos como si fueran la misma cifra puede crear falsas incidencias y ocultar errores reales.
Respuesta rápida: concilia primero cada reserva con los importes pactados con el proveedor; después, con las transferencias realizadas. Por separado, relaciona las operaciones del procesador de pagos con los abonos bancarios. Conserva la moneda, el criterio de fechas y las pruebas de cada ajuste.
Esta guía de cierre para operadores utiliza categorías de la documentación de Orcar ERP y documentación pública de pagos. No incluye clientes reales, tarifas de socios ni calendarios contractuales de liquidación.
1. Separa venta, derecho de cobro y efectivo
| Registro | Qué responde | Qué no demuestra |
|---|---|---|
| Venta y pago del cliente | Qué se cobró o reembolsó al viajero | Cuánto corresponde al proveedor |
| Liquidación del proveedor | Importe debido por reservas elegibles y ajustes pactados | Que el dinero llegó a su banco |
| Abono del procesador y movimiento bancario | Qué dinero se trasladó y a qué cuenta | Que todas las reservas y obligaciones estén liquidadas |
El informe de conciliación de Stripe relaciona los abonos bancarios con sus lotes de pagos y otras operaciones. Distingue importes brutos, comisiones, netos y operaciones aún no abonadas.[8] Un abono del procesador al vendedor no equivale a una transferencia del vendedor a la empresa de alquiler.
Define también «ventas»: el valor presupuestado, el dinero cobrado y el ingreso contable no son intercambiables. Esta es una guía operativa, no asesoramiento contable o fiscal. La diferencia entre el precio al cliente y el importe del proveedor no demuestra por sí sola un beneficio.
2. Crea una hoja de conciliación por reserva
Usa una fila por reserva para los importes acordados y filas vinculadas para cada reembolso, ajuste y asignación de transferencia. No sobrescribas el importe original cuando aparezca una operación posterior.
| Grupo | Datos que conservar | Comprobación |
|---|---|---|
| Identificación | Referencias interna y del proveedor, canal, moneda | ¿Hay duplicados o un proveedor incorrecto? |
| Fechas | Reserva, pago, recogida, devolución, ajuste, periodo y zona horaria | ¿Qué evento determina la inclusión según el contrato? |
| Importes | Vehículo, protección y extras pactados, ajustes aprobados | ¿Quién recibe o asume cada partida? |
| Movimientos | Identificador del pago o reembolso, referencia bancaria, importe asignado | ¿Se ha contado dos veces una operación? |
| Resolución | Importe debido, pagado, pendiente, motivo y revisor | ¿La diferencia está documentada? |
La documentación de Orcar ERP organiza los informes por socio con recuentos de reservas, ingresos de vehículos y extras, reembolsos y liquidación neta. Son categorías de partida, no una fórmula contractual universal. Un informe descargado tampoco demuestra que se haya pagado.
Separa protección y extras cuando tengan distintos beneficiarios. Un descuento financiado por la plataforma no tiene necesariamente el mismo efecto que uno asumido por la empresa de alquiler. Consulta el acuerdo antes de deducirlo del importe del proveedor.
3. Calcula una reserva ficticia
Ejemplo inventado exclusivamente para explicar el método. No son precios, comisiones ni datos de clientes de Orcar. Supongamos una reserva en KRW, un proveedor, sin conversión de moneda y con impuestos y comisiones de procesamiento resueltos por separado.
El cliente pagó 300.000 KRW. Al proveedor le corresponden 240.000 KRW por el vehículo y 12.000 KRW por un extra. Más tarde se reembolsan 30.000 KRW al cliente. Solo para este ejemplo, las partes aprueban reducir 20.000 KRW del importe del proveedor; el vendedor asume el resto del reembolso.
| Cálculo del proveedor | KRW |
|---|---|
| Vehículo pactado | 240.000 |
| Extra pactado | +12.000 |
| Ajuste aprobado | -20.000 |
| Total debido al proveedor | 232.000 |
| Transferencia ya asignada | -100.000 |
| Pendiente de conciliar | 132.000 |
El cobro neto al cliente es 270.000 KRW; el derecho del proveedor, 232.000 KRW; el saldo pendiente, 132.000 KRW. La diferencia de 38.000 KRW entre los dos primeros no es un beneficio demostrado: el ejemplo no calcula todos los costes e impuestos del vendedor.
No vuelvas a restar el reembolso de 30.000 KRW de los 232.000 KRW. La parte del proveedor ya está reflejada en el ajuste aprobado. Si no existe acuerdo sobre el reparto, déjalo pendiente, sin inventar porcentajes.
4. Investiga diferencias en un orden fijo
- Alcance y moneda: compara el mismo socio y canal. Si la moneda del cliente difiere de la de liquidación, conserva ambas y el cambio realmente aplicado, no el de hoy.
- Corte del periodo: distingue el mes de reserva, recogida, ajuste y transferencia. Una partida fuera del periodo puede ser una diferencia temporal.
- Titular de cada partida: confirma quién recibe los extras o asume descuentos y comisiones. Una deducción del procesador no tiene por qué ser una deducción del proveedor.
- Reembolsos y recuperaciones: vincula el reembolso al ajuste aprobado y comprueba si hay que recuperar dinero ya transferido.
- Efectivo y duplicados: coteja referencias y asignaciones; revisa movimientos fallidos, pendientes o repetidos. Cuenta reservas y transacciones por separado.
Stripe ofrece un ejemplo concreto: en su integración de cargos y transferencias separados, reembolsar un cargo no revierte automáticamente las transferencias asociadas. La plataforma debe conciliar la recuperación por separado.[7] Esto describe esa arquitectura, no afirma que Orcar o todas las empresas de alquiler utilicen Stripe Connect así.
El informe de Stripe para abonos automáticos agrupa transacciones por lote. Para abonos manuales remite al informe de saldo; los instantáneos requieren conciliación con el historial de operaciones.[8] Elige según el flujo real.
5. Cierra con una lista de excepciones
Para cada diferencia abierta, conserva importe, moneda, motivo, prueba pendiente, responsable y próxima revisión. Distingue desfases de fechas, ajustes sin aprobar, referencias bancarias ausentes y discrepancias contractuales. Explicar una diferencia no significa haberla resuelto: mantenla abierta hasta disponer de pruebas.
Un cierre defendible conecta reserva, acuerdo, cambios aprobados y movimiento bancario. No modifica importes hasta que coincidan dos hojas. Usa referencias de reserva y elimina datos de pago antes de compartir ejemplos fuera del equipo autorizado.
Las categorías de Orcar ERP ayudan a estructurar esa revisión. Esta guía no promete conciliación bancaria automática, fechas fijas de pago ni una reducción medida de errores. Amplía el contexto en cómo funciona un sistema de reservas y distingue el problema del viajero en cómo rastrear un reembolso.
¿Quieres hablar de tu proceso con Orcar? Prepara una muestra sin datos identificativos con estas columnas y utiliza las opciones de contacto de Orcar. No incluyas documentos de clientes ni tarifas confidenciales en la primera consulta.
6. Preguntas frecuentes
¿Deben coincidir las ventas y el pago al proveedor?
No necesariamente. La venta, el derecho contractual y el dinero transferido tienen definiciones distintas. Documenta cómo se pasa de una cifra a otra.
¿Un reembolso recupera automáticamente lo pagado al proveedor?
No lo supongas. Comprueba el contrato y el sistema de pagos. El ejemplo de cargos y transferencias separados de Stripe exige conciliar las transferencias aparte.[7]
¿Una transferencia puede liquidar varias reservas?
Sí. Registra una sola referencia bancaria y reparte el importe, sin repetir el total en cada reserva. Los abonos del procesador también pueden agrupar varias operaciones.[8]
¿Una diferencia sin explicar es una pérdida?
No necesariamente. Revisa alcance, fechas, moneda, ajustes y pruebas bancarias antes de clasificarla como pérdida o simple desfase.
Fuentes y alcance: [8] Stripe: informe de conciliación de abonos. [7] Stripe: cargos y transferencias separados. Consultadas el 23 de septiembre de 2026. Las descripciones de Orcar reflejan documentación del producto, no una auditoría de liquidaciones reales. La imagen generada es conceptual, no una captura del ERP ni un gráfico financiero.