Fixing mistakes

You will make mistakes in the books. Everybody does. What matters is fixing them in a way that leaves the record explainable.

Which fix to use

Payment on the wrong lot

The most common error, and the least alarming.

FinancesFund transactions → open the receipt's row → Move to another lot, with a reason.

The money never left the fund — it was only ever credited to the wrong ledger. After the move, the original lot's balance goes back up, the correct lot's comes down, and both ledgers show what happened.

Money that never cleared

FinancesFund transactions → open the receipt's row → Reverse.

For an NSF cheque, a failed transfer, or a payment keyed twice. Unlike a move, a reversal takes the cash back out of the fund — which is correct, because it was never there.

A reversal will show in your next bank reconciliation, which is exactly what you want: the books now agree with the bank.

For a bounced cheque, also consider whether your bylaws let you charge an NSF fee, and whether the owner is now in arrears with interest accruing.

Charge raised in error

Open the lot from FinancesOwner accounts → Cancel invoice, with a reason.

Use it for a charge that shouldn't have been raised at all — a lot billed that shouldn't have been, a duplicate fee run, interest council decided to waive. For a charge that was right in principle but wrong in amount, cancel and reissue rather than editing.

Expense recorded in error

FinancesFund transactions → open the expense's row → Reverse expense, with a reason.

For a bill paid twice, a payment recorded against the wrong invoice, or a spend charged to the wrong fund. The reversal posts a single credit back to the same fund, carrying a link to the entry it corrects — so the fund gets its money back and both rows stay on the books explaining each other.

Until recently this was the one correction the product didn't have. Money in had three; money out had none, and the only workaround left in a council's hands was to record a second, fictional expense to cancel the first — stating something untrue about money spent, which is the opposite of what s.35(2)(a) asks you to keep.

The confirm step names the entry back to you — amount, vendor and description — because an expense carries its invoice number in the description, and that line is often the only way to tell "the one for invoice 31936" from the other four cheques written to the same contractor.

Where it lands. A reversal inherits the budget line and the vendor of the entry it corrects, so it nets against the right line rather than falling into "no category, no payee" where nothing could ever cancel it out. Fund balances, the statement, budget vs actual and the next bank reconciliation all reflect it. Nothing owner-side moves — an expense reversal posts no owner leg — so lot ledgers, arrears and Form B are untouched.

Correct it where you noticed it

Every correction above is offered on the row itself in FinancesFund transactions, behind the chevron at the end of the row. That's where you're standing when you spot the problem: finding a misapplied receipt means reading the cash journal, and being sent to another screen to act on it is how a correction becomes a thing you'll do later.

A row only offers what it can actually take. A fund contribution, a transfer and a correction leg carry no payment, so they offer nothing; an entry already corrected offers nothing either. The panel names the lot a receipt currently sits on before it offers to move it, because moving money without knowing where it is now is worse than not offering the control.

When a correction is dated

A correction posts on the day you make it, and that is usually right. What you cannot do is date one into a period you have already closed — the refusal names the boundary:

The books are closed up to 2026-06-30, so nothing can be dated 2026-05-14. Date this in the current period instead — that is how a closed year is corrected, because the owners have already been given those financials.

That is the whole point of closing the books. A correction is honest about when it happened only if it can't be dropped into a year the owners have already approved. If the amount is large enough to distort either year, note it in the statement and mention it at the AGM.

Writing a good reason

The reason is read by someone who wasn't there — an owner, a future treasurer, possibly a tribunal. Make it carry the facts.

Weak: "Correction", "Error", "Fixed"

Good:

• "Payment received 14 June credited to lot 204 in error; e-transfer reference confirms lot 402."
• "Cheque #1043 returned NSF by the bank on 22 June."
• "June fee invoice raised twice by the fee run on 1 June; this is the duplicate."
• "Interest waived by council resolution of 12 July — payment delayed by bank error, evidence provided by owner."

Explaining it to an owner

Send them to their own ledger, where the original, the correction and the reason all appear in date order. It answers the question better than an email will, and it demonstrates that the corporation's records are kept properly — which is often the real concern behind the question.

Mistakes outside the ledger

Wrong meeting result. A finalized result reflects the recorded votes. If a vote was wrongly recorded, correct the vote and re-finalize, and note it in the minutes. If the result was wrong on the substance, that's a governance matter, not a data-entry one — take advice.

Wrong compliance date. Re-record the duty or report with the right date; the cycle recalculates.

Wrong unit entitlement. Fix it in units and lots, then re-check any levy allocated on the old figure — it will be wrong in proportion.

Person on the wrong lot. Fix it on the roster. If charges posted to the wrong lot as a result, correct those separately using the fixes above.

When you're not sure

Two rules that will not get you into trouble:

1. Don't improvise. If none of the corrections above fits, contact support before entering anything. An awkward entry made to "balance it out" is far harder to unpick than the original problem.
2. Never post a plug. A balancing entry with no explanation destroys the property that makes the ledger worth having.

Everything you do is recorded in the audit trail with your name and the time — including corrections. That's not a warning; it's the feature.