Glossary
Payment history
The dated record of every payment received from a client, in order, showing how a balance reached its current state.
What it means
A payment history is the list behind the total. Each entry records an amount, the date it arrived and usually a note about what it covered.
Its value is not the sum — that could be stored in one field. It is that the sequence can be read. A history shows whether payments arrive promptly or after chasing, whether they have slowed, and whether an amount was ever short. None of that is visible in a total.
It is also what settles disputes. When a client believes they have paid more than your records show, a dated list usually resolves it in one message, because most disputes are genuine confusion — a payment attributed to the wrong project, or an instalment nobody recorded.
For a history to be worth keeping, dates must mean the date money arrived rather than the date it was typed in. A system that stamps everything with today's date produces a chronology that is wrong in ways nobody notices until it matters.
Reading the sequence
A client's history shows $20,000 on 12 January, $10,000 on 4 February and $5,000 on 19 February against a $50,000 fee.
The total says $35,000 paid and $15,000 outstanding. The sequence says something more useful: the payments are getting smaller and further apart.
That pattern is a reason to follow up now rather than waiting another month — a judgement the total alone would not support.
Illustrative example. Names and amounts are made up.
How this works in Umikflow
- Every payment keeps its own amount, date and note on the client file, listed in order.
- The date is set by you when recording, so entering last week's payments today still produces a correct timeline.
- The dashboard also surfaces the most recent payments across all clients, as a check that what you think you recorded is what you did.