NIBRS reporting for Texas police departments.

A practical guide to Texas NIBRS reporting, RMS requirements, certification, errors, Texas-specific reporting, and what agencies should expect from their software vendor.

Texas law-enforcement agencies don't just need an RMS that can store incident reports.

They need an RMS capable of turning the agency's operational records into accurate, complete NIBRS data and submitting that information through the Texas Department of Public Safety Uniform Crime Reporting program.

Since September 1, 2023, Texas DPS states that Texas criminal-justice agencies are required to implement a NIBRS-compliant records management system and submit NIBRS data monthly to the Texas DPS UCR Program.

That makes NIBRS reporting part of the RMS—not a side project.

A good NIBRS workflow starts with the incident record, not the monthly export.

NIBRS reporting is not something records staff “do at the end of the month.” The quality of the submission begins with how incidents, offenses, victims, offenders, arrests, property, and relationships are captured when the record is created.

This guide explains what Texas agencies need to understand about the reporting process, where the RMS and vendor fit, what makes Texas reporting different, and what to ask when evaluating or changing systems.

What is NIBRS?

The National Incident-Based Reporting System, or NIBRS, is the FBI's incident-based crime reporting system.

Unlike the older Summary Reporting System, which primarily aggregated monthly crime totals, NIBRS captures detailed information about individual crime incidents and the offenses within them.

That can include information about:

• offenses
• victims
• known offenders
• relationships between victims and offenders
• arrestees
• property
• locations
• circumstances
• clearances

The FBI describes NIBRS as providing substantially more context about crime than the traditional summary-reporting model.

For an agency, that means a NIBRS submission is ultimately built from the facts contained in its operational records.

Texas agencies are required to report through NIBRS

Texas fully transitioned participating agencies to NIBRS reporting in 2021.

Then, effective September 1, 2023, House Bill 4879 required Texas criminal-justice agencies to implement a NIBRS-compliant RMS and submit NIBRS data to DPS for the UCR program. DPS describes the reporting cadence as monthly.

For a Texas police department, that means NIBRS capability should be treated as a core RMS requirement.

When evaluating a system, don't stop at:

“Does your RMS support NIBRS?”

Ask:

Show us how an incident becomes a Texas NIBRS submission.

The reporting workflow starts with the report

At a high level, the process looks something like:

Officer documents incident
        ↓
Structured incident data captured
        ↓
Offenses / victims / offenders /
arrestees / property connected
        ↓
Supervisor / records review
        ↓
NIBRS validation
        ↓
Errors and warnings corrected
        ↓
Monthly submission generated
        ↓
Texas DPS receives submission
        ↓
Errors / warnings reviewed
        ↓
Records corrected and resubmitted

The important point is that the quality of the file at the bottom depends heavily on the quality and structure of the records at the top.

If the officer doesn't capture information required for NIBRS, someone eventually has to resolve it.

Often that person is in Records.

NIBRS should be part of normal report entry

A well-designed RMS should help capture required reporting information while the operational record is being created.

That doesn't mean turning an officer's report into a NIBRS questionnaire.

It means the RMS should understand which reporting fields matter and present them at an appropriate point in the workflow.

For example, depending on the incident, the system may need enough structured information to understand:

• what offense occurred
• when and where it occurred
• victims
• offenders
• victim/offender relationships
• property
• weapons
• arrests
• clearance information
• applicable offense attributes

The objective is:

Collect the right facts once, as part of the record, and use them for reporting afterward.

Not:

Write the report first and rebuild it for NIBRS at the end of the month.

Texas reporting is more than the federal NIBRS file

This is one of the most important distinctions for a Texas RMS evaluation.

Texas DPS maintains Texas-specific reporting requirements in addition to the national NIBRS specification.

DPS's Texas-centric specifications include state-specific validations and reporting for areas including:

• Family Violence
• Drug Seizures
• Sexual Assault

