Ohio State walked away from being an early Workday Student adopter after spending into the tens of millions. A large public research university's finance go-live left hundreds of research awards stuck in processing and its own research leadership warning in writing about "audit risks and compliance violations." One private university's Student program landed at more than $265 million over 7 years. Another pushed its go-live a full year, entirely because financial aid was more complex than the plan assumed. The pattern in the EDUCAUSE data is the same: the student module is the least-adopted, least-mature leg of the ERP.
None of that is a Workday-versus-anyone argument. It is that grants and student carry compliance obligations, seasonal deadlines, and cross-module seams that HCM and Financials do not. This is the tactical version. How the grant object model actually works, where the Foundation Data Model (FDM) decides your grants accounting before anyone configures an award, why the payroll-to-grants seam produces most audit findings, why Student deploys in waves over years, and what the institutions that landed it did differently. Written from the seat that owns the outcome, not the seat that sells the software.
HCM and Financials replace systems you already understand. Grants and Student replace a federal compliance regime and an academic calendar you cannot move. A configuration mistake here surfaces as an audit finding, a Title IV problem, or a researcher who cannot spend their award. Plan these two as the risk, not the tail end of the program.
1. Why Grants and Student Are the Hard Modules
Three things make these two different. First, they carry outside obligations. A grant is a contract with a sponsor and a federal compliance regime behind it; a student record feeds financial aid rules and federal reporting. Second, Student runs on an immovable annual clock. Every institution needs the same registration and aid windows, so deployment and product resources are contended for at the same time of year, which is why Workday Student go-lives roll across a full academic year. Third, the unified data model exposes bad data instead of hiding it. There is no nightly interface between a grants system and the ledger because there is no separate grants system, so a legacy problem that used to sit quietly in one silo now posts live across the institution.
Staff grants and student as their own workstreams with their own leads, their own data conversion, and their own go/no-go, from day one. Folding them into "Finance" and "HR" is how they arrive at go-live under-tested.
The research enterprise is a fifth of the budget and most of the risk. On the programs that struggled publicly, research was a small share of headcount but a large share of the exposure. At one large public university, research covered close to a fifth of a roughly $10 billion budget, and it was the sponsored-research processes, not payroll or the general ledger, where the go-live pain concentrated. Size the grants workstream to the risk it carries, not to its share of transactions.
2. Grants Are Objects, Not Projects
Systems built on a project foundation bolt grants on top and lose the nuances: sponsor types, grant hierarchies, multi-source billing. Workday models the grant as a first-class object so it can carry those natively. The structure that trips people up: an award is the versioned contract with the sponsor, and it holds one or more award lines. The attributes on the line, not the header, drive costing, revenue recognition, and how you bill the sponsor. Three line types set everything downstream. Cost reimbursable bills off actual posted expense and recognizes revenue as cost is incurred. Fixed amount bills on an installment schedule. Prepaid takes a sponsor advance and tracks the balance down. Pick the wrong line type and you have locked in the wrong revenue timing for the life of the award, and unwinding it means amendments.
The grant itself is the FDM worktag that carries the money and the accounting, and a single grant can sit in more than one hierarchy at once, a department rollup and a sponsored-programs rollup, so the college and the research office each get the view they need. Closeout has teeth: once an award line moves to closeout in progress, Workday blocks new expense from posting, which is exactly what you want and also exactly what strands a late invoice on unrestricted funds if departments were not trained on the cutoff.
Make award-line-type selection a sponsored-programs decision with a review step, not a default a setup analyst picks. It is the single choice that fixes billing and revenue for the whole award.
3. The FDM Decides Grants Before You Configure Anything
The FDM replaces a segmented chart of accounts with worktags. You choose a driver worktag, grant, gift, project, and related worktags auto-populate: fund, function, class, program. For a grant, selecting the grant driver should pull the restricted sponsored fund, the organized-research function, and the funding-source class automatically, so a principal investigator (PI) or a department cannot hand-pick the wrong fund. The design mistakes are predictable. Replicating the legacy chart of accounts as hundreds of worktag values. Function coding that does not cleanly separate organized research from instruction, which corrupts the F&A rate proposal later. Failing to plan the two grant hierarchies. And company-versus-worktag mismatches where an expense booked to a different company than the award line simply drops off the sponsor invoice until someone moves it.
Treat the account posting rule set and the grant-to-fund defaulting as controlled configuration, not setup-and-forget. Stand up a standing fund-mismatch exception report so a silent mis-post surfaces within a pay cycle instead of at audit.
The grants model is a Phase 0 deliverable, due before the build. On a recent academic-medical-center deployment, the grants worktag structure was a Phase 0 design deliverable with a hard multi-week deadline, finished before anyone configured a single award, because the entire finance tenant was built off it. Every grant transaction then carried the same bundle: company, cost center, ledger account, program, project, grant, spend category, location. The grant was one worktag inside that bundle. The teams that treated the FDM as the real grants project, and not as a data-entry step before the fun configuration, were the ones whose grant reporting worked on day one.
4. Indirect Cost and F&A: Where the Money Leaks
Facilities and Administrative recovery, Workday's term for indirect cost, is governed by federal cost principles, and Workday calculates and posts it automatically off the award line's rate agreement. The engine is only as good as the base. Indirect cost is charged as a percentage of Modified Total Direct Cost, and that base excludes capital equipment, participant support, patient care, rental of space, scholarships and fellowships, tuition remission, and the portion of each subaward over 25,000 dollars. If equipment, tuition remission, patient care, or that first-25,000-per-subaward rule are not flagged as non-overhead-bearing, Workday burdens them with F&A and over-bills the sponsor, a classic exception. The money at stake is real: universities recover only 25 to 30% of a project's total cost through their negotiated rate, and reported a 6.8 billion dollar under-recovery of indirect cost in a single year. A misconfigured base compounds an already thin recovery.
Test the F&A base against real award data before go-live: run equipment, tuition remission, patient care, and an over-25,000 subaward through the engine and confirm each is excluded. This is a 2-hour test that prevents a multi-year billing exception.
5. Seam One: Grants to Financials
Users never pick a ledger account. They pick worktags, and the account posting rule set maps the grant worktag bundle to the ledger behind the scenes. Because the grant shares the FDM with core Financials, sponsor billing, receivables, deferred revenue, and revenue recognition all run natively on the award instead of in a separate subledger you interface nightly. The benefit is that there is no interface-reconciliation class of failure. The cost is that a bad rule-set entry posts with no error. On a real go-live, salary-cap transactions posted to grant-related funds when they should have posted to an institutional fund, a posting-rule defect that required an exception report and mass correction, not a user fix.
No interface means no safety net. The teams that came from a bolt-on grants system kept looking for the nightly reconciliation between grants and the general ledger. There is not one, because there is not a separate grants ledger. That removes a whole class of interface failures and replaces it with a configuration-and-governance discipline: the posting rules ARE the reconciliation, so they have to be owned, change-controlled, and monitored like a financial control, not tuned once and forgotten.
6. Seam Two: Grants to HCM and Payroll, the Audit Seam
Salary is the largest cost on most awards, and it flows from HCM appointments through payroll costing onto grant worktags. Effort certification is generated from that payroll distribution. The control object is the Payroll Costing Allocation, which says which grants a worker's salary charges, in what proportion, with effective dates. For an NIH award, Workday auto-splits pay above the salary cap onto a cost-share fund. The effort statement is only a mirror of payroll; if actual effort differs from payroll distribution, commonly by more than a five-percent institutional tolerance, the department must run a Payroll Accounting Adjustment to move the charge before it can certify.
"We are concerned about the potential for unanticipated costs, lost opportunities, audit risks and compliance violations."
That sentence was not written by a critic or a consultant. It was written by the institution's own research leadership, about its own system. This seam is the reason.
Where it breaks is well documented from an institution's own published defect notes. Retro pay posts to the current costing allocation, not the allocation in effect for the retro period, which undercharges the grants that should have carried the cost. The salary-cap engine misfires on non-standard pay. Mixing up the correction tools, a Payroll Accounting Adjustment versus a funding transfer, creates a second problem on top of the first. All of this matters because late cost transfers are the number-one audit theme, the 90-day standard is what auditors use, and "staff shortages" is explicitly an unallowable justification for a late transfer. A slow award-setup backlog after go-live manufactures exactly those late transfers. The consequence is on the record: one health science center paid $13 million to settle a False Claims Act case rooted in inaccurate effort tracking and inadequate internal controls.
Do not trust the effort statement as generated. Before you open the certification window, run payroll-costing-versus-actual and salary-cap exception reports, clear the adjustments, and standardize the correction tool by defect type. The certification cycle should confirm a reconciliation that already happened, not be the first time payroll gets corrected.
7. Foundation Funds Are Not Sponsored Grants
At research institutions and academic medical centers, money arrives two ways that look similar and behave oppositely. A gift is a donation with no performance obligation; contribution revenue is recognized when the unconditional promise is made. A sponsored grant carries a performance obligation; when it is conditional or a reimbursement, revenue is recognized only as it is earned, often only after the expense is incurred, and unearned money goes back to the sponsor. These are different worktags with different funds and different revenue rules.
A hard line drawn in the design, not the cleanup. On a health-system finance build, the team drew the gift-versus-grant line during FDM design, on purpose, because the two recognize revenue on opposite principles. Foundation gifts were unconditional transfers; sponsored grants, most of them research, carried conditions and reimbursement mechanics where revenue could not be recognized until it was earned. Drawing that line up front kept restricted-fund reporting clean. Institutions that discover the distinction during year-end close instead spend the close reclassifying revenue.
8. Student deploys in waves because the academic calendar says so
Student is not one go-live. It is a sequence of switches thrown as the academic calendar needs them, across successive terms and usually multiple years. Workday Student spans six areas: admissions, curriculum and the academic foundation, student records, advising, student financials, and financial aid. The foundation layer, academic structure, programs, calendars, and eligibility, supports everything else, so it goes first. Then records and registration, then student financials, then aid, each lit up as the term needs it. The reasons are structural: the annual clock means every institution needs the same windows at once, the scope is enormous, and institutions do this once in 20 to 25 years with no internal muscle memory. You cannot register students before the catalog exists or bill them before they register.
Sequence Student go-lives to the academic calendar, not to a project milestone chart. Light up the academic foundation and records first, prove registration on a real term, and hold financial aid until it is genuinely ready. Forcing a term boundary before you are ready is how a slip becomes a crisis.
9. Switching the student system of record has no quiet weekend
Switching the student system of record off a legacy Student Information System (SIS) is a phased, term-by-term handoff, not a clean swap. The legacy SIS stays the system of record for prior terms while Workday becomes the system of record for new terms, so a single student's record is split across two systems by term, with a formal coexistence period where both run live. Historical conversion is selective by design: institutions convert active students and a few years of history, migrate a defined historical academic record, and leave classes of legacy data out of Workday entirely, served instead from a data platform. Expect to keep the legacy system alive for historical corrections for years, not to do a one-time load.
The active-versus-historical cutline is a real decision, usually enrolled-now or within the prior few years, and it drives conversion volume and cost. And financial aid is the repeat offender. One university pushed its go-live a full year at the aid checkpoint, after roughly $14 million and two and a half years, because its aid rules were more complex than the plan assumed. Another kept its legacy aid engine running alongside Workday. Registration is where hidden policy complexity surfaces first, which is why the institutions that did well ran a full mock registration term before going live.
Define the active-versus-historical cutline early, plan to serve historical records from a data platform rather than converting everything, and treat financial aid as its own gated milestone that can slip without moving records and registration. Never let aid drag the whole go-live past a term boundary.
10. Seams Three and Four: Student to Financials, HCM, and Reporting
Student to Financials. Tuition, fees, aid disbursements, waivers, and refunds post to the general ledger automatically, with a revenue category worktag required on every revenue line driving the ledger account. Map it wrong and you get a compliance problem: at one institution, tuition and fees charged to sponsored awards posted as scholarships at go-live, a classification that did not comply with federal and institutional grant rules. Even with auto-posting, the student receivable subledger has to tie to the ledger control account, and misconfigured charge, waiver, or refund rules make it diverge and stall the close.
Student to HCM and Reporting. One person, one record. A student who works in the library, a grad student on a research appointment, a faculty member who advises, are one Workday record with multiple roles, not duplicate records stitched by an interface. The payoff and the risk are the same fact: a change is visible everywhere immediately, so a role or status collision, an HR termination that disagrees with an enrollment, corrupts payroll and enrollment reporting at once. Faculty appointment data in HCM also drives PI eligibility and effort, so the seams compound. And institutional reporting forces the join: a single IPEDS submission pulls enrollment, human resources, and finance from one model, so census dates have to be defined consistently across Student, HCM, and Finance or the counts do not tie.
Govern the revenue-category catalog jointly across Student Financials, Sponsored Programs, and the Controller before go-live, and test the sponsored-tuition path specifically. Stand up a person-data governance body that owns the shared-record rules, source of truth per attribute, duplicate prevention, role lifecycle, because in a one-record model that is a data-integrity control, not a nicety.
11. The published retrospectives converge on governance, not software
The published retrospectives converge. ERP in higher education cannot just be an IT project, and success turns on change management and staffing, not the software. The institutions that recovered or avoided the crisis did five things. They treated grants configuration as its own workstream and validated award lines, F&A exclusions, the salary-cap split, and the effort loop with real data, not just headers. They staffed for the post-go-live award-setup surge, because the single most damaging grants failure at the hardest go-live was a months-long setup backlog that both froze research spending and manufactured late cost transfers. They kept faculty able to see their own grant balances, since a PI who cannot see burn rate cannot manage the award. They caught readiness at the go-live gate rather than pushing through it: one large university paused its student cutover days before the first release when campus was not ready, and ran the next terms on the legacy system rather than force it. And they set the expectation that go-live is the beginning of stabilization, standing up dashboards and a real faculty escalation path for the weeks after.
Before go-live, ask the two questions that predict the outcome. Can a PI see their own grant balance on day one, and is there a staffed plan for the award-setup surge in the first 90 days. If either answer is no, you are buying an audit finding.
The rest of the ERP is a known quantity. Grants and student are where the compliance regime, the academic clock, and the module seams all meet, and they are where the public failures happened. None of those failures were really about the software.
Land the Two Modules That Decide the Program
Design the grant worktags before you configure an award. Prove the F&A base and the effort loop with real data. Sequence Student to the calendar and let aid slip on its own. Keep faculty able to see their money, and staff the surge that follows go-live. Do those, and grants and student stop being the modules that stall the program and become the ones that prove it.
Related: Finance ERP modules, HCM and HR modules, Payroll modules, and Data conversion and integrations. See also The cutover playbook.