Skip to content

Payments and expenses

Recording money in and money out — cheques and e-transfers against a lot, bills paid from either fund, and transfers between the two.

ForCouncilProperty managers

Two forms cover most of a treasurer's month.

The date on every posting

Every money form in ManageStrata carries a Date field, and it is the same field with the same rules everywhere: record a payment, record an expense, charge all units, issue an invoice, charge interest, raise a special levy, move the reserve contribution across.

It is pre-filled with today, because most postings really are made on the day they happen. Change it when they weren't.

The date the money actually moved, which is not always the day you record it. This is what decides the month it lands in — on the statements, on the budget, and at your year end.

That is the whole reason the field exists. Time cards arrive after the month they belong to. An insurance premium is paid on the 2nd for a period that ended on the 31st. Payroll is dated the last day of the month and keyed the following week. A corporation that cannot say when cannot produce a monthly statement that agrees with its bank.

The confirm step tells you which month you're about to land in — "Dated 2026-07-31 — July 2026" — because the date on the form doesn't tell you which statement it joins, and that is the thing you set it for.

Three boundaries, and they are not the same

BoundaryWhat happens
A date in the futureRefused. A posting records money that has already moved, and a future-dated row would be invisible in every view of the ledger — it would post successfully and then not be there.
A closed periodRefused, with the closing date named. Date it in the current period instead: that is how a closed year is corrected, because owners have already been given those financials.
Before your opening balanceA warning, never a block. That figure already contains everything up to its date, so a posting behind it is counted twice. But a corporation still rebuilding its history has real reasons to post there, and it knows more about why than the software does.

Date issued is not the due date

On Charge all units and Issue invoice there are two dates and they mean different things. Date issued is when the charge is raised, and decides the month it lands in — backdate it to bill a month you missed. Due date is when the owner has to pay. Getting them the wrong way round bills the right money in the wrong month.

Money in — record a payment

FinancesRecord payment, for a cheque or e-transfer received from an owner.

FieldNotes
LotWhich lot the money is for. Get this right — it's the field that most often goes wrong
PayingWhich charge it settles, or on account. See below
AmountAs received
Date receivedThe date the money actually arrived, not the day you're keying it. Pre-filled with today; change it to backdate — see the date on every posting
MethodCheque, e-transfer, cash, bank transfer
ReferenceCheque number or transfer reference — invaluable at reconciliation time

The payment posts to that lot's ledger, reduces their balance, and appears in Fund transactions against the fund.

It's the same form wherever you open it — from Finances, or from the lot's own page where the lot is already known. Pick the lot and it offers that lot's outstanding charges; the two can't drift apart.

Which charge it settles

Paying lists what the lot currently owes, at what's left on each charge rather than its face value — a $16,666.67 levy that's had a payment against it is offered at what remains. Leave it on on account and the payment pays the balance down oldest first, which is right for an owner simply clearing their balance.

Naming the charge does two things nothing else does:

  • It puts the money in the right fund. A payment on account credits operating. A special levy payment belongs in the levy's own fund — s.108 requires levy money to be held for the purpose it was raised for.
  • It moves the invoice off "issued". A part payment marks the charge partial, a full one marks it paid, and that's what a Form B reads to tell a buyer what the seller still owes.

Either way the lot's ledger shows what the payment settled, line by line. See owner ledgers.

Card payments aren't live yet

Card payment is built and switched off while the pricing is settled, so every payment is one you record here. Owners aren't offered a Pay button; they're told to pay the way the council directs. When it's on, an owner paying online will post to their ledger without anyone touching it — see billing strata fees.

Enter the date received

Backdating to the actual receipt date is correct and important. It's what makes bank reconciliation work, it's what decides whether a payment landed before interest started accruing, and it's what puts the money in the right month on the statement.

When a payment would put the lot in credit

The confirm step warns you when the payment is larger than what the lot actually owes — when recording it would leave the lot with a credit balance. If ManageStrata can also see recent receipts of the same amount, it says so: "lot 01 already has 2 payments of $275.00 recorded today (as cheque, eft)."