Texas-specific data is represented through Segment Levels 8 and 9 in applicable flat-file reporting. DPS notes that those Texas-specific segments are used for state reporting and are not forwarded to the FBI as standard NIBRS segments.

So:

“Our software supports FBI NIBRS” is not the same as demonstrating that it supports Texas reporting requirements.

Ask specifically about Texas.

Texas uses its own validations and error codes

Texas DPS's Texas-centric technical specification includes state-specific validation rules.

Those errors are identified with Texas-specific codes such as:

T-221
T-832
T-937

DPS explains that T- errors apply to Texas-specific validation and that certain Texas validations supersede the general NIBRS guidelines for state data-quality purposes.

That matters operationally.

Your RMS or reporting workflow should give Records personnel enough information to determine:

What record caused the error?

What does the error mean?

What information needs to change?

Can the correction be made in the operational record?

Will the corrected record appear in the next submission?

A cryptic error file that only the software vendor can understand creates unnecessary dependency.

Know which specification your RMS supports

Texas DPS currently accepts multiple versions of NIBRS and Texas-mandated reporting.

As of September 2026, DPS lists:

DPS also currently uses the FBI's 2023 NIBRS User Manual and continues to publish technical specifications and implementation documentation for vendors and agencies.

Ask your RMS vendor:

Which NIBRS specification version are we currently producing?

Then:

Which Texas-specific specification are we using?

The answer should not be:

“NIBRS.”

It should be specific.

Offense codes matter

Texas DPS maintains a Texas UCR Offense Code Table to help agencies and RMS vendors map Texas state offenses to the appropriate Summary Reporting and NIBRS classifications.

DPS says the table is intended for both law-enforcement agencies and RMS vendors to use as guidance when building and maintaining offense-code tables. DPS's current page notes updates connected to Version 20 offense codes effective September 1, 2025 and shows the table updated as of May 4, 2026.

This is another reason a Texas RMS cannot treat its offense catalog as a static list.

Ask:

• Who maintains the Texas offense catalog?
• How are DPS/UCR code changes handled?
• How are new statutes added?
• How are obsolete statutes retired?
• What happens to historical incidents when an offense mapping changes?
• Can staff see the NIBRS/UCR classification associated with an offense?
• How quickly are legislative/DPS changes reflected in the software?

A reporting system is only as reliable as the data it is classifying.

The agency still owns the accuracy of its data

A vendor can help generate the submission.

That does not transfer responsibility for the agency's crime data to the vendor.

Texas DPS specifically tells agencies that they are the master record holder for their data and are responsible for submitting accurate and complete reports, correcting validation errors and warnings, maintaining communication with DPS when vendor/product/POC changes occur, and staying current with applicable reporting specifications.

That's an important procurement distinction:

The vendor provides the reporting machinery. The agency remains responsible for the record.

A good vendor should make that responsibility easier to manage—not obscure it.

What should the RMS vendor be responsible for?

At minimum, an RMS vendor supporting Texas NIBRS should be able to explain how it handles:

• NIBRS-compatible data structures
• Texas-specific reporting fields
• NIBRS export/submission format
• offense-code mapping
• required specification changes
• validation logic
• error handling
• certification/re-certification support
• Texas-specific Segments 8 and 9
• updates to Texas technical requirements

The vendor should also be able to help answer:

Is the problem in the source record, the mapping, the submission generator, or the reporting specification?

The agency should not have to reverse-engineer its RMS vendor's submission process.

What should the agency be responsible for?

The agency generally owns the operational side of the reporting process.

That includes responsibilities such as:

• accurate reports
• appropriate offense classification
• complete required information
• supervisory/records review
• correcting reporting errors
• maintaining monthly reporting
• communication with DPS
• keeping agency contacts current
• ensuring the RMS is being used correctly

This is why NIBRS can't be treated as an IT-only responsibility.

It involves:

Patrol + supervisors + Records + the RMS vendor.

Certification and re-certification matter

