Guides & Resources

How to Reconcile School Fee Collections with Razorpay, Paytm, Easebuzz, PayU, BillDesk and Bank

21 August 2026

If your school collects fees online through multiple payment gateways, confirming that a parent successfully made a payment is only the first part of the finance process.

The complete money flow may look like:

Student / Parent → School Fee Collection System → Payment Gateway → Bank

For a school using gateways such as:

Razorpay
Paytm
Easebuzz
PayU
BillDesk

the finance team needs to answer two separate reconciliation questions.

Reconciliation 1

Did every successful fee transaction recorded by the school agree with the corresponding payment-gateway transaction?

Reconciliation 2

Did the payment gateway subsequently settle the expected money into the school's bank account?

Together, these create a 3-way school fee collection reconciliation:

School Fee Collection Report ↔ Payment Gateway Reports ↔ Bank Statement

Cointab can automate this process across multiple payment gateways and help the finance team identify exactly where an unreconciled school fee transaction is stuck.

Why school fee reconciliation is more than payment matching

A school fee transaction carries considerably more information than a simple ₹ amount.

A payment may relate to a particular:

Student
Enrollment
School or campus
Grade
Academic activity
Fee type
Fee category
Service period
Receipt
Invoice
Order
Payment gateway
Refund

The finance team therefore needs to preserve the connection between:

Who paid → What they paid for → Which gateway collected it → Whether the money reached the bank

If these layers are reconciled separately in spreadsheets, it becomes easy to lose that connection.

A typical school fee collection report

The school's internal fee collection report may contain information such as:

Information	Example purpose
Legal Entity	School/entity receiving the fee
Enrollment Date	Date associated with the enrollment
Student / Participant	Person for whom the fee was collected
Enrollment ID	Unique enrollment reference
School / Campus	Relevant school
Grade	Student grade
Venue	Relevant location
Fee Description	Activity or fee title
Service Period	Period to which the fee belongs
Fee Type	Tuition, activity, event or other fee
Fee Category	Additional classification
Gross Fee	Original fee amount
Discount	Discount granted
Gateway Charges	Payment processing charges where recorded
Net Fee	Fee after relevant adjustments
Transaction Amount	Amount paid
Payment Type	Transaction classification
Payment Medium	Online payment channel
Transaction Status	Success, failed, pending, etc.
Transaction ID	Payment transaction identifier
Gateway Order ID	Order reference passed to the gateway
Receipt No.	School receipt reference
Invoice No.	School invoice reference
Order ID	Internal order reference
Refund Status	Whether the payment has been refunded
Refund Transaction ID	Refund reference
Refund Date	Date of refund

The actual school report may contain additional educational and operational information.

For reconciliation, the most important fields are generally:

Transaction ID
Gateway Order ID
Internal Order ID
Receipt / Invoice
Transaction Amount
Transaction Status
Payment Gateway
Refund ID
Student / Enrollment reference

Why the student or enrollment reference should remain attached

Suppose the finance team discovers an unmatched payment of:

₹18,500

Knowing only the amount and gateway transaction ID is not enough.

The school may need to determine:

Which student made the payment?
Which enrollment does it belong to?
Which fee category was being paid?
Was a receipt issued?
Was the student's account updated?
Does the parent need to be contacted?

The reconciliation output should therefore retain the underlying student or enrollment context even when the actual financial matching is primarily based on transaction and order IDs.

The first reconciliation: school fee system vs payment gateway

The first stage compares:

School Fee Collection Report ↔ Payment Gateway Transaction Report

The objective is to establish whether the school's recorded payment agrees with what the payment gateway actually processed.

For example:

School fee system

Transaction ID:

TXN-784521

Order ID:

ORD-56218

Amount:

₹24,000

Status:

Successful

Payment gateway

Order ID:

ORD-56218

Amount:

₹24,000

Status:

Captured

The transaction exists on both sides for the expected amount.

It can be treated as:

Fully Matched

School transaction exists but payment gateway transaction is missing

Suppose the school system says:

Student: Student A
Order: ORD-74218
Amount: ₹32,500
Status: Successful

but no corresponding transaction can be identified in the relevant gateway report.

Cointab can report:

Present in School System but not found in Payment Gateway

The finance team can investigate:

Was the transaction actually processed?
Is the gateway transaction in another report period?
Was the wrong payment gateway recorded?
Is the order ID incorrect?
Did the school's system mark the transaction successful incorrectly?

This is an important exception because the student's fee account and the external payment processor may disagree.

Payment gateway transaction exists but school system does not

The reverse situation can also occur.

For example:

Payment gateway

Payment ID:

pay_984521

Order ID:

ORD-65821

Amount:

₹18,000

Status:

Successful

School system

No corresponding successful transaction.

Cointab can report:

Present in Payment Gateway but not found in School System

The school can investigate whether:

Student payment succeeded but the school system did not update
Callback or API processing failed
Receipt was not generated
Payment was recorded against another student/order
Transaction is still pending internally

This can be particularly important because a parent may have successfully paid even though the school's system still shows fees outstanding.

Same transaction, different amount

Suppose the same order is available on both sides.

School fee report

Order ID:

ORD-84215

Amount:

₹25,000

Gateway

Order ID:

ORD-84215

Amount:

₹24,500

The order reference connects the transactions, but the amount differs.

Cointab can report:

Partially Matched

The finance team can then investigate the ₹500 difference.

Multiple payment gateways make school reconciliation harder

Many schools do not rely on one online payment provider.

Different transactions may be collected through:

Razorpay
Paytm
Easebuzz
PayU
BillDesk

Each gateway produces a different report structure.

The school therefore faces a normalization problem before the reconciliation even begins.

For example, the equivalent transaction identifier may be called:

payment_id
transaction_id
txnid
payu_id
PGI Ref. No.

The settlement identifier may similarly be represented differently by each provider.

A manual Excel process therefore often requires a separate reconciliation workbook or formula set for each gateway.

Reconciling school fees with Razorpay

A Razorpay settlement report can contain fields such as:

Useful Razorpay reconciliation fields can include:

payment_id
order_id
amount
fee
tax
created_at
settlement_id
settlement_utr
settled_at

For the first reconciliation, the school's:

Gateway Order ID / Transaction ID

can be compared with Razorpay:

order_id / payment_id

along with the amount.

Example: school collection vs Razorpay

School system

Gateway:

Razorpay

Gateway Order ID:

order_784521

Transaction Amount:

₹20,000

Razorpay

order_id:

order_784521

amount:

₹20,000

payment_id:

pay_985214

The fee transaction agrees.

Cointab can classify it as:

Fully Matched

The next question becomes whether that Razorpay transaction was subsequently included in a settlement received by the school's bank.

Razorpay fee and tax information

Razorpay also provides:

This can help explain why:

Gross student collections ≠ Bank settlement

For example:

Student payment

₹20,000

Gateway fee + tax

₹400

