Skip to main content

CALPADS error brief · SENR

SENR0037

Duplicate enrollment with same Enrollment Start Date
Severity Fatal
Error type Input Validation
Record type SENR

Official CALPADS rule

What CALPADS is rejecting

Student primary enrollment submission cannot have the same Enrollment Start Date for the same student in another LEA Primary Enrollments are defined as: - Enrollment Status = “10” (Primary); - Enrollment Status = “30” (Short Term), and the enrollment period exceeds 30 days; Note: Enrollments with a N470 (NoShowOther) exit and a Enrollment Exit Date equal to or one day prior to the Enrollment Start Date are NOT considered Primary Enrollments.

Focus fields

Fields validated

1.22 - Enrollment Start Date 1.04 - Reporting LEA 1.05 - School of Attendance

Recommended correction path

Suggested resolution

Read the complete validation

CALPADS rule: A submitted primary enrollment cannot have the same Enrollment Start Date as a primary enrollment for the same student in another LEA.

For this validation, primary enrollments include:

  • Enrollment Status 10 — Primary.
  • Enrollment Status 30 — Short Term, when the enrollment period exceeds 30 days.

An enrollment exited with N470 No Show is not treated as primary when its Exit Date equals the Start Date or is one day before it.

Severity: Fatal   Type: Input Validation

Fields validated:

  • 1.04 Reporting LEA
  • 1.05 School of Attendance
  • 1.22 Enrollment Start Date
Humorous illustration of two nearly identical students appearing at once, representing two LEAs starting primary enrollment on the same date
One SSID, two LEAs, one identical primary Start Date: CALPADS needs the chronology reconciled.

How SENR0037 differs from SENR0027 and SENR0028

Identify the conflict boundary before choosing the workflow
ErrorWhat CALPADS foundOperational consequence
SENR0027A primary enrollment overlaps another primary enrollment inside the same LEA.Fatal; the LEA generally controls both records and reconciles them internally.
SENR0028A primary enrollment overlaps an existing primary enrollment in another LEA.Warning/Data Discrepancy; the submission can create a concurrent-enrollment anomaly requiring inter-LEA reconciliation.
SENR0037The two cross-LEA primary enrollments have the exact same Start Date.Fatal; the identical start collision must be resolved before the submitted record can post.

SENR0037 is not merely “another overlap.” It isolates a particularly strong contradiction: two LEAs claim that their primary enrollment responsibility began on the same day.

Do not automatically move your Start Date forward one day. The correct date is the student’s supported first day of enrollment/attendance or responsibility under current procedures. If your date is correct, the other LEA’s date, status, SSID linkage, school, or record may be wrong. Each LEA must correct only the record it owns.

Decide which problem created the identical date

Identity, ownership, and chronology require different corrections
FindingLikely problemCorrection owner
Submitted SSID belongs to another studentWrong-student/SSID linkage made unrelated enrollments appear to collide.Your LEA corrects its SIS identity linkage and every affected submission.
Your actual first attendance was laterPre-enrollment, registration, rollover, or import date was reported as Start Date.Your LEA corrects field 1.22 and the authoritative enrollment record.
Other LEA’s student never attendedIts expected enrollment may require supported N470 no-show treatment.The other LEA evaluates and corrects its own record.
Other LEA used wrong SSID or dateIts record, not yours, created the collision.The other LEA verifies identity and corrects its SIS/CALPADS record.
One enrollment is genuinely concurrent, not primaryAn Enrollment Status was defaulted or misclassified.The LEA owning the misclassified record applies the factual status definition.
Both LEAs support the same first dayIdentity, concurrent activity, responsibility, or attendance remains disputed.Both CALPADS coordinators escalate through authorized procedures with evidence; neither invents a date.

What “same Start Date” can conceal

The identical value may come from very different events
ScenarioWhy dates matchWhat to verify
Both LEAs use the first day of the academic yearBulk rollover or pre-enrollment opened both records automatically.Where did the student actually begin attending, and which enrollment should have been activated?
Student transferred on the common datePrior and receiving LEAs both treated the transition date as their Start Date.The prior record’s true Start/Exit chronology and the receiving LEA’s first attendance.
Duplicate SSID assignment/linkageTwo students’ local records point to one SSID.Authorized identity evidence before changing any enrollment dates.
Future enrollment loaded earlyA scheduled placement was submitted before actual attendance and happens to match another LEA’s date.Whether the future enrollment is permitted and whether the Start Date represents an actual supported event.
Short-term placement exceeded 30 daysStatus 30 became primary for the validation and shares the other record’s Start Date.Duration, institutional eligibility, actual attendance, and whether the segment should have closed or changed.
No-show record lacks special treatmentAn expected enrollment remains primary because N470 or its date sequence is wrong.Whether the student appeared and whether the supported same-day/one-day-prior exit applies.

Coordinate without assigning blame

Each LEA verifies and changes its own record
Your LEA verifiesAsk the other LEA to verifyShared outcome
Correct student/SSID, Reporting LEA, School of Attendance, first attendance, Start Date, and status.Correct student/SSID, school, Start Date, status, attendance, and any Exit Date/reason.Agreement on the factual identity and chronology—not a negotiated artificial date.
Whether the record was activated by registration, rollover, import, or actual attendance.Whether its same-date record is active, closed, duplicated, short-term, or a no-show.A named owner for each supported correction.
Whether your next SIS extract will preserve the correction.Whether its next extract could restore the incorrect value.Postflight verification after both systems update.

