Skip to content
All modules Finance

Transport Fees software for Indian schools

Route-based billing

Feature identity

Transport Fees

An illustration, not a screenshot. The interactive example below shows what this capability actually does.

Example view

Transport Fees in a school workflow

Route-based billing

Finance
Transport Fees in a school workflow
Finance
  1. 01
    Required context

    Active transport allocations, route pricing and fee/tax configuration must be confirmed before rollout.

  2. 02
    Supported work

    Monthly billing run with preview-before-commit and per-student proration.

  3. 03
    Reviewable result

    A previewed monthly rider-billing result with proration, waitlist/suspension exclusions and its own accounting classification.

Example record

Transport Fees

Authorised view
  • Monthly billing run with preview-before-commit and per-student proration
  • Waitlisted or suspended riders never get billed
  • Per-school GST configuration on SAC 9964, split computed on read
  • Reconciles to “Transport Fees Income” across every statement
A previewed monthly rider-billing result with proration, waitlist/suspension exclusions and its own accounting classification.
Code-native illustrative example · not live product UI · no customer dataExample labels and outcomes come from this capability's reviewed catalogue record.

Product scope

What it does

Route fees become real invoices through a monthly billing run — one transport invoice per rider, idempotent per month, with proration built in (join on the 1st: full month; by the 15th: half; later: skipped). GST is a per-school choice (exempt for own fleets, or the 5/12/18% slabs for operators), and transport income lands in its own ledger head, never mixed into tuition.

The school problem

School teams need a dependable way to handle Transport Fees: Route-based billing. The required records, assigned roles and review boundary must remain explicit.

Day-to-day work

How your school uses it day to day

Route-based billing.

  1. Monthly billing run with preview-before-commit and per-student proration
  2. Waitlisted or suspended riders never get billed
  3. Per-school GST configuration on SAC 9964, split computed on read
  4. Reconciles to “Transport Fees Income” across every statement

Operational result

What your school gets

A previewed monthly rider-billing result with proration, waitlist/suspension exclusions and its own accounting classification.

Access and ownership

Who typically uses it

  • Transport manager
  • Accountant
  • Fee-desk executive
  • Finance approver

What each person can actually see depends on the role you give them and which classes or records you assign.

Availability and setup

What to confirm before rollout

Finance catalogue capability

  • Active transport allocations, route pricing and fee/tax configuration
  • Confirm plan scope, role permissions, data dependencies and any provider or migration prerequisites during the demo and proposal.

Connected operating context

Available workflows

These are the documented neighbouring capabilities that school teams may review with this module. A related page does not imply that every hand-off is automatic or enabled in every plan.

Explore all modules

Buyer questions

Frequently asked questions

The questions school owners ask before they subscribe: what it does, who can see it, and what to set up first.

Does Transport Fees work on its own?

Transport Management, Fee Structure, Fee Collection, Transport Reports are the documented neighbouring capabilities. They help a school evaluate the surrounding hand-offs, but a related page does not mean every integration is automatic or included in every plan.

What should our school prepare before enabling Transport Fees?

Active transport allocations, route pricing and fee/tax configuration. Confirm plan scope, role permissions, data dependencies and any provider or migration prerequisites during the demo and proposal.

Is AI used in Transport Fees?

No AI capability is asserted for Transport Fees. Its documented work remains controlled by school records, roles and permissions.

How do we confirm the plan and implementation scope?

Plan inclusion and rollout scope depend on the live plan matrix, readiness state and your school's written proposal. The demo team will confirm the applicable boundary before rollout.

See it in your school context

Run transport fees the connected way.

See how this workflow fits your school's current records, roles, plan and rollout requirements.