Settlement contribution

₹19,600

A bank reconciliation should therefore not necessarily expect each gateway settlement to equal the gross value of all student payments.

The gateway's settlement economics need to be considered.

Reconciling school fees with Paytm

A Paytm report can contain fields such as:

transaction_id
order_id
transaction_date
status
amount
commission
gst
payout_id
utr_no
payout_date
settled_date
payment_mode
settled_amount
bank_transaction_id
reference_transaction_id
merchant_ref_id

and many additional gateway and settlement attributes.

For reconciliation, the most useful fields may include:

transaction_id → order_id → amount → status → payout_id → UTR → settled_amount

Example: school fee vs Paytm transaction

School system

Gateway Order ID:

ORD-56241

Amount:

₹35,000

Paytm

order_id:

ORD-56241

transaction_id:

PTM-98452

amount:

₹35,000

status:

Successful

The transaction is fully matched.

The Paytm:

payout_id
utr_no
settled_amount

can then be used for the bank-settlement stage.

Paytm commission and GST can explain settlement differences

Paytm can separately report:

amount
commission
GST
settled_amount

The finance team can therefore understand the bridge between:

Gross fee collected

and:

Net money settled

Rather than treating the difference as an unreconciled amount, Cointab can preserve these fields for settlement analysis.

Reconciling school fees with Easebuzz

An Easebuzz report can contain fields such as:

amount
payout_actual_date
peb_transaction_id
txnid
paid_out
payout_id
payout_amount
bank_name
service_charge_amount
bank_transaction_id
total_amount
service_tax_amount
refund_amount
peb_settlement_amount
transaction_type
realised_payment_date
status
udf1 to udf5

Useful identifiers can therefore include:

txnid
peb_transaction_id
bank_transaction_id
payout_id

alongside transaction and settlement amounts.

Easebuzz transaction vs settlement reconciliation

The same Easebuzz file can provide information relating to both stages.

Transaction identification

Use fields such as:

txnid
peb_transaction_id
amount
status

Settlement identification

Use fields such as:

payout_id
payout_amount
bank_transaction_id
payout_actual_date
peb_settlement_amount

This allows the school to follow a fee payment from the internal collection record through to the eventual payout.

Reconciling school fees with PayU

A PayU report can contain fields including:

amount
date
net_amount
merchant_utr
settlement_utr
merchant_id
date_of_transaction
payu_id
customer_name
status
bank_name
transaction_id
payment_gateway
bank_reference_no
payment_type
service_fee
service_tax
settlement_date

Useful fields for school fee reconciliation can include:

transaction_id / payu_id → amount → status

and for settlements:

settlement_utr / merchant_utr → net_amount → settlement_date

Example: PayU fee collection to settlement

Suppose the school fee system records:

Order: ORD-86214

Amount: ₹28,000

PayU records the corresponding transaction for:

₹28,000

and later reports:

Net Amount: ₹27,450

Settlement UTR: UTR98521463

The first reconciliation confirms the student's payment.

The second reconciliation determines whether the:

₹27,450

settlement reached the bank under:

UTR98521463

Reconciling school fees with BillDesk

A BillDesk settlement report can contain:

This structure is particularly useful for reconciliation because it contains:

Gateway reference
Bank reference
Settlement UTR
Gross amount
Charges
GST
Net amount

The Ref. 1 through Ref. 8 fields can also contain merchant-defined information that may help connect a transaction back to the school's student, invoice, receipt or order references.

BillDesk reference fields can help connect payments to students

Suppose the school passes:

Enrollment-78421

to BillDesk as one of the reference values.

The resulting BillDesk report may contain it in:

Ref. 2

or another configured reference field.

The finance team can then retain a direct connection between:

Student / Enrollment → BillDesk transaction → Settlement

This is useful where the gateway's primary PGI reference is not meaningful to school users.

The second reconciliation: payment gateway vs bank

Matching a student's fee payment with a gateway transaction does not prove that the school received the money.

The second reconciliation is therefore:

Payment Gateway Settlement ↔ Bank Statement

The objective is to verify that the gateway transferred the expected settlement into the school's bank account.

A typical bank statement format

The bank file may contain fields such as:

Bank Field	Purpose
Value Date	Bank value date
Net Amount	Transaction value
Transaction Details	Bank narration
Debit	Debit amount
Credit	Credit amount
Transaction Date & Time	Booking timestamp
Reference / Cheque No.	Bank reference
Balance	Running account balance

For gateway settlement reconciliation, useful bank fields can include:

Credit
Value Date
Transaction Details
Reference No.

Payment-gateway settlements are usually not one payment = one bank credit

This is one of the most important differences between the first and second reconciliation.

At the payment stage:

One school fee transaction ↔ One gateway transaction

may often be possible.

At the settlement stage:

Many student payments → One payment-gateway settlement → One bank credit

is common.

For example:

Razorpay transactions

Student A: ₹20,000
Student B: ₹25,000
Student C: ₹15,000
Student D: ₹30,000

Gross:

₹90,000

Less gateway charges and taxes:

₹1,800

Net settlement:

₹88,200

The bank may contain one credit:

₹88,200

The bank transaction should therefore be reconciled against the gateway settlement, not individually against each student's payment.

Settlement ID and UTR bridge the gateway to the bank

Most payment gateways provide a settlement or payout identifier.

Examples include:

Razorpay

settlement_id
settlement_utr

Paytm

payout_id
utr_no

Easebuzz

payout_id
bank_transaction_id

PayU

settlement_utr
merchant_utr

BillDesk

UTR
Bank Ref. No.

These references can often be matched against:

Bank reference number
Bank narration
Transaction details

This creates the second leg of the 3-way reconciliation.

Example: Razorpay settlement vs bank

Razorpay

Settlement ID:

setl_785214

Settlement UTR:

HDFC985214763

Net settlement:

₹4,85,000

Bank

Reference:

HDFC985214763

Credit:

₹4,85,000

The settlement exists in both systems for the same amount.

Cointab can classify it as:

Fully Matched

Gateway says settled but bank credit is missing

Suppose a gateway reports:

Settlement UTR: UTR78452169

Settlement Amount: ₹6,25,000

Status: Settled

but no corresponding credit can be identified in the bank statement.

This becomes:

Present in Payment Gateway but not in Bank

The finance team can investigate:

Settlement date timing
Correct bank account
Bank file period
Incorrect UTR
Failed/delayed settlement

This is a materially different issue from a student's payment not appearing in the gateway.

Bank credit exists but gateway settlement is not identified

The opposite can also happen.

The bank may show:

Credit: ₹3,85,000

Reference: UTR45218963

but the finance team cannot immediately identify the corresponding gateway settlement.

This can happen because:

Settlement belongs to another gateway
Bank narration is abbreviated
Gateway settlement report belongs to another date
Several merchant accounts are involved
Reference formatting differs

Cointab can keep such bank-side exceptions separate for investigation.

