Payments
Payments are a single ledger covering all three modules. A rental, a sales order and a repair are three very different things operationally, but the money is tracked in one place, so "what is owed to us" has one answer rather than three.
Every payment has exactly one parent
A payment belongs to a rental, or a sales order, or a service order — never to more than one, and never to none. This is enforced at the database level, not just in the interface, so the ledger cannot drift into a state where money is attached to nothing.
The practical consequence: if a customer pays a single amount covering both a rental and a repair, record it as two payments, one against each. That is what keeps each record's own balance correct.
What a payment records
- Amount
- Due date — when you expect the money
- Paid date — when it actually arrived
- Status — see below
- Payment method — cash, card, Pix and so on
Payment statuses
| Status | Meaning |
|---|---|
| Upcoming | Due in the future |
| Pending | Due now, not yet paid |
| Paid | Settled, with a paid date |
| Overdue | Past its due date and unpaid |
The payments screen
The list defaults to sorting by paid date, so the most recent activity is what you see first. A hide pending toggle strips the list down to settled money when you are reconciling rather than chasing.
What reaches the dashboard
Pending payments belonging to active rentals appear on the dashboard automatically, alongside overdue totals. This is deliberate: equipment that is out with a customer and unpaid is the money most likely to be quietly forgotten.
Receipts
Payment receipts itemise the underlying services and costs rather than showing a single total, so a customer collecting a repaired generator sees the parts and the labour separately.
Cash payments and the drawer
If your company uses the cash register and a session is open, cash payments are counted against that session automatically — you do not record them a second time. See Cashier.