IEP software, built around the rules it has to follow

An Individualized Education Program is a legal document before it is a form in an application. Federal regulation sets what it must contain, when it must exist, who may see it and, from 2027, how accessible the system holding it has to be.

This page is for two buyers: a district whose IEP system cannot hold its process, and an edtech company building a special education product that has to survive procurement. Bles Software builds custom software, AI agents and integrations from Israel for clients in the US, the UK, the EU and Israel. We do not sell an IEP product. We build the one your process needs, or fix the one you own.

What IEP software has to do before it is worth buying or building

Four jobs hide behind the phrase. IEP writing software drafts and edits the plan itself. IEP management software holds the caseload, the team meetings and the dated obligations around them. Progress monitoring records the goal data and turns it into the report a parent receives. Reporting and integration push the result into the student information system and the State extract. Most products are strong at one or two of those and thin on the rest, which is how a district ends up running a platform plus three spreadsheets.

So the useful question is not which IEP software is best, it is which of the four your process breaks on. Hours lost to quarterly reports is a progress data problem, not an editor problem. Missed review and reevaluation dates is a clock problem. An edtech product that stalls in procurement is usually an accessibility and records problem. Each costs a different amount to fix and only one of them is a rewrite. The sections below are the constraints any of the four has to satisfy, taken from the regulation rather than from a feature list.

IEP software for schools, and the three people who have to live with it

IEP software for schools is never bought for one user, whatever the demo shows. The case manager writes and revises plans under time pressure and wants fewer screens between a draft and a signature. The special education director needs the caseload, the dated obligations and the exceptions in one view, because the questions arriving from the State and from parents are about dates and services rather than prose. The records office answers inspection and amendment requests and has to produce a complete, readable history for one child without exporting the whole system. A product strong for the first of those and thin for the other two is why the director and the records office end up working outside it.

Two constraints apply to a school purchase that do not apply to a private buyer. The system has to meet the accessibility requirement in 28 CFR 35.200 by the date set for the district's own population size, and the contract has to put the vendor inside the school official exception at 34 CFR 99.31 rather than leave education records sitting with an ordinary supplier. Both are procurement questions before they are engineering questions, and both are cheaper to satisfy in a system designed for them than to retrofit afterwards. An edtech company selling into districts meets the same two questions from the other side, which is where the procurement stalls we are asked to fix usually begin.

Start from what the regulation says the document must contain

34 CFR 300.320(a) lists what an IEP must include, and it reads like a data model somebody already wrote for you: present levels, measurable annual goals, how progress toward them is measured and reported, the services and program modifications, any non participation with nondisabled children, assessment accommodations, and the projected start date with frequency, location and duration.

Most IEP systems that frustrate their users store that as free text behind a rich editor. Progress reporting then becomes manual work, because a goal that is only prose cannot be measured by the software holding it. Model goals and their measurement method as structured records and the quarterly report writes itself.

What IEP creation software has to produce besides the document

The plan is the visible output and it is not the only one. 34 CFR 300.321(a) sets who must be on the IEP Team: the parents, not less than one regular education teacher of the child if the child is or may be participating in the regular education environment, not less than one special education teacher or, where appropriate, a special education provider, a representative of the public agency who is qualified to provide or supervise specially designed instruction and is knowledgeable about the general education curriculum and the agency's resources, and an individual who can interpret the instructional implications of evaluation results. The parent or the agency may bring others with knowledge of the child, and the child attends whenever appropriate. 34 CFR 300.322 requires that parents be notified early enough to have an opportunity to attend, that the notice state the purpose, time, location and who will attend, and that a meeting held without a parent carry a record of the attempts to arrange one. A system that models the meeting as a roster and a notice, rather than a date on a form, produces that record as a by-product.

Consent is narrower than the habit around it. 34 CFR 300.300(b)(1) requires informed parental consent before the initial provision of special education and related services, a gate on services rather than a signature on every revision. 34 CFR 300.324(a)(6) allows a change to be made by amending the IEP rather than redrafting it, where under 34 CFR 300.324(a)(4) the parent and the agency agree not to convene the Team for it and the Team is informed of the change, and requires that on request a parent be given a revised copy with the amendments incorporated, a version history requirement in everything but name. 34 CFR 300.323(d) requires the plan to be accessible to every teacher and provider responsible for implementing it, each informed of their own responsibilities and of the accommodations it calls for. IEP creation software that stores those three as events rather than fields answers most of an audit by itself.

• The IEP goal bank: measurable annual goals in eight domains
• The IEP accommodations builder: classroom and testing supports
• The IEP meeting agenda builder: a timed agenda per meeting type

Transfers, and the student information system handoff

A student who transfers mid year is where an IEP system shows what it is. Under 34 CFR 300.323(e) a child moving to another public agency in the same State and enrolling in a new school in the same school year must receive services comparable to the previous IEP until the new agency adopts that plan or writes a new one. 34 CFR 300.323(f) is not the same path for a move from another State: comparable services run until the new agency conducts an evaluation, where it decides one is necessary, and then develops and implements a new IEP where appropriate, with no option to adopt the previous one. 34 CFR 300.323(g) binds both offices: the new agency must take reasonable steps to promptly obtain the child's records, the IEP included, and the previous agency must respond promptly.

So the handoff is not an export button. It is handing another agency a complete and readable plan with its history, and taking one in without retyping it, while the student information system stays the record of enrolment. Name that integration surface as a contract and decide per field which side is the source of truth, and the comparable services period stops being a week of forwarded email.

Goal banks, measurable goals and the tracking behind them

Goals are where IEP software is thinnest, and they are also what the regulation is most specific about. 34 CFR 300.320(a) requires measurable annual goals and, in the same list, a description of how progress toward each goal will be measured and when periodic reports will be issued. A goal bank helps a team write faster, and a useful one is standards aligned, editable and owned by the district rather than fixed by a vendor. It does not satisfy the regulation by itself. A goal taken from a bank still has to carry a baseline, a criterion, a measurement method and a schedule, or the system holding it cannot report progress and somebody rebuilds the report by hand in a spreadsheet.

So the useful shape is one record rather than two. Store the goal text, where it came from in the bank, its baseline and its criterion in the same structure as the data collected against it, and the periodic report comes out of data that is already entered. IEP goal tracking then stops being a separate thing to buy and becomes a view of the plan the district already has. That is the part of this work we have built most often, and it is why progress monitoring has a page of its own, linked from the card above, instead of a paragraph here.

The clocks the system should keep, not the staff

Four dated obligations run through every special education office. An initial evaluation must be conducted within 60 days of receiving parental consent, or the timeframe the State sets instead (34 CFR 300.301(c)(1)). An IEP must be in effect for each child at the start of each school year (34 CFR 300.323(a)). The team reviews it not less than annually (34 CFR 300.324(b)(1)(i)). A reevaluation must occur at least once every three years unless the parent and the agency agree it is unnecessary (34 CFR 300.303(b)(2)).

These are cheap to build and expensive to miss. Derive every due date from consent, school year start and the last signed plan, then surface what is at risk this week. Build the exceptions too: the 60 day window does not apply where a parent repeatedly fails to produce the child, or where a child transfers mid evaluation.

FERPA shapes the architecture, including ours

Parents may inspect and review education records (34 CFR 99.10) and ask for an amendment where a record is inaccurate or misleading (34 CFR 99.20), with a hearing if that is refused (34 CFR 99.21). A system that overwrites history in place, or cannot produce a complete readable record for one child on request, makes both rights hard to honour.

The vendor relationship has its own rule. Under 34 CFR 99.31(a)(1)(i)(B) a contractor counts as a school official only where it performs a function the agency would otherwise use employees for, is under the direct control of the agency over the use and maintenance of education records, and is subject to the redisclosure limits in 34 CFR 99.33(a). Read that as a build constraint: scoped and logged access, and development against realistic synthetic records rather than live student data.

Accessibility now has a date on it

The Department of Justice published its Title II web and mobile accessibility rule on 24 April 2024, at 89 FR 31320. It requires public entities to meet WCAG 2.1 Level A and AA for web content and mobile apps they provide, directly or through contractual, licensing or other arrangements. Procurement teams read that last clause twice, because a purchased IEP system is exactly such an arrangement.

The dates then moved. An interim final rule published on 20 April 2026 extended both by a year, and 28 CFR 35.200(b) now reads: 26 April 2027 for a public entity other than a special district government with a total population of 50,000 or more, and 26 April 2028 for an entity under 50,000 or any special district government. For a school district the rule settles its own classification. 28 CFR 35.104 defines a special district government as a public entity other than a county, municipality, township or independent school district, so an independent school district is not one, and the same section sets a district's total population from the Census Bureau's most recent Small Area Income and Poverty Estimates. Look that figure up before assuming the later date, because a district at 50,000 or more is on April 2027.

Where AI helps, and where it must not decide

The useful applications are narrow and real: turning a case manager's observations into a first draft of present levels, suggesting measurable phrasing for a goal the teacher already chose, or flagging that a draft goal has no stated measurement method before the meeting rather than after it.

What it must not do is decide eligibility, services, placement or goals. The IEP is developed by a team that includes the parents, and 34 CFR 300.324(a)(1) sets what that team must consider. We found no Department of Education or OSEP guidance specific to AI in IEP development as of September 2026, so State and district policy governs and it varies. Build the approval step, the authorship record and the log of what was suggested versus what a human kept.

Buy IEP creation software, or build it

Most districts should buy. If your process is the statutory one and nothing more, an established platform already holds the content list in 34 CFR 300.320(a), the review clock and the forms your State accepts. A buyer who recognises their own process in a product demo has the answer.

The test is cheap to run before anyone is paid. Write the fields your State extract needs beside the ones the platform exports, then write every system that has to agree about a student. Where both lists are covered, buy, and spend the difference on training the case managers. Where they are not, the gap is an integration and data shape problem, the half a licence does not fix however good the editor is.

What a first engagement looks like

The honest first question is whether to build at all. An established platform that fits your process is cheaper than anything custom, and we will say so if that is what your requirements describe. Custom earns its cost when the process is genuinely yours: an unusual State reporting extract, a multilingual parent workflow, a product you are taking to market, or a system sitting between tools that will not talk to each other.

Where a build is right, the first paid step is small and yours whether or not we continue: a written scope of the workflow as it runs today, the integration surface against your student information system, the data model for goals and progress, and a delivery sequence with the compliance clocks in it.