Custom student information system for higher education
In higher education, the student information system is the register where four things come together that elsewhere in the institution are managed separately: who is enrolled, which programme that student is following, which credits have been earned, and which certificate follows from them. Everything around it relies on it. The learning environment pulls groups from it, timetabling pulls enrolments on teaching units from it, financial administration derives tuition fees from it, and the national registers expect a periodic return from it. If there is an error in the register, that error travels on to the diploma supplement and to the funding data. Appfront builds custom software around that core: additional registration where the package falls short, integrations with Studielink and DUO, portals for students and lecturers, and the calculation rules that turn individual results into a graduation decision. For universities of applied sciences, research universities, non-publicly funded providers of higher education, and partnerships that offer programmes across institutions.
The core register of a university of applied sciences or university
A student information system, usually abbreviated to SIS in the sector, is the administrative core of a higher education institution. It keeps track of the person, their enrolment on a programme, the course units that belong to that programme, the study credits earned, and the final certificate. That sounds like four records, but it is really one: a result only has meaning within a course unit, a course unit only within a programme of a particular cohort, and a programme only within an enrolment that was valid at the time the examination was taken. That chain is exactly what a spreadsheet or a standalone assessment application fails to hold together.
What distinguishes higher education from other education sectors is that the student has control over their own programme. They choose electives, take a minor at another faculty, spend a semester abroad, apply for an exemption, switch to a related programme and bring credits earned along the way. Each of these steps changes the set of requirements they must meet to graduate, while the requirements themselves are set out per cohort and per academic year in the programme and examination regulations. A SIS that does not model this as data moves the calculation work to the study advisers and the risk to the examination board.
The second characteristic is that administration has to reach outside the institution. In the Netherlands, applications and enrolment run through Studielink, programmes only exist once they are listed in the national register of accredited programmes, enrolments and diplomas are reported to the DUO register, and that reporting underpins funding. A system that is internally consistent but does not keep this chain up to date is not finished.
You only notice what this means in practice when something goes wrong. A student enrolled in the wrong variant is not placed in the right group in the learning environment and is missing from the exam participant list. A course unit with an incorrect number of credits produces a transcript that does not match the diploma supplement. An enrolment that was wrong on the reference date resurfaces in the check on funding data. These are all consequences of the same thing: there is one register that the rest of the institution relies on, and that register must be explainable, not just populated.
Are you in the right place? This page is about HBO and university education, and about student administration as the core register. If you are looking for a system to track the development of individual pupils, with observations, support agreements and parent communication in primary and secondary education, you want a student monitoring system. If you are concerned with the wider operations of an institution, including timetabling logistics, staff, procurement and the data behind funding, then education ERP is the broader starting point. Within that, the SIS is one register in a larger landscape; here, it is the subject.
One person, multiple enrolments
The same student can have a bachelor's, a pre-master's and contract education running side by side. The record follows the person, while the entitlements follow the enrolment.
The programme differs per cohort
The 2023 requirements apply to the 2023 cohort. A curriculum change must not quietly move current students onto a different programme.
The diploma is a decision, not a document
The examination board determines the result. The system must support that determination and keep it traceable, years later too.
Enrolment and admission, where the record begins
Applying for a bachelor's or master's degree in Dutch higher education goes through Studielink. The student submits their enrolment request there, and the institution receives that request in its own system, enriches it, and sends statuses back. That sounds like an integration and in practice is a process: an application is not a snapshot but a file that keeps moving for a long time. The student changes their chosen programme, withdraws their request and applies again, supplies their prior education details later, chooses a different start date, or turns out on closer inspection not to be eligible. Each of those events arrives as a message, in an order that is not guaranteed and sometimes with retrospective effect.
That is why the first design question is not which fields you store, but how you handle that stream of events. A system that overwrites an enrolment with the latest status loses the reason a status changed. A system that records every event and derives the current state from them can later explain why this student counted on 1 October and that one did not. The difference is not theoretical: the data underpinning funding is checked every year, and you must be able to show, per enrolment, which conditions were met at what point. Recording that a payment was received is not enough; you must be able to demonstrate that it was on time and which tuition fee category applied.
On the identity side there is a second requirement. An institution registers the student under a personal identification number, usually the citizen service number (BSN) and otherwise an education number for those who do not have one. That number enables exchange with national registers and is at the same time the most sensitive field in the entire file: it may only be used where the law permits, it should not serve as a search key in an internal portal, and it has no place in an export file sent to a dashboard provider. Alongside that number lives the institution's own student number, and the two must remain strictly separated in their function.
Enrolment then determines the tuition fee, and that is not an amount you enter but an outcome of rules. Which tuition fee category someone owes follows from criteria relating to nationality and residence status, and to whether they have previously obtained a degree of the same type. For certain first-year students, a reduction also applies. This means the system must derive the category, record the criteria used, and be able to recalculate when personal details change, because a nationality detail that is later corrected changes the basis retroactively. In addition, enrolment in higher education is per academic year: re-enrolment is required, and a student who deregisters mid-year loses, from the end date, the right to sit examinations. These are also data that go outward, since deregistration affects the student's study finance.
Admission is a decision with a burden of proof
Enrolment is only possible once eligibility is established, and that assessment differs per admission route. For the student progressing from secondary education, it concerns the type of diploma, the profile and sometimes additional subject requirements set per programme; a missing subject is then a deficiency that must be remedied before the start. For the lateral entrant with a foreign diploma, it concerns an evaluation of that diploma and a language test. For those who lack the required prior education and are twenty-one or older, there is the admission-examination route. For the master's applicant, it concerns whether their bachelor's degree grants access, with or without a pre-master programme and under which conditions. Programmes with a limited number of places add a selection procedure, with rank numbers, placement rounds and filling places that become available when someone withdraws.
These are not variations of the same form. They are different decisions with different supporting documents, different decision-makers and different deadlines. What custom software adds here is that the decision itself becomes an object: which requirement was assessed, on the basis of which document, by whom, with what outcome and under which condition. Without that record, the admission decision lives in a mailbox and the student administration has to reconstruct what was agreed every time there is an objection. With it, applicants can see in their own portal what is still expected of them, which is exactly the question that causes most phone calls.
Study programme and curriculum as a data model
This is where the hardest part of a student information system sits, and the part that is most often only half solved in practice. A degree programme is not a single list of subjects. It is a recognised programme with a form, full-time, part-time or dual, with possible specialisations, a curriculum that differs by cohort, and requirements set out in the education and examination regulations for that academic year. Beneath that sit teaching units with a study load, an assessment format and sometimes partial assessments that together make up one result. Alongside them is free space that the student fills in themselves, such as a minor at another faculty or teaching at another institution.
Anyone who models this as a flat list of subjects runs into three predictable problems. A curriculum change affects students who started under the old regulations. A discontinued teaching unit makes points already earned worthless unless someone records what replaced it. And the question of whether someone can graduate can no longer be answered without manual work, because the requirements are in a PDF and the results are in a database. The regulations for the year should therefore exist as data, not only as a document, with a validity period and a reference to the adopted text.
That same structure is also what the rest of the landscape needs. The digital learning environment wants groups and participants per teaching unit, the timetabling system wants to know how many students have enrolled, and the assessment office wants to know who is eligible at each assessment point. They should all take that from the core register, not from their own copy that quietly drifts out of step.
Beneath the curriculum sits a separate process: enrolling students on teaching units and assessment moments. That involves capacity limits, priority rules for students for whom the unit is compulsory, enrolment periods that open and close, and the question of what happens if someone withdraws too late. The same applies to assessments: who is eligible, how many attempts someone has already used, and whether a condition applies that must be met first. This is precisely where administration and teaching meet, and where a system that only records what has already happened lets the organisation down.
Degree programme, variant and cohort
The recognised degree programme with its form and specialisations, and beneath it, per intake year, the curriculum that applies to that cohort.
Teaching unit and study load
Study points, assessment format and partial assessments that together lead to one result, with the weighting by which that result is determined.
Elective space and minors
Free space that the student fills in, including teaching from another faculty or institution, which is nevertheless checked against the requirements.
Entry requirements and assessment conditions
Conditions for being allowed to take part in a unit or an assessment, checked at enrolment rather than afterwards.
Transitional arrangements
When the curriculum changes, recording which old unit is replaced by which new one, so that points already earned continue to count.
Learning outcomes and microcredentials
Flexible part-time education describes units as learning outcomes, and shorter modules lead to a recognised certificate alongside the degree.
ECTS and result registration
The European Credit Transfer System gives higher education a common unit of account: a full academic year stands for sixty study points, and under Dutch law one study point equals twenty-eight hours of study load. A university of applied sciences bachelor's comprises two hundred and forty points, a research university bachelor's one hundred and eighty, and a master's sixty or more. That unit makes study load comparable between institutions and between countries, which is exactly why it cannot be free-text entry in the administration. Points are not awarded for effort but for a passed teaching unit, so the question is not how many points someone has, but on the basis of which result.
This is where the real work begins. A result for a course unit often arises from weighted partial assessments, sometimes with a minimum requirement per component that the weighting may not compensate for. The rounding rule varies by programme: to the nearest half, to the nearest whole number, or no rounding below a certain threshold. For a resit, the regulations determine whether the highest or the most recent result applies. An exemption is not a grade, but it is a reason to award credits, and so it counts towards the credit totals and not towards the average. Results may have a validity period, and an expired result must visibly expire rather than quietly disappear. Each of these rules is set per programme, and every rule that is not in the system is carried out by a staff member with a calculator.
The weighted average is the underestimated component. It is used for admission to a master's programme, for a progression decision and for selection within the institution, and almost every programme calculates it slightly differently: weighted or unweighted by study credits, with or without exemptions, with or without the unsuccessful attempt of a resit. As long as that average is calculated in a spreadsheet, it is a decision without traceability. In the register it should be a computed value with a readable explanation: which results were included, with which weighting, and which rule was applied.
Data entry has its own standards of rigour. Grades often arrive in bulk from a learning environment or from an assessment and examination platform, which is fine as long as the core register remains the established record. Who may enter a result, who may publish it and who may still change it after publication are three distinct authorisations. A change after publication should carry a reason, a decision-maker and a timestamp, because that is the audit trail a student, an examination board or an auditor will rely on years later. Recording fraud or an irregularity belongs in a separate, restricted part of the file, kept apart from the ordinary transcript.
The same data feeds study progress monitoring, a second application with its own requirements. First-year students receive advice on continuing their studies based on the credits they have earned at a given point, and that advice is a decision with consequences. It should therefore be calculated reproducibly, with a fixed reference date, with a record of the warnings that preceded it and with room to take personal circumstances into account. The study adviser also needs a picture that goes beyond a credit total: which components are missing, which agreements have been made and which adjustments apply. And the student wants to see in their own portal how they stand against their programme, not against an average.
This is precisely where the file becomes sensitive. A request for an accommodation due to a disability, a meeting with the student dean, a payment arrears or a fraud case are not data that belong on the general student screen. They sit behind a separate authorisation, with a record of who has viewed them. Authorisation in a student information system is therefore rarely a simple role: an examiner sees their own course units, a study adviser their own programme, an administrative staff member a faculty, and a decentralised administrator may configure the system but not view its contents. Retention periods also differ by type of data, which means that clean-up should be a built-in function rather than an annual manual task. The same rule applies to test and acceptance environments: real student data should not be held there.
- Weighting of partial assessments with a minimum requirement per component
- Rounding rules per programme, held in the system and not in someone's head
- Highest or most recent attempt, according to that year's regulations
- Exemptions as a reason for credits, with a dedicated code
- Validity period of results visible, not discarded
- Weighted average as a calculated value with an explanatory note
- Entry, publication and amendment as separate permissions
- Every change after publication recorded with reason, decision-maker and time
Test your idea first: a working prototype in 1 day
With OneDayBuild, we turn your idea into something tangible in one day for €1,150, so you can see whether further development is worth the investment. Decide to go ahead with the full build? Then we credit the full cost.
Explore OneDayBuild →From results to a certificate
In higher education, a diploma is not a file that comes out of a printer, but the outcome of a decision. The examination board establishes that the examination has been taken, and at that moment a date of result, a degree, possibly a specialisation and possibly a judicium come into being. That decision rests on a check that is far more laborious than it appears: does the set of results obtained meet the requirements of the programme as they applied to this cohort, including the free space, the requirements for the graduation project and the transitional arrangements for mid-course curriculum changes?
Why the graduation check so often remains manual work
Because the requirements are written in a document and the results are held in a system. The regulations state, for example, that the free space must form a coherent whole, that a portion of the credits must be obtained at a certain level, that a minor may not overlap with the compulsory units, and that the graduation project may only begin once a number of components have been completed. As long as nobody records those conditions as rules, a staff member checks them per student against the transcript beside them. That works with dozens of graduates and grinds to a halt with hundreds, precisely in the period when everything has to be done at once.
What custom development delivers here is a check that gives the student and the board the same picture: for each requirement, whether it has been met, with which result, and what is still missing. The outcome is advice, not an automatic decision, because the board retains its own authority and may deviate on grounds of an exemption or a hardship clause. That is precisely why a deviation should also be recorded as a deviation, with who made the decision and on what grounds. A student who disagrees with a decision of the examination board can appeal to the Examinations Appeals Board, and then the question is not what the system calculated but what was decided and why.
A second set of requirements attaches to the certificate itself. A higher education diploma comes with a diploma supplement that explains the programme, the level, the study load in credits and the grading system, so that an employer or a foreign institution can place the document. Anyone who leaves the programme without a diploma is entitled to a statement of the components they did complete. A certificate is in principle issued once, and anyone who has lost their paper obtains not a duplicate but a digital extract from the national diploma register. That means delivery to that register is part of the certification itself and not an administrative afterthought.
Retention is the final piece, and the element most often forgotten in in-house builds. Diploma data must remain findable and verifiable decades later, even if the system that produced it no longer exists. That calls for a readable export format, for signing that remains verifiable, and for an agreement on which data may in fact be deleted. For shorter modules, the digital variant comes into play: a signed certificate that the holder can share themselves and a recipient can verify without phoning the institution.
Exchange with national registers and chain partners
A student administration in higher education never stands alone. At the front end, enrolments come in from Studielink and statuses flow back out to it. An enrolment can only exist on a programme listed in the national register of recognised programmes, under the code assigned to it, and that recognition depends on the programme's accreditation. At the back end, enrolments and diplomas go to DUO's register, where they underpin funding and where the student's study finance relies. An enrolment recorded incorrectly there is not a minor administrative blemish: it affects the institution's funding and the student's money.
Those submissions are not a one-way street. You submit, you receive feedback, and that feedback includes rejections you must put right. Corrections arrive retrospectively, sometimes after a reference date, and then a data point changes that has already been sent in a file. The part that is most often underestimated when building in-house is exactly this: not the sending, but keeping track of what you sent and when, what was accepted, what was rejected, and what has changed since. Without that administration about the administration, every discrepancy becomes a hunt through log files.
Within the education landscape, data exchange works best through an open standard rather than an application-by-application integration. The sector has a shared specification for education data, so a learning environment, a timetabling application, a student app or a dashboard all retrieve the same data in the same way. The same applies to sign-in: federated authentication and an institution-independent identity let a student take a course at another institution without a second account. Anyone offering education across institutions needs that, because an enrolment on a unit elsewhere must come back as a result in your own records. For the learning environment itself, a dedicated integration is often the fastest route, for example an itslearning integration.
International mobility has its own chain. For exchange students, European agreements exist to exchange learning agreements and nominations digitally, and to retrieve results obtained elsewhere in a standardised format rather than from a scanned paper. That saves more than typing: it makes the provenance of a result verifiable at the moment the examination board bases an exemption or an inclusion in the programme on it.
When an off-the-shelf package is the better choice
The Dutch market for student information systems in higher vocational and university education is not an empty space. A small number of mature packages serve the large majority of institutions, and those packages already have the integration with Studielink and the delivery to DUO in place, including tracking changes in legislation and national standards. For an institution following the usual pattern, with cohorts, a regulation per academic year, examinations and graduation per programme, that is the more sensible route. Your effort then shifts from building to configuring, and for a core register that is more honest work than it sounds.
Custom development pays off in fewer situations than vendors suggest, but in clearly identifiable ones. The first is an education model that does not fit the cohort way of thinking: flexible part-time education in which the student enters per learning outcome and sets their own route, or a non-state-funded provider that works with continuous intake instead of academic years. The second is an institution that wants to keep the package as its register but gets stuck on everything around it: the application portal, the support from the study adviser, the graduation check, the reporting to the programme director. Building that layer on the data from the package is often the shortest route to a difference people actually notice. The third is collaboration between institutions, where none of the existing systems owns the process.
There is a downside too. With in-house development, keeping up with changing regulations and national standards falls to your own organisation, and in this chain that is no small item. That is why the middle path is often the best answer: the package remains the source for person, enrolment and result, and the custom development sits in the processes, the portals and the rules that set you apart. We would rather discuss how we weigh that trade-off, and what does and does not belong in custom development, before a tender process begins.
- Message traffic with Studielink, including withdrawals
- Programme codes from the national programme register
- Delivery of enrolments and diplomas to DUO
- Feedback, rejections and recovery as a process of their own
- Corrections with retroactive effect from a reference date
- Open standard for education data across the landscape
- Federated login and an institution-independent identity
- European exchange for mobility and achieved results
Frequently asked questions about a student information system
The student information system is the register: person, enrolment, programme, result and diploma. The digital learning environment is where the teaching itself takes place, with materials, assignments and feedback. Grades often originate in that learning environment or in an assessment platform, but only gain meaning once they have been recorded and published in the core register. The learning environment takes groups and participants from the register; the register does not take its truth from the learning environment. Reverse that division of roles and you end up with two sources showing different grades and no rule for deciding which one applies.
A student tracking system follows the development of individual pupils, with observations, support agreements and communication with parents, and is mainly suited to primary and secondary education. An education ERP covers the broad operations of an institution, so also timetabling logistics, staff, procurement and the data underlying funding. A student information system for higher education sits between them as the core register: enrolment, curriculum, credits and diplomas, with the exchange to Studielink and DUO. In a wider landscape, that register is the source on which the other systems rely.
Any institution offering publicly funded higher education in the Netherlands receives applications and enrolments via Studielink, and delivers enrolments and diplomas to the register at DUO. That exchange is not a one-off import but an ongoing process of messages, statuses, feedback and rejections that must be corrected. The hardest part is not sending, but keeping track of what you delivered and when, what was accepted, and what has changed since. For corrections that are backdated across a reference date, you must be able to explain that later.
A full academic year is worth sixty credits (studiepunten), and under Dutch law one credit equals twenty-eight hours of study load. Credits therefore belong to a completed course unit, not to a student as a loose number. The model needs to handle weighted partial assessments, rounding rules per programme, the choice between highest and most recent attempt, exemptions as a result type of their own, and a validity period after which a result can lapse. The weighted average should also be a calculated value, with an explanation of which results were included and with what weighting.
Entering, publishing and changing after publication are three different authorities, and a system should treat them as such. For the examiner, entering and publishing are routine work; a change after that touches a finalised result and therefore needs a reason, a decision-maker and a timestamp. The examination board remains authorised to establish the outcome and to deviate from it, for example on the basis of an exemption. That trail is what a student, an examination board or an auditor will rely on years later.
Often, yes, and for many institutions that is the more sensible route. A small number of mature packages serve most of higher education in the Netherlands, with the message exchange with Studielink and delivery to DUO already built in. If your education follows the usual pattern of cohorts, a regulation per academic year and certification per programme, you can buy that off the shelf. Custom development becomes interesting for flexible education built around learning outcomes, for rolling intake without academic years, or where the package works well as a register but the processes around it are the problem.
Related services
Student tracking system
If the question concerns following individual pupils, with observations, support agreements and parent communication in primary and secondary education, you need a custom student tracking system development.
Education ERP
If the question reaches beyond student administration, into timetabling logistics, staff, procurement and the data underpinning funding, then custom education ERP development is the broader starting point.
Examination software
If the bottleneck lies in assessment itself, covering a question bank, delivery, marking and grade boundaries, then custom examination software development is the right page. The result then flows into the core register.
Take a close look at your student administration
Tell us three things: how an application currently moves through your organisation, where the graduation check is still done by hand, and what happens when DUO rejects a delivery. Those three answers usually reveal whether the problem sits in the register itself, in the processes around it, or in the integrations between them. Even if the outcome is that you are better off staying with a package, the conversation gives a sharper picture of what you should and should not have built.