Payments are separate rows against an invoice, each with an amount, method, reference, date and notes, plus who recorded it. The invoice's paid_amount and balance are updated from them, and status flips to partial or paid. Full payment on a materials or final invoice also nudges the project pipeline forward.
Also called: mark as paid · log a cheque · customer paid · record a deposit · part payment
- 1Record Payment defaults the amount to the outstanding balance and opens with the method picker.
- 2A live duplicate check warns before submitting if a matching reference or same amount/date already exists.
- 3Recording writes the payment row, recomputes paid and balance, and flips status when the balance clears within half a cent.
- 4A fully-paid invoice fires an event-driven pipeline nudge (materials paid to Materials, final paid to Complete) fire-and-forget, so recording never blocks on it.
Builders take cheques, e-transfers and cash long before they take cards, and an invoice that can only be settled online sits open in the system while the money is already in the bank. Payments are recorded by hand with a date, method, reference and note, partial amounts included, and the balance and status follow. Card payments land in the same place when they arrive, so an invoice's payment history reads the same however the money came in — and a payment that clears a job's balance nudges the project forward rather than asserting it has moved.
- Payments tracked outside the system and drifting from the invoices.
- Manually recomputing a balance after a part payment.
- The project board not reflecting that money has landed.
See it on your own jobs
Twenty minutes, your numbers, no slide deck. We’ll build one of your real buildings in front of you and send you the estimate link at the end — yours to keep either way.
or keep browsing features →