The complete 3-way school fee reconciliation

The complete reconciliation can be viewed as two linked checks.

Check A: School vs payment gateway

Did the student's online payment reach the gateway correctly?

Check B: Payment gateway vs bank

Did the gateway subsequently settle the money to the school?

This allows each fee collection to progress conceptually through:

Recorded by School → Confirmed by Gateway → Settled to Bank

A useful status model for school fee collections

Once the three datasets are connected, fee collections can be understood much more clearly.

School	Gateway	Bank	Meaning
✓	✓	✓	Complete collection flow
✓	✕	—	School recorded payment but gateway transaction missing
✕	✓	—	Gateway received payment but school system missing it
✓	✓	✕	Payment confirmed but settlement not found in bank
✓	Amount differs	—	Transaction needs amount investigation
✓	Refunded	Settlement/Bank review	Refund flow requires reconciliation

This is more useful than maintaining independent Excel sheets for each system.

Example: complete school fee collection

School system

Student:

Student A

Enrollment:

ENR-78421

Order:

ORD-56218

Amount:

₹24,000

Status:

Successful

Razorpay

order_id:

ORD-56218

payment_id:

pay_874521

amount:

₹24,000

Settlement:

SET-98521

Bank

Settlement UTR:

UTR98521463

Credit received as part of the corresponding gateway settlement.

The payment has completed the full chain:

School ✓ → Gateway ✓ → Bank ✓

Example: parent paid but school account did not update

Paytm

Transaction ID:

PTM-785214

Order ID:

ORD-62518

Amount:

₹30,000

Status:

Successful

School fee system

No corresponding successful collection.

This is a high-priority operational exception.

The parent may have paid successfully while the student's account still shows the fee as outstanding.

The finance or student-services team can investigate the exact order rather than asking the parent to pay again.

Example: school shows payment but gateway does not

School

Order:

ORD-84521

Amount:

₹18,500

Status:

Successful

Gateway

No corresponding transaction identified.

The school can investigate:

Whether success status was set prematurely
Whether another gateway handled the order
Whether reference formatting is wrong
Whether transaction data arrived in another file

Example: gateway payment is successful but settlement has not reached bank

PayU

Transaction:

Successfully processed

Associated settlement:

₹5,75,000

Settlement UTR:

UTR87452136

Bank

No matching credit.

The student payment itself is not the issue.

The exception is specifically:

Gateway → Bank

This allows the finance team to follow up with the correct party.

Gateway charges should not be mistaken for missing collections

Suppose the school collected:

₹10,00,000

during a period.

The gateway deducts:

Processing fees: ₹15,000
GST: ₹2,700

Net settlement:

₹9,82,300

The bank receives:

₹9,82,300

The reconciliation is correct.

A simple:

Student collections total vs bank credits total

comparison would incorrectly produce:

₹17,700

as an unexplained difference.

The gateway report explains the bridge.

Reconcile gateway fees and taxes where required

Different gateways expose fee information differently.

For example:

Razorpay

Paytm

commission
gst

Easebuzz

service_charge_amount
service_tax_amount

PayU

service_fee
service_tax

BillDesk

Charges
GST

These fields can be retained and validated as part of the settlement working.

This lets finance teams explain:

Gross Collections - Gateway Charges - Taxes ± Adjustments = Net Settlement

Refund reconciliation is essential for school fee collections

School fee transactions can also be refunded.

For example:

Enrollment cancelled
Event cancelled
Duplicate payment
Excess payment
Student withdrawal
Incorrect payment

The school report may contain information such as:

Refund Status
Refund Type
Refund Transaction ID
Refund Date

The payment gateway may separately report:

Refund transactions
Original transaction references
Refund amount
Settlement adjustment

These should be reconciled separately from successful fee collections.

Why refund reconciliation matters

Suppose the school records:

Original Fee: ₹25,000

Refund: ₹25,000

but the gateway has not processed the corresponding refund.

The parent-facing school account and the external money movement are now inconsistent.

The opposite can also occur:

The gateway may process a refund but the school's internal fee system may still show the collection as retained.

Both situations require investigation.

Refunds can affect future gateway settlements

A refund does not always result in a separate bank debit.

Depending on the gateway process, a refund may be adjusted against:

Future collections
Future settlement
Existing merchant balance

This means the settlement reconciliation may include:

Gross successful transactions - Fees - Refund adjustments = Net settlement

Cointab can retain refund and settlement data so finance teams can understand such differences rather than treating them as unexplained bank mismatches.

Multiple legal entities create another reconciliation dimension

A school group may operate more than one legal entity.

The same payment-gateway environment may therefore collect fees belonging to different:

Schools
Entities
Campuses
Programs

The internal collection report's legal-entity information should remain available during reconciliation.

This helps ensure that a transaction is ultimately attributed to the correct entity even where payment processing is centralized.

School and grade data can remain available without driving the financial match

Fields such as:

School
Grade
Venue
Fee category

may not be needed to identify the gateway transaction.

However, they become valuable once an exception is found.

For example, the finance team may discover that several unreconciled payments belong to:

One campus
One grade
One fee category

This can reveal an operational problem in the underlying collection process.

Reconcile receipts and invoices as supporting controls

The school system may also generate:

Receipt No.
Invoice No.

These fields can remain attached to each reconciled transaction.

This helps ensure that:

Successful gateway payment → Student fee record → Receipt / invoice

remains traceable.

If the gateway transaction exists but no receipt was generated, the reconciliation can support further investigation.

Different gateway status terminology needs to be normalized conceptually

Each gateway may use different terminology for transaction state.

One provider may say:

captured

another:

success

another:

settled

and another may expose multiple processing states.

For reconciliation, the finance team ultimately needs common business questions:

Was the payment successful?
Was it refunded?
Was it settled?
Was it disputed or reversed?

Cointab can reconcile based on the configured source data without requiring every gateway file to have identical column names.

Do not match only on amount

School fees can use standard fee amounts.

For example, hundreds of students may each pay:

₹25,000

Matching transactions only on amount would create serious false-match risk.

A reliable reconciliation should consider useful references such as:

Gateway Order ID
Transaction ID
Internal Order ID
Payment ID
Receipt
Invoice
Merchant reference

along with amount and date.

One order ID can be more useful than the student name

Names can contain:

Spelling differences
Parent names
Student names
Abbreviations

A unique gateway or order reference is generally much more reliable for financial matching.

Student information should remain available for explanation and follow-up, while system-generated transaction identifiers drive the reconciliation wherever possible.

Timing differences are normal

A fee may be paid late at night on:

31 March

The gateway may process it immediately.

The settlement may happen on:

2 April

and the bank may credit it on:

2 or 3 April.

These are different stages of the same transaction lifecycle.

The reconciliation should therefore distinguish:

Payment Date

from:

Settlement Date

from:

Bank Value Date

rather than expecting all three dates to be identical.

Weekend and holiday settlements can create legitimate delays