What commonly produces SENR0037

Symptoms, likely causes, and durable corrections
What you findLikely causeDurable correction
Both dates equal the first school dayTwo LEAs rolled forward an expected student.Verify actual attendance/ownership and correct the unsupported activation.
Your Start Date predates first attendanceApplication, registration, import, or schedule date populated field 1.22.Correct the SIS enrollment event and extract mapping.
Other LEA record should be a no-showThe expected enrollment was left open or exited incorrectly.Other LEA applies supported N470 and date treatment.
Identity information differsOne LEA used the wrong SSID or linked the correct SSID to the wrong local student.Resolve identity before any enrollment correction and review all affected file types.
One placement is concurrentBoth SIS systems defaulted to status 10.Determine instructional responsibility and correct the misclassified status if supported.
Corrected date returns laterA CALPADS-only edit was overwritten by an unchanged SIS/extract.Repair the authoritative source and verify the next generated row.
Same collision affects many studentsRollover, vendor conversion, or bulk start-date logic used a shared default.Stop the batch, repair the process, and reconcile the entire affected population.

Choose the diagnostic pathway

  • Verify student identity and SSID
    • Does the submitted SSID belong to the intended student?
    • Do authorized identity fields align with the local record?
    • Could an SSID have been mistyped, merged, replaced, duplicated, or attached to the wrong student?
    • Stop date correction until identity is established.
  • Verify your Start Date
    • When did the student first attend or become your LEA’s responsibility?
    • Was field 1.22 populated from attendance, registration, scheduling, import, or rollover?
    • Does the school calendar explain a default shared date?
    • Is Reporting LEA and School of Attendance correct?
    • Does Enrollment Status accurately describe the placement?
  • Inspect the other LEA record
    • Which LEA and school reported the same Start Date?
    • Is that enrollment open or closed?
    • What status and Exit Date/reason appear?
    • Could it be a duplicate, future enrollment, short-term placement, or no-show?
    • Which LEA owns the value that needs correction?
  • Coordinate the correction
    • Use an authorized, privacy-protected channel.
    • Compare only the evidence needed to establish identity and chronology.
    • Do not instruct the other LEA to use an unsupported date.
    • Assign each correction to the LEA that owns the record.
    • Agree when both parties will verify the ODS.
  • Review downstream effects
    • Did the wrong Start Date affect attendance, ADA, SINF, SPRG, SELA, assessment, course, cohort, or special-education records?
    • Did the wrong SSID affect other students or file types?
    • Did a bulk process create more same-date collisions?
    • Will subsequent extracts preserve the corrected chronology?

Resolve the identical Start Date

  1. IdentityConfirm SSID.
  2. DatesCompare both starts.
  3. EvidenceEstablish attendance.
  4. OwnershipEach LEA corrects its record.
  5. VerificationConfirm accepted chronology.

Primary participants

  • CALPADS coordinators in both LEAs
  • Registrar/enrollment staff
  • Attendance and school-site staff
  • Student records/SSID staff
  • District student-services staff when needed
  • SIS and integration support

Evidence to preserve

  • SENR0037 rejection and submission ID
  • Verified identity/SSID
  • Both CALPADS enrollment histories
  • First attendance and registration chronology
  • Authorized inter-LEA contact record
  • Before/after raw SENR rows
  • Accepted ODS result

Recommended correction path

  1. Preserve the rejected row

    Capture submission ID, SSID, Reporting LEA, School of Attendance, Start Date, Status, and untouched SENR row.

  2. Confirm the student and SSID

    Resolve identity before changing dates in either LEA.

  3. Locate the other LEA’s record

    Document its school, Start Date, status, Exit Date/reason, and current ODS state.

  4. Verify your first attendance

    Use attendance, enrollment, registration, and responsibility evidence—not a default date.

  5. Contact the other LEA securely

    Ask it to verify identity, first attendance, status, and whether its record should remain, change, or receive no-show treatment.

  6. Assign correction ownership

    Each LEA repairs only its unsupported SIS/CALPADS values.

  7. Correct the authoritative source

    Repair Start Date, school, status, SSID linkage, no-show record, rollover, or extract logic where the evidence requires.

  8. Submit and verify

    Confirm SENR0037 clears and CALPADS shows the intended inter-LEA chronology.

  9. Review the shared population

    Find other identical Start Dates created by the same school calendar, rollover, SSID linkage, import, or status default.

Before closing the issue

  • Confirm the SSID belongs to the intended student.
  • Verify Reporting LEA, School of Attendance, Start Date, and Status are factual.
  • Confirm the other LEA has verified and corrected its record when applicable.
  • Ensure no unsupported same-date primary enrollment remains.
  • Verify both SIS extracts preserve the accepted chronology.
  • Review attendance, ADA, program, assessment, course, cohort, funding, and special-education effects.

Official SENR0037 troubleshooting page  |  Current CALPADS SSID and Enrollment Procedures  |  SDLA CALPADS Code Sets V.18