The Money That Arrives Before the Sale
A customer pays half up front for something you have not made yet. That money is in your bank and it is not your revenue — and most systems have nowhere to put it except an invoice for goods you have not delivered.
Somebody orders forty chairs, pays half to start the work, and the money lands in your account this morning. Nothing about that is unusual and every part of it is sensible: you need the cash to buy materials, and they need you committed. The question is what your system now says happened — and in most of them the honest answer is "a sale", which is the one thing that definitely did not happen.
This matters more than it sounds, because the error compounds in two directions at once. Your revenue for the month is overstated by money you have not earned, and your obligations are understated by the same amount — you owe those chairs, and nothing in the record says so. One mistake, counted twice.
Three kinds of early money, and only one is yours
| What arrived | What it actually is | When it becomes revenue | What happens if you cancel |
|---|---|---|---|
| A deposit on an order | An obligation. You owe goods or a refund. | On delivery, in full or in part. | Returnable, less whatever your terms allow you to keep. |
| A non-refundable booking fee | Earned on receipt, genuinely. | Immediately — you sold the option, and the option was taken. | Yours. This is the only row where cancellation costs you nothing. |
| A retainer or credit on account | A balance the customer owns and can spend. | As it is drawn down against actual work. | Returnable in full unless drawn. |
| A security deposit | Not yours at any point. You are minding it. | Never. It is not revenue in any circumstance. | Returnable in full, and holding it should be provable. |
Where it goes in a system with no place for it
The structural question is simple: can your system record money from a customer that is not attached to an invoice? For a great many systems — including this one — the answer is no, and it is worth stating precisely rather than discovering it on a Friday.
The constraint here, stated exactly
A customer payment must reference an invoice. The link is mandatory at the database level, not merely in the interface, so there is no on-account balance, no unallocated receipt and no credit sitting against a customer waiting to be applied. Money is recorded against a document, or it is not recorded. One consequence is worth knowing before it surprises you: the payment is tied to the invoice such that removing the invoice removes the payment record with it, so an invoice raised in error and deleted takes the evidence of a real receipt along with it. Reverse with a credit note rather than deleting, and the trail survives.
So the deposit has to become an invoice. That is the only door, and taking it has consequences you should choose deliberately rather than absorb by accident.
The deposit has to become an invoice, because an invoice is the only thing a payment can attach to. Which means your receivables now contain a document for goods that do not exist yet.
The deposit invoice, and the three things it costs you
Raising an invoice for the deposit amount works, and it is what almost everybody does. It is worth being clear-eyed about what it does to your numbers.
- Your revenue moves early. A deposit invoice dated today puts that amount into today's sales figure, weeks or months before you deliver. If your month-end reporting reads from invoices, the month is overstated — and the month you finally deliver in is understated by the same amount, so two periods are wrong to make one payment right.
- Your receivables briefly lie. Between raising the deposit invoice and receiving the money, that amount is an outstanding debt. It is usually outstanding for about four minutes, but if the two events land either side of a period end, your ageing report shows a debtor who has in fact already paid.
- Your tax point may move, and that is not a preference. In many places issuing a tax invoice is itself the event that creates the liability, regardless of whether anything has been delivered. Whether a deposit should carry tax is a jurisdiction question with a real answer, and it is the one item on this page you should not resolve by reasoning from first principles.
The mitigation for the first two is the same and it is unglamorous: make deposit invoices identifiable. A consistent prefix, a dedicated item line, anything that lets a report separate "invoiced because delivered" from "invoiced because paid in advance". Without that marker, no amount of care at the point of entry can be recovered later, because the two are indistinguishable in the data.
Cancellation is the test that finds everything
Every weakness in a deposit process shows up on cancellation, which is why it is worth walking through before you need to. The customer cancels the forty chairs. You have their money, you have bought some timber, and now four questions arrive at once: how much do you return, what document reverses the deposit invoice, what happens to the revenue you already recognised, and who decides.
The first is commercial and belongs in your terms, written before the order rather than negotiated after the cancellation. The second is mechanical — a credit note against the deposit invoice, never a deletion, for the reason in the callout above. The third follows from the second automatically if your reporting reads net of credit notes, and does not if it reads gross, which is worth checking once rather than assuming. The fourth is the one that gets skipped, and it is the one that matters: if nobody owns the decision, the default is a full refund, because that is what the person facing the annoyed customer will do.
Three questions for whoever supplies your sales system
Finding out before you take the money
Can I record a payment from a customer that is not against an invoice?
What you are listening for
Yes with a named mechanism, or a clear no.
How to read the answer
A clear no is workable — you use deposit invoices and mark them. Be wary of "you can just raise an invoice", which is the workaround presented as the feature, and skips the reporting consequences entirely.
How does a report distinguish a deposit invoice from a delivery invoice?
What you are listening for
A field, a type, a flag — or a naming convention you will have to enforce yourself.
How to read the answer
If the answer is a convention, that is fine and it is now your job. Write it down on day one; conventions that live in one person's habits do not survive that person.
What happens to the payment record if the invoice is deleted?
What you are listening for
A specific answer, ideally "you cannot delete an invoice with a payment".
How to read the answer
Cascading deletion of payment records is common and reasonable as engineering. It is also a way to lose evidence of real money, so you want to know whether the guardrail is the software or your own discipline.
A process that survives a busy month
Decide these once, before the next deposit arrives
- Deposit invoices carry a marker — a prefix, an item code, something a report can filter on. Agreed and written down, not remembered.
- The deposit terms, including what is retained on cancellation, are in the document the customer agrees to before they pay.
- Nobody deletes an invoice that has a payment against it. Corrections go through credit notes, always.
- One named person decides refund amounts on cancellation. Not the person taking the phone call, unless that is a deliberate choice.
- Month-end includes one check: total deposit invoices raised, against total deposits still undelivered. If those two are unrelated numbers, the marker is not being applied.
- Whether deposits carry tax in your jurisdiction is confirmed with someone qualified, once, and recorded next to the process.
The short version
Money that arrives before delivery is an obligation wearing the costume of revenue, and most systems have exactly one place to put it: an invoice. Take that door deliberately — mark the deposit invoices so a report can tell them apart, reverse with credit notes rather than deletions, and decide who owns the refund call before somebody is standing in front of you asking for one. The accounting can be made right afterwards in almost every case. What cannot be reconstructed afterwards is which invoices were deposits, so put the marker on from the first one.