If a parent pays on a weekend, the gateway may not settle the transaction until the next applicable settlement cycle.

The school-vs-gateway reconciliation can still show:

Fully Matched

while the gateway-vs-bank leg remains temporarily open.

When the settlement arrives later, the bank reconciliation can complete.

This prevents legitimate timing differences from being mistaken for errors.

Reconcile many student payments to one bank settlement

One of the main reasons the 3-way model is important is that the relationship changes between stages.

Stage 1

Usually:

Individual School Transaction ↔ Individual Gateway Transaction

Stage 2

Usually:

Many Gateway Transactions ↔ One Settlement ↔ One Bank Credit

For example:

500 school fee collections may ultimately form:

3 Razorpay settlements

and therefore:

3 bank credits

The system needs to preserve both the transaction-level and settlement-level views.

Different gateways can settle on different schedules

A school using five gateways may receive settlements at different times.

For example:

Razorpay settlement A
Paytm settlement B
Easebuzz settlement C
PayU settlement D
BillDesk settlement E

Each follows its own:

Settlement ID
UTR format
Fee structure
Settlement timing

The bank statement then contains credits from all of them.

A consolidated reconciliation helps the finance team understand which bank credit belongs to which payment gateway.

Example: one bank account receives multiple gateway settlements

Suppose the bank statement contains:

₹4,85,000
₹6,20,000
₹3,42,500
₹7,15,000
₹2,80,000

These may relate to different settlements from:

Razorpay
Paytm
Easebuzz
PayU
BillDesk

Without settlement UTRs, the finance team may need to manually inspect bank narrations.

With the gateway settlement reports, the corresponding:

UTR
Payout ID
Settlement ID
Net Amount

provide much stronger reconciliation references.

Manual Match for known payment or settlement relationships

Some transactions may still use inconsistent references.

For example:

Gateway

Settlement ID:

SET-78421

Amount:

₹5,42,000

Bank

Narration:

PG SETTLEMENT 21AUG

Reference:

HDFC985214

Credit:

₹5,42,000

If the finance team knows these represent the same settlement but no common reference can be identified automatically, Cointab provides:

Manual Match

The user can select the corresponding records and confirm the relationship.

This is useful for:

Abbreviated bank narrations
Legacy settlement formats
Older payment transactions
Missing reference numbers

A useful exception framework for school finance teams

The 3-way reconciliation can turn thousands of transactions into a few clear exception types.

School vs Gateway exceptions

School success but gateway missing
Gateway success but school missing
Amount difference
Status difference
Duplicate transaction
Refund difference

Gateway vs Bank exceptions

Gateway settlement missing from bank
Bank credit missing from gateway settlement data
Settlement amount difference
UTR mismatch
Settlement timing difference

Fee and adjustment exceptions

Gateway fee difference
GST difference
Refund adjustment
Other settlement deduction

This makes exception ownership much clearer.

Know which team or party needs to investigate

The reconciliation can also help route each exception.

School system / technology team

Examples:

Gateway transaction succeeded but school fee account did not update
Receipt not generated
Wrong gateway order recorded

Finance team

Examples:

Settlement amount difference
Bank credit unidentified
Gateway fee discrepancy
Refund accounting difference

Payment gateway

Examples:

Settlement marked completed but not received
Incorrect settlement amount
Missing transaction
Unexpected gateway charge

The output becomes an operational workflow rather than just a spreadsheet.

Download the complete school fee reconciliation in Excel

Once the reconciliation is complete, Cointab can provide the entire working in Excel.

The output can preserve useful school-side context such as:

Student / Participant
Enrollment reference
School
Grade
Fee type
Transaction ID
Order ID
Receipt
Invoice
Amount
Refund status

alongside payment-gateway information such as:

Gateway transaction ID
Gateway order
Payment status
Fee
Tax
Settlement ID
UTR

and bank information such as:

Bank reference
Value date
Credit amount
Transaction narration

This provides a complete audit trail from student payment to bank receipt.

Use the reconciliation for parent payment queries

A parent may contact the school saying:

"I have paid, but the portal still shows the fee as outstanding."

Instead of searching several systems manually, the finance team can trace:

Enrollment → Order ID → Gateway Transaction → Payment Status

If the gateway shows payment success but the school report does not, the issue can immediately be routed to the relevant internal team.

This can significantly improve the handling of payment-related student or parent queries.

Use the reconciliation for month-end fee collection control

At month end, the finance team may need to confirm:

Total online fees recorded
Total successful gateway collections
Total refunds
Gateway charges
Settlement amounts
Amount received in bank
Transactions still unreconciled

A 3-way reconciliation provides the transaction-level evidence supporting these totals.

Instead of relying only on aggregate numbers, finance teams can drill into the remaining exceptions.

Reconciliation is different from merely checking bank receipts

A bank credit proves that the school received money.

It does not prove:

Which students paid
Which gateway transactions formed the settlement
Whether every successful payment reached the school system
Whether refunds were handled correctly

Similarly, a successful gateway transaction does not prove that settlement reached the bank.

This is why the complete chain matters:

School System ↔ Gateway ↔ Bank

How Cointab helps automate school fee reconciliation

Cointab can help schools reconcile online fee collections by allowing finance teams to:

Upload the school fee collection report
Retain student and enrollment context
Reconcile multiple payment gateways
Work with Razorpay reports
Work with Paytm reports
Work with Easebuzz reports
Work with PayU reports
Work with BillDesk reports
Match transaction and order references
Compare transaction amounts
Identify successful gateway transactions missing from the school system
Identify school transactions missing from gateways
Reconcile refunds
Review gateway charges and taxes
Group transactions into settlements
Match settlement IDs and UTRs
Reconcile payment-gateway settlements with bank credits
Identify settlement amounts missing from the bank
Identify unidentified bank credits
Manually match transactions where references differ
Download the complete reconciliation working in Excel
Upload updated data and rerun reconciliation

Automate 3-way school fee collection reconciliation

If your school collects fees through Razorpay, Paytm, Easebuzz, PayU, BillDesk or multiple payment gateways, manually reconciling each gateway in separate Excel files can become difficult as transaction volumes increase.

Cointab can create a structured three-way reconciliation:

School Fee Collection Report

↓

Razorpay / Paytm / Easebuzz / PayU / BillDesk

↓

Bank Statement

The finance team can determine:

Whether every successful student fee payment reached the payment gateway
Whether every gateway collection is represented in the school's system
Whether payment amounts agree
Whether refunds agree
How gateway charges affect settlement
Which transactions belong to each settlement
Whether each payment-gateway settlement reached the bank
Which student payments or settlements remain unresolved

The result is an end-to-end financial control over online school fee collections — from the student's payment through to the final bank receipt.

If your school currently reconciles online fee collections and multiple payment gateways manually in Excel, you can use Cointab to automate the entire process.

Try Cointab

