Ask for money up front, record it when it lands, and spend it down against the work as you go. Every movement is a real event with a document behind it, and the receipt shows the customer exactly how the number was arrived at.

Request a deposit and the app produces a numbered document stating what you are asking for and the total it is measured against, sent the same three ways as anything else. When the money comes in, record it against the request. If they pay part of it, that is a real event too: the documents say where the request stands and what is still owed on it. And a deposit that arrived before you ever asked can be recorded on its own.

  • Numbered deposit request stating the amount and the total behind it
  • Sent by BuiltWright email, your own mail app, or the share sheet
  • Record the deposit when it lands, against the request
  • Partial payment against a request handled as its own event
  • Record a deposit that came in before any request existed

Deposit money does not just sit there as a number. It gets applied to purchases and invoices, and every movement in or out is recorded. Available, applied, and remaining are tracked per deposit and across the job, so the question of how much of their money you are still holding always has an answer. Turn on auto-apply and purchases draw against the deposit on their own, or leave it off and apply it yourself.

  • Every movement of deposit money in and out, with a transaction history
  • Available, applied, and remaining, per deposit and in total
  • Applied to purchases and to invoices
  • Optional auto-apply of deposits to purchases
  • Deposit covers a line at what the customer is billed, so work they already paid for shows nothing still owed
  • Customer credit surfaces when you took more than the job consumed

Jobs fall through and deposits come back. Cancelling a request and refunding money are both recorded events with their own status and their own documents, rather than a record you quietly remove. So a year later the history reads honestly: money came in on this date, this much of it was spent, this much went back, and here is the paper for each step.

  • Cancel a deposit request as a recorded event with its own status
  • Refund a deposit with a document behind it
  • The history stays intact rather than being erased
  • The ledger reflects the refund like any other movement

Every payment produces a receipt, and the receipt shows its arithmetic instead of just a number. Contract total, what was received before this, what they just paid, credit for work that was approved and then skipped, and the balance left. Every row prints even when it is zero, because "previously received, nothing" is exactly what a first receipt needs to say. Underneath, it names every payment on the job to date and which receipt covered each one, so the document accounts for the whole job rather than one moment in it.

  • Contract total, previously received, this payment, credits, and balance
  • Every row prints, including the zeroes
  • Credit for approved work that was skipped, so the shortfall explains itself
  • Payment history naming every payment and the receipt it was issued on
  • A job with no approved work or issued estimate omits the contract line instead of printing zero
  • Numbered, branded, and permanent, like every other document

Deposit requests, a ledger that tracks every dollar in and out, refunds that stay on the record, and receipts that show their arithmetic. Bought once, with no monthly charge behind any of it.