Recording a check, cash or card payment by hand

A check handed over at the dock is not a second-class payment. LakeOps records it as the same kind of thing as a card paid online, and nothing downstream asks which is which.

Recording one

Payments attach to a job, because the job is the thing that has a price. Open the job and find Record a payment in its money panel. The amount starts filled in with what the job still owes, so the usual check for the whole bill is one press; change it to what actually arrived, and say how it was paid: card, bank transfer, check, cash or other.

When a bank payment is already on its way

A customer who paid by bank from the completion email has a payment that takes a few days to clear, and it can still fail. While it is clearing, the amount box leaves it out — it starts at what is owed minus what is clearing, or empty if the clearing payment covers the whole bill — and a note above the box names the most you can record without overpaying.

Type more than that and nothing is recorded yet. The job page says how much you tried to record and how much would have been enough, and offers Record it anyway for the day the customer really did pay twice. That is the usual way a job ends up overpaid: a check handed over at the dock while the same bill’s bank payment was still clearing.

If a job is paid more than it is owed

LakeOps tells the office rather than the customer. The job’s money panel reads Overpaid by the difference and lists the payments involved, the people at your shop who can refund a payment get an email, and the dashboard shows a card counting the overpaid jobs that opens the list of them. If part of it is a bank payment that later fails, the flag clears by itself.

To give the extra back, use the Refund link beside the payment in that panel. It opens the refund form with the overpaid amount filled in and recommends Refund and bill again — see refunds and who pays the fees for why.

LakeOps notes who recorded it and when, and works out which customer it belongs to from the job. That is the whole entry.

Partial payments and deposits

Record what actually arrived. A job can carry several payments and the balance simply reflects the difference. A deposit in April and the rest in June is two payment rows, and at no point is anybody asked to reconcile them by hand.

Refunds

A refund attaches to the payment it reverses. On a payment you recorded by hand, Refund on the payments list opens a form: the amount (it starts at what is left on the payment, and you can type less), an optional reason, and the two buttons. The refund records that the money went back — you return the check or the cash yourself; no card is touched. Refund means it is given back for good; Refund and bill again — a check that bounced — puts it back on what they owe.

Email the customer about this refund starts unticked on a payment you recorded by hand, because that refund is usually you correcting your own entry. Tick it when you really are handing money back, and the customer is emailed that it is coming back from you directly.

Refunds of card and bank payments, and what happens to the fees, are in refunds and who pays the fees.

Where a recorded payment shows up

• On the job — as its balance.
• On the customer — billed, collected, outstanding, and what they were worth by season.
• On the property — same shape, one shoreline.
• On the completed-work report, which can filter to paid or unpaid work.
• On the customer’s own completion page, so somebody who pays by check and then follows the link does not see a demand for money they already sent.

This works in both payment modes

Recording payments by hand is not a fallback for shops without online payments. Even with LakeOps Payments switched on, some customers will hand you a check at the landing, and that check gets recorded here exactly the same way.

What this is not

It is not double-entry bookkeeping, and it is not trying to be. There is no ledger, no accounts receivable module and no accounting sync. It is a record of what you charged and what came back, which is what your bookkeeper actually needs from an operations system — see getting your data back out.