International Student SEVIS Compliance Software: Why a Rejected Batch Record Sits Unnoticed Until the Site Visit

Why the risk here is different from every other campus system

Most administrative software fails in ways that cost money or time. This one fails in a way that costs an institution its Student and Exchange Visitor Program certification, and with it the ability to enrol F and J students. That is a revenue line most universities cannot replace, and it is why the international student and scholar services office behaves differently from every other office on campus.

The failure mode is not dramatic. A batch of records goes to SEVIS overnight. Eleven come back with errors, in a result file that nobody opens because the process was set up years ago by someone who has since left, and the person running it now believes that no news is good news. Six months later, a site visit asks why forty two students were never registered for the term. Nobody was negligent. The loop was never closed.

In our experience with institutions in this space, the underlying problem is almost always the same. SEVIS work is submission plus reconciliation, and most implementations treat it as submission. The government's system is the record of truth, your system holds what you believe, and any difference between them is a compliance gap that grows silently. Everything else, the advising, the e forms, the document generation, is comfort. The reconciliation is the job.

Problem 1: batch reporting without a result loop is a liability

The SEVIS batch interface accepts an XML submission and returns a result identifying which records were accepted and which were rejected, with error codes. That is a well designed contract and it works. What institutions build around it varies enormously.

A serious implementation treats every submitted event as an outstanding obligation until SEVIS confirms it. Each event carries a state: queued, submitted, accepted, rejected with a code, corrected and resubmitted. Rejections are triaged automatically where the cause is mechanical and routed to a named adviser where judgement is required, with an ageing clock, because an unresolved rejection is a reportable event that did not happen. There is a daily reconciliation that compares your record set to what SEVIS holds and surfaces divergence rather than assuming agreement. And there is an alarm when a batch does not run at all, which is the single most common failure we find when we inherit these systems, since a silent scheduler is indistinguishable from a clean night.

The schema also changes on the government's timetable, not yours. Any build must treat schema version as configuration with a validation layer that fails loudly against the current version before submission, rather than discovering an incompatibility from a rejection file after the deadline has passed.

Problem 2: enrolment truth lives in the student information system, and it moves daily

Term registration reporting requires knowing who is actually enrolled, at what load, with which exceptions authorised. Full course of study rules, the limits on online study, authorised reduced course loads for medical or academic reasons, programme extensions and level changes all determine what should be reported and when. That data lives in Banner, PeopleSoft, Workday or Colleague, and it changes throughout add and drop.

The pattern that fails is an export at a point in time. A student drops below full time on the last day of the add and drop period, after the export, and the record reported to SEVIS says something that is no longer true. The pattern that works is a continuous read with rules evaluated as data changes, so a student falling below the threshold generates an adviser task the same day and a reportable event only after the adviser has determined whether an authorisation applies.

This integration is where most of the real engineering sits. It is also where local rules concentrate: how your institution defines full time for a thesis student, how a graduate assistantship counts, how your medical school's block scheduling maps to credits, how a consortium or cross registration arrangement is treated. Packaged products handle the common cases well and are configured against a model. Institutions whose academic structures do not fit that model end up maintaining a spreadsheet of exceptions, which is the signal that a build might be warranted.

Problem 3: practical training is a case type, not a form

Curricular and optional practical training bring workflow that continues long after the recommendation is made. A curricular training authorisation ties to a specific course, employer and date range. Post completion optional practical training brings an unemployment day count that the student must manage and the institution should be watching, employer reporting obligations, and for eligible students a science and technology extension with its own reporting cycle and employer requirements.

Students in this phase have often left campus, which means the interface they use has to work on a phone, send reminders that land, and accept employer details without an adviser retyping them. The office needs a view of who is approaching a threshold, not a list of everyone. Institutions that do this badly discover the problem when a student's status is terminated for something that a reminder would have prevented, and the human cost of that is the reason experienced advisers are so protective of their processes.

A build should treat each of these as a case type with its own required evidence, its own clocks and its own reportable events, all feeding the same batch pipeline. If practical training is modelled as a form that produces a document, the tracking will fall to a spreadsheet within a year.

Problem 4: exchange visitors are a different programme with different obligations

