What is an obligation in billing?
An obligation is the fact that a specific party is expected to pay a specific amount, for a specific reason, by a specific date. An invoice is a document that communicates it.
Most systems store only the document, and inherit a set of problems as a result.
The problems that come from storing only invoices
Three, and each of them is familiar to anyone who has closed a period.
- An invoice you forgot to raise is revenue that never existed. There is no record that anything was owed.
- An invoice that is voided and reissued has erased its own history. The previous amount, and the reason it changed, are gone.
- Money owed under a standing agreement that nobody invoices monthly does not appear as expected revenue at all.
What an obligation carries that an invoice does not
An obligation exists because of a relationship and a policy. A member owes annual dues because they are a member. A resident owes service charge because they occupy a unit. That is true whether or not paperwork was generated.
It also carries its own state, and the state model is richer than an invoice's. An invoice is roughly paid or unpaid. An obligation can be upcoming, due, partially fulfilled, fulfilled, overdue, disputed, rescheduled, waived, canceled or written off — and, importantly, moving between those states does not delete the previous one.
Why the history matters
The question that exposes an invoice-only model is: what did this account owe on 31 March, as at 31 March? Not what a corrected ledger now says it owed.
Arrears schedules, AGM registers, conveyancing inquiries and legal escalations all ask a version of that question. A model that rewrites charges in place cannot answer it, and the answer usually matters most when the relationship has already deteriorated.
The practical consequence
Keeping the obligation separate means you can answer 'what should we have collected?' from the obligations rather than by counting documents — which in turn makes every ratio built on it trustworthy.