For schools with multiple campuses, legal entities, high transaction volumes, multiple payment gateways or customized fee collection systems:

Book a Demo

Guides & Resources

How to Reconcile School Fee Collections with Razorpay, Paytm, Easebuzz, PayU, BillDesk and Bank

21 August 2026

If your school collects fees online through multiple payment gateways, confirming that a parent successfully made a payment is only the first part of the finance process.

The complete money flow may look like:

Student / Parent → School Fee Collection System → Payment Gateway → Bank

For a school using gateways such as:

Razorpay
Paytm
Easebuzz
PayU
BillDesk

the finance team needs to answer two separate reconciliation questions.

Reconciliation 1

Did every successful fee transaction recorded by the school agree with the corresponding payment-gateway transaction?

Reconciliation 2

Did the payment gateway subsequently settle the expected money into the school's bank account?

Together, these create a 3-way school fee collection reconciliation:

School Fee Collection Report ↔ Payment Gateway Reports ↔ Bank Statement

Cointab can automate this process across multiple payment gateways and help the finance team identify exactly where an unreconciled school fee transaction is stuck.

Why school fee reconciliation is more than payment matching

A school fee transaction carries considerably more information than a simple ₹ amount.

A payment may relate to a particular:

Student
Enrollment
School or campus
Grade
Academic activity
Fee type
Fee category
Service period
Receipt
Invoice
Order
Payment gateway
Refund

The finance team therefore needs to preserve the connection between:

Who paid → What they paid for → Which gateway collected it → Whether the money reached the bank

If these layers are reconciled separately in spreadsheets, it becomes easy to lose that connection.

A typical school fee collection report

The school's internal fee collection report may contain information such as:

Information	Example purpose
Legal Entity	School/entity receiving the fee
Enrollment Date	Date associated with the enrollment
Student / Participant	Person for whom the fee was collected
Enrollment ID	Unique enrollment reference
School / Campus	Relevant school
Grade	Student grade
Venue	Relevant location
Fee Description	Activity or fee title
Service Period	Period to which the fee belongs
Fee Type	Tuition, activity, event or other fee
Fee Category	Additional classification
Gross Fee	Original fee amount
Discount	Discount granted
Gateway Charges	Payment processing charges where recorded
Net Fee	Fee after relevant adjustments
Transaction Amount	Amount paid
Payment Type	Transaction classification
Payment Medium	Online payment channel
Transaction Status	Success, failed, pending, etc.
Transaction ID	Payment transaction identifier
Gateway Order ID	Order reference passed to the gateway
Receipt No.	School receipt reference
Invoice No.	School invoice reference
Order ID	Internal order reference
Refund Status	Whether the payment has been refunded
Refund Transaction ID	Refund reference
Refund Date	Date of refund

The actual school report may contain additional educational and operational information.

For reconciliation, the most important fields are generally:

Transaction ID
Gateway Order ID
Internal Order ID
Receipt / Invoice
Transaction Amount
Transaction Status
Payment Gateway
Refund ID
Student / Enrollment reference

Why the student or enrollment reference should remain attached

Suppose the finance team discovers an unmatched payment of:

₹18,500

Knowing only the amount and gateway transaction ID is not enough.

The school may need to determine:

Which student made the payment?
Which enrollment does it belong to?
Which fee category was being paid?
Was a receipt issued?
Was the student's account updated?
Does the parent need to be contacted?

The reconciliation output should therefore retain the underlying student or enrollment context even when the actual financial matching is primarily based on transaction and order IDs.

The first reconciliation: school fee system vs payment gateway

The first stage compares:

School Fee Collection Report ↔ Payment Gateway Transaction Report

The objective is to establish whether the school's recorded payment agrees with what the payment gateway actually processed.

For example:

School fee system

Transaction ID:

TXN-784521

Order ID:

ORD-56218

Amount:

₹24,000

Status:

Successful

Payment gateway

Order ID:

ORD-56218

Amount:

₹24,000

Status:

Captured

The transaction exists on both sides for the expected amount.

It can be treated as:

Fully Matched

School transaction exists but payment gateway transaction is missing

Suppose the school system says:

Student: Student A
Order: ORD-74218
Amount: ₹32,500
Status: Successful

but no corresponding transaction can be identified in the relevant gateway report.

Cointab can report:

Present in School System but not found in Payment Gateway

The finance team can investigate:

Was the transaction actually processed?
Is the gateway transaction in another report period?
Was the wrong payment gateway recorded?
Is the order ID incorrect?
Did the school's system mark the transaction successful incorrectly?

This is an important exception because the student's fee account and the external payment processor may disagree.

Payment gateway transaction exists but school system does not

The reverse situation can also occur.

For example:

Payment gateway

Payment ID:

pay_984521

Order ID:

ORD-65821

Amount:

₹18,000

Status:

Successful

School system

No corresponding successful transaction.

Cointab can report:

Present in Payment Gateway but not found in School System

The school can investigate whether:

Student payment succeeded but the school system did not update
Callback or API processing failed
Receipt was not generated
Payment was recorded against another student/order
Transaction is still pending internally

This can be particularly important because a parent may have successfully paid even though the school's system still shows fees outstanding.

Same transaction, different amount

Suppose the same order is available on both sides.

School fee report

Order ID:

ORD-84215

Amount:

₹25,000

Gateway

Order ID:

ORD-84215

Amount:

₹24,500

The order reference connects the transactions, but the amount differs.

Cointab can report:

Partially Matched

The finance team can then investigate the ₹500 difference.

Multiple payment gateways make school reconciliation harder

Many schools do not rely on one online payment provider.

Different transactions may be collected through:

Razorpay
Paytm
Easebuzz
PayU
BillDesk

Each gateway produces a different report structure.

The school therefore faces a normalization problem before the reconciliation even begins.

For example, the equivalent transaction identifier may be called:

payment_id
transaction_id
txnid
payu_id
PGI Ref. No.

The settlement identifier may similarly be represented differently by each provider.

A manual Excel process therefore often requires a separate reconciliation workbook or formula set for each gateway.

Reconciling school fees with Razorpay

A Razorpay settlement report can contain fields such as:

Useful Razorpay reconciliation fields can include:

payment_id
order_id
amount
fee
tax
created_at
settlement_id
settlement_utr
settled_at

For the first reconciliation, the school's:

Gateway Order ID / Transaction ID

can be compared with Razorpay:

order_id / payment_id

along with the amount.

Example: school collection vs Razorpay

School system

Gateway:

Razorpay

Gateway Order ID:

order_784521

Transaction Amount:

₹20,000

Razorpay

order_id:

order_784521

amount:

₹20,000

payment_id:

pay_985214

The fee transaction agrees.

Cointab can classify it as:

Fully Matched

The next question becomes whether that Razorpay transaction was subsequently included in a settlement received by the school's bank.

Razorpay fee and tax information

Razorpay also provides:

This can help explain why:

Gross student collections ≠ Bank settlement

