Finance

The Finance workspace is split into tabs so each kind of finance work has a clear place. Use the tab that matches the question you are trying to answer.

Finance structures define reusable recurring or one-time plans, such as tuition, admission fees, teacher salary, sub admin salary, finance manager salary, vendor expenses, or other school-defined amounts.

• A structure is created once, then assigned to students, teachers, sub admins, finance managers, sections, cohorts, courses, or another income/expense entity.
• Student structures are income for the school. Teacher, sub admin, finance manager, and other expense structures are expenses for the school.
• Amounts support cents, so values such as 1250.50 can be saved and shown correctly.
• Generated entries track payment state separately from the structure definition.
• Timed entries generated by the finance scheduler create in-app notifications and web push notifications when push is enabled.
• School finance payment verification is recorded inside EduVerse. AI subscription checkout is handled separately from school fee and payroll workflows.
• Use Create one-time entry for a single charge or payable, including a named external payer or payee, without creating a recurring structure.
• Group assignments capture the people in the selected group when the structure is saved. Later enrollment changes do not automatically change these assignments.
• Choose the currency on each new structure or one-time entry. Changing the organization default does not convert or relabel existing entries or transactions. Payroll and reports calculate one currency at a time.
• Recurring due days support 1 through 31 and clamp to the last day of shorter months. Semester and yearly plans can follow calendar periods or their start date; new academic-cycle plans follow their start date.
• Once entries exist, create a new plan to change its billing cycle, start date, or period anchor. Editing an amount or due day can optionally update outstanding entries; entries with payment or pending-claim amounts above the new amount are skipped.
• Finance administrators can reject a pending claim or reverse a recorded payment with a reason. Reversal preserves the original transaction, adds its opposite, and reopens the balance. It does not send a bank refund.
• Finance records retain their currency and target name when a person is removed. Historical currencies already changed by older software may require manual review.

The amount is the value used when entries are created from the structure. It should match the agreement for every selected assignment target.

• Use a positive amount that matches the billing agreement.
• Use decimal points when cents matter, such as 99.50 or 1250.75.
• For one-time structures, the amount usually represents the full charge.
• For recurring structures, the amount usually represents the value for each billing period.
• Changing an existing structure does not automatically rewrite old entries or transactions.
• If you choose to update current outstanding entries, paid and cancelled entries are still kept as they were.

Payroll is the staff payment side of finance. Teachers, Sub Admins, and Finance Managers can all receive assigned payment structures and generated payment entries.

• Use teacher payment structures for teachers.
• Use sub admin payment structures for Sub Admin staff accounts.
• Use finance manager payment structures for Finance Manager staff accounts.
• Staff members can use My Finance to view their own assigned payroll records when their role has that view.
• Payroll entries are expenses for the school, not student fee income.

Students and other assigned users can submit payment claims where enabled. Finance staff verify claims, reject invalid claims, and maintain transaction history for audit visibility.

• A payment claim records who claimed payment, how much was claimed, how it was paid, when it was claimed, and any note or reference.
• Unverified payments still need staff review.
• Confirm a payment only after checking the receipt, transaction reference, cash record, or other school-approved proof.
• Confirmed payments update the paid amount and transaction history.
• A user cannot confirm their own claim. Another allowed staff member must review it.
• A claim can only be confirmed or rejected while it is still waiting for review.
• Once the full amount is paid, confirmation controls are restricted and the entry displays as fully paid.

A payment claim sends an entry to staff for review. It is useful when someone has paid outside EduVerse and needs the school to verify the payment.

• Claimants should choose the correct entry and claimed amount before submitting.
• Receipt links, transaction references, and notes should be clear enough for staff to verify.
• A claimed payment remains Awaiting Approval until staff confirms it.

Payment confirmation is the staff action that accepts a payment claim or records a verified payment. This changes the entry balance and may create a confirmed transaction record.

• Review who claimed, what they claimed, how they paid, when they claimed it, and why or what reference they provided.
• Confirm only the amount that was actually verified.
• Use partial confirmation when only part of the balance was paid.
• Once an entry is fully paid, it appears as paid instead of due or awaiting approval.
• If a confirmed transaction needs correction later, use a reversal or refund record. Do not treat transaction editing as the normal correction method.
• Keep receipt and reference details readable so later audits make sense.

Transactions are confirmed money records. They are created after a payment or staff payout is accepted, confirmed, or reversed.

• Use Transactions to answer money questions such as what was paid, how much was confirmed, which entry it belongs to, and which payment method or reference was used.
• Transactions should stay clear and stable. Corrections should happen through reversal or refund records instead of quietly changing the original money record.
• Transactions are useful for finance reporting, payment history, and checking confirmed income or expenses.

Audit logs show the history of finance actions. They are designed for review, accountability, and troubleshooting.

• Creating too many duplicate structures instead of assigning one structure to the right targets.
• Confirming a payment claim before checking receipt or reference details.
• Assuming a claimed payment is already paid before staff approval.
• Editing a structure and expecting paid entries or transactions to rewrite automatically.
• Using Transactions to investigate system changes when Audit Logs are the right place.
• Assigning staff payroll under Other Expense instead of using Teacher, Sub Admin, or Finance Manager targets.