Texas DPS maintains a certification process for agencies beginning NIBRS reporting and for agencies that need to re-certify because of a vendor or product change.

Its current certification procedure explicitly covers:

1. agencies transitioning to NIBRS
2. new UCR agencies
3. agencies re-certifying because of a change in vendor and/or vendor product

That's especially important if you're replacing your RMS.

Changing RMS vendors is not merely a data-conversion project.

It may also trigger a reporting-certification project.

Ask the new RMS vendor

• Have you supported Texas agencies through certification?
• Have you supported agencies through re-certification after changing RMS vendors?
• Who works with DPS?
• Who generates the test files?
• Who reviews errors?
• How much agency involvement is required?
• What happens if the initial test file exceeds the allowable error rate?

Make NIBRS transition part of your implementation plan.

Certified vendor vs. NIBRS-capable software

Texas DPS maintains a public list of vendors actively working with Texas agencies to submit NIBRS.

DPS says a vendor is added when it is working with a Texas LEA through the certification process and actively submitting live data. Vendors that stop actively working with any Texas agency for more than six months can be removed.

That makes the list useful evidence of actual Texas reporting activity.

But DPS also gives agencies an important warning:

Inclusion on the list does not mean the vendor or agency is CJIS compliant.

The vendor listing only reflects NIBRS/UCR technical reporting activity.

Those are two different questions:

Can this RMS produce acceptable Texas NIBRS data?

and

Does our overall environment satisfy applicable CJIS security requirements?

Don't confuse them.

Thin Line's Texas NIBRS experience

Thin Line Software is currently listed by the Texas Department of Public Safety among vendors actively working with Texas agencies to submit NIBRS data.

DPS's current vendor list includes Thin Line Software alongside other Texas NIBRS vendors and explains that listed vendors are actively working with Texas agencies on certification and live NIBRS submissions.

The appropriate claim is:

Thin Line Software is listed by Texas DPS among vendors actively working with Texas agencies to submit NIBRS data.

Not:

• “approved by Texas DPS”
• “certified by Texas DPS as an RMS”
• “CJIS certified”
• “endorsed by Texas DPS”

The precise language is both stronger and more credible.

Vendors actively working with Texas agencies to submit NIBRS (Texas DPS)

Test-file requirements vary

Under DPS's current certification procedures, an agency working with a vendor that has previously successfully submitted Texas NIBRS data generally has a different test-file requirement from an agency working with a vendor that has not.

The current DPS procedure says:

• agencies with certified vendors submit one whole month of test data
• agencies with vendors not certified for Texas UCR purposes submit three whole months of test files

DPS also requires Texas-mandated reporting to be part of the certification process.

That is another practical reason to ask a vendor about its actual Texas reporting history, not simply whether its brochure says “NIBRS compliant.”

A monthly workflow should be repeatable

Once the agency is live, NIBRS reporting becomes recurring operational work.

A good workflow might look like:

1. Identify records ready for reporting

Determine which incidents belong in the reporting period and whether they have reached the appropriate status.

2. Find data-quality problems

Identify missing or invalid reporting information before submission.

3. Correct the operational record

Where possible, fix the actual incident/offense/person/property data—not merely the export.

4. Generate the submission

Produce the applicable monthly NIBRS/Texas reporting file or transmission.

5. Submit

Follow the current DPS reporting mechanism.

6. Review errors and warnings

Don't assume “file accepted” means every record was correct.

7. Correct and resubmit as necessary

Preserve a repeatable process.

8. Document completion

Records staff should be able to establish that the reporting cycle was completed.

Errors should point back to the case

Imagine Records receives:

T-832

or another NIBRS validation error.

The useful question isn't:

What character in the flat file is wrong?

The useful question is:

Which incident needs attention?

A strong RMS reporting workflow should help Records get from:

Error
  ↓
Incident
  ↓
Offense / victim / offender /
property / arrest field
  ↓
Correction
  ↓
Revalidation

The reporting system should connect data quality back to the actual operational record.