For example:

Student payment

₹20,000

Gateway fee + tax

₹400

Settlement contribution

₹19,600

A bank reconciliation should therefore not necessarily expect each gateway settlement to equal the gross value of all student payments.

The gateway's settlement economics need to be considered.

Reconciling school fees with Paytm

A Paytm report can contain fields such as:

transaction_id
order_id
transaction_date
status
amount
commission
gst
payout_id
utr_no
payout_date
settled_date
payment_mode
settled_amount
bank_transaction_id
reference_transaction_id
merchant_ref_id

and many additional gateway and settlement attributes.

For reconciliation, the most useful fields may include:

transaction_id → order_id → amount → status → payout_id → UTR → settled_amount

Example: school fee vs Paytm transaction

School system

Gateway Order ID:

ORD-56241

Amount:

₹35,000

Paytm

order_id:

ORD-56241

transaction_id:

PTM-98452

amount:

₹35,000

status:

Successful

The transaction is fully matched.

The Paytm:

payout_id
utr_no
settled_amount

can then be used for the bank-settlement stage.

Paytm commission and GST can explain settlement differences

Paytm can separately report:

amount
commission
GST
settled_amount

The finance team can therefore understand the bridge between:

Gross fee collected

and:

Net money settled

Rather than treating the difference as an unreconciled amount, Cointab can preserve these fields for settlement analysis.

Reconciling school fees with Easebuzz

An Easebuzz report can contain fields such as:

amount
payout_actual_date
peb_transaction_id
txnid
paid_out
payout_id
payout_amount
bank_name
service_charge_amount
bank_transaction_id
total_amount
service_tax_amount
refund_amount
peb_settlement_amount
transaction_type
realised_payment_date
status
udf1 to udf5

Useful identifiers can therefore include:

txnid
peb_transaction_id
bank_transaction_id
payout_id

alongside transaction and settlement amounts.

Easebuzz transaction vs settlement reconciliation

The same Easebuzz file can provide information relating to both stages.

Transaction identification

Use fields such as:

txnid
peb_transaction_id
amount
status

Settlement identification

Use fields such as:

payout_id
payout_amount
bank_transaction_id
payout_actual_date
peb_settlement_amount

This allows the school to follow a fee payment from the internal collection record through to the eventual payout.

Reconciling school fees with PayU

A PayU report can contain fields including:

amount
date
net_amount
merchant_utr
settlement_utr
merchant_id
date_of_transaction
payu_id
customer_name
status
bank_name
transaction_id
payment_gateway
bank_reference_no
payment_type
service_fee
service_tax
settlement_date

Useful fields for school fee reconciliation can include:

transaction_id / payu_id → amount → status

and for settlements:

settlement_utr / merchant_utr → net_amount → settlement_date

Example: PayU fee collection to settlement

Suppose the school fee system records:

Order: ORD-86214

Amount: ₹28,000

PayU records the corresponding transaction for:

₹28,000

and later reports:

Net Amount: ₹27,450

Settlement UTR: UTR98521463

The first reconciliation confirms the student's payment.

The second reconciliation determines whether the:

₹27,450

settlement reached the bank under:

UTR98521463

Reconciling school fees with BillDesk

A BillDesk settlement report can contain:

This structure is particularly useful for reconciliation because it contains:

Gateway reference
Bank reference
Settlement UTR
Gross amount
Charges
GST
Net amount

The Ref. 1 through Ref. 8 fields can also contain merchant-defined information that may help connect a transaction back to the school's student, invoice, receipt or order references.

BillDesk reference fields can help connect payments to students

Suppose the school passes:

Enrollment-78421

to BillDesk as one of the reference values.

The resulting BillDesk report may contain it in:

Ref. 2

or another configured reference field.

The finance team can then retain a direct connection between:

Student / Enrollment → BillDesk transaction → Settlement

This is useful where the gateway's primary PGI reference is not meaningful to school users.

The second reconciliation: payment gateway vs bank

Matching a student's fee payment with a gateway transaction does not prove that the school received the money.

The second reconciliation is therefore:

Payment Gateway Settlement ↔ Bank Statement

The objective is to verify that the gateway transferred the expected settlement into the school's bank account.

A typical bank statement format

The bank file may contain fields such as:

Bank Field	Purpose
Value Date	Bank value date
Net Amount	Transaction value
Transaction Details	Bank narration
Debit	Debit amount
Credit	Credit amount
Transaction Date & Time	Booking timestamp
Reference / Cheque No.	Bank reference
Balance	Running account balance

For gateway settlement reconciliation, useful bank fields can include:

Credit
Value Date
Transaction Details
Reference No.

Payment-gateway settlements are usually not one payment = one bank credit

This is one of the most important differences between the first and second reconciliation.

At the payment stage:

One school fee transaction ↔ One gateway transaction

may often be possible.

At the settlement stage:

Many student payments → One payment-gateway settlement → One bank credit

is common.

For example:

Razorpay transactions

Student A: ₹20,000
Student B: ₹25,000
Student C: ₹15,000
Student D: ₹30,000

Gross:

₹90,000

Less gateway charges and taxes:

₹1,800

Net settlement:

₹88,200

The bank may contain one credit:

₹88,200

The bank transaction should therefore be reconciled against the gateway settlement, not individually against each student's payment.

Settlement ID and UTR bridge the gateway to the bank

Most payment gateways provide a settlement or payout identifier.

Examples include:

Razorpay

settlement_id
settlement_utr

Paytm

payout_id
utr_no

Easebuzz

payout_id
bank_transaction_id

PayU

settlement_utr
merchant_utr

BillDesk

UTR
Bank Ref. No.

These references can often be matched against:

Bank reference number
Bank narration
Transaction details

This creates the second leg of the 3-way reconciliation.

Example: Razorpay settlement vs bank

Razorpay

Settlement ID:

setl_785214

Settlement UTR:

HDFC985214763

Net settlement:

₹4,85,000

Bank

Reference:

HDFC985214763

Credit:

₹4,85,000

The settlement exists in both systems for the same amount.

Cointab can classify it as:

Fully Matched

Gateway says settled but bank credit is missing

Suppose a gateway reports:

Settlement UTR: UTR78452169

Settlement Amount: ₹6,25,000

Status: Settled

but no corresponding credit can be identified in the bank statement.

This becomes:

Present in Payment Gateway but not in Bank

The finance team can investigate:

Settlement date timing
Correct bank account
Bank file period
Incorrect UTR
Failed/delayed settlement

This is a materially different issue from a student's payment not appearing in the gateway.

Bank credit exists but gateway settlement is not identified

The opposite can also happen.

The bank may show:

Credit: ₹3,85,000

Reference: UTR45218963

but the finance team cannot immediately identify the corresponding gateway settlement.

This can happen because:

Settlement belongs to another gateway
Bank narration is abbreviated
Gateway settlement report belongs to another date
Several merchant accounts are involved
Reference formatting differs

