Refunds, deposits and part-payments

You paid a deposit in January, the balance in March, and half of it came back in May because the second item was wrong. There are four pieces of paper, three different amounts, and no document anywhere that describes what actually happened.

This is the case where the receipt-per-transaction model quietly stops working. The unit of the record is no longer a transaction; it’s a sequence, and nothing in the pile represents the sequence.

The shapes that break the model

A deposit. The receipt records a payment, not a purchase. What was bought is described elsewhere, in an order or a quote, and the amount on the deposit receipt bears no relation to the eventual total.

A balance payment. Records the remainder. On its own it is nearly meaningless — an amount with no purchase attached — and it is very often the only document that survives, because it’s the last one and therefore the freshest in the pile.

A refund. Money moving the other way, usually with its own document, usually not referencing the original in any way you could search for. The refund often lands weeks later, by which point the original has been filed and forgotten.

A partial refund. The worst of these. One item returned from a basket of six, so the original receipt is still valid for most of itself and overstated for the rest, and neither document says which.

An exchange. Sometimes a refund and a fresh purchase, sometimes one document, sometimes nothing. The record depends on the vendor’s till rather than on what happened.

A credit note. Not a payment. An entitlement to future value, which may be used, partly used, or never used, and which sits in an ambiguous state indefinitely.

Instalments. Many small payments against one purchase — individually trivial, collectively the whole spend, each indistinguishable from a subscription on a statement.

Why they’re hard

No document holds the sequence. Each artefact is a truthful record of one event and none of them describe the arc. There is no natural place for the sequence to live, so it doesn’t.

The amounts disagree, correctly. What you were charged, what you paid, what you net paid, and what the goods cost are four different numbers here, and every one of them appears on some document. Anyone reconciling later has to work out which is which.

The events are separated by time. Deposit and balance can be months apart, refunds arrive unpredictably, and instalments run for a year. Anything organised strictly by date scatters the pieces of one purchase across the archive.

Refunds arrive when attention has moved on. By definition, after the purchase was dealt with. This is the single most common reason a refund never gets recorded: the file was closed.

The practice

Make the purchase the unit, not the payment. One record per purchase, holding every document belonging to it. In a flat file scheme, that means every related file shares a distinctive string — the order reference, or the vendor plus the item — so a single search returns all of them regardless of their dates.

Write a one-line summary of the sequence. This is the artefact nobody creates and it is the whole solution. Plain text, in the record: deposit paid, date, amount; balance paid, date, amount; item returned, date, refund amount; net. Ten seconds, and it replaces twenty minutes of forensic work later.

Name refunds after the thing they refund. Not after the refund. A file named for the original purchase, marked as a refund, sits next to its parent and is impossible to miss. A file named by the refund’s own date and amount is orphaned the moment you look away — what happens to metadata on why the filename is the only reliable place to put this.

Keep the quote or order alongside the payment records. For a deposit-and-balance purchase, the order is the only document that says what was bought. It is not a receipt and it is not optional.

Handle credit notes as open items. A credit note is a live thing until it’s used or expires. Keep it where you’ll see it — with the pending items rather than in the closed archive.

Check the refund arrived. A refund agreed is not a refund received. This is the point at which matching against a statement earns its keep, and it is the failure that costs actual money rather than just tidiness.

Keep or bin

KEEP OR BIN — a multi-payment purchase

  · One-line written summary of the
    sequence
                    → KEEP. The only artefact that
                      describes what happened.

  · Order or quote for a deposit purchase
                    → KEEP. The only document saying
                      what was bought.

  · Deposit receipt
                    → KEEP, but it is a payment
                      record, not a purchase record.
                      Meaningless alone.

  · Balance receipt on its own
                    → NOT THE RECORD. An amount with
                      no purchase attached. Needs the
                      order and the deposit beside it.

  · Refund document, named after the
    original purchase
                    → KEEP. Named after itself, it's
                      an orphan.

  · Original receipt after a partial
    refund
                    → KEEP, annotated. Still correct
                      for most of itself and
                      overstated for the rest.

  · Unused credit note
                    → KEEP as an open item, not
                      archived. It isn't finished.

  · Which amount and which date govern for
    any filing purpose
                    → ASK LOCALLY. Timing and
                      treatment rules vary by
                      jurisdiction.

The date problem underneath

A purchase spread over months has several defensible dates — order, deposit, balance, delivery, refund — and filing by “the date” means choosing one. File consistently by whichever you pick and record the others in the summary line, so nothing depends on having chosen correctly. Which date any rule cares about is covered further in which date a record belongs to.

The reason field is still missing too, and these are the worst case for it: the reason was known in January when the deposit was paid, and the only document you’ll still have in two years is March’s balance receipt. So the summary line carries the reason as well as the sequence, written at the start rather than the end — writing it down at the time applied to a purchase that takes a season to complete.

What this doesn’t settle

Which date a spend is treated as occurring on. How a refund affects anything. Whether a deposit is treated differently from a payment. What a credit note counts as. Whether a part-refunded receipt needs correcting somewhere, and how.

All of that is treatment, it varies by jurisdiction and circumstance, and it belongs to your tax authority or adviser. What this page settles is that they cannot answer any of it from a pile of four documents with no note explaining how they relate — and that the note takes ten seconds if written while the sequence is happening.