What starts the 30 day clock, and what does not
The FCRA 611 reinvestigation window starts on receipt of notice, not on the day the letter was written. The difference is worth building for.
Ask five operators when the thirty day window starts and you get four answers. The letter date. The postmark. The day the agency scanned it. The day somebody in the office wrote it on the spreadsheet. Only one of those is the statute, and the gap between them is where an examiner finds their first question.
What the statute says
FCRA 611(a)(1)(A), 15 U.S.C. 1681i, requires a consumer reporting agency to complete a reinvestigation of disputed information within 30 days of receiving notice of the dispute from the consumer. Not of sending. Of receiving.
Two things extend it to 45 days. The first is the consumer providing additional relevant information during the period, under 611(a)(1)(B). The second is where the dispute follows a free annual file disclosure requested under FCRA 612(a). Both are conditions with evidence attached, which means both can be recorded rather than assumed.
Why the difference matters in a record
If your system dates the clock from the letter, three things go wrong at once. Every window is short by the time in transit, which makes the queue lie in your favour. Every escalation is early, which trains the team to ignore the queue. And every reconstruction after the fact depends on somebody remembering that the dates were nominal.
If your system dates the clock from the acceptance scan, all three problems disappear and are replaced by one honest constraint: a case with no acceptance scan has no clock. That constraint is the useful one, because it is visible.
| Dated from | Start | Due | On 2026-08-11 |
|---|---|---|---|
| Letter date | 2026-07-14 | 2026-08-13 | Due in 2d |
| Acceptance scan | 2026-07-16 | 2026-08-15 | Due in 4d |
| Spreadsheet entry | 2026-07-20 | 2026-08-19 | Open |
What we built instead of a date field
The clock on a case is not a date. It is four things: the rule that creates the window, a pointer to the document that evidences the start, the derived due date, and an append only list of extensions. Three of the four are read only to every seat in the tenant. Writing to the due date returns 403 clock_not_writable, and the response says to record the extending event instead.
That sounds inflexible until the first time somebody asks why a due date moved. With an editable field the answer is an audit entry saying a person changed a number. With an extension list the answer is an audit entry naming 611(a)(1)(B) and pointing at the consumer submission that triggered it.
The case with no start evidence
During migrations we consistently find cases where nobody can produce the acceptance scan. The tempting behaviour is to date them from the letter and move on, because the alternative is a list of exceptions on day one of a new system.
We do the opposite. An imported case whose clock cannot be reconciled to a start evidence document arrives flagged, with no due date and a state that reads exactly that. It is uncomfortable and it is correct: the system now says what your file actually supports, which is the only position that survives being asked about.
What this does not fix
None of this makes an agency answer faster, and none of it changes an outcome. A window that expires without a written result is still a window that expired. What changes is that you can see it on the day it happens rather than the week somebody notices, and you can say precisely when it started and why.