Cointab can keep such bank-side exceptions separate for investigation.

The complete 3-way school fee reconciliation

The complete reconciliation can be viewed as two linked checks.

Check A: School vs payment gateway

Did the student's online payment reach the gateway correctly?

Check B: Payment gateway vs bank

Did the gateway subsequently settle the money to the school?

This allows each fee collection to progress conceptually through:

Recorded by School → Confirmed by Gateway → Settled to Bank

A useful status model for school fee collections

Once the three datasets are connected, fee collections can be understood much more clearly.

School	Gateway	Bank	Meaning
✓	✓	✓	Complete collection flow
✓	✕	—	School recorded payment but gateway transaction missing
✕	✓	—	Gateway received payment but school system missing it
✓	✓	✕	Payment confirmed but settlement not found in bank
✓	Amount differs	—	Transaction needs amount investigation
✓	Refunded	Settlement/Bank review	Refund flow requires reconciliation

This is more useful than maintaining independent Excel sheets for each system.

Example: complete school fee collection

School system

Student:

Student A

Enrollment:

ENR-78421

Order:

ORD-56218

Amount:

₹24,000

Status:

Successful

Razorpay

order_id:

ORD-56218

payment_id:

pay_874521

amount:

₹24,000

Settlement:

SET-98521

Bank

Settlement UTR:

UTR98521463

Credit received as part of the corresponding gateway settlement.

The payment has completed the full chain:

School ✓ → Gateway ✓ → Bank ✓

Example: parent paid but school account did not update

Paytm

Transaction ID:

PTM-785214

Order ID:

ORD-62518

Amount:

₹30,000

Status:

Successful

School fee system

No corresponding successful collection.

This is a high-priority operational exception.

The parent may have paid successfully while the student's account still shows the fee as outstanding.

The finance or student-services team can investigate the exact order rather than asking the parent to pay again.

Example: school shows payment but gateway does not

School

Order:

ORD-84521

Amount:

₹18,500

Status:

Successful

Gateway

No corresponding transaction identified.

The school can investigate:

Whether success status was set prematurely
Whether another gateway handled the order
Whether reference formatting is wrong
Whether transaction data arrived in another file

Example: gateway payment is successful but settlement has not reached bank

PayU

Transaction:

Successfully processed

Associated settlement:

₹5,75,000

Settlement UTR:

UTR87452136

Bank

No matching credit.

The student payment itself is not the issue.

The exception is specifically:

Gateway → Bank

This allows the finance team to follow up with the correct party.

Gateway charges should not be mistaken for missing collections

Suppose the school collected:

₹10,00,000

during a period.

The gateway deducts:

Processing fees: ₹15,000
GST: ₹2,700

Net settlement:

₹9,82,300

The bank receives:

₹9,82,300

The reconciliation is correct.

A simple:

Student collections total vs bank credits total

comparison would incorrectly produce:

₹17,700

as an unexplained difference.

The gateway report explains the bridge.

Reconcile gateway fees and taxes where required

Different gateways expose fee information differently.

For example:

Razorpay

Paytm

commission
gst

Easebuzz

service_charge_amount
service_tax_amount

PayU

service_fee
service_tax

BillDesk

Charges
GST

These fields can be retained and validated as part of the settlement working.

This lets finance teams explain:

Gross Collections - Gateway Charges - Taxes ± Adjustments = Net Settlement

Refund reconciliation is essential for school fee collections

School fee transactions can also be refunded.

For example:

Enrollment cancelled
Event cancelled
Duplicate payment
Excess payment
Student withdrawal
Incorrect payment

The school report may contain information such as:

Refund Status
Refund Type
Refund Transaction ID
Refund Date

The payment gateway may separately report:

Refund transactions
Original transaction references
Refund amount
Settlement adjustment

These should be reconciled separately from successful fee collections.

Why refund reconciliation matters

Suppose the school records:

Original Fee: ₹25,000

Refund: ₹25,000

but the gateway has not processed the corresponding refund.

The parent-facing school account and the external money movement are now inconsistent.

The opposite can also occur:

The gateway may process a refund but the school's internal fee system may still show the collection as retained.

Both situations require investigation.

Refunds can affect future gateway settlements

A refund does not always result in a separate bank debit.

Depending on the gateway process, a refund may be adjusted against:

Future collections
Future settlement
Existing merchant balance

This means the settlement reconciliation may include:

Gross successful transactions - Fees - Refund adjustments = Net settlement

Cointab can retain refund and settlement data so finance teams can understand such differences rather than treating them as unexplained bank mismatches.

Multiple legal entities create another reconciliation dimension

A school group may operate more than one legal entity.

The same payment-gateway environment may therefore collect fees belonging to different:

Schools
Entities
Campuses
Programs

The internal collection report's legal-entity information should remain available during reconciliation.

This helps ensure that a transaction is ultimately attributed to the correct entity even where payment processing is centralized.

School and grade data can remain available without driving the financial match

Fields such as:

School
Grade
Venue
Fee category

may not be needed to identify the gateway transaction.

However, they become valuable once an exception is found.

For example, the finance team may discover that several unreconciled payments belong to:

One campus
One grade
One fee category

This can reveal an operational problem in the underlying collection process.

Reconcile receipts and invoices as supporting controls

The school system may also generate:

Receipt No.
Invoice No.

These fields can remain attached to each reconciled transaction.

This helps ensure that:

Successful gateway payment → Student fee record → Receipt / invoice

remains traceable.

If the gateway transaction exists but no receipt was generated, the reconciliation can support further investigation.

Different gateway status terminology needs to be normalized conceptually

Each gateway may use different terminology for transaction state.

One provider may say:

captured

another:

success

another:

settled

and another may expose multiple processing states.

For reconciliation, the finance team ultimately needs common business questions:

Was the payment successful?
Was it refunded?
Was it settled?
Was it disputed or reversed?

Cointab can reconcile based on the configured source data without requiring every gateway file to have identical column names.

Do not match only on amount

School fees can use standard fee amounts.

For example, hundreds of students may each pay:

₹25,000

Matching transactions only on amount would create serious false-match risk.

A reliable reconciliation should consider useful references such as:

Gateway Order ID
Transaction ID
Internal Order ID
Payment ID
Receipt
Invoice
Merchant reference

along with amount and date.

One order ID can be more useful than the student name

Names can contain:

Spelling differences
Parent names
Student names
Abbreviations

A unique gateway or order reference is generally much more reliable for financial matching.

Student information should remain available for explanation and follow-up, while system-generated transaction identifiers drive the reconciliation wherever possible.

Timing differences are normal

A fee may be paid late at night on:

31 March

The gateway may process it immediately.

The settlement may happen on:

2 April

and the bank may credit it on:

2 or 3 April.

These are different stages of the same transaction lifecycle.

The reconciliation should therefore distinguish:

Payment Date

from:

Settlement Date

