Design the control first
Give every fee handoff one record and one owner.
Fee errors persist when responsibility is described as ‘the accounts team’ and several spreadsheets, screens or messages are treated as equally authoritative. Name the source, owner, cut-off and evidence for each stage before accepting money.Start with a short control note for the academic year. It should say who approves the fee structure, who may record an offline payment, who can view the provider dashboard, who checks the bank statement, who contacts a family and who authorises an adjustment. Separate preparation, collection, reconciliation and approval where staffing allows; where it does not, add a documented second review for high-risk changes.
| Control point | Primary owner | Independent evidence or review |
|---|---|---|
| Fee structure | Authorised school fee administrator | Approved academic-year schedule, version and effective date |
| Student assignment | Student-record or fee owner | Active learner, class, payer relationship and approved exception |
| Offline collection | Named cashier or authorised administrator | External receipt or approved source record plus daily collection total |
| Online transaction review | Authorised provider-dashboard user | Order, payment, amount, status and event timestamps |
| Bank settlement | Finance reconciler | Settlement identifier or UTR matched to the bank statement |
| Exception approval | Finance lead or school-authorised approver | Reason, evidence, action, actor and completion date |
One-day test
Can the school reconstruct yesterday without asking who remembers?
Choose one collection day and trace opening dues, offline records, online attempts, captured payments, provider fees, settlements, bank credits and open exceptions. If a step depends on a chat message, screenshot or one person’s memory, turn it into an approved record before volume increases.
- The school has named the authoritative fee schedule for the academic year.
- Every permitted payment channel has a written record and close time.
- Editing rights and reconciliation rights are assigned deliberately.
- A family-facing status is not changed from an unverified screenshot or verbal claim.
- Exceptions are recorded in one queue rather than spread across inboxes and messages.
Build a trustworthy starting point
Define what is due before trying to explain what was paid.
A payment can be technically correct and still be allocated to the wrong learner, academic year or fee expectation. Freeze the meaning of the fee position before the collection window opens.Approve the academic-year fee schedule.
Record the classes, fee heads, amounts, due dates, effective date, approver and version. Keep a superseded version available for explaining historical balances.
Confirm the learner and payer relationship.
Check the active learner, class and linked parent context before exposing dues or accepting a payment against the record.
Separate an opening balance from a current charge.
Retain the source, as-of date and approval for brought-forward amounts so a new fee schedule does not silently rewrite history.
Record approved exceptions outside the standard schedule.
Use the school’s authorised process for any concession, scholarship, allocation, waiver or correction. Do not infer that Schylva supports these workflows.
Publish only the reviewed payer view.
Check the amount, learner, year, due context and payment availability in a sample or approved account before wider release.
| Field | Control question | Typical mismatch |
|---|---|---|
| Academic year | Which period owns this fee and balance? | Payment applied to the current year instead of an opening balance |
| Learner and class | Which active learner and class structure were approved? | Sibling or transferred learner selected |
| Fee head and amount | Which approved schedule version created the amount? | Old and revised schedules mixed |
| Due date or instalment | What does the school expect by this date? | A part payment appears as a complete instalment |
| Opening balance | What source and as-of date support it? | Historical amount changed without approval |
| Adjustment | Who approved the reason and value? | Correction used to hide an unreconciled collection |
Balance integrity
Never silently change an opening balance to make reconciliation pass.
A balancing edit can conceal the real error: a missing transaction, wrong learner, duplicate record, unprocessed refund or incorrect source. Preserve the original position, post only an authorised correction through the school’s accounting process and keep the explanation linked to the affected record.
Schylva is not presented as accounting software. Its current public fee scope does not claim invoices, fee allocation, concessions, scholarships, refunds, formal receipts or a general ledger. Keep the school’s approved accounting and documentary requirements in the appropriate system and confirm how the operational fee view is reconciled to them.
Trace the payment path
Use identifiers and verified states—not a success screenshot.
The offline and online branches create different evidence. Both need a unique school context, amount, time, responsible actor and a status that can be checked independently.For an offline payment, record the approved source before changing status.
An authorised Schylva administrator can record a supported offline payment against a student’s fee record. Razorpay is not involved in that branch. The school must still retain the approved cash, cheque, transfer or other external evidence; perform its own daily collection control; and issue any required receipt through its formal documentary process because Schylva does not currently claim a formal receipt workflow.
For an online payment, distinguish order, payment, capture and settlement.
When the school has configured Razorpay, a linked parent can start the supported online-payment path. Schylva creates the order, Razorpay processes checkout under its terms and Schylva verifies the completed payment before updating the fee record. Razorpay’s official payment-gateway flow separates the order, checkout response, signature verification, capture and later settlement. Treat these as related but different states.
| Evidence | Why retain it | Do not treat it as |
|---|---|---|
| School learner and fee context | Identifies the person, year and expected amount | Proof that money moved |
| School collection or record reference | Connects the operational entry to the approved source | A provider payment ID |
| Provider order ID | Connects a payment attempt to the merchant’s order context | A captured payment or bank credit |
| Provider payment ID and status | Identifies the attempt and its verified lifecycle state | Settlement unless settlement evidence also matches |
| Settlement ID and UTR | Connects provider settlement evidence to a bank transfer | One student payment when the settlement is aggregated |
| Amount, fees, tax and timestamps | Explains gross-to-net movement and cut-off timing | An allocation decision without the school fee context |
State boundary
Payment captured is not the same as money credited to the school’s bank.
Razorpay describes a captured payment as confirmed and queued for settlement. Its settlement documentation separately provides settlement IDs and UTRs, and notes that a processed settlement event still precedes the bank credit reflecting after the applicable transfer timeline. Verify the bank statement before closing the settlement.
Close all three records
Reconcile school status, provider activity and bank settlement in sequence.
A useful daily close does not force the three totals to match prematurely. It explains timing, provider deductions, aggregation and every exception between them.Freeze the reconciliation cut-off.
Record the school date, time zone and cut-off. Keep later attempts and late status changes in the next run or a clearly labelled adjusting run.
Export or review school payment records.
Separate supported offline records from verified online records, then group by learner, amount, date and available reference.
Match online records to provider payments.
Match the order and payment identifiers, amount, currency, state and timestamps. Do not use amount and parent name alone as a unique key.
Bridge provider payments to settlements.
Use the provider settlement report to explain which payments, fees, taxes, refunds and adjustments produce each net settlement.
Match settlements to the bank statement.
Use the settlement identifier or UTR and exact net amount. Leave processed-but-not-credited items open until the bank evidence arrives.
Prove offline collections separately.
Match the day’s offline records to the school’s approved collection register, deposit evidence and formal accounting or receipt process.
Publish the close and exception queue.
Record matched counts and values, open items by reason, ageing, owner, evidence needed and next review time. Require approval for material write-offs or corrections.
| Comparison | Match on | Explain separately | Close evidence |
|---|---|---|---|
| Schylva fee record → Razorpay payment | Learner or school context, order ID, payment ID, gross amount and verified status | Failed attempts, retries, late authorisation and duplicate payment IDs | Each supported online record has one verified provider payment |
| Razorpay payment → provider settlement | Payment ID, settlement ID, gross amount and settlement inclusion | Provider fee, tax, refund, dispute, hold or adjustment | Gross activity bridges to the provider’s net settlement |
| Provider settlement → bank statement | Settlement ID or UTR, net amount and credit date | Bank timing, rejected transfer or unmatched bank credit | The exact net amount appears in the intended school account |
| Offline Schylva record → school collection control | Learner, amount, mode, date and school source reference | Cash variance, cheque state, transfer timing or deposit batch | Record agrees to approved collection and accounting evidence |
Razorpay’s official settlement reconciliation endpoint can return payments, refunds, transfers and adjustments associated with a settlement period. The school’s process may use authorised dashboard reports rather than an API, but the control principle is the same: retain the identifiers and bridge gross activity to the net amount instead of comparing only two headline totals.
Close rule
Zero unexplained difference matters more than zero open timing items.
A captured payment awaiting settlement or a processed settlement awaiting bank credit can remain open with evidence and a next review. A forced adjustment that makes totals equal without identifying the underlying item is not reconciliation.
Resolve by lifecycle state
Give every failed, pending, reversed or disputed item a distinct action.
The same family message—‘money was deducted’—can describe several payment states. Verify identifiers and current provider evidence before changing the fee record or promising a resolution time.| Observed state | First verification | School action | Close when |
|---|---|---|---|
| Failed; no debit reported | Provider payment ID, failure status and any retry | Keep fee due; explain that another attempt needs a new verified outcome | Failure and any later attempt are independently classified |
| Failed or pending; payer reports debit | Provider status, bank reference, time, amount and payment method | Do not record paid from a screenshot; give the approved provider or bank grievance route | Later capture, reversal or provider/bank resolution is evidenced |
| Captured; not in settlement | Payment ID, capture time, settlement state and any hold | Keep the settlement item open and review under the provider agreement | Included in a settlement or formally resolved |
| Settlement processed; bank credit missing | Settlement ID, UTR, net amount and intended bank account | Check the statement and escalate through the provider’s merchant path | Exact credit appears or the transfer is formally resolved |
| Duplicate payment | Distinct order/payment IDs, payer, learner, amounts and timestamps | Protect both records; follow the school-approved refund or adjustment process outside Schylva | Authorised outcome and final provider/bank evidence are retained |
| Refund requested or pending | Original captured payment, refund ID, amount and provider status | Do not mark complete from initiation alone; Schylva does not claim a refund workflow | Final refund state and school accounting treatment are verified |
| Dispute or chargeback | Provider case ID, reason code, response deadline and supporting records | Restrict sensitive evidence, assign an authorised owner and obtain qualified advice if needed | Provider outcome, bank movement and school record treatment agree |
| Offline variance | Collection record, external receipt, cash/cheque/transfer evidence and deposit batch | Stop unsupported edits and use the school’s incident and approval process | Difference is corrected or formally accepted by an authorised approver |
Failed-transaction boundary
Do not promise one reversal time for every payment method.
RBI’s failed-transaction framework defines method-specific turnaround and compensation conditions. The 2025 Payment Aggregator Directions require a dispute mechanism and agreements that delineate responsibilities for failed transactions, refunds, grievances and reconciliation. Verify the current official rule, payment method and provider process; this guide does not decide a payer’s entitlement.
Razorpay notes that late authorisation can change an earlier failed-looking attempt, and its payment webhooks can show a failed event followed by a captured event for the same transaction. The practical response is idempotent: keep identifiers, process a provider event once, review the current state and never create a second paid record merely because the state changed later.
Use a calm, evidence-led family response.
- Acknowledge the report without saying paid, failed or refunded before verification.
- Ask only for the minimum safe identifiers: date, amount, payment method and permitted transaction reference—not a password, PIN, OTP, CVV or full card data.
- State which school or provider record is being checked and when the family will receive an update.
- Do not request payment again while a genuinely ambiguous debit is under active review unless the school has explained the risk and approved process.
- Share the relevant provider or bank grievance path when the issue sits outside the school’s record.
- Close the conversation only after the fee record and financial outcome are both explained.
Protect the evidence and the boundary
Limit payment access, then evaluate Schylva against the real control plan.
Fee data connects a learner, family relationship and financial event. Give each role only the information needed for its task, keep credentials out of school records and separate public product claims from the school’s accounting responsibilities.The RBI’s 2025 Payment Aggregator Directions require payment aggregators to maintain dispute, security, fraud-prevention, merchant due-diligence and escrow controls. They do not make a school ERP the payment aggregator, bank or accounting ledger. The school should record its own provider agreement, authorised users, settlement account, escalation path and reconciliation evidence, then review them with qualified advisers where required.
Sensitive-data boundary
Never collect credentials or full payment-instrument data for reconciliation.
A reconciliation record normally needs provider-issued identifiers, amount, status, timestamps and settlement evidence—not passwords, API secrets, PINs, OTPs, CVVs or full card details. Keep production Razorpay keys and bank credentials in the approved secure administration path, never in a spreadsheet, support ticket or public Schylva enquiry form.
| Gate | Ready when | Stop and investigate when |
|---|---|---|
| Fee position | Schedule version, opening balances and authorised adjustments are explainable | A balance was changed only to make totals agree |
| Payment records | Every paid status has a permitted source and unique evidence | Screenshot, name or amount is the only proof |
| Provider reconciliation | Orders, payments, fees, tax, refunds and adjustments bridge to settlements | Captured and settled are treated as the same state |
| Bank reconciliation | Each net settlement matches the intended account by UTR or approved reference | A processed settlement is closed without bank evidence |
| Exceptions | Every open item has reason, value, ageing, owner and next review | Differences remain in private messages or an unowned spreadsheet |
| Access and retention | Authorised roles, evidence location, retention and removal decisions are recorded | Credentials or unnecessary family/payment details appear in working files |
Supported today
- Fee-structure configuration for the relevant class and academic year
- Authorised class and student fee-status review
- Supported offline school payment recording
- Linked-parent fee status and payment history
- Configured parent payment order and verification through Razorpay
Confirm for your school
- Academic year, class fee structure and parent-visible information
- Authorised administrators and the offline recording process
- Whether and how the school will configure Razorpay
- Provider charges, exception handling and school reconciliation
- The external accounting, receipt, refund and evidence process
Not currently claimed
- Full accounting, bookkeeping, general ledger or invoice workflow
- Fee allocation, concessions, scholarships or refunds
- Formal receipts or document workflow
- Automatic bank or payment-gateway reconciliation
- Every payment gateway, student self-payment or non-login fee reminders
Demonstration brief
Bring one redacted fee path and one settlement question.
Use a fictional or approved sample class structure and trace an offline record plus a configured parent-payment path. Ask how identifiers and verified status are exposed, then document the external reconciliation work the school still owns. Never submit student records, bank details, payment credentials, Razorpay keys or production data through a public form.
India’s Digital Personal Data Protection Act, 2023 and notified Digital Personal Data Protection Rules, 2025 establish a framework with phased commencement. This guide does not determine applicability, child-data conditions, lawful purpose, retention periods or exemptions for a school. Verify current notifications and obtain qualified advice.
Frequently asked questions
Clarify the decision and its boundaries.
Use these answers as a starting point, then verify the relevant source, rule and school process.What is school fee reconciliation?
It is the process of matching the school’s expected and recorded fee activity to payment-provider transactions and settlements, then matching each net settlement to the bank statement. Offline collections are reconciled separately to the school’s approved collection, deposit, receipt and accounting evidence. Every difference remains open with a reason and owner until resolved.
Is a successful online-payment screen enough to mark a school fee as paid?
No. A browser success response is not independent settlement evidence. Use server-verified provider identifiers and the current payment state before updating the operational fee record, then separately reconcile the captured payment to provider settlement and bank credit.
What is the difference between captured and settled?
In Razorpay’s documented lifecycle, captured means the payment is confirmed and queued for settlement. Settlement is the later transfer process to the merchant account. Reconcile the payment into a provider settlement and use its settlement ID or UTR to verify the related net bank credit.
How should a school handle ‘money debited but fee still due’?
Collect only the minimum safe reference, amount, date and payment method; check the current provider payment state and any later event; keep the item in an exception queue; and give the family the approved school, provider or bank escalation path. Do not mark paid from a screenshot or promise a universal reversal time.
Does Schylva automatically reconcile Razorpay settlements with the bank?
No. Schylva’s current public scope includes a configured parent Razorpay order and payment verification, but does not claim automatic bank or gateway reconciliation. The school must maintain the provider-to-bank close through its authorised finance process.
Does Schylva issue formal fee receipts or handle refunds?
No current claim is made for a formal receipt or refund workflow. Schylva fee status and history are not a formal receipt or accounting record. Handle required documents, refunds and their accounting treatment through the school’s approved external process and relevant payment provider.
Which Razorpay charges should the school expect?
Razorpay transaction charges remain payable by the school under the provider’s applicable terms and are separate from Schylva access fees. Confirm current pricing, taxes, settlement deductions, refund treatment, disputes and chargebacks in the school’s provider agreement and written commercial review.
What data should the school share when asking for fee-management support?
Use fictional, redacted or formally approved sample context whenever possible. Share only the minimum permitted identifiers and status evidence through the approved support route. Never send passwords, OTPs, PINs, CVVs, full card data, API secrets, bank credentials, live student records or production payment data through a public demo or quote form.
Primary sources and further reading
Read the official material behind the context.
Sources were reviewed when this guide was updated on 30 August 2026. Always verify the current official version before relying on a rule or requirement.Reserve Bank of India
Master Direction on Regulation of Payment Aggregator (PA) — 15 September 2025 Current primary direction reviewed for payment-aggregator definitions, dispute responsibilities, refunds, reconciliation, security and settlement context. It does not make this guide legal or regulatory advice.Reserve Bank of India
Harmonisation of Turn Around Time and customer compensation for failed transactions Official method-specific failed-transaction framework. Verify current amendments, the relevant payment method and the responsible regulated entity.Razorpay
Payment Gateway flow Provider documentation separating order creation, checkout, signature verification, capture and settlement in an online-payment flow.Razorpay
About Payments and payment lifecycle Provider documentation for payment states, late authorisation and dashboard actions. Confirm the school’s live account configuration and current provider terms.Razorpay
Fetch Settlement Recon Details Provider API reference illustrating payment, refund, transfer and adjustment details used to bridge gross activity to settlements.Razorpay
Settlements webhook events Provider documentation for settlement identifiers, UTR, fees, tax and the distinction between a processed settlement event and bank credit.Razorpay
About Refunds Provider documentation for refund types, states, reports and source refunds. Schylva does not currently claim a refund workflow.National Payments Corporation of India
UPI Frequently Asked Questions Official UPI context for checking transaction status and merchant grievance routes. The applicable bank or provider process may differ by case.Ministry of Electronics and Information Technology
Digital Personal Data Protection Act, 2023 Primary statutory source for qualified review. This guide does not decide applicability or provide a legal interpretation.Ministry of Electronics and Information Technology
Digital Personal Data Protection Rules, 2025 Official Gazette notification with phased commencement. Verify later notifications and obtain qualified advice where required.