Skip to content

Splitting a part payment across fee heads

Status: in review, 3 October 2026. Code: a webapp PR on top of #1835 (it needs that PR's ERP migration first).

Why this exists

  1. Who asked: the founder, directly.
  2. Observed pain: a structure has a development fee of ₹20,000 and a tuition fee of ₹30,000. A family pays ₹30,000 and wants ₹20,000 on tuition and ₹10,000 on development. The desk had no way to record that. A payment was money against the structure as a whole, and receipts and head-wise reports estimated each head's share.
  3. Cost of not doing it: parents claim the tuition component under Section 80C and need a receipt that states it. Many schools bank development or building funds separately and reconcile by head. With no real split, the receipt and head-wise totals are estimates and accountants keep a side ledger.
  4. Validated or a guess: the founder's request plus the 80C and separate-account practice. No customer ticket is cited yet.
  5. How we'll know: the accountant records the split once, and the receipt and the student's remaining dues per head match it. If we removed it, accountants would be back to correcting head-wise figures by hand.

How it works

  • The Record Payment modal shows a "Split by fee head" block when the payment is a part payment and two or more heads still owe money. Each head shows what's due and takes an amount.
  • Staff enter the split, or leave it blank. Entered amounts must each be within what that head still owes and must add up to the payment. Left blank, the payment is split in proportion to what each head still owes.
  • A full payment needs no split: it settles every head.
  • Discount: each head's due is its amount less a proportional share of the student's discount. There is no per-head discount entry.
  • Online and portal payments are split proportionally; parents don't choose heads.
  • Receipts: when staff entered the split, the receipt lists each head with the amount paid, so tuition is stated on its own. Otherwise the receipt keeps its existing layout (installments, or heads with "Paid earlier" and "Balance due").
  • Refunds come back off a payment's heads in proportion to how it was split.

The installment schedule is unchanged. Installments say when money was due; the head split says what it paid for. A payment can be both, for example clearing Term 1 while paying ₹20,000 of tuition.

Data

erp.fee_payment_heads records one row per payment per head, with the amount allocated. fee_payments.head_split_by_staff marks splits entered at the desk.

Older payments are not backfilled. They have no head rows and count against each head in proportion to the structure's line amounts, the same estimate head-wise reports already used.

Non-goals

  • Parents choosing heads in the portal.
  • A discount on a specific head (for example a tuition-only concession).
  • Changing older receipts. Receipts are frozen when issued.
  • Rewriting head-wise collection reports. They still apportion; using the recorded split there is a follow-up.

Rejected alternatives

  • Always print heads on the receipt. Every payment gets a head split, but printing it for proportional splits would replace the installment receipt layout schools already use, for a split nobody chose.
  • Fill heads in a fixed order (for example tuition first) as the default. It needs every school to order heads deliberately; proportional matches today's head-wise estimates, so reports don't jump.
  • Backfill old payments. It would invent a split nobody recorded and change past figures. Apportioning on read gives the same numbers without writing them down as fact.