A promise enters the spreadsheet
At fictional sound studio Harbour Audio, producer Noa agrees a project with client Cedar Films. Later, invoice INV-208 requests EUR1,200. A finance dashboard displays a box called PaymentObligation and draws an arrow from that box to the invoice. It looks tidy enough to settle the matter.
But what does the arrow claim? That the invoice documents a payment request? That it relates to an existing commitment? That issuing it created a commitment? These are different propositions. A neat diagram cannot choose among them simply by drawing the line with a confident colour.
Before the invoice has a number
Payment commitments can arise in arrangements that precede an invoice, or in situations where no invoice exists. For this fictional workflow, the studio wants to track an agreed project commitment and later connect the billing records that describe it. That is a modelling choice, not a conclusion about anyone's legal rights.
A payment-obligation model should specify the parties, the amount, the relevant evidence and its relationship to billing documents. An invoice can document a payment request without being the commitment's only possible source. The diagram illustrates this workflow; it does not establish legal rights.
The order that became two invoices shows why a request, a supply record and a payment request deserve separate identities. The invoice that arrived before the money follows the equally important gap between billing and recorded payment.
Two arrows reduce one balance
Now use a deliberately simple example. INV-208 has an invoice total of EUR1,200. Payment P-11 allocates EUR300 to it. Payment P-19 allocates another EUR400. Assume there are no adjustments, credits, fees, refunds or currency conversions in this example.
The outstanding amount is EUR1,200 − EUR300 − EUR400 = EUR500. The balance diagram makes each allocated payment visible, ending with EUR500 still outstanding. The allocation is essential: a payment received from Cedar Films is not automatically a payment against this particular invoice.
A single payment might be allocated across several invoices, or remain partly unallocated. The model needs room for that reality. Otherwise the system confidently spends the same EUR400 twice, a feature customers rarely request in writing.
Put names on the parties
Noa is the studio's contact. Harbour Audio is the service provider. Cedar Films is the customer in this scenario. A debtorId or creditorId should resolve to a defined party role, with its meaning stated in the owning model, rather than an arbitrary contact record.
Customer is a role explains the commercial connection. Organization beyond the name helps keep that connection intact when a company changes its display name. Currency is part of the number keeps both the starting amount and every allocation interpretable.
A balance needs a point of view
EUR500 outstanding is true for these stated records and assumptions at a stated point in the workflow. A later allocation changes it. A reversed payment changes it again. Recording an allocation date separately from a bank transaction date can explain why two systems briefly disagree.
A practical model therefore preserves the events behind the balance and identifies the snapshot being shown. It also keeps the obligation, supporting documents and settlement evidence distinct. That makes a graph useful for investigation: readers can follow why an amount appears, which records support it and what would change it, without treating a plausible label as a verdict.
