Degree Audit and Academic Advising Software: Why Students Keep Taking Courses That Do Not Count Toward Their Degree

Week three of a student's final term

A senior meets her adviser to confirm she is on track. She is not. A 300 level elective she took in her second year was applied to her minor, and because your double counting policy allows a course to satisfy either the minor or the major upper division requirement but not both, the major is one course short. Nobody told her. The audit showed green for two years because the exception a department chair granted in 2023 was entered against the wrong requirement block.

She can graduate a term late or take an overload with permission. Either way there is now a complaint, a request for a fee refund, and a conversation about whether the institution misled her. Multiply by the number of students who discover this in their last term and you have a retention problem, a complaints problem and a real financial exposure, all created by a rule encoded slightly wrong four years ago.

Degree audit is not an advising convenience. It is the system that decides whether a course counts, and under federal rules aid is limited to coursework applicable to the student's programme. That makes the audit an input to enrolment status and aid eligibility, not just a checklist. When it is wrong, it is wrong expensively.

Requirement grammar is a language, and generic tools do not speak it

A degree requirement is rarely a list. It is a set of nested conditions: nine credits from this group, of which at least six must be upper division, no more than three from any single discipline, excluding courses used to satisfy the general education distribution, with a minimum grade of C minus in each, and a residency rule that says at least half the major must be taken here. Then multiply by every programme, every minor, every certificate and every catalog year in force.

Ellucian Degree Works is the most widely deployed answer to this and its requirement encoding uses Scribe, a domain specific language. It is capable, and the practical consequence is that your entire requirement corpus depends on the small number of people who can write and debug it. CollegeSource uAchieve has a similarly long history and similar depth, with the same concentration of specialist skill and an interface students notice is older than they are. Stellic brings a modern student facing planning experience and strong advising engagement, and institutions with unusually intricate requirement grammar still spend time negotiating what can be expressed cleanly.

The honest observation is that all three can encode most rules. The difference a custom build makes is who can change them, how fast, and whether the result is data you can query rather than a document you can read.

Catalog year rights are the trap that ages badly

A student entering under the 2022 catalog keeps those requirements even after the programme is revised twice. She changes major in year three, which may move her to the current catalog or may not, depending on your policy. She takes a leave and returns, which may reset her rights, depending on your policy. Meanwhile a course in her original requirement list was discontinued in 2024, and the department published an approved substitution that exists in a memo.

Most systems handle catalog years as versions of a programme, which is correct as far as it goes. What breaks is everything around the version: the discontinued course, the policy about major changes, the leave rules, and the fact that departments revise requirements without anyone reconciling what happens to students mid stream. A build should model catalog year as a right attached to the student with an explicit reason for any change, keep every requirement version live rather than archived, and maintain course lifecycle data so a discontinued course resolves to its approved successor automatically instead of silently failing to match.

Exceptions are the real system, and they live in email

Every institution's audit is a rules engine plus a large body of exceptions granted by department chairs: substitutions, waivers, credit adjustments, requirement swaps for study abroad, and one off decisions to honour a course taken before a policy changed. These are the most consequential entries in the whole system and they are usually requested by email, approved by reply, and typed in by a staff member who interprets what the chair meant.

What a build does is make the exception a first class object with a workflow. The adviser proposes it against a specific requirement in a specific block, the chair approves in the system, the applied result is previewed before approval so everyone sees exactly what changes on the audit, and the record retains who approved it and why. Then reporting becomes possible, and reporting on exceptions is uncomfortable in a useful way: when you can see that one department granted ninety substitutions for the same requirement last year, that is not an exception pattern, that is a requirement which needs revising.

What if planning is where advising actually happens

The questions students ask are hypothetical. What happens if I switch to economics. What if I add this minor. What if I do the semester abroad and take these three courses. If I fail this course, what does my final year look like. Answering those means running the audit against a hypothetical programme and a hypothetical set of future enrolments, which is a different computation from auditing history.

This is where a custom engine earns its cost, because the same rules have to evaluate completed work, in progress work and planned work, with clear signalling about which is which. A good planner also knows when courses are actually offered, since a plan that requires a course only taught in alternate autumns is not a plan. Connecting the audit engine to real offering patterns turns a checklist into something a student can act on, and it moves the advising conversation from what have you done to what should you do next.

