IPEDS and Institutional Research Reporting Software: Can You Reproduce Last Year's Published Number Exactly?

Why institutional research breaks on the day someone questions a number

A trustee reads the graduation rate in a news ranking and asks why it differs from the one in the strategic plan. The IR director knows the answer in outline: the ranking uses the IPEDS first-time full-time cohort, the strategic plan uses an all students completion measure the cabinet agreed on in 2021, and the state dashboard uses a third definition that counts transfers out as successes. Explaining that takes twenty minutes. Proving it takes three days, because the query that produced the strategic plan figure was edited in 2023 and the version that generated the original number no longer exists.

The stack in most IR offices: the SIS, which is Banner, Colleague, PeopleSoft Campus Solutions or Workday Student, a set of Evisions Argos or Cognos queries built over a decade, a folder of Excel files named with dates and initials, the IPEDS keyholder web forms, a Tableau or Power BI (Business Intelligence) server that half the campus has access to and nobody governs, and possibly HelioCampus or Watermark Institutional Reporting sitting on top. Each piece is defensible. Together they have one structural flaw: the numbers are computed from a live database that keeps changing underneath them.

That is the whole problem. A student drops retroactively in November for an October census. A grade change posts in January that alters a term GPA used in a fall report. A degree is conferred with a backdated conferral date. None of those are errors, they are normal registrar operations. But every one of them silently changes a number you already published, and the only defence is a snapshot that was taken and never touched again. Most institutions think they have that. Most institutions have an Excel file.

In the IR projects we have delivered, the recurring cost is not survey submission time, it is defence time: several days a year reconstructing how a published figure was produced, plus a standing anxiety that the IR director is the only person who can do it. When that person retires, the institution loses its ability to explain its own history.

Problem 1: the census is a date, not a snapshot, and your reports know the difference

Your fall census is a defined day. What most systems do is run a query on or after that day with an as-of filter, which sounds equivalent and is not. Filtering by effective date reconstructs the past using today's record state, and any field without full effective dating, which in a typical SIS is most of them, returns today's value. Program of study, residency, level, and full time status all move.

Argos and Cognos are query tools, so they inherit this problem completely. HelioCampus and Watermark do better because they warehouse, but a warehouse is only a snapshot if you version it, and out of the box many implementations simply overwrite the current picture each night.

What a custom build does: on census night, take a full extract of the entities that matter, meaning student, enrolment, course registration, aid, program and demographic records, and write it immutably with a snapshot identifier. Nothing later can modify a snapshot. Corrections create a new snapshot that references the old one with a documented reason. Then every report declares which snapshot it ran against, and that identifier goes on the face of the output. Three years later, rerunning the report against that snapshot produces the same number it produced then. That single design decision removes the majority of defence work in this category and costs very little at build time.

Problem 2: four authorities, four definitions of the same word

Headcount and FTE are not one thing. IPEDS has its own instruction for FTE by level and control. Your state system has a funding formula with different rules for dual enrolment and non degree seeking students. Your accreditor asks in another shape. The Common Data Set has its own definitions and its own footnotes. And your cabinet asks for the number they have been looking at since 2019, which matches none of them.

The near universal workaround is one query per authority, built separately, drifting separately. When a definition changes, and the state changes them, you have to remember which of the fourteen queries embed the old rule. Somebody always forgets one, and that is the number that ends up in a press release.

What a custom build does: define the base facts once and the definitions as named, versioned rules on top. Degree seeking status, level, attendance status, residency, first time status and program CIP mapping become explicit rule objects with an effective date range and a named owner. IPEDS Fall Enrolment uses one set of rules, the state formula uses another, and both read the same underlying snapshot. When your state changes its dual enrolment treatment, you version one rule and every downstream report tells you it changed and what it produced before and after. The reconciliation memo between IPEDS and the state number stops being an annual archaeology project and becomes a generated comparison.

Problem 3: six year cohorts outlive your systems

Graduation Rates asks you to follow a first-time full-time cohort for six years, and GR200 for eight. Outcome Measures asks you to follow four cohorts including part time and non first time students, which most institutions never tracked before it existed. Over that window students stop out and return, change level, transfer out and complete elsewhere, and your own SIS gets upgraded or replaced.

The practical failure is that the cohort membership list itself is not stored. It gets recomputed each year from current data, so a student who is recoded in year three quietly leaves or joins a cohort defined in year one. Then your six year rate moves for a cohort that closed, and you cannot explain why.

What a custom build does: materialise the cohort as a list of student identifiers at the moment of definition, stamped with the snapshot it came from, and never recompute it. Each subsequent year adds status observations against that fixed list. Transfer out completions come from National Student Clearinghouse StudentTracker returns, which arrive as fixed width files that need matching, deduplication and a manual review queue for ambiguous matches, and that queue is real work you should budget for. Exclusions, which for IPEDS are limited and specific, get recorded per student with the reason and the approver rather than applied as a filter nobody remembers writing.

Problem 4: revisions have to be a first class concept, not an accident

