Un pago se imputa, no se asigna

El primer modelo natural es un pago con una foreign key a una factura. Sobrevive hasta que el primer cliente paga un número redondo que cubre dos facturas y parte de una tercera.

Lo que pasa de verdad en cobranzas: llega plata, y alguien decide adónde va. A cuotas en orden. A varias facturas. Parcialmente, dejando un resto que se vuelve crédito. A veces se reimputa después, porque el cliente dice que era para otra cosa.

Nada de eso entra en una sola foreign key.

El modelo que aguanta

El pago es su propia entidad, con importe y fecha. Y aparte hay registros de imputación que lo vinculan con lo que salda — cada uno con su propio importe. La suma de las imputaciones es, como máximo, el pago. Lo que sobra es crédito en la cuenta.

Lo que esto compra, más allá de la corrección:

• La reversa se vuelve posible. Deshacer un pago es deshacer sus imputaciones — que son registros explícitos, no una mutación que hay que reconstruir.
• El pago parcial deja de ser un caso especial.
• La pregunta “¿por qué esta cuota figura saldada?” tiene una respuesta que le podés mostrar al cliente.
• La reimputación es una operación normal, no un arreglo de datos.

El costo, y por qué vale

Cada lectura es un join y el saldo es una suma. Ese es el precio — y es el correcto, porque la alternativa no es más simple: es la misma complejidad implementada como una serie de excepciones.

La lección general: cuando una relación entre dos objetos de negocio lleva adosados una cantidad, una fecha o un motivo, no es una foreign key. Es una entidad.