That's the shape of the mistake worth catching. A receipt has no reference the system can key on, so nothing stops the same cheque being entered twice — and money recorded that the lot was never charged overstates the fund and puts a paid-up owner into fictitious credit, which only a correction can undo.

It warns; it never blocks. An owner prepaying a year ahead, two owners of one lot paying the same share, a re-issued cheque after a void — all real postings. Read the sentence, and if you recognise the payment, carry on.

What it won't catch

A lot deep in arrears paid the same amount twice stays in debit throughout, so nothing fires. That case is indistinguishable in the ledger from a legitimate catch-up — a council entering a year of back-history posts exactly that pattern — so the check stays quiet rather than crying wolf through every book migration. Reconciliation is what finds it.

Payments that aren't strata fees

Money for a special levy, a chargeback or a fine is recorded the same way, against the same lot. It settles the oldest outstanding charge on that ledger unless you direct it otherwise. Where an owner is paying a specific invoice — a levy instalment while still in arrears on fees, say — say so in Paying rather than only noting it in the reference: that's what routes the cash to the levy's fund and what a certificate reads.

The receipt the owner gets

Recording a payment emails the owner a receipt, and the confirmation now says whether it actually went out — because "Payment recorded" on its own left a treasurer with no way to tell, and one council had been sending receipts for a week without knowing it.

You will see one of:

What it saysWhat to do
Receipt emailed to Jane Doe.Nothing.
No receipt was emailed: no owner of this lot has an email address on the roster, or they have turned email off.Add an address on the roster, or download the receipt.
The receipt could not be emailed just now — resend it from the ledger.Resend it (below).
Receipt emailed to 1 of 2 owners.Resend it for the rest.
Email isn't set up, so no receipt went out.Download one from the ledger.

Download or resend it from the lot's ledger. On FinancesOwner accounts → the lot → open the payment's row:

  • Download receipt renders a PDF on the spot — the corporation's name and logo, the lot, the owners, the amount, how it arrived, what it settled, the balance after it, and a short reference like 3F2A9C1D the owner can quote back. Nothing is stored; it is built from the payment and the ledger every time, so the copy you print at a meeting says what the one in an owner's inbox says.
  • Email receipt sends it again, with the PDF attached, to whoever is on the roster now. That is the answer to the owner who changed address, never got the first one, or simply asks at tax time.

The receipt is dated from the ledger, not the clock

An owner who pays on the 30th and is emailed a receipt dated the 3rd has been sent a document that disagrees with their own bank. The receipt carries the date you entered on the form.

No receipt for a reversed payment

A payment that has since been reversed offers neither control. Issuing a receipt for it would certify money the corporation does not hold.

Money out — record an expense

FinancesRecord expense, for a bill the corporation paid.

The decision that matters is which fund:

Operating fund — insurance, utilities, landscaping, cleaning, management fees, routine repairs. Anything recurring or ordinary.

Contingency reserve fund — the big planned replacements the reserve exists for: roof, elevator, boiler, envelope, parkade membrane.

Which fund is a real decision

Charging a reserve project to operating blows your operating budget and hides what the reserve is actually spending. Charging routine maintenance to the reserve drains the fund and may breach your Act. When it's genuinely ambiguous — a major repair that isn't quite a replacement — decide it at council and minute the decision.

Record the vendor, an honest description, the date paid, the amount and the budget line it belongs to, and link it to the work order or component it relates to where one exists. That linkage is what makes next year's reserve projection accurate — a roof replaced this year shouldn't still be counted as due.

The reference

Reference is the number the bill was issued under — whatever the vendor actually printed. An invoice number, a statement number, a cheque number, a PO. It's free text and optional, and there's no format check, because "31936", "INV-2026-0042" and "Aug stmt" all turn up and a field that rejects the third is a field that gets bypassed.