You will revise. Someone discovers a CIP miscoding that put a program in the wrong category for two collection years. IPEDS has an unlock process for exactly this reason. What matters operationally is what happens on your side: the corrected figure must be produced, the original figure must remain visible, and every downstream artefact that used the original, meaning the Common Data Set, the fact book, the rankings submission, the accreditation report, must be identifiable so you can decide which to correct.

No standard tool tracks that lineage, so it lives in the IR director's memory and in email. When the correction is significant, the question from the provost is always the same: what else used that number. There is no good way to answer it from a folder of spreadsheets.

What a custom build does: track publication as an object. Every published figure records the snapshot, the rule versions, the survey or document it went into, and the date it was released. A revision produces a new figure linked to the old one, and the system lists every publication affected. That list is the whole deliverable. It turns a week of anxious searching into a screen you show the provost in the meeting where you disclose the error, which is a much better meeting.

Problem 5: the logic lives in one person and one unreadable query

The Argos datablock that produces Fall Enrolment has 400 lines of SQL with a WHERE clause containing eleven conditions, four of which encode policy decisions made by people who left. There is no comment explaining why non degree seeking students in program code 9998 are excluded. There is no test that would catch it if someone removed that line. The institution's official numbers depend on a file that only one person can safely edit, and that person is planning to retire.

What a custom build does: put the logic in version control with a reviewer, name every rule after the policy it implements, and write regression tests that reproduce the last three years of submitted figures from the stored snapshots. That last item is the one to insist on. If a change to the codebase alters a historical number, the test fails and you find out that afternoon rather than at the next trustee meeting. This is ordinary software practice, and its absence is the single largest structural risk in most IR offices. Succession planning in institutional research is a technical problem before it is a staffing one.

What this costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, this is the honest shape. A focused first release, meaning immutable census snapshots, versioned definition rules, and reproducible outputs for your three heaviest IPEDS components plus the state submission, runs $55,000 to $120,000 and ships in 10 to 14 weeks. That is a system you use for the next collection cycle, not a prototype. A full institutional research platform adding six year cohort tracking with Clearinghouse matching and a review queue, Outcome Measures, Common Data Set generation, accreditor reporting, a publication lineage register, and a governed dashboard layer with row level access runs $140,000 to $320,000 phased over 6 to 12 months.

What drives price up here specifically: the number of external authorities you report to, since each state system and accreditor is its own definition set. Whether you are mid SIS migration, because reporting across a Banner to Workday transition means reconciling two record models and that is a project on its own. Multi campus systems where each campus codes programs differently. Dual enrolment volume, which complicates nearly every definition. And the depth of history you need to reconstruct, because loading and validating ten years of prior snapshots from backups is real archaeology.

What keeps price down: starting with the fall census snapshot and Fall Enrolment, Completions and Graduation Rates. Those three carry most of your defence risk and teach the definition versioning pattern that everything else reuses.

Build versus buy, and when buying is the right call

Buy, or rather stay where you are, if you are a small single campus institution under about 2,000 students with a simple program mix, one state authority, and an IR office of one who has documented the queries. The overhead of a warehouse will not pay back. Evisions Argos is a reasonable tool when the reporting logic is genuinely simple, and HelioCampus or Watermark Institutional Reporting can be the right call if you want a managed warehouse and your definitions are close to standard.

Build when two or more of these are true. You cannot reproduce a figure you published three years ago from stored data. Your definitions differ meaningfully across IPEDS, your state and your accreditor and each has its own hand built query. You report to more than one state or operate multiple campuses with different program coding. You are inside an SIS migration and need continuity of official numbers across it. Or your entire reporting capability depends on one person and one query file, which is the condition we see most often and the one institutions consistently underestimate.

Our position: the value here is not dashboards, and you should be suspicious of any proposal that leads with them. The value is reproducibility. A number you can defend in year five is worth more than ten interactive charts, and the institutions that get burned are the ones that bought visualisation before they fixed the snapshot.

How to choose a developer for institutional research reporting

Ask them how they would make a figure reproducible three years later. The right answer is immutable snapshots plus versioned definition rules plus a stored link from every published number to both. A developer who answers with a nightly ETL into a star schema has described a data warehouse, which is necessary and not sufficient, and the difference will cost you the first time a trustee asks a question.

Ask whether they will write regression tests against your previously submitted figures. If they have not thought about testing historical outputs, they will break a published number during a refactor and nobody will notice until it matters.

Ask which SIS they have extracted from and how they handled effective dating. Banner, Colleague, PeopleSoft Campus Solutions and Workday Student each carry history differently, and the person who has done this will immediately start talking about which tables lack proper effective dates. That instinct is the qualification.

Ask who owns the code, the snapshots and the warehouse, in writing, before kickoff. You should own the repository, the cloud accounts, and the right to hire anyone else to continue. At Digital Heroes the client owns the code from the first commit. Your official numbers are institutional memory, and institutional memory should not live in a vendor's account.