Members & accounts
Manage every relationship — including the ones that pay for each other.
People, organizations and households, with payers, account holders and beneficiaries as separate records. Because a parent paying for three children is the normal case, not an exception to work around.
People.Organizations.Households.Payers.
- People, organizations and households as parties
- Multiple relationships per party, each with its own dates
- Payer, account holder and beneficiary as separate roles
- Corporate accounts with individual beneficiaries
- Household and family groupings
- Registered paying numbers used in payment matching
Part of one system
Members & accountsObligationsBillingPaymentsReconciliationCollectionsCommunicationsMember portalStandingEntitlementsReporting. See how they fit
Payer
acc-3307Northbridge Design Partners
Not a member. Holds no entitlements of its own.
Obligation
obl-8841Annual corporate membership · $5,400
18 named architects, billed as one agreement.
Settlement
2 payments- Payment 1 · 14 Feb$3,000
- Payment 2 · 11 Aug$2,400
- Settled in full$5,400
Two payments, seven months apart, against one obligation. Neither is a whole membership; together they are eighteen.
Standing
Good standing18 individual memberships active. Each architect votes, appears in the directory and renews their certification in their own name — none of them has paid the association anything.
payer ≠ beneficiary ≠ account holder
Almost every membership and billing system assumes those three are the same person, then bolts on a workaround the first time they are not. The workarounds are familiar: a duplicate record for the parent, a note in a free-text field saying who actually pays, a corporate account with eighteen fake email addresses, a spreadsheet mapping phone numbers to members.
Each of those makes the database slightly less true, and the damage shows up at reconciliation time — because when a payment arrives from a number that belongs to a person who is not the member, there is nothing legitimate to match it against.
Modelling the three separately is unglamorous, and it is the reason the rest of the system can be accurate.
Real arrangements
Who pays for whom, in practice.
A parent pays for three children
One payment, three obligations, three student records, one statement the parent can read.
A company pays for 25 employees
One agreement, one transfer, twenty-five memberships and twenty-five sets of entitlements.
A spouse pays the other's dues
The payer's phone number is not on the member's record unless somebody put it there.
A family pays collectively
Different amounts from different people, all against one household's obligations.
A sponsor pays a student's fees
The sponsor is not a parent, is not a student, and needs their own receipts.
One payer settles several accounts
A landlord paying service charge on four units. One payment, four ledgers.
A member pays for a guest
A one-off obligation attached to someone who is not a member at all.
A diaspora relative pays from abroad
A rail with different identifiers and no local number to match on.
A branch pays for its chapter
Money moving inside the organization, still needing to land on the right accounts.
The record
What Zetu holds about a relationship.
Identity
Person, organization or household. Names as they should appear on a statement, and as they appear on a payment rail.
Relationships
Why this party matters to you, since when, and in what capacity — with more than one allowed at a time.
Accounts
The financial relationship itself: what is billed to it, what settles against it, what it currently stands at.
Contacts
Phone numbers, email addresses and channel preferences — including the numbers people actually pay from.
Obligations
Everything expected of them, in every state, with the history of how it got there.
Settlements
Every payment, credit, waiver and adjustment that has landed against them, from whichever payer.
Standing
Where the account stands today, why, and the trail of how it changed.
Entitlements
What they can currently access, and when each item was granted or withdrawn.
Communications
What was sent, on what channel, and what came back — attached to the account it was about.
Documents and notes
Agreements, correspondence and the internal notes that explain an exception.
Capabilities
What is in members & accounts
- People, organizations and households as parties
- Multiple relationships per party, each with its own dates
- Payer, account holder and beneficiary as separate roles
- Corporate accounts with individual beneficiaries
- Household and family groupings
- Registered paying numbers used in payment matching
- Membership status and plan history
- Complete account and obligation history
- Documents, agreements and internal notes
- Contacts and per-channel communication preferences
- Relationships that end on a date rather than being deleted
- Terminology configured to your organization's own words
Questions
Members & accounts, in practice
We don't call them members. Does that matter?
No. Residents, students, parents, subscribers, franchisees, contributors, owners, households and companies are all the same shape underneath: a party with a relationship that explains why money is expected. Zetu is built so the vocabulary an organization uses on screen is configuration, not a rename exercise across the product.
Can one person have several relationships with us?
Yes, and they should. Someone can be an individual member, a director of a corporate member, and a parent paying for a child in the same organization — three relationships, three sets of obligations, one human being. Collapsing them into one record is how statements end up incomprehensible and reminders end up embarrassing.
How do you handle a company paying for its employees?
The company is the payer and holds the agreement. Each employee is a beneficiary with their own membership, their own standing and their own entitlements. One bank transfer settles the corporate obligation, which settles the individual memberships underneath it. None of the employees has paid you anything, and all of them are in good standing.
What happens when a relationship ends?
It ends on a date rather than being deleted, and everything attached to it — obligations, settlements, communications, standing history — stays with the record. Outstanding balances do not vanish because someone left; that is precisely when the history matters most.
Keep reading
- ObligationsWhat each relationship is expected to pay.
- ReconciliationWhy registered paying numbers matter.
- EntitlementsWhat the relationship grants access to.
- Why payer and beneficiary should be separate recordsThe modelling argument in full.
- Zetu vs membership softwareWhere member databases end.
- SchoolsWhere payer and beneficiary diverge hardest.
Bring us one messy month.
Bring one month of obligations and one month of payments. We will show you what reconciles, what does not, and what that is costing you.