It used to have nowhere to live but the description, which meant nothing could notice the same bill arriving twice — the commonest way an expense ends up wrong in the first place. Now, if the corporation has already posted that reference, the form says so before you commit: "Reference 31936 is already on the books — 'Pest control — quarterly', dated 2026-08-29."

A warning, not a block

Vendors do reissue numbers and councils do split payments across two postings, so a repeated reference is suspicious rather than wrong. Corrections are left out of the check, or every reversal would flag itself.

The reference shows as a chip beside the description in the journal, and in full behind the row's chevron.

Transfers between funds

Strata fees arrive whole in the operating fund, including the part that belongs to the reserve — a fee is billed as a single invoice because that's what a Form B certifies as the lot's monthly fee. So the CRF contribution only reaches the reserve when it's moved.

FinancesBudgetReserve fund contribution does that, a month at a time, and shows how much of the year's contribution has gone across so far. Operating goes down and the reserve goes up in one entry, both legs together or neither. Do it monthly with the fee run rather than when you happen to remember, so the reserve balance is always meaningful. More →

The budget line

Budget line on the expense drawer is what makes budget vs actual mean anything. It's a picker, not free text: it offers the lines your council actually adopted, so spend can only be reported against a line that exists — no more "Landscaping" one month and "Grounds" the next.

It's optional, and last in the form. Made mandatory it would sit on the fastest path in the product and get answered with whatever's first in the list by whoever's in a hurry — and a budget monitored against categories chosen that way is worse than one monitored against none, because it looks right.

Leave it unset and the spend is reported as Uncategorised on the budget: visible as a gap rather than absorbed into a line it doesn't belong to.

Nothing before this is categorised

Postings made before budget lines existed genuinely have no line against them, and nothing was guessed retroactively. They show under Uncategorised. If a figure there matters, the way to fix it is to reverse and re-record with the line named — not to edit history.

Reviewing what's been recorded

FinancesFund transactions shows every fund posting in date order with a running balance per fund, narrowable by fund, by money in or out, by budget line, by payee, and by date.

The budget-line filter is the way behind a figure on the budget: "$4,800 of legal advice — spent on what?" is a click on the line and then a read. The running balance is unaffected by narrowing; it's the fund's real balance rather than a total of what's on screen.

Asking it for a span of days

The journal could once be narrowed only to a calendar month — which is what the month rows on the statement's Month by month view still link to, and the wrong shape for most of what people bring to a cash journal. What did we spend over the summer? Everything since the AGM? The fortnight either side of that cheque? None of those is a month.

So there's a date range, with three presets and a calendar:

  • This month
  • Last 3 months — three months including this one
  • Your fiscal year, labelled with the year itself rather than called "this fiscal year", so a July-to-June council can see which one it's being offered

The presets are worked out against your corporation's clock and your fiscal year, not the browser's — a manager in Toronto reading a Vancouver corporation's books is three hours ahead of the day those books are keeping, and the last evening of the month is exactly when that changes what "this month" means.

Nothing is dated into the future, so the calendar stops at today and the presets do too. Following a month link and then widening it is the same control: type into the boxes already showing August and you get June-to-August, and Clear dates appears while there's a range to clear.

Spotting a misapplied receipt

Money in is a flow filter away — the fastest place to spot a payment credited to the wrong lot before an owner does — and the corrections are on the row itself. Correct it where you noticed it →

Budget Watch flags the odd ones

On the Council plan, the Budget Watch agent reviews spending and flags what looks unusual — a category well over budget, a duplicate-looking payment, a fund running low — in plain English, for you to confirm or dismiss. See AI agents.

When something is wrong

Don't delete it. Every fix has its own recorded correction:

SituationWhat to use
Payment credited to the wrong lotMove to another lot, with a reason
Cheque bounced (NSF), or keyed twiceReverse the payment
Charge raised in errorCancel invoice, with a reason
Expense recorded in error, or against the wrong fundReverse the expense, with a reason

Full detail in fixing mistakes.

Still stuck? Open Support in the top bar of the app, ask the Assistant, or contact us.