Find program, catalog term, and export problems in your SIS data before a degree audit implementation begins.
The kickoff goes well, and then someone on the IT side runs the first data extract. A degree retired three years ago is still attached to an active program, and a requirement carries the wrong year. The audit that was supposed to be a quick win now needs a cleanup project first.
Your SIS data is ready for a degree audit when programs, catalog terms, course data, and student records all line up with what the audit will read. This checklist walks through each area so registrars and IT leaders can find problems before go-live.
Start with the skeleton by pulling every program, plan, and subplan that students can currently declare, then confirm each one points to a live set of requirements. A common problem is a degree that was deleted or retired but remains linked to an active program, which leaves the audit trying to read requirements that no longer exist. Orphaned plans and duplicated subplans belong on the same list.
UW-Madison's degree audit data documentation shows how much an audit leans on this structure. It defines an academic plan as an area of study such as a major, minor, or certificate, with subplans that a student can also declare. If that mapping is wrong, everything downstream inherits the error.
Catalog year is a setting where quiet errors can hide. The same Wisconsin documentation explains that a student's catalog year and term determine which version of the curriculum applies, and that different requirement types can follow different dates, subject to school or college policy. General education may follow matriculation, for example, while major requirements may follow the date the major was declared. Its audit requirements also record the first catalog year and term in which they apply, and its degree requirements record the last.
A calendar entry in the wrong year can attach a student to the wrong version of a requirement. Spot check effective dates on a sample of programs from each college, comparing the SIS to the published catalog. Stakeholders who want a refresher on the concept can start with what a catalog year is.
Requirements often reference course attributes and cross-listings, so course records carry more weight than most teams expect. Check that active courses have complete titles and credit values, and that cross-listed and equivalent courses are linked consistently.
Give prerequisites and corequisites special attention. Depending on how your SIS is configured, these rules may sit in free text or in structures that do not export cleanly, so test an actual export and read what comes out. A prerequisite that exists in the catalog but arrives in the audit as a blank field is easy to miss in a spreadsheet review.
Perfect requirement data still produces bad audits when student records do not line up with it. The University of Iowa's registrar team notes that audit results rely on student records checked against encoded requirements, so an error in the student data or in the encoding can change the outcome. Students who changed majors or transferred in are good places to look for mismatches.
Run a sample that deliberately includes them. Confirm each has a declared program and a catalog term the audit can read, and note records where a program change left old values behind.
Readiness includes the process that keeps the data ready, and that is where projects often stall. Iowa describes encoders reviewing each catalog page every year to confirm the audit matches the catalog. Its workflow shows approved changes flowing to several downstream systems, and a separate team tracks changes that affect sample plans. Its 2026-27 catalog editing window runs from Oct. 27 to Jan. 16. A change that lands after your own window closes is worth treating as a risk.
Define a version of this for your own campus. Name who approves a program change and who confirms afterward that the SIS and the audit agree.
A readiness review works best when registrars and IT run it together. Pairing the two puts program knowledge and export knowledge in the same room. Group the findings by owner and fix structural problems first, then re-run the same sample extract after each round so you can watch the issues shrink. Finishing this before a vendor arrives means your timeline rests on known data.
If you'd like a second set of eyes on your data before a project begins, request a demo and we can talk through what your SIS exports and where a modern degree audit would need support. Our piece on questions to ask before replacing your student information system covers the system side of the same decision.
A degree audit needs current programs, plans, and subplans along with requirement sets tied to catalog terms. It also needs complete course data and student records that carry a declared program and catalog term. Prerequisites, corequisites, and equivalencies matter wherever your requirements reference them.
It helps to run the checklist first, because the findings shape your timeline and what you ask vendors to support. You can start without perfect data, and knowing where the problems are keeps surprises out of the implementation plan.
The term attached to a requirement decides which version applies to a student. A requirement dated to the wrong year, or a student attached to the wrong catalog term, can produce an audit that looks fine and is wrong.
Many campuses split it, with the registrar's office owning the requirements and IT owning the data feeds. Whatever the split, a named owner for each program change keeps the SIS and the audit from drifting apart.
At least once a year, aligned with your catalog cycle. Many institutions also review when a program, policy, or course changes, since a change made after your catalog editing window closes is worth treating as a risk.