J category exchange visitors are not F students with a different form. The programme has its own categories with their own duration rules, insurance requirements set by the Department of State that the sponsor must verify and monitor, site of activity reporting, and the home residency requirement that affects a visitor's future options and therefore every conversation you have with them.

At many institutions the J population is administered partly outside the international office, particularly research scholars sponsored through a medical centre, a national laboratory relationship or a research administration unit. That split is where records diverge, and it is one of the clearest cases for a custom build, because the requirement is a single compliance picture across units whose processes and staffing are genuinely different rather than accidentally different.

Problem 5: advising volume is the daily reality and the reason staff resist change

An office serving several thousand students runs on e forms and case queues: travel signature requests, programme extensions, change of level, reduced course load petitions, transfer out requests, employment questions, letters for driving licences and social security applications. Hundreds of case types, each with required documents and an approval path.

This is the part packaged systems do well, and it is worth being honest about that. Sunapsis in particular was built inside a large university's international office and it shows in the workflow design. If your advising process is conventional, replicating it from scratch is an expensive way to reach a similar place. The build case is not that you can design better forms. It is that your compliance and enrolment logic is genuinely local, or that your organisational structure spans SEVIS school codes and units in a way the product cannot represent, and that the advising layer has to sit on top of that model rather than beside it.

What this costs and how long it takes

A first release covering batch submission with full result reconciliation and alerting, term registration driven by continuous enrolment reads, document issuance and the core reportable events runs $70,000 to $150,000 and ships in 12 to 18 weeks. A full platform adding advising case types and student e forms, practical training workflows with post completion tracking, exchange visitor management including insurance verification, and audit and site visit reporting runs $180,000 to $400,000 phased over 6 to 12 months.

What drives cost up: the number of SEVIS school codes and campuses, since each carries its own officials and its own reporting. Student information system integration depth, which is the largest single line and is different for Banner, PeopleSoft, Workday and Colleague. Local academic structures that complicate full course of study determination, such as medical and law programmes or block scheduling. A separate exchange visitor administration unit that must be brought into one picture. Single sign on and the security review your information security office will require. And accessibility conformance, which belongs in the build rather than in remediation.

What keeps it down: implementing the reconciliation loop and registration reporting first, keeping your existing e form process for a phase, and migrating advising workflows once compliance is provably solid.

Build versus buy, and when buying is the right call

We say buy more often in this category than in almost any other we write about. If you are a single campus with one SEVIS school code, conventional academic structures and an international office running standard advising, Sunapsis or Terra Dotta ISSS is the right decision. They encode years of compliance detail, they track regulatory change as part of the product, and the downside of a home grown gap is certification risk rather than an inconvenience. Buy also if your office is short staffed, because a build needs your most experienced adviser's attention for weeks and taking that person off the queue has its own compliance cost.

Build when two or more of these are true. You operate several SEVIS school codes across campuses and need one compliance picture with per code separation. Your exchange visitor population is administered by a medical centre or research office outside the international office and the records already diverge. Your academic structures require so many exceptions to the packaged registration logic that staff maintain a parallel spreadsheet. You need workflows and data joined to systems the product does not integrate with, for example a research administration platform or a payroll system for on campus employment. Or you have inherited an existing custom system that works but has no reconciliation loop, which is a rebuild of a specific part rather than a whole platform and is the most common engagement we see here.

How to choose a developer for SEVIS compliance software

Ask them what happens when a batch record is rejected at 2am. The answer must include a state machine per event, automatic triage of mechanical errors, routing of judgement cases to a named adviser with an ageing clock, and an alarm when the batch did not run at all. If they describe submitting a file and logging the response, they will build the exact failure this office fears.

Ask how they will keep enrolment current. A nightly export is not an answer for add and drop week. A continuous read with rules evaluated on change is.

Ask what they have integrated by name, and be specific about your student information system and its version. Ask whether they have worked with a regulated government interface where the schema changes on someone else's timetable, and how they version and validate against it before submission rather than after rejection.

Ask who owns the code and settle it in writing before kickoff. You should hold the repository, the cloud accounts and the right to hire another firm, and given that this system holds immigration records for your students, encryption, role based access and retention should be settled in the same conversation. At Digital Heroes the client owns the code from the first commit. Then ask the developer directly whether they think you should build at all. In this category, a firm willing to tell you to buy Sunapsis is a firm worth hiring for the parts you genuinely need.