from:

Bank Value Date

rather than expecting all three dates to be identical.

Weekend and holiday settlements can create legitimate delays

If a parent pays on a weekend, the gateway may not settle the transaction until the next applicable settlement cycle.

The school-vs-gateway reconciliation can still show:

Fully Matched

while the gateway-vs-bank leg remains temporarily open.

When the settlement arrives later, the bank reconciliation can complete.

This prevents legitimate timing differences from being mistaken for errors.

Reconcile many student payments to one bank settlement

One of the main reasons the 3-way model is important is that the relationship changes between stages.

Stage 1

Usually:

Individual School Transaction ↔ Individual Gateway Transaction

Stage 2

Usually:

Many Gateway Transactions ↔ One Settlement ↔ One Bank Credit

For example:

500 school fee collections may ultimately form:

3 Razorpay settlements

and therefore:

3 bank credits

The system needs to preserve both the transaction-level and settlement-level views.

Different gateways can settle on different schedules

A school using five gateways may receive settlements at different times.

For example:

Razorpay settlement A
Paytm settlement B
Easebuzz settlement C
PayU settlement D
BillDesk settlement E

Each follows its own:

Settlement ID
UTR format
Fee structure
Settlement timing

The bank statement then contains credits from all of them.

A consolidated reconciliation helps the finance team understand which bank credit belongs to which payment gateway.

Example: one bank account receives multiple gateway settlements

Suppose the bank statement contains:

₹4,85,000
₹6,20,000
₹3,42,500
₹7,15,000
₹2,80,000

These may relate to different settlements from:

Razorpay
Paytm
Easebuzz
PayU
BillDesk

Without settlement UTRs, the finance team may need to manually inspect bank narrations.

With the gateway settlement reports, the corresponding:

UTR
Payout ID
Settlement ID
Net Amount

provide much stronger reconciliation references.

Manual Match for known payment or settlement relationships

Some transactions may still use inconsistent references.

For example:

Gateway

Settlement ID:

SET-78421

Amount:

₹5,42,000

Bank

Narration:

PG SETTLEMENT 21AUG

Reference:

HDFC985214

Credit:

₹5,42,000

If the finance team knows these represent the same settlement but no common reference can be identified automatically, Cointab provides:

Manual Match

The user can select the corresponding records and confirm the relationship.

This is useful for:

Abbreviated bank narrations
Legacy settlement formats
Older payment transactions
Missing reference numbers

A useful exception framework for school finance teams

The 3-way reconciliation can turn thousands of transactions into a few clear exception types.

School vs Gateway exceptions

School success but gateway missing
Gateway success but school missing
Amount difference
Status difference
Duplicate transaction
Refund difference

Gateway vs Bank exceptions

Gateway settlement missing from bank
Bank credit missing from gateway settlement data
Settlement amount difference
UTR mismatch
Settlement timing difference

Fee and adjustment exceptions

Gateway fee difference
GST difference
Refund adjustment
Other settlement deduction

This makes exception ownership much clearer.

Know which team or party needs to investigate

The reconciliation can also help route each exception.

School system / technology team

Examples:

Gateway transaction succeeded but school fee account did not update
Receipt not generated
Wrong gateway order recorded

Finance team

Examples:

Settlement amount difference
Bank credit unidentified
Gateway fee discrepancy
Refund accounting difference

Payment gateway

Examples:

Settlement marked completed but not received
Incorrect settlement amount
Missing transaction
Unexpected gateway charge

The output becomes an operational workflow rather than just a spreadsheet.

Download the complete school fee reconciliation in Excel

Once the reconciliation is complete, Cointab can provide the entire working in Excel.

The output can preserve useful school-side context such as:

Student / Participant
Enrollment reference
School
Grade
Fee type
Transaction ID
Order ID
Receipt
Invoice
Amount
Refund status

alongside payment-gateway information such as:

Gateway transaction ID
Gateway order
Payment status
Fee
Tax
Settlement ID
UTR

and bank information such as:

Bank reference
Value date
Credit amount
Transaction narration

This provides a complete audit trail from student payment to bank receipt.

Use the reconciliation for parent payment queries

A parent may contact the school saying:

"I have paid, but the portal still shows the fee as outstanding."

Instead of searching several systems manually, the finance team can trace:

Enrollment → Order ID → Gateway Transaction → Payment Status

If the gateway shows payment success but the school report does not, the issue can immediately be routed to the relevant internal team.

This can significantly improve the handling of payment-related student or parent queries.

Use the reconciliation for month-end fee collection control

At month end, the finance team may need to confirm:

Total online fees recorded
Total successful gateway collections
Total refunds
Gateway charges
Settlement amounts
Amount received in bank
Transactions still unreconciled

A 3-way reconciliation provides the transaction-level evidence supporting these totals.

Instead of relying only on aggregate numbers, finance teams can drill into the remaining exceptions.

Reconciliation is different from merely checking bank receipts

A bank credit proves that the school received money.

It does not prove:

Which students paid
Which gateway transactions formed the settlement
Whether every successful payment reached the school system
Whether refunds were handled correctly

Similarly, a successful gateway transaction does not prove that settlement reached the bank.

This is why the complete chain matters:

School System ↔ Gateway ↔ Bank

How Cointab helps automate school fee reconciliation

Cointab can help schools reconcile online fee collections by allowing finance teams to:

Upload the school fee collection report
Retain student and enrollment context
Reconcile multiple payment gateways
Work with Razorpay reports
Work with Paytm reports
Work with Easebuzz reports
Work with PayU reports
Work with BillDesk reports
Match transaction and order references
Compare transaction amounts
Identify successful gateway transactions missing from the school system
Identify school transactions missing from gateways
Reconcile refunds
Review gateway charges and taxes
Group transactions into settlements
Match settlement IDs and UTRs
Reconcile payment-gateway settlements with bank credits
Identify settlement amounts missing from the bank
Identify unidentified bank credits
Manually match transactions where references differ
Download the complete reconciliation working in Excel
Upload updated data and rerun reconciliation

Automate 3-way school fee collection reconciliation

Cointab can create a structured three-way reconciliation:

School Fee Collection Report

↓

Razorpay / Paytm / Easebuzz / PayU / BillDesk

↓

Bank Statement

The finance team can determine:

Whether every successful student fee payment reached the payment gateway
Whether every gateway collection is represented in the school's system
Whether payment amounts agree
Whether refunds agree
How gateway charges affect settlement
Which transactions belong to each settlement
Whether each payment-gateway settlement reached the bank
Which student payments or settlements remain unresolved

The result is an end-to-end financial control over online school fee collections — from the student's payment through to the final bank receipt.

If your school currently reconciles online fee collections and multiple payment gateways manually in Excel, you can use Cointab to automate the entire process.

Try Cointab

For schools with multiple campuses, legal entities, high transaction volumes, multiple payment gateways or customized fee collection systems:

Book a Demo