A check arrives in a deposit queue with a date that appears to be several months old. Another shows a date in the future. A third has a date field that the scan captured as a blur. They may look like variations of one problem, but they are three different states: a date that can be read and compared with the presentation date, a future date whose handling depends on notice and policy, and a value the system cannot reliably read at all.
Combining them into a single “date exception” hides the evidence an operations team needs. The first step is to extract the date faithfully. The next is to keep the extraction result separate from the decision about payment, funds availability or review.
Three date states, three next steps
| State | What the document shows | What the workflow should do |
|---|---|---|
| Appears stale-dated | A readable check date is more than six months before the presentation date. | Keep the check date and presentation date visible as separate evidence; apply the bank’s configured review policy. |
| Appears post-dated | A readable date falls after the presentation date. | Preserve the date and any notice record; route through the relevant bank policy instead of treating the date alone as a payment instruction. |
| Date unreadable or ambiguous | The image does not support one reliable date, or formats such as 03/04 leave month and day unclear. | Return an unreadable or ambiguous state with the image region; request review or a clearer image before comparing dates. |
The six-month comparison is not a universal “expired check” switch. Regulation CC’s commentary describes a check deposited more than six months after its date as a reasonable indication it may be uncollectible, referring to U.C.C. 4-404; the bank is not obligated to pay every such check, but the provision does not say it must reject all of them. A workflow should report the signal and leave the payment decision to the applicable policy. See the eCFR commentary to Regulation CC, Appendix E.
A future date needs its own context
A future date is not the same as an old date. The Regulation CC commentary says a post-dated check may be a reason to doubt collectibility. But whether a bank must wait can depend on notice and state law. The Consumer Financial Protection Bureau explains that banks and credit unions generally do not have to wait for the date on a check unless the customer has given notice that is valid under applicable law; it advises customers to contact their institution and learn its policy. Its overview describes written notice given a reasonable time before receipt and the shorter period for oral notice.
For an operations system, this means the printed date is only one part of the record. The workflow may also need the presentation timestamp, any stop or hold notice, when and how the institution received that notice, and the policy version used to route the item. Do not infer that a future date alone proves a valid hold request or tells the system what action to take.
The distinction is operational as well as legal. A queue that labels every future date “reject” can turn a field extraction into a payment decision. A queue that labels it “review” can preserve the evidence and send the case to the bank’s policy path without claiming a legal outcome.
Unreadable means unknown
Date fields are small, often handwritten, and easy to misread when a scan is skewed, faint or compressed. A model may see a plausible month and day even when the year is missing. In other cases, a slash-separated date can support two interpretations. A value that looks plausible is not the same as a value supported by the image.
Keep the raw transcription, the normalized value, confidence and the source region together. If the month and day are not certain, return an ambiguity state; if no reliable characters can be read, return unreadable. Do not fill a missing year from the current year or silently swap the month and day. The check OCR API describes check-date extraction alongside validation state and source evidence. A reviewer should be able to inspect the same pixels that produced the candidate date.
- Preserve the printed value — keep the transcription exactly as read before normalizing it to a machine date.
- Keep uncertainty explicit — store confidence and an unreadable or ambiguous status instead of returning a guessed date.
- Keep the image region — let a reviewer see the date field in context, including nearby marks that may change the reading.
Compare two dates, not one
A stale-date check needs both the date printed on the check and the date it was presented. The second value usually comes from the deposit or capture event, not from the check image. Store its source and timestamp separately. Without that context, the system can extract a date but cannot reliably say how old the item was when it entered the queue.
For a concrete example, a check dated April 1 and presented on October 2 has crossed the “more than six months” comparison described in the federal commentary. A check dated April 2 and presented on October 2 has not crossed that same boundary. A policy may still consider other information; the example only shows why the comparison needs exact dates and a clearly defined rule.
Dates also travel through locale settings and downstream systems. Preserve the original string, the normalized calendar value, the presentation timestamp and the time zone used by the workflow. If the image says 03/04/2026 and the source does not establish the date format, do not make the output appear more certain than the document.
Design the route around evidence
A practical workflow keeps extraction and handling separate. It records what the check appears to say, how confident the reading is, what other event date was used for comparison, and which policy route was selected. The audit trail should retain the original image, the date region, the model or rule version, any reviewer correction and the final routing outcome.
That record makes three common outcomes easier to distinguish: a readable date that appears older than the configured threshold, a readable future date that requires the institution’s notice and policy context, and a date that cannot be read confidently enough to compare. It also keeps later review from turning a low-confidence OCR result into a claim that the bank received a particular date.
This boundary matters in duplicate check review too. A date can help explain a pair, but it is not enough to establish that two captures are the same instrument. The duplicate-check guide explains why routing, account and serial fields are the identity evidence, while payment amount and image details provide context for review.
What to return to the payment queue
A useful extraction record makes each next step traceable without pretending that OCR has resolved policy:
- Check date — raw text, normalized value when supported, confidence and image coordinates.
- Comparison date — presentation or deposit timestamp, source system and time zone.
- Date state — readable, appears stale-dated, appears post-dated, ambiguous or unreadable.
- Review evidence — image region, notice record where applicable, policy identifier and reviewer disposition.
Cogneris can extract a check date and flag missing or unreadable fields for review. The payment institution’s rules and the available document evidence determine what happens next. When the date is clear, the record can support a comparison. When it is not, the right result is an explicit uncertainty that a person can resolve.
Sources
- 12 CFR Part 229, Appendix E — commentary on stale-dated and post-dated checks under the reasonable-cause exception.
- 12 CFR § 229.13 — exceptions to funds-availability requirements, including reasonable cause to doubt collectibility.
- Consumer Financial Protection Bureau: post-dated checks — consumer overview of notice, state law and institution policy.