Cash, bank transfer, Stripe: accurate records
A payment received on site matters as much as an online payment.
A villa rarely collects through a single channel. A deposit arrives by card from the booking link, the balance comes in cash on the shoot day, and the agency client pays by bank transfer three weeks later. The difficulty is not accepting all three: it is that two of them record nothing on their own.
A confirmed booking is not a paid booking
These are two distinct states, and confusing them is expensive in both directions. A confirmed booking says a slot is held. A paid booking says an amount has arrived. In between there may be a deposit, a balance, or nothing at all.
The day your calendar shows "confirmed" for both cases, you welcome a production crew without knowing whether they have paid anything — and you find out in front of them.
Record what arrived, not what was promised
The rule fits in one sentence: a payment is recorded when the money has landed, not when it was announced.
A transfer announced by email is not a transfer received. A cheque handed over is not a cheque cleared. If you record the promise, your balance becomes a forecast, and a forecast cannot tell you whether to open the villa tomorrow morning.
The five facts behind every payment
| Fact | Why it matters |
|---|---|
| Actual amount | What arrived, not what was expected — the two often differ |
| Payment method | Cash, transfer, card: it tells you where the trace lives |
| Date received | The date of the money, not the date of the data entry |
| Reference | Transaction id, transfer reference, or a manual receipt number |
| Who received it | On site, this is the only trace that exists |
The first three are enough for the balance to be right. The last two earn their keep the day someone disputes a payment — and that day comes.
The gross total trap
A refund does not erase a payment: they are two entries. The payment stays, the refund is added with the opposite sign, and what you display everywhere is the difference.
Without that subtraction, a fully refunded but still confirmed booking announces "nothing to pay" next to a button asking for the full price. The client is right to be confused.
Cash deserves more rigour, not less
It is the only method with no automatic trace, so the only one where the trace depends entirely on you. Three habits are enough:
- Record it before putting the money away, not in the evening. A payment noted three hours later is a payment whose amount is reconstructed from memory.
- Give the client a receipt, even a message recapping amount, date and booking. It is their proof as much as yours.
- Name the person who received it. On a team of three, that is what prevents next week's argument.
Transfers need a rule, not vigilance
A bank transfer arrives unannounced and unattached: the bank label rarely carries the booking name. Ask for a reference in the payment description from the very message that states the amount, and hold that line — it is what turns an unreadable statement into a series of matchable rows.
Without it, every month-end is spent cross-checking amounts against dates, and two bookings at the same rate become impossible to tell apart.
One place, never two
The parallel spreadsheet is the natural temptation when some payments do not arrive online. It is also the most reliable source of wrong accounts: two ledgers always drift, and the one the client is looking at is always the one that turns out to be wrong.
If a payment exists, it exists in the same place as the others, whatever channel it came through. The balance is then computed from those rows, and it gives the same answer to the team, to the client and to you. For what comes next — chasing what is still due — see Remind clients without chasing them.