The audit should be data, not a printable page

The single biggest limitation of the traditional model is that an audit is generated as a document per student. That makes institutional questions expensive. Which students are one course from completing a minor they have not declared. How many students still need this capstone next term, so should we run two sections. Which requirements are most often satisfied by exception. Which students in this cohort are enrolled in courses that do not apply to their programme, which is both an advising signal and an aid eligibility issue.

When the audit is a structured evaluation stored per student per run, all of those become queries. Registrars typically discover within weeks that this reporting capability, rather than the audit itself, is what changes decisions. It also makes graduation checking a review of exceptions rather than a manual pass over every applicant in the final term.

What the build has to include

• A requirement rules engine with nested conditions, group minimums, grade thresholds, residency rules and explicit double counting policy per requirement.
• Requirement versioning with all versions live, and catalog year modelled as a right attached to the student with recorded reasons for any change.
• Course lifecycle data so discontinued or renumbered courses resolve to approved successors rather than silently failing to match.
• Exceptions as workflow objects with proposal, preview of effect, approval, and full retention of who approved what and why.
• What if evaluation across completed, in progress and planned coursework, with offering patterns so a plan is achievable.
• Audits stored as structured data per run, enabling cohort level queries rather than only per student documents.
• Graduation checking driven by the engine, with staff reviewing exceptions instead of re verifying every requirement.
• An adviser view that shows why a course did not count, in plain language, because that is the question that generates every appeal.

What it costs and how long it takes

From Digital Heroes delivery experience, a first release with the rules engine, catalog year handling and exception workflow for your highest volume programmes runs $70,000 to $140,000 over 12 to 16 weeks. The full platform with what if planning, advising workflow, graduation checks and reporting runs $180,000 to $420,000 across 8 to 14 months.

What drives the price: the number of programmes and the intricacy of their requirement grammar, especially in engineering and health sciences where professional accreditation dictates structure. The number of catalog years you must keep live, since institutions with long completion times carry more. Migration of existing encoded requirements, which is genuinely hard because Scribe and similar encodings often embed institutional decisions nobody documented elsewhere. And integration with your student information system for enrolment, grades and course catalogue, which has to be reliable because a stale audit is worse than no audit.

What keeps it down: starting with the twenty programmes covering most of your enrolment, running the new engine in parallel against the existing one, and comparing outputs student by student. That parallel comparison is the only credible way to prove a new engine before trusting it, and it also finds the errors in the old one.

Build versus buy, and the honest Degree Works answer

Keep Degree Works or uAchieve if it is working and your complaint is turnaround on encoding changes. That is frequently a staffing constraint rather than a product constraint, and hiring or training a second encoder is cheaper and faster than a replacement project. Replacing a functioning audit engine is one of the riskiest things a registrar can undertake, because errors are discovered by students in their final term.

Build when two or more of these are true. Requirement encoding is bottlenecked on one or two people and departments wait months for changes. Exceptions are granted by email and applied by interpretation. Your audit cannot answer cohort level questions without exporting to a spreadsheet. What if planning is not usable enough for students to trust it, so advisers do it by hand. Or you run competency based, non credit or unusually structured programmes that the packaged document model was never designed to represent.

How to choose a developer for degree audit software

Ask them how they would express a rule where a course may satisfy either the minor or the major upper division requirement but not both, and where a chair has granted a documented exception for one student. If they cannot articulate that cleanly on a whiteboard, they will not be able to build it, because that pattern is the everyday reality of this domain.

Ask how they would validate the new engine against your existing one. The only acceptable answer involves running both across your live student population and reconciling differences, one by one, until every difference is explained. Anyone who proposes going live on a sample has not appreciated what a wrong audit costs a student.

Ask how the adviser sees why a course did not count. Explanation quality is not decoration in this system. It is the difference between an adviser trusting the audit and an adviser keeping a private spreadsheet, and once that spreadsheet exists you have lost.

Ask who owns the code, the repository and the cloud accounts, and settle it before kickoff. At Digital Heroes the institution owns the code from the first commit, along with the right to hire anyone else to continue. Your encoded requirements represent decades of curriculum decisions, and that corpus should belong to the institution rather than sitting in a proprietary encoding you cannot take with you.