What an RFP should say about fees, payments, and school accounting

State the RFP outcome

An RFP should state what the school needs to decide and improve: configure fees, manage accounts, invoice, receive and allocate payments, issue receipts, reconcile, communicate statements, process refunds, correct balances, report, recover, and retain history.

Describe campuses, payer groups, fee items, currencies, methods, banks, gateways, accounting systems, reports, users, calendars, accessibility needs, support windows, and exceptions.

Require verifiable answers

For each requirement, include user, scenario, input, expected output, calculation, permission, audit event, evidence, acceptance test, implementation responsibility, support route, limitation, and priority.

Require suppliers to distinguish available now, configurable, dependent, manual, roadmap, unsupported, or not evidenced. Ask for representative demonstrations using anonymised school-like data.

Cover risk and exit

Include privacy, security, records, accessibility, safeguarding, retention, disposal, backups, restoration, incident response, subprocessors, integrations, role changes, reporting, training, support, renewal, and exit.

The U.S. Department of Education data governance checklist covers quality, access, security, lifecycle, sharing, disposal, and monitoring. Obtain qualified local finance, privacy, security, records, accessibility, safeguarding, and legal review.

Make scoring defensible

Score fee configuration, payment allocation, reconciliation, exception handling, statements, reports, usability, accessibility, security, privacy, implementation, migration, support, total cost, internal capacity, and exit.

Keep evidence, assumptions, conflicts, unresolved questions, acceptance gaps, and decision owner. Revisit the RFP after demonstrations, reference checks, pilot tests, and at 30, 60, and 90 days after implementation.

Make the next improvement testable

Use this guidance to improve one bounded part of what an RFP should say about school fee management software. Name the owner, financial record, evidence, correction route, and review date so staff can apply it consistently.

Check an ordinary transaction and one meaningful exception. If either depends on undocumented knowledge, add the missing definition, validation rule, permission, approval, training note, or support route.

Record what changed, what remains manual, and who reviews the result before the next billing, payment, or reconciliation cycle.

Keep the decision beside its evidence so the next finance or operations colleague can understand the rule without relying on informal memory.

Use the review to decide whether the change should be expanded, repaired, narrowed, consolidated, or held.

Recheck the boundary when a fee item, payer, campus, currency, payment method, gateway, accounting rule, calendar, or policy changes.