Degree Audit Software Problems: The 7 That Cost Students a Term, and How to Avoid Them

Why does the requirement encoding scope keep getting underestimated?

Almost every degree audit project is scoped as if a requirement were a list of courses with a credit total. Requirements are not lists. A single block routinely reads as nine credits from this group, of which at least six must be upper division, no more than three from any one discipline, excluding anything already used for the general education distribution, with a minimum grade in each, subject to a residency rule about how much of the major must be taken here. Then you multiply that by every major, minor, concentration, certificate and catalog year in force.

Teams that miss this build a checker rather than an engine. It works beautifully on the twelve programmes used during discovery and then meets a professional accreditation driven curriculum in engineering or nursing where the sequencing rules interlock, and the model runs out of expressiveness. The response is usually a hard coded special case, and once there are forty special cases the system is no longer a rules engine, it is a codebase only one developer understands.

The fix is to prove expressiveness before you commit. Pick your five most awkward programmes, not your five cleanest, and require the developer to express those requirements in the proposed model during the proposal phase, on a whiteboard, in front of your curriculum staff. Include at least one double counting rule, one residency rule and one rule with a grade threshold. If the model handles those five, it will handle the ordinary ones. If it handles only the ordinary ones, you will be paying for special cases for the next decade.

What goes wrong when you migrate existing encoded requirements?

The instinct is to convert. You already have hundreds of programmes encoded in Scribe or an equivalent, so the plan becomes a translation exercise from one encoding into another. This is the single most reliable way to import a decade of undocumented decisions into a brand new system without noticing.

Encoded requirements accumulate institutional memory that exists nowhere else. Somebody decided in 2016 that a particular transfer course satisfies a lab requirement. Somebody else added a condition to stop a specific double count that a department objected to. A third person built a workaround for a course renumbering that was never cleaned up. None of it is in the catalogue. All of it is load bearing, and a mechanical translation carries it forward with the reasoning stripped out, so the new system behaves oddly and nobody can say why.

The approach that works is re authoring against the published catalogue with department confirmation, treating the existing encoding as a reference rather than a source. Where the new authored version and the old encoding disagree, that disagreement is the interesting artefact: either the old system was wrong, or there is a decision your catalogue does not reflect and should. Budget for it as a curriculum project with registrar and department time in it, not as a data conversion line item, because staffing it as the latter is how a twelve week build becomes a nine month one.

Why do student information system integrations break after launch?

The audit is only as current as the enrolment, grade and catalogue data feeding it, and those feeds fail in ways that produce wrong answers rather than obvious errors. A student drops a course after the census date and the drop arrives on a different feed with a different cadence than enrolments, so for a few days the audit counts a course that no longer exists. A grade change flows through as a new record rather than a replacement and the engine sees two attempts. A course is renumbered between catalogues and the equivalency table is updated by hand a term later, so every student who took it under the old number stops matching.

Transfer credit is the worst of it. Equivalencies are maintained by different people from requirements, often in a separate system, and the audit depends completely on them. When one is added retrospectively, the audits that already ran are stale, and an adviser opens last month's audit and reads a number that is no longer true.

The fixes are specific. Re evaluate on any event that could change an outcome, including grade changes, drops, equivalency updates and requirement version changes, rather than on a nightly schedule alone. Stamp every audit with the data as of time so an adviser can see when it was computed. Reconcile daily against the student system on record counts and flag divergence rather than assuming the feed ran. And treat course lifecycle data, meaning renumbering, discontinuation and approved successors, as a first class part of the model rather than something the equivalency table handles by accident.

What happens when exceptions and catalog year rights are not properly covered?

Every institution's real audit is the rules engine plus a large body of chair granted exceptions, and in most places those exceptions are requested by email, approved by reply, and typed in by a staff member interpreting what the chair meant. That interpretation is where the damage occurs. A substitution applied against the wrong requirement block satisfies something that was already satisfied and leaves the intended requirement open, or worse, closes a requirement the student has not actually met.

Catalog year rights fail more slowly and just as expensively. A student entering under one catalogue changes major in year three, takes a leave, and returns. Each of those events interacts with your policy differently, and if the system models catalog year as a simple pointer to a programme version, the policy lives in a staff member's head. Meanwhile a course in the original requirement list was discontinued and the approved substitution exists in a departmental memo.

The fix is to make the exception a first class object with a workflow. The adviser proposes it against a specific requirement in a specific block, the system previews exactly what changes on the audit before anyone approves, the chair approves inside the system, and the record retains who approved what and why. Then model catalog year as a right attached to the student with a recorded reason for every change, keep all requirement versions live rather than archived, and let discontinued courses resolve to approved successors automatically. The reporting that falls out of this is uncomfortable and useful: ninety substitutions granted against the same requirement in one year is not an exception pattern, it is a requirement that needs rewriting.

Should you build custom or configure what you already own?

Some institutions should not build, and the honest test is what your actual complaint is. If your complaint is that requirement encoding takes months to turn around, that is very often a staffing constraint wearing a software costume. Ellucian Degree Works can express most requirement grammar, and the reason changes are slow is usually that two people know Scribe and both have other jobs. Training or hiring a second encoder is faster, cheaper and less risky than replacing a working audit engine, and replacement is one of the riskiest projects a registrar can undertake because the errors are found by students in their final term.

The same applies to CollegeSource uAchieve. If the interface is dated but the audits are correct, an interface complaint does not justify a rebuild. And if your students are not planning in the system because the what if experience is poor, look seriously at Stellic before commissioning anything, because that is the problem it was built for and it sits alongside an existing audit engine rather than replacing it.

Build when the constraint is structural rather than operational. Exceptions are ungoverned and applied by interpretation. Your audits cannot answer cohort level questions without exporting to a spreadsheet. Your programme structures, such as competency based or non credit provision, do not fit the packaged document model at all. Two of those together make a real case. One of them on its own usually does not.

How do hidden costs get into the quote?

The first is programme count and complexity, quoted as a number when it should be quoted as a mix. Forty straightforward liberal arts programmes and forty accredited health science programmes are not the same work, and a quote that treats them identically has not looked at your catalogue.

The second is catalog years. Institutions with long completion times, part time populations or generous readmission policies carry far more live requirement versions than they expect, and every live version is a version somebody has to author and validate.

The third is the parallel run. Running the new engine alongside the existing one across your live student population and reconciling every difference is the only credible way to earn trust, and it is real work for both the developer and your staff. Quotes that omit it are quoting a build without a validation. Expect it to surface errors in your current audits too, and expect resolving those to take registrar time.

The fourth is explanation quality. Telling an adviser why a course did not count, in language that ends the conversation rather than starting an appeal, is a design effort that gets cut from scope and rebuilt under pressure after go live.

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

The audit has to be structured data rather than a generated document. The moment it is a printable page per student, every institutional question becomes an export: which students are one course from an undeclared minor, how many need the capstone next term so you can size sections, and which students are enrolled in coursework that does not apply to their programme, which matters because federal aid is limited to applicable coursework.

The engine has to evaluate completed, in progress and planned coursework with the same rules and clear signalling of which is which, and the planner needs real course offering patterns. A plan that requires a course taught only in alternate autumns is not a plan, and a student who builds one in your system and then cannot execute it trusts nothing you show them afterwards.

Explanation is not decoration. When an adviser cannot see why a course failed to count, they keep a private spreadsheet, and once that spreadsheet exists you have two systems of record and the expensive one is losing.

Finally, settle code and data ownership before kickoff. Your encoded requirements represent decades of curriculum committee decisions, and that corpus belongs to the institution rather than inside an encoding you cannot take with you.