Treasury, levies and dues
The community's money on a double-entry ledger: how a levy is charged, how a payment lands, how a statement is produced and what happens when nobody pays.
The most important sentence in this guide: tribe.one never holds your community's money. Members pay into the community's own bank account. The app raises the charges, records what came in, and reconciles it against the bank — it is a ledger and a filing cabinet, not a payment processor. That is why there is no "pay by card" button in the South African flow, and why the treasurer's bank statement import matters more than any dashboard.
What the ledger is
A double-entry ledger with wallets. A community has a treasury wallet, and can add budget and reserve wallets. Every movement of money is a transaction — an expense, a contribution, a transfer between wallets, a budget allocation or a refund — and every transaction posts balanced entries to wallets. Nothing moves without a trace.
In a stokvel community the same machinery is dressed for the job: the module is called Stokvel funds and dues are contributions rather than levies. In a housing community every screen says levy. It is the same ledger.
The pages
| Page | What it is | Who |
|---|---|---|
/treasury | Balances, 30-day in and out, pending approvals, recent movements, and the reconciliation card | Everyone reads; treasurer adds transactions |
/treasury/ledger | The full ledger, every posting | Every member — transparency is deliberate |
/treasury/contributions | Schedules and their charges, the payment-claims queue, recently paid | Everyone (their own rows); treasurer reviews claims |
/treasury/arrears | Who owes, worst first, oldest first | Treasurer. Housing communities only |
/treasury/statements | Bank statement import and unmatched credits | Treasurer |
/treasury/owner-statements | Automatic owner statements and a send-now button | Treasurer. Housing only |
/treasury/budgets | Budgets for the current, upcoming and past periods | Everyone reads; treasurer creates |
/treasury/reports | Collection summary, arrears report, member statement | Treasurer |
/my-dues | The member's own dues, proof-of-payment claims and statements | Each member, for themselves |
A brand-new community has no treasury wallet, and the ledger refuses the first transaction with "No community wallet exists to credit". The treasury page offers Create first wallet until that is done.
How dues are charged — five ways
A schedule is the rule ("R450 a month, due on the 1st, seven days' grace"); the charges it generates are the individual amounts owed. The question a treasurer must answer first is who is charged, and how much.
| Chosen as | What the amount means | Good for |
|---|---|---|
One amount for the whole communityflat | Every member is billed the same. Not tied to a property at all. | Neighbourhoods and savings groups; dues that are not about bricks |
Per unitper_unit | Each billable parcel is charged that amount. An owner with three units pays three times. | The default for housing communities |
Per square metreper_sqm | The amount is the total you want to raise this cycle, split by floor area. | Schemes that levy on size |
By participation quotaper_pq | The amount is the total to raise, split by participation quota — the sectional-title standard. | Body corporates |
Rate card by unit typerate_card | The schedule amount is ignored; each parcel's amount comes from the rate card for its unit type, as at the due date. | Mixed estates with a tariff per class |
Two things are easy to get wrong, and both are worth stating plainly. With per square metre and by participation quota, typing R950 does not charge each owner R950 — it raises R950 in total across the scheme. With a rate card, a unit class with no rate configured is charged nothing, and a blank cell is deliberately not a zero.
Schedules are only ever flat in a non-housing community. A stokvel has no parcels, so the parcel question never arises.
Running a levy cycle
- Create the schedule. Treasury → Levies → New schedule: name, amount, frequency (monthly, quarterly, annual, one time), due day, grace period, late fee, and — in a housing community — what it is charged against.
- Charges appear on their own. A daily job raises the charges for every cycle that has started, backfilling any months a schedule was created late, and marks each one due, overdue or scheduled. Creating or editing a schedule triggers an immediate run, so you do not wait until midnight to see the numbers.
- For parcel-based schedules, watch the run. The schedule page has Run the levy now, which reports how many charges it created and lists the parcels it could not bill — units with no owner, no measurement for a size-based basis, or no rate on the card — with a link to fix each one. A flat schedule has no parcels to charge, so the button does not apply to it.
- Owners are told. Each charge issues a notification to the person liable, with the amount, the period and the community's banking reference.
- Payments come in. See the next section — a member claims, or the treasurer records it.
- Unowned parcels are neither billed nor counted. They are excluded from the charge run and from the denominator a per-square-metre or per-quota levy is split across, so a missing owner quietly raises everyone else's share. That is the right answer for the ledger and the wrong answer for the community's cash flow — which is why the run names the parcels and links to the fix.
When somebody pays
There are three roads into the ledger, and they differ in how much trust they assume.
The member claims, the treasurer confirms
- The member pays by EFT, quoting the reference shown on their dues page.
- They submit proof — I've paid — upload proof on
/my-dues. A photo or PDF, up to 10 MB, held privately. - The treasurer approves or rejects the claim in the payment-claims queue. A rejection carries a reason the member can see.
- Approving does not post the money. It creates a pending treasury transaction. Someone with approval rights then posts it, and the charge shows paid once receipts cover the amount plus any late fee. The person who filed the proof can never post it themselves.
The treasurer marks it paid offline
Cash, an EFT that arrived without a claim, a card payment taken at the office: Mark paid on the contributions page records the method, the date and an optional reference. It posts an approved contribution straight to the ledger — by design, without an approval gate, because a treasurer confirming cash in hand is the approval.
The bank statement reconciles it
/treasury/statements imports FNB, Standard Bank, generic CSV or OFX statements, detects duplicates by re-upload, and surfaces credits it cannot place. Resolve matches one to a contribution or ignores it. Statements need a bank account configured first.
Arrears
/treasury/arrears lists every parcel in arrears, worst first, each with its oldest unpaid due date — the answer to "who owes us, and how long has it been". Housing communities only, because a stokvel's arrears are a different conversation.
- Send a reminder. Send an arrears reminder opens a notice already addressed to "Owners with unpaid levies" — the audience is resolved from the ledger at send time, not from a list someone maintained by hand. Two templates ship with it: a polite reminder and a final notice before referral.
- Answer one household at a time. The contribution detail page shows a single charge with that household's year of history, and allows a Waive with a reason. Waiving moves no money and leaves a record.
- Prove the position. A clearance certificate for a parcel is derived from the ledger at the moment it is printed — clear or not clear, with the amount. It is never a stored flag, so a certificate cannot be outdated by the time it is signed.
Member-based charges stop when a resident moves out, because the person left. Unit-based charges continue, because the property is still owned — the liable party is the ownership, not the occupant. That distinction is why the move-out flow and the levy run are separate things.
Statements and certificates
- Owners get a statement per parcel: charged, received, outstanding and not yet due, with the owners and their shares, printable.
- Every member can open their own statement for any period from their dues page and print it.
- Automatic delivery can be set to monthly or quarterly on a chosen day of the month, in-app or by email — with a Send now for the last full month when a committee needs it today. Sending twice is refused rather than silently duplicating.
Statements and certificates are always derived at the moment you look at them, so a reprint shows today's position, not the position on the day it was first issued.
Approvals
An expense can require a second pair of eyes. An approval policy states a threshold and how many approvers are needed at or above it; the default is R1,000 with one approver, drawn from admin and treasurer.
- At the threshold and above, a transaction waits in Pending until someone with approval rights acts — unless the policy demands two approvers, in which case the person who raised it cannot also approve it.
- With the default single-approver policy, a treasurer can also approve their own transaction after a confirmation that names what they are doing ("Approve your own transaction?"). The bar is a policy setting, not a built-in prohibition — raise the policy to two approvers and self-approval stops being possible.
- The person who filed a proof of payment can never post the resulting transaction, whatever the threshold.
Approval policies are set at platform level today — a community that needs a different threshold should ask rather than assume the number.
The rules money obeys
- Cents, never rands. Every amount is stored as an integer number of cents and formatted for display. No floating point, ever.
- ZAR and en-ZA by default, with the currency configurable per community.
- The ledger is append-only. A posting cannot be edited or deleted. A mistake is corrected with a reversing entry, and the original stays visible — the reversal is what shows as Reversed.
- Reversing is admin-only, and in this release it is not a button. The permission to void a posted transaction belongs to the admin, but the transaction screen offers only Approve and Reject, so a reversal currently means asking tribe.one to do it. Plan around a second entry rather than a correction.
- A levy record outlives an account. Deleting a member's login does not erase what they were charged; the charge keeps the payer's name as it was when it was raised, so a statement still makes sense after an ownership transfer.
- Part payments are first-class. What is owed is the charge plus any late fee, minus what has been received, never below zero.
Rental billing
Communities that let out units get a separate billing path for rent and utilities, kept apart from levies on purpose: a tenant's rent is not a levy, and the taxable-style record of it belongs to the lease.
- Leases — signed per unit, with rent, deposit, billing day, grace days and lease documents held privately.
- Rent invoices — generated monthly on the billing day, or on demand with Generate now. Payments can be recorded partially; an unpaid invoice becomes overdue after its grace period.
- Late fees — a lease can carry a default late fee, stamped onto an invoice when it goes overdue and frozen once it is paid.
- Meter readings and tariffs — tenants submit readings, the property manager verifies them, and a verified reading produces a utility charge only where a tariff exists for that property.
- Faults — a tenant reports a fault from My rental; it is triaged, assigned to a member or a contractor, and commented on until it is closed.
Late-fee automation exists for rental invoices only. On levy schedules a late fee can be configured and is counted and printed, but nothing applies it automatically — it is a number for the committee to act on.