Fees
Purpose
The Fees domain manages fee definition, scheduling, billing, adjustments, penalties, collections, and payment tracking.
The Fees domain consists of:
- Fee Structure
- Fee Component
- Fee Schedule
- Student Fee
- Fee Adjustment
- Late Fee Policy
- Fee Charge
- Payment
Business Context
Schools define fee structures for Academic Years and Classes.
Examples:
2026-2027
Grade 5
- Admission Fee
- Tuition Fee
- Annual Fee
- Transport Fee
When Students are enrolled, applicable fees are generated automatically.
Schools can then:
- Collect payments
- Apply discounts
- Apply scholarships
- Waive fees
- Apply late fees
- Track outstanding balances
Fee Structure
Purpose
Fee Structure defines the fee configuration applicable to a Class for an Academic Year.
Examples:
2026-2027
Grade 5
- Admission Fee
- Tuition Fee
- Annual Fee
- Transport Fee
Relationships
Fee Structure to Academic Year
- Each Fee Structure belongs to exactly one Academic Year.
Fee Structure to Class
- Each Fee Structure belongs to exactly one Class.
Fee Structure to Fee Components
- A Fee Structure contains one or more Fee Components.
Key Design Decisions
Academic-Year Scoped
Fee Structures belong to:
- Academic Year
- Class
Fee structures may vary between years and classes.
No Versioning
Fee Structure versioning is excluded from V1.
Administrative updates are managed directly.
Attributes
Identity
- FeeStructureId
- AcademicYearId
- ClassId
Status
- Active
- Archived
Audit
- CreatedAt
- CreatedBy
- UpdatedAt
- UpdatedBy
Fee Component
Purpose
A Fee Component represents an individual fee item within a Fee Structure.
Examples:
- Admission Fee
- Tuition Fee
- Annual Fee
- Transport Fee
- Exam Fee
- Library Fee
Key Design Decisions
Configurable Components
Fee Components are configurable.
The platform must not hardcode fee types.
Mandatory and Optional Components
A Fee Component may be:
- Mandatory
- Optional
Examples:
Mandatory:
- Tuition Fee
Optional:
- Transport Fee
Attributes
Identity
- FeeComponentId
- FeeStructureId
- Name
Amount
- Amount
Configuration
- IsMandatory
Status
- Active
- Archived
Fee Schedule
Purpose
Fee Schedule defines when a Fee Component becomes payable.
A School may follow different billing models for different Fee Components.
Key Design Decisions
Frequency Per Component
Billing frequency belongs to the Fee Component.
Examples:
Tuition Fee
- Monthly
Annual Fee
- Yearly
Exam Fee
- HalfYearly
Supported Frequency Types
- Monthly
- Quarterly
- HalfYearly
- Yearly
- Custom
Attributes
Identity
- FeeScheduleId
- FeeComponentId
Configuration
- FrequencyType
Schedule Details
- DueDate
- Amount
Status
- Active
- Archived
Student Fee
Purpose
Student Fee represents an amount payable by a Student Enrollment.
Student Fees are generated from Fee Structures.
Relationships
Student Fee to Student Enrollment
- Each Student Fee belongs to exactly one Student Enrollment.
Student Fee to Fee Component
- Each Student Fee originates from exactly one Fee Component.
Student Fee to Payment
- A Student Fee may have multiple Payments.
Student Fee to Fee Adjustment
- A Student Fee may have multiple Adjustments.
Student Fee to Fee Charge
- A Student Fee may have multiple Charges.
Key Design Decisions
Generated from Enrollment
Student Fees are generated when a Student Enrollment becomes active.
Partial Payments Supported
A Student Fee may be paid through multiple Payments.
Examples:
Fee Due:
₹12,000
Payments:
₹5,000
₹3,000
₹4,000
Attributes
Identity
- StudentFeeId
- StudentEnrollmentId
- FeeComponentId
Financials
- BaseAmount
- TotalCharges
- TotalAdjustments
- AmountPaid
- OutstandingAmount
Due Information
- DueDate
Status
Possible values include:
- Pending
- PartiallyPaid
- Paid
- Cancelled
Audit
- CreatedAt
- CreatedBy
- UpdatedAt
- UpdatedBy
Derived States
Derived states should not be persisted.
Due
Current Date <= DueDate
and
Status is not Paid
Overdue
Current Date > DueDate
and
Status is not Paid
Fee Adjustment
Purpose
Fee Adjustments reduce payable amounts.
Adjustments are applied at Student Fee level.
Examples
- Sibling Discount
- Scholarship
- Staff Child Concession
- Fee Waiver
Key Design Decisions
Student Specific
Adjustments are Student-specific.
They are not defined within Fee Structures.
Multiple Adjustments Supported
A Student Fee may have multiple Adjustments.
Examples:
- Scholarship
- Sibling Discount
applied simultaneously.
Types
- Discount
- Scholarship
- Waiver
Calculation Types
- FixedAmount
- Percentage
Attributes
Identity
- AdjustmentId
- StudentFeeId
Configuration
- Type
- CalculationType
- Value
Details
- Reason
- EffectiveFrom
- EffectiveTo
Approval
- ApprovedBy
- ApprovedAt
Late Fee Policy
Purpose
Late Fee Policy defines how penalties are calculated when fees become overdue.
Policies are configuration entities.
They do not represent financial transactions.
Supported Policy Types
OneTime
Example:
₹500 once after due date.
PerDay
Example:
₹10 per day
Maximum ₹500
SlabBased
Example:
1-15 Days → ₹100
16-30 Days → ₹300
31+ Days → ₹500
Attributes
Identity
- PolicyId
- FeeComponentId
Configuration
- PolicyType
Effective Dates
- EffectiveFrom
- EffectiveTo
Status
- Active
- Archived
Fee Charge
Purpose
Fee Charges increase the amount payable by a Student.
Charges are generated from business rules and policies.
Examples
- Late Fee
- Penalty
- Additional Charge
Key Design Decisions
Charges are Operational Records
Charges are generated based on configured policies.
They provide an auditable financial trail.
Charges are Separate from Adjustments
Charges increase amounts due.
Adjustments reduce amounts due.
Types
- LateFee
- Penalty
- OtherCharge
Attributes
Identity
- ChargeId
- StudentFeeId
Details
- Type
- Amount
- Reason
Generation
- GeneratedOn
Payment
Purpose
Payment represents money collected against Student Fees.
Key Design Decisions
Partial Payments Supported
A Payment may settle part of a Student Fee.
Payment Tracking
All collections are recorded as Payment records.
Payment Methods Tracked
Supported examples:
- Cash
- Cheque
- UPI
- Card
- Bank Transfer
- Online Gateway
Attributes
Identity
- PaymentId
Financials
- Amount
Details
- PaymentDate
- PaymentMethod
- ReferenceNumber
- Notes
Audit
- CreatedAt
- CreatedBy
Calculations
Net Amount Due
Net Amount Due is calculated as:
Base Amount
- Charges
- Adjustments
Outstanding Amount
Outstanding Amount is calculated as:
Net Amount Due
- Payments
Constraints
Fee Structure Uniqueness
A School may have only one active Fee Structure per:
- Academic Year
- Class
Student Fee Generation
Student Fees must be generated from active Fee Structures.
Adjustment Scope
Adjustments may only apply to Student Fees.
Charge Scope
Charges may only apply to Student Fees.
Exclusions
The following capabilities are excluded from V1:
- Refund Processing
- Fee Structure Versioning
- Accounting Ledger Integration
- Payment Gateway Integration
- Reservation Quotas
- Seat Blocking
These capabilities may be introduced later.
Future Considerations
The following capabilities may be introduced later:
- Refunds
- Payment Gateway Integration
- Accounting Integration
- Automated Fee Reminders
- Dynamic Fee Rules
- Fee Structure Versioning
- Installment Plans
- Financial Reporting
These capabilities should not require redesign of the Fees domain.
Summary
Core decisions:
- Fee Structure belongs to Academic Year and Class.
- Fee Components are configurable.
- Billing frequency is configured per Fee Component.
- Monthly, Quarterly, HalfYearly, Yearly, and Custom schedules are supported.
- Student Fees are generated from Student Enrollments.
- Partial Payments are supported.
- Fee Adjustments support Discounts, Scholarships, and Waivers.
- Late Fee Policies support OneTime, PerDay, and SlabBased rules.
- Fee Charges support Late Fees and Penalties.
- Transport is treated as a Fee Component.
- Refunds are deferred from V1.