Scholarship Management Software Problems: The 5 That Cost Real Money, and How to Avoid Them

Why does the application portal get built instead of the rule engine?

Because the portal is what everyone can picture. Students are filling in thirty separate forms, staff are chasing incomplete files, and the obvious answer is one attractive application with saved progress, document upload and a reviewer view. That is worth having, and any competent developer will build it well.

It does not touch the problem that decides whether restricted money moves. Your eligibility rules were written in gift agreements by donors and their lawyers, decades apart, with no idea that a settings screen would one day exist. Preference shall be given to students demonstrating financial need who are members of a named congregation, and failing that to any student from the county pursuing a health profession. That is a priority cascade with a fallback, and a criteria builder with dropdowns cannot express it, so it becomes a note in a spreadsheet column that one person interprets each spring.

The second half of the problem is direction. Packaged systems mostly run forwards: the applicant picks funds, or answers questions, and the system filters. What a foundation needs is the reverse. Given this applicant, show every fund they qualify for, ranked, including the ones the program officer would never have thought to check. That reverse match is how the fund restricted to descendants of employees of a mill that closed in 1994 finally gets awarded, and it is the single screen that justifies the whole build. If a vendor cannot show it to you, the rest of the demonstration does not matter.

What goes wrong when you migrate gift agreements, award history and applicant data?

The gift agreements are the hard part and they are not really a migration. They are a translation exercise, from legal prose into structured rules with hard requirements, preferences and fallbacks held separately, because a preference treated as a filter is exactly how a fund goes unawarded for three years. Nobody can do this except your program staff working with whoever holds the fund agreements, and it is the longest task in the project. It also does not need a developer, which means you can start it today.

Award history brings its own trouble. Historic awards were recorded against fund names that changed, funds that merged, and in older records against a general scholarship line with the fund identified only in a memo field. Migrating that as if it were clean data produces a stewardship report you will have to correct in front of a donor. Load history as an archive tied to the fund where the link is certain, mark the rest as unverified, and be explicit with your board about which years are reportable.

Applicant data is the third, and it carries obligations rather than difficulty. Households supplied income documentation and transcripts, some sensitive, much of it collected under a privacy notice written for a different system. Decide what you need to retain and for how long, and write the retention rule into the build rather than carrying every uploaded document forward because migrating it was easier than deciding.

Why do the institution and disbursement integrations break after launch?

Two integrations decide whether the system survives its second season.

Enrolment verification is the first. Where your programme supports it, an institutional data source such as the National Student Clearinghouse gives you a scheduled check rather than a memory. Where it does not, you are sending structured requests to registrars who reply on their own timetable and in their own format. The failure to design against is silence: a verification request that was never answered looks identical to one that has not been processed, so build an explicit unanswered state with an age and an owner, and let a payment hold follow from it automatically.

Disbursement to bursars is the second and it is an accounting workflow, not an email. Each institution wants its own student identifier, its own file or cheque format, and its own reference on the remittance. What breaks after launch is the return path. A student withdraws in October, the institution refunds in January, and the money has to land back against the original award and restore that specific restricted fund balance rather than a general pool. Foundations get this wrong routinely because the payment goes out when everyone is watching and the refund arrives when nobody is. Model returns as first class events from day one, reconcile pledged against paid against returned against remaining continuously, and the donor report becomes a by product rather than a project.

What happens when renewal conditions and verification are not covered?

A renewable award is a multi year commitment with conditions attached: continued enrolment, a minimum grade point average, sometimes a continued programme of study, sometimes continued financial need. In most foundations those conditions are checked because somebody set a calendar reminder, which works until the person who set it changes role.

The costs of not covering this are quiet and cumulative. Money stays committed to students who no longer qualify, so it is unavailable to the next cycle while still appearing spoken for in your forecast. Students who do qualify drop out of the process because the renewal asks them to complete a full application again, which is the difference between most of them returning and most of them not. And when the investment committee sets spending policy, the multi year commitment picture is a guess.

The fix is to store renewal conditions with the award, check them on a schedule against verification data, and produce a decision queue with the evidence attached rather than a list of names. Ask students only for what is missing. Release discontinued awards back to available balance with a dated record so the fund can be used in the next cycle. Then the multi year commitment becomes a forecast the committee can actually see. One thing to coordinate rather than assume: an outside scholarship interacts with a student's aid package because institutions account for outside awards within cost of attendance, so confirm the current position with the financial aid office rather than relying on a general summary.

Should you build custom or configure what you already own?

If you administer fewer than about forty funds with conventional criteria such as residence, school, grade point average and field of study, configure. AwardSpring and Foundant Scholarship Lifecycle Manager are built for exactly that shape, they will run your season better than a first version of anything custom, and building would be a poor use of grant dollars.

If you are a university already committed to Blackbaud, Blackbaud Award Management is the path of least resistance and the integration value into the wider estate is real. If you run a corporate or association programme with one defined criteria set, Kaleidoscope covers it well. In all three cases the honest test is whether the funds that do not fit the model are numerous enough to justify a build and a year of your program team's attention.

Build when two or more of these are true. You administer more than roughly a hundred and twenty separately restricted funds. Funds go unawarded because matching is manual. Your gift agreements contain priority cascades and fallbacks a criteria builder cannot express. You disburse to many institutions and reconcile returns by hand. Or you carry multi year renewable commitments that nobody is systematically verifying, so your available balance for the coming cycle is an estimate.

How do hidden costs get into the quote?

Unusual restrictions first. The cost driver is not the number of funds, it is how many have genuinely awkward rules, because each one is analysis time with your program officer rather than code. A quote based on a fund count and not a sample of your worst gift agreements is a guess. Hand a developer your ten strangest agreements before anyone prices the work.

Second, institutional integrations. Verification and disbursement differ per institution, and a foundation sending money to forty colleges is not doing one integration forty times, it is doing one integration plus thirty nine variations in identifiers, formats and contacts. Agree how many are in scope and what happens to the rest.

Third, financial need analysis. If you accept aid data or income documentation, you have taken on privacy obligations, access control and retention rules that need their own attention rather than a checkbox. Fourth, fund accounting integration, which is its own discipline and where the finance team's requirements usually arrive late. Fifth, the reviewer experience, since volunteers use the system once a year for two weeks and it therefore has to be obvious with no training at all, which takes iteration rather than specification.

What separates a build that works from one that fails here?

The foundations that succeed arrive with their rules already drafted. They spend the autumn transcribing gift agreement restrictions into structured hard requirements, preferences and fallbacks, with a plain language rendering the finance committee can read and sign off. That work is the project, and doing it before development starts consistently produces a shorter build and a lower invoice.

Second, every award decision must store its evaluation. Not a note saying eligibility confirmed, but a record showing which criteria were satisfied by which application data against which version of the rule. Three years later when an auditor or a donor family asks why this student received this fund, you produce the evaluation rather than reconstruct it from memory. That is the difference between a compliance trail and a story.

Third, take reviewer conflicts seriously rather than trusting a checkbox. Detect likely conflicts from data you already hold, such as shared surname, same employer or same high school, and route them to the program officer to resolve. Where a donor family member sits on a panel by agreement, which is common and legitimate, record the mitigation explicitly. Make blind review an enforced mode with the suppression provable in the record, and watch panel calibration so that a panel scoring consistently lower than another does not quietly decide who gets funded.

Finally, settle ownership before kickoff: the repository, the cloud accounts, all award and applicant data, and the right to hire another firm. At Digital Heroes the client owns the code from the first commit. A foundation carrying multi decade fiduciary obligations should not hold its award records inside a system it cannot leave.