Hay saldo, pero no historial: cuándo los pagos necesitan un libro mayor

El saldo del vendedor en su panel era de 100 euros y ahora es de 70. El desarrollador explica: «Ajustamos el saldo después de un reembolso». El equipo financiero pregunta: ¿qué reembolso, quién lo autorizó y por qué de 30? Si la respuesta solo está en un chat, la cifra en pantalla ya dejó de ser un resultado verificable. Se convirtió en la última opinión de alguien sobre el dinero.

Un libro mayor interno de dinero hace falta cuando el producto registra obligaciones y varios tipos de movimiento de fondos. Su tarea: para cada importe, mostrar el motivo del cambio, las partes relacionadas y la prueba. A continuación analizamos el modelo operativo. El esquema de asientos contables, la contabilidad fiscal y los requisitos de conservación se definen por separado con los especialistas responsables.

Qué significa exactamente su saldo

Empiece por la pregunta que la interfaz promete responder. «Cuánto le debemos al vendedor», «cuánto se puede liquidar ahora» y «cuánto tiene el PSP» describen magnitudes distintas. Si se las llama con una sola palabra, el equipo de desarrollo corregirá cifras supuestamente erróneas que en realidad responden a preguntas diferentes.

El modelo propuesto guarda por separado las obligaciones confirmadas, las restricciones de disponibilidad y los movimientos reales. Una retención puede reducir la liquidación disponible sin extinguir la obligación. Una solicitud de liquidación enviada todavía necesita un resultado documentado. La definición de cada indicador debe estar al alcance de soporte junto con su desglose: qué registros entran en el importe y por qué.

La partida doble ayuda a comprobar la coherencia del movimiento de valor: el debe y el haber de una operación deben cuadrar. La documentación de TigerBeetle explica este principio y cómo el signo del cambio depende del tipo de cuenta. Es un mecanismo de control, no una prueba automática de que la clasificación económica sea correcta.

Un pago hipotético de 100 euros

Supongamos que el modelo acordado del marketplace reparte un pago confirmado así: al vendedor le corresponden 97 euros y la comisión de la plataforma es de 3 euros. El PSP retiene por separado 2 euros de costes de la plataforma. En este ejemplo didáctico se excluyen impuestos, reservas y otras retenciones.

Tras estos eventos, el derecho de cobro de la plataforma frente al PSP es de 98 euros. La obligación con el vendedor es de 97 euros. El resultado económico de la plataforma antes de otros gastos es de 1 euro. Se puede comprobar la igualdad: 98 = 97 + 1. Si en la interfaz del vendedor aparece 98, probablemente se mezcló el dinero en manos del proveedor con la obligación frente al vendedor.

Ahora, de los 97 euros del vendedor, 20 quedan restringidos temporalmente por un motivo acordado de antemano. Hay 77 disponibles para liquidar, pero la deuda total con él sigue siendo de 97. Levantar la restricción devolverá la disponibilidad, no creará una venta nueva. Si el modelo del producto trata la retención de otra forma, hay que reflejarlo explícitamente, no forzar el cálculo para que encaje con el ejemplo.

Para cada registro, guarde el número de operación, la moneda, el motivo, la hora del evento, la hora del registro y el vínculo con el pago original. Conviene distinguir ambas horas: hoy puede llegar un mensaje sobre un evento de ayer. La política de asignación al periodo contable debe estar acordada; de lo contrario, una carga nocturna cambiará sin que nadie lo note un informe ya entregado.

Una corrección deja rastro

En este modelo, un registro erróneo se corrige con un ajuste vinculado, no borrando las huellas. En la cadena se ven el evento original, el error detectado y la corrección aprobada. El ajuste tiene autor, motivo y confirmación. Así otra persona podrá reconstruir lo ocurrido sin acceder al chat privado del desarrollador.

Sin embargo, un registro inmutable también puede conservar con esmero datos incorrectos. No sabrá por sí solo que un pago se asignó al vendedor equivocado. Por eso hacen falta comprobaciones de pertenencia de la operación, de transiciones admisibles y una conciliación independiente con el PSP y el banco. Que los totales cuadren ayuda a detectar parte de los errores, pero dos errores que se compensan entre sí pueden mantener el cero general.

Regla operativa para una corrección manual: muestre el efecto esperado antes de ejecutarla. ¿Qué importe cambiará y para qué participante? ¿Qué disponibilidad será distinta? ¿Cómo se reflejará el ajuste en el próximo informe? Para las acciones relevantes, aplique las facultades acordadas y el control de una segunda persona.

Los céntimos y las monedas son parte del modelo

No sume euros y dólares en una misma cuenta sin una operación de cambio explícita. Guarde la moneda y la escala del importe. En la API de Stripe, los importes suelen expresarse en la unidad mínima, aunque para algunas monedas y liquidaciones rigen reglas especiales. Las reglas de formato de importes de Stripe muestran por qué el «multiplicar por cien» universal es peligroso.

Para su propio modelo, elija una representación numérica exacta y reglas de redondeo en cada frontera. Una prueba didáctica que reparte un euro entre tres participantes debe explicar el céntimo sobrante. Asignarlo a un participante al azar según el orden de procesamiento equivale a obtener un resultado financiero inestable.

Empiece por un saldo en disputa

Elija un tipo de operación real, pero use datos sintéticos para el diseño. Intente reproducir el saldo a partir de los registros sin leer el campo balance ya calculado. Después añada un evento repetido, un informe tardío, una corrección parcial y una restricción de disponibilidad. Si distintas personas obtienen el mismo importe explicable, el modelo empieza a funcionar.

La conciliación responde si sus registros coinciden con los datos externos. El libro mayor responde por qué considera usted que a alguien le corresponde ese importe. Sin la segunda pregunta, la primera tarea se convierte fácilmente en un cuadre diario de cifras a la fuerza.