That makes corrections easier to understand and helps prevent the same issue from recurring.

Warnings deserve attention too

Agencies sometimes focus entirely on records that are rejected.

But Texas DPS tells agencies to address validation errors and warnings received during reporting.

A warning may not prevent the file from processing, but it can still identify a data-quality issue worth reviewing.

Ask the vendor:

How are warnings displayed?

Can Records identify the affected incident?

Can warnings be tracked until resolved?

Does the system distinguish informational warnings from submission-blocking errors?

Don't make the only workflow:

Rejected / Accepted.

Data quality is more nuanced than that.

Reporting quality should be visible before month-end

Don't wait until submission day to discover that fifty incidents are missing information.

Ideally, records staff or supervisors should be able to see reporting problems as they accumulate.

For example:

NIBRS readiness

17 incidents need review

5 missing victim/offender relationship
4 invalid offense mapping
3 incomplete property information
3 Texas-specific reporting issues
2 other validation problems

The exact presentation will vary by RMS.

The principle is what matters:

Month-end should be submission work, not archaeological work.

Supervisory review can improve NIBRS quality

NIBRS isn't solely a Records problem.

If the RMS can identify important missing information while the report is still in supervisor review, the agency has an opportunity to resolve the problem while the incident is fresh.

For example:

Officer submits
       ↓
System identifies required data issue
       ↓
Supervisor reviews
       ↓
Officer corrects
       ↓
Report approved
       ↓
NIBRS-ready record

That is generally better than:

Officer submits
       ↓
Supervisor approves
       ↓
Three weeks pass
       ↓
Records finds problem
       ↓
Records tries to reconstruct incident

The system should help move data-quality work earlier in the process where practical.

Changing RMS vendors requires planning for NIBRS

If your agency is replacing its RMS, add NIBRS to the implementation checklist.

The project may involve:

Legacy RMS
    ↓
Data conversion
    ↓
New RMS configuration
    ↓
Texas offense/NIBRS mapping
    ↓
NIBRS testing
    ↓
DPS certification / re-certification
    ↓
Go-live
    ↓
First production submission
    ↓
Post-go-live validation

Do not assume the data-conversion work and the NIBRS transition are the same thing.

They're related projects.

Historical records need to survive.

New production records need to report correctly.

Both matter.

Changing systems also means preserving historical records. Read the data conversion guide.

Ask what happens to historical NIBRS data

During an RMS conversion, clarify what happens to historical reporting information.

Questions can include:

• Are historical offenses preserved as they were recorded?
• Are old NIBRS codes preserved?
• Are historical submissions themselves converted?
• Are historical errors/warnings retained?
• Does the agency need historical reporting files separately?
• Will converted incidents accidentally be treated as new reportable incidents?
• How does the system distinguish converted history from current reporting activity?

A conversion should not create a flood of false “new” NIBRS records simply because historical incidents arrived in the new RMS.

This is one of the reasons the conversion and NIBRS teams need to coordinate.

Texas DPS provides training and quality-control resources

Texas DPS's Incident Based Reporting Compliance & Training Unit provides statewide NIBRS reporting support, training, audits, quality-control assistance, and technical resources.

Its current 2026 training materials include topics such as:

• NIBRS overview
• Group B offenses
• NIBRS errors and warnings
• Texas-specific errors
• Texas-specific reports
• NIBRS for ISD police departments
• N-DEx
• Use of Force

DPS also encourages both agencies and RMS vendors to subscribe to its UCR listserv for specification updates.

Thin Line's role should be to help agencies understand the workflow and point them to the authoritative requirements.

A NIBRS self-audit for your agency

RMS and vendor

• Our RMS supports Texas NIBRS reporting.
• We know which NIBRS specification version it uses.
• We know which Texas-mandated specification version it uses.
• Our vendor monitors Texas specification changes.
• Our vendor maintains applicable offense-code mappings.
• We know who to contact at the vendor with reporting problems.
• We know whether our vendor is actively working with Texas agencies on NIBRS submissions.

Operational records

• Officers capture required reporting information during report entry.
• The system identifies missing required information.
• Supervisors can identify important reporting problems before approval.
• Records can see which incidents are not NIBRS-ready.
• Corrections are made to the operational record where appropriate.

Texas-specific reporting

• Our RMS handles Texas-specific reporting requirements.
• Family Violence reporting is addressed.
• Drug Seizure reporting is addressed.
• Sexual Assault reporting is addressed.
• Texas-specific validations/errors are visible to Records.
• Staff understand that Texas requirements extend beyond federal NIBRS alone.

Monthly process

• Someone owns monthly NIBRS reporting.
• Staff know when the submission is due.
• Records are reviewed before submission.
• Errors are tracked.
• Warnings are reviewed.
• Corrections are resubmitted when necessary.
• Submission completion is documented.

Staff knowledge

• Records staff know how to interpret reporting issues.
• Supervisors understand how report quality affects NIBRS.
• Officers receive guidance on recurring data-quality problems.
• Staff know where DPS reference/training materials are located.

Changing systems

• NIBRS re-certification has been discussed with the new vendor.
• Certification/testing is part of the implementation plan.
• Historical converted records will not accidentally create new reportable activity.
• The first production submission after go-live will receive additional validation.

20 questions to ask an RMS vendor about Texas NIBRS

Bring these to a demonstration. Don't accept “yes” as the answer to most of them. Ask the vendor to show you.

1. Which NIBRS specification version does your RMS currently support in Texas?
2. Which Texas-mandated reporting specification do you support?
3. Are you currently working with Texas agencies submitting NIBRS to DPS?
4. How many Texas agencies are actively submitting through your RMS?
5. Have you supported a Texas agency through NIBRS certification?
6. Have you supported one through re-certification after an RMS change?
7. Who monitors DPS technical-specification changes?
8. How do Texas UCR offense-code updates get into the product?
9. How quickly are legislative/offense changes implemented?
10. Show us how the officer's incident becomes the NIBRS record.
11. Show us how Records sees missing NIBRS information.
12. Show us a Texas-specific validation error.
13. Can the user go directly from the error to the affected incident?
14. How are warnings handled?
15. How are Segments 8 and 9 handled?
16. How do we create the monthly submission?
17. What does the agency have to do when DPS returns an error?
18. What support do you provide during our first production submissions?
19. How are converted historical records kept out of current NIBRS reporting?
20. If DPS changes its specification next year, what happens?

Common NIBRS warning signs when evaluating an RMS

“We're NIBRS compliant.”

Follow up with:

In Texas? Which specification version? Which agencies are currently submitting?

NIBRS lives on a separate screen nobody sees until month-end

Ask whether reporting data can be captured and validated as part of the operational workflow.

Only the vendor can interpret errors

Records personnel should be able to identify the affected incident and understand what requires attention.

Federal NIBRS is treated as the entire Texas requirement

Ask about Texas-specific reporting and validations.

The offense catalog is rarely updated

Ask who owns Texas legislative and DPS code changes.

The vendor can't explain re-certification

This becomes particularly important when replacing an RMS.

Everything is “fixed in the export”

If the source incident record is wrong, silently changing the outbound file can leave the agency's operational record inconsistent with what it reported.

Ask how corrections flow back into the source record.

Reporting should improve the record—not compete with it

NIBRS creates detailed crime statistics for state and national use.

But the agency's first responsibility is still maintaining a dependable operational record.

The best reporting workflow uses that record as the source:

Capture the facts → review the work → validate the reporting → submit the data.

Not:

Write the report → build a second reporting record → hope they agree.

When the RMS is designed properly, reporting requirements and operational records reinforce each other.

Officers build better structured records.

Supervisors catch problems earlier.

Records personnel spend less time reconstructing missing information.

And the monthly submission becomes a product of normal recordkeeping rather than a separate administrative exercise.