NFIRS asked you to pick a code. You looked up the number that came closest to what happened, you entered it, and you moved on. Nearly fifty years of fire service reporting worked that way.
NERIS does not work that way, it asks for specific strings (words or phrases). Not a number that stands in for a description, but the exact word or phrase the system expects, spelled the way the system expects it. If the string does not match, the report does not go through, it gets rejected. That is the biggest difference, and it matters more than it sounds.
The vocabulary is not the vocabulary you use
No matter how long you've been on a fire department, you've noticed fire departments have their own language. It developed on firegrounds and in station kitchens over decades, and it is efficient because everyone in the room already knows what it means. NERIS wasn't built from that language, it was built from a data standard and expects standard inputs.
For example, look at mutual aid. Every department in the country understands mutual aid. You call for it, you give it, you have agreements on file, and you have a good idea of who is coming before they arrive.
NERIS doesn't ask whether you gave or received mutual aid and leave it there. It asks for the type of aid, and the types are not the words anyone uses on scene. There is aid given in support of another department, aid given in lieu of another department, and aid where your department is acting as another department. Those are three different things in the data standard, and a department that thinks of all three as "we ran to the next county over" has to learn which one applies before the report will go.
Then it asks for a direction, given or received, as a separate field. Then it asks for the other department's NERIS Entity ID.
That last one is worth sitting with. Under NFIRS you could describe aid without needing to identify your partner in the national system. Under NERIS, your neighbor's Entity ID is a piece of data you have to hold. There is a public search tool for looking those up and the IDs are structured rather than random, so this is a solvable problem, but it is a new thing to keep track of and it did not exist before.
Aid from agencies that are not fire departments is handled separately again. Law enforcement, social services, animal services, utilities and public works, remediation services. If PD was on scene, that is not a note in the narrative, it is a categorized entry with its own direction.
None of that is unreasonable, and it produces better data than NFIRS did. But nobody on a fireground says "acting as," and the distance between how a call actually went and how NERIS wants it described is the work.
The modules depend on the incident
NFIRS had modules too. NERIS has more of them, and which ones a report requires depends on the incident subtype.
A fire gets a fire suppression section, a medical call gets sections about the sick or injured person, a hazardous situation gets its own, a rescue gets its own, and aid gets its own when aid was involved. The envelope around all of them stays the same, and the sections inside it change based on what kind of call it was.
Working out which sections a given subtype requires is the first real obstacle for anyone building against this, and it is the same obstacle for a department filling out a report by hand. Get it wrong and the report does not go.
Rejection is all or nothing
This is the part that changes how you have to think about the work.
When NERIS rejects a report, it does not reject the field, it rejects the report. The response tells you what failed, so you are not guessing, but you are not fixing one box and moving on either. The whole thing bounces, and it bounces after you thought you were done.
For a career department with a records division, that is an annoyance. For a volunteer who came home at two in the morning, slept, worked a full day at another job, and sat down at nine at night to write up the call, finding out at the end that a string three sections back was not spelled the way NERIS expects it is something else.
Spelling counts, case counts, and the exact form of the phrase counts. There is no partial credit and no close enough.
Which is why validation has to happen first
If a report can only fail as a whole, the only sensible place to catch problems is before it is submitted.
That is a workflow argument more than a technical one. The system will tell you what went wrong, it just tells you at the worst possible moment, after the person filling out the report has already mentally closed the file. Catching it earlier does not make the data better, it makes the person doing the work more likely to finish.
Every mismatch between plain language and NERIS language is a place a report can fail. The department did not choose that vocabulary and has no reason to have memorized it. Software should be doing that translation, and it should be doing it while the report is being written rather than after it has been sent.
What this means for your department
NERIS is not harder than NFIRS because it asks for more, it is harder because it asks for exactness in a place where the fire service has always used judgment.
That is not a criticism of the standard. Exactness is what makes the data worth collecting. But it does mean the tool you use matters more than it did. Under NFIRS, a bad tool cost you time. Under NERIS, a bad tool costs you submitted reports.