Step 2 of 4 · Fees, finance, and payroll

Fees and payments

Generate invoices and receive payments against student balances.

Fees and payments in LiveSchools365 Finance and Payroll

Fees and payments is a Finance and Payroll workflow in the Financial control area of LiveSchools365 school management software. Generate invoices and receive payments against student balances. Schools use it so A traceable financial position from operational transaction to ledger impact.

Connect fee billing, payments, expenses, accounting, approvals, and payroll. The people who typically work here are Accountant, Finance manager, Administrator, Approver. The rest of the module stays one click away, so an inquiry, register, invoice, or stock movement does not have to be re-typed into another product.

What this workflow changes

Structured billing This sits inside Finance and Payroll rather than a separate spreadsheet, which keeps the audit trail on the same student, staff, or item record.
Invoice allocation This sits inside Finance and Payroll rather than a separate spreadsheet, which keeps the audit trail on the same student, staff, or item record.
Receipt traceability This sits inside Finance and Payroll rather than a separate spreadsheet, which keeps the audit trail on the same student, staff, or item record.

How it fits the rest of Finance and Payroll

Open these related Finance and Payroll guides when you want the step before or after Fees and payments:

Finance dashboard — Review receivables, expenses, approvals, and accounting readiness.
Payroll management — Configure components and process auditable salary runs.
Accounting workspace — Create balanced journals and inspect posted entries.

How schools evaluate this screen

During a demonstration or trial, Accountant, Finance manager, Administrator, Approver should complete one realistic example: a new inquiry, a section register, a fee receipt, a notice, or a stock issue, depending on the module. Then confirm that the same record appears on the dashboard, the related report, and the next workflow. That is the test of a school ERP: one operational picture instead of parallel files.

Trend Developers can walk this exact screen against your admission, attendance, exam, or fee process. You can also start a 14-day trial and use the matching live form after sign-in.

All Finance and Payroll workflows · Start a trial · View pricing · Request a demonstration

Guide depth

Interface

Desktop interfaceComplete operational workspace with demonstration data

Structured billing

Invoice allocation

Receipt traceability

Page anatomy

Fields, controls, and effects

Use this reference to understand what each area accepts and what it changes.

Billing scopeCampus, grade, section and month selects · Input

Purpose: Invoice month lists every month in the selected billing session. Choosing a month sets the invoice date to the last day of that month and the due date to the 5th of the next month. Both dates can still be changed.
Rules: Requires an active fee structure for that month.
Application effect: Previews how many challans will be generated and their total amount.

Fee headsChecklist · Input

Purpose: Tick the fee heads from this month's fee structure. The voucher includes only the ticked heads.
Rules: At least one fee head must stay ticked.
Application effect: Unticked heads are left off the invoice.

Invoice / due dateDates · Input

Purpose: Set posting and payment deadline. They fill in from the invoice month and can be edited.
Rules: Due date should not precede invoice date.
Application effect: Appears on invoices and ageing.

Late fee fineNo late fee, fixed amount per day, or percentage · Input

Purpose: Choose no fine, a fixed amount for each day after the due date, or a percentage of the amount due once the due date has passed.
Rules: A fixed amount or percentage is required when a fine is selected. The percentage cannot be more than 100.
Application effect: The challan states the rule. The fine is added to the balance after the due date while the fee is still unpaid, and a payment includes it.

StudentSearch/select · Input

Purpose: Choose a payer for receipt entry.
Rules: Use the correct student code.
Application effect: Loads open invoices.

Amount / payment mode / referenceNumber and text/select · Input

Purpose: Record money received and trace information.
Rules: Amount must be positive; reference may be required.
Application effect: Creates payment and allocations.

AllocationInvoice checklist/amounts · Input

Purpose: Distribute payment across invoices.
Rules: Allocated total cannot exceed receipt.
Application effect: Reduces invoice balances.

Batch vouchersEye and printer on a batch · Output

Purpose: The batch list filters by academic year, then by the months that already have batches. The eye opens that batch's vouchers in a wider window, where a search box finds a voucher and Detail opens it. Print challans prints every voucher in the batch, with the office, student, and bank copies together on one page.
Rules: Printing does not change the batch status.
Application effect: Each copy lists the fee heads and the amount payable.

Generate / receiveCommands · Output

Purpose: Create invoices or post payment.
Rules: Review preview and totals first.
Application effect: Updates ledger and dashboards.

Fee defaultersDays past due · Input

Purpose: Campus, grade, section, search, minimum outstanding, and days past due sit above the defaulter list. Send message opens a wide window. Zoom the template, and insert <STNAME>, <CLASS>, <FEEHEAD>, or <PAYABLEAMOUNT>. Those placeholders are replaced for each student when the message is queued.
Rules: Choose the filters, then load defaulters.
Application effect: Queue message creates one communication delivery per student and selected channel.

Collection receiptsView on a collection date · Action

Purpose: Opens that day's receipts grouped by payment mode, with a total for each mode.
Rules: Uses the same campus and payment-mode filters as the loaded reconciliation.
Application effect: Does not change any receipt.

Bank interfaceBank channel · Input

Purpose: On Receive Fee Payment, Bank interface registers a bank. The bank asks what a challan number or student code is due, then posts the payment with its own transaction id. The same id returns the same receipt. Payment attempts are listed on Bank Receivings, where the school or the bank can open a dispute and the school marks it resolved with a note.
Rules: Copy the API key and signing secret when the channel is created. They are shown only then. The amount can be part of the dues and cannot be more than the amount due.
Application effect: The receipt is stored as Bank Transfer or Online, with the bank transaction id as the reference.