Subscription dues and family-level billing.

A community organisation in Chennai sends out monthly subscription invoices to its 1,800 member households on the first of each month. One of those households is a 78-year-old widow living alone, who is the only remaining member of what was once a four-person household. Another is a joint family of nine across three generations, billed as a single household with the eldest son as head. A third is a recently married couple who have just separated from the husband's parents' household and need their own subscription record from this month forward.

Each of these households is a different shape, and each needs to be billed correctly. The widow's subscription is reduced because the rate is per adult member and there is one. The joint family's subscription is the full rate because there are multiple adult members under one head. The new couple's subscription starts this month, and the original household's subscription should not double-count them.

This is the operational reality of family-level billing in a community organisation. The unit of billing is the household, not the individual. The membership of the household is a moving target. The system has to express this without becoming brittle, because the alternative is the administrator maintaining a parallel spreadsheet of "billing adjustments" that slowly diverges from the membership database.

The system that runs at Toloba Chennai AEM, the community organisation whose membership and billing system we maintain as a long-term partnership, was built around the discipline that the billing layer reads from the membership data, not from a parallel record.

Why per-family billing is structurally different from per-user billing

Most subscription billing systems, including the SaaS billing products that dominate the market, are built around per-user or per-seat models. The customer is an individual or a company. The subscription is a flat or tiered fee. The billing cycle is monthly or annual. The model is simple because the underlying customer relationship is simple.

A community organisation does not have this kind of customer. The customer is the household, and the household's composition changes. The rate is sometimes per adult, sometimes per household, sometimes scaled to the household's circumstances. The discounts and waivers are negotiated case by case in a trustees' meeting and recorded as part of the family's record. The invoice has to reflect all of this without breaking.

A SaaS billing tool retrofitted to this model accumulates exceptions until the exception layer is bigger than the rule. The administrator ends up maintaining the real billing logic in their own head, with the software as a fancy invoice printer. The fitted system inverts this: the billing logic lives in the system, and the administrator's role is to handle the genuinely exceptional cases.

The shape of the family record that billing reads from

The household record carries a small number of fields that billing depends on. The household identifier. The head of household, who receives the invoice. The list of active adult members in the household, derived from the person records that link to this household. The applicable subscription tier or rate. Any active waiver or adjustment, with its reason and expiry date.

When the billing run executes on the first of the month, it queries the household records, computes the subscription amount based on the rate and the household composition, applies any active adjustments, and generates the invoice. The invoice dispatches through WhatsApp and email, with a payment link.

The crucial discipline is that the billing run does not have its own copy of the family composition. It reads the live membership data. When a person's status changes from active to deceased, the next month's invoice reflects the change automatically. When a household separates, the next month's billing reflects the separation. When a member migrates out, the billing reflects it.

This is what prevents the parallel spreadsheet problem. The administrator does not have to remember to update billing when the membership changes. The system reads the truth at the time of the run.

Separate adult children and the household split event

The most common mutation in a community membership database is the adult child who forms their own household. A 28-year-old who married last year, lived with the parents for a transition period, and has now moved into their own home and wants to be billed as a separate household.

The household split is a specific event the system handles. The adult child is moved to a new household with their spouse, the new household is created with its own subscription rate, and the original household's billing recomputes from the next cycle. The historical record preserves the previous household membership for queries that look back.

The reverse event also happens. A household consolidates when an elderly parent moves in with an adult child, or when a financially constrained family asks to be billed jointly with relatives. The system supports the consolidation event the same way: clean state transitions, preserved history, correct billing from the next cycle.

The broader treatment of how the membership data model itself is structured is at membership databases for community institutions.

Deceased members and the question of when billing changes

A death in a community is treated with care, and the billing system has to reflect this. The deceased member's record stays in the database. The household's billing changes from the next cycle, with the change calculated from the rate structure (per adult, per household, scaled to remaining members).

The institution sometimes maintains the previous rate for a grieving family for an agreed period as a form of solidarity. The administrator records this as a waiver with an expiry date. The billing engine respects the waiver. After the agreed period, the regular rate resumes.

Each of these decisions is a small operational interaction between the institution and the family. The system supports the interaction by making the adjustment easy to record and the billing accurate to reflect it. The institution communicates warmth. The system delivers correctness. Both sides of the relationship are served. The related view on contributions as relationships rather than transactions is at voluntary contributions and community trust.

Special collections and voluntary contributions alongside subscriptions

A community organisation runs more than one financial stream. The subscription dues are predictable. The special collections for specific causes, like a building fund or a relief effort, are episodic. The voluntary contributions for institutional purposes are continuous but unstructured.

The billing surface has to express all three without confusing them. The subscription invoice on the first of the month is one document. A special collection appeal is a separate communication, with its own payment link and acknowledgement flow. A voluntary contribution can come in at any time and is recorded against the household with its purpose noted.

A household's annual financial summary, which the institution shares with the household for tax or personal record purposes, rolls up all three streams cleanly. Subscriptions paid. Special collections contributed to. Voluntary contributions made. The household sees one document with the full picture. The institution's own reporting separates the streams for governance.

What this enables for the administrator and the trustees

The administrator running the monthly billing cycle, with this system in place, spends about 20 minutes on the run itself. The work is reviewing the generated invoices, handling the small number of exceptions that have come up since the last cycle, and triggering the dispatch. The remainder of the month, the billing engine handles receipts, follow-ups, and payment recording automatically.

The trustees see a monthly financial dashboard that reflects the actual state of the institution's recurring revenue, special collections, and voluntary inflows. The dashboard reads from the same data the billing engine uses, which means there is no reconciliation gap between what the billing system shows and what the governance dashboard shows.

This is what decision infrastructure for a community organisation's billing looks like. A data model that respects the household shape. A billing engine that reads the live membership truth. A discipline that keeps the exception layer small. The broader view of how we approach community institution systems is on the approach page.

When you are ready to talk through what this looks like for your organisation, Start a Conversation.