How Automatic Meal-Rate Billing Actually Works

Ask most mess managers how they calculate a monthly bill and you'll get some version of "I add up the bazar khata, divide by however many people ate, and hope nobody argues." It works, until someone does argue — and in a hostel with twenty members eating a different number of meals every day, someone always does.

Meal units, not headcounts

The mistake most manual systems make is billing per member instead of per meal. If Member A ate 60 meals this month and Member B ate 45, splitting the bazar bill evenly between them is exactly the dispute waiting to happen. A meal-rate system instead totals every meal unit actually eaten — one per meal, plus fractional guest meals — across the whole workspace for the period.

That total comes straight from the attendance members already recorded: a per-meal on/off toggle for each day, respecting whatever cutoff time and cutoff-days-before the workspace has set, enforced in the workspace's own timezone so a cutoff means the same thing to everyone eating there.

The rate itself

Once the period closes, the calculation is simple in principle:

• Every bazar expense for the period is totalled.
• That total is divided by the total meal units eaten, producing one meal rate for the period.
• Guest meals — added by members in half-guest increments, priced either at that same meal rate or a fixed per-guest rate — are folded in at their own price.

What doesn't go into that division is utilities. Electricity, gas, water and wifi are tracked separately and split equally across members instead of by meal count — someone who cooks and eats every meal shouldn't pay more for the wifi than someone who's rarely home. Manage-only members — an owner who runs the place but eats elsewhere — are excluded from both the meal-unit total and their own bill entirely.

Writing the bill

With a rate in hand, the system writes one debit per member: their meals at the period's rate, their guest meals, their equal share of utilities. Each member's bill draws on any credit they've already built up — from deposits or from fronting bazar cash themselves — oldest credit first, and any leftover balance after that is reported back as a refund due, never silently kept.

None of this involves money actually moving through the app. A payment recorded against a bill — cash, bKash, Nagad, bank transfer, or "other" — is a manually entered record of something that happened outside it, not a live transaction. There's no payment gateway sitting behind any of these labels.

What an admin sees after

Once bills are generated, an admin gets a per-member breakdown of exactly how a figure was reached, a collection-status view across every member for the period, and each member's own payment history against their bills. Nobody has to reconstruct the math from a notebook to answer "why is my bill this much" — the breakdown already says so.

See the full walkthrough of automatic bill generation, or check current pricing — the product is free while in beta, with every feature above included.