A brick kiln runs on advances. A group of majdur is given money before the season starts, or against work not yet completed, and that advance is worked off over weeks or months as production continues. It is a system built on trust, and for the most part it works—until settlement day, when the owner's number and the group's number do not match.
The mismatch is rarely fraud. It is usually a small, honest gap: a partial payment that was not written down the day it happened, a deduction for material that got mixed in with a wage entry, or a group's advance that was never split out per member until someone left midway through the season.
How advance tracking is usually done
Most bhattas keep one entry per labour group in a register: an opening advance, then a running list of payments made against work completed, usually in piece-rate terms tied to production. A munshi updates it, often from memory or a scrap of paper, at the end of a long working day.
For a single, stable group working the full season, this is usually enough. The trouble compounds when there are several groups, when membership within a group changes, or when advances, wage payments and material deductions all land in the same book without a clear label for which is which.
Where disputes actually come from
- Group totals without an individual break-up. A group advance is easy to record as one number, but when one majdur leaves early or a new one joins, splitting the balance fairly requires records that were never kept per person.
- Deductions mixed with payments. Material issued on credit, a loan, or an interest adjustment recorded in the same line as a wage payment makes it hard to explain the final number later.
- No date discipline. A payment written down two days after it happened, from memory, tends to drift from what was actually paid.
- Different people keeping the count. If the owner remembers one figure and the munshi's book shows another, there is no single source either side trusts by default.
- Production-linked pay that is not connected to the production record. Piece-rate wages depend on output, but if the wage book and the production book are separate, someone has to manually match them—and mistakes get made in that matching step, not in the writing itself.
What a good labour account actually needs to do
Fixing this is less about the software and more about what the record needs to preserve. Whether on paper or on a screen, a labour account that avoids disputes needs the same things:
- A running balance per group and per individual, not just per group.
- Every advance, payment, and deduction entered with its own date and type—never merged into one line.
- A direct link between production entries and the wage they generate, so piece-rate pay is calculated from the same numbers as the production record, not re-typed separately.
- A statement either side can look at together at settlement time, showing every entry that built up to the final balance—not just the total.
What changes when this moves into eBrix
eBrix keeps labourer and group accounts connected to the same production entries the munshi is already recording. An advance, a part-payment, or a deduction is entered as its own dated transaction, and the running balance—per group and per individual within it—updates immediately.
Because piece-rate work is drawn from the same production record used elsewhere in the system, wages owed are calculated from actual recorded output rather than a manual estimate carried over from memory. When a group member leaves partway through a season, the individual balance is already separated out, so settlement does not require reconstructing months of shared entries by hand.
Being honest about the trade-off
None of this replaces the need to enter transactions as they happen. A payment recorded three days late in eBrix is exactly as unreliable as one written three days late in a register—the software only removes the arithmetic and matching work, not the discipline of timely entry.
The clearest improvement shows up for kilns running more than one labour group, or where group composition changes mid-season. A single, stable group with no membership changes may not feel a large difference beyond having a backup of the register.
Making settlement day easier
- Review the statement with the group before the final payment, not after—most disputes are resolved faster when both sides see the same entry list.
- Record deductions the same day material or a loan is given, tagged separately from wage payments.
- Split group advances into individual shares as soon as membership is confirmed, rather than waiting until someone leaves to work it out.
- Keep the previous season's closed statement as a reference—patterns in advances tend to repeat season to season.