Dual Dating Subsequent Event Footnote Usage Lookup
Check subsequent-event chronology, dual dating for supplied adjusting events, and note disclosure for supplied nonadjusting events.
Description
Subsequent-event treatment involves chronology, recognition and disclosure.
Subsequent-event treatment involves chronology, recognition and disclosure. This screen applies entered treatment labels rather than deciding their applicability.1
The returned values include Event chronology valid, Disclosure requirement satisfied, Dual date required, Dual date satisfied, Event treatment. The How section below explains the calculation, input rules and interpretation.
When to use Dual Dating Subsequent Event Footnote Usage Lookup
Use Dual Dating Subsequent Event Footnote Usage Lookup when you need to evaluate the supplied records under the calculation and evidence rules below. This blanket dual-dating rule is the embedded screen, not a complete standard: report issuance timing and auditor knowledge are absent. Recognition/disclosure facts are not verified.
Prepare source-backed observations and the applicable engagement policy before entering facts. Use consistent monetary units and periods. Supply all boolean evidence flags explicitly, and treat a successful screen as a reason to continue professional review.
How to use Dual Dating Subsequent Event Footnote Usage Lookup and understand its results
- Prepare source-backed observations and the applicable engagement policy before entering facts. Use consistent monetary units and periods. Supply all boolean evidence flags explicitly, and treat a successful screen as a reason to continue professional review.
- Enter dualDated, eventDate, eventType, financialStatementDate, notesDisclosed using the field table and calculation rules, then run the tool.
- Read chronologyValid, disclosureSatisfied, dualDateRequired, dualDateSatisfied, treatment. The explanation below defines the units, signs, ordering and any flags or placeholder values.
- If the tool reports an input issue, correct the values and run it again. Apply the stated assumptions when interpreting a successfully returned result.
| Input field | Meaning | Value type; see rules below | Requirement |
|---|---|---|---|
| dualDated | Financial statements dual dated | boolean | Required |
| eventDate | Event date | string | Required |
| eventType | Event type | string; one of "adjusting_subsequent", "nonadjusting_subsequent", "recognized_subsequent" | Required |
| financialStatementDate | Financial statement date | string | Required |
| notesDisclosed | Event disclosed in notes | boolean | Required |
Require real exact calendar dates, exact type and two booleans. Return chronology flag; no error for an earlier event. Dual date required only for adjusting label and satisfied when not required or supplied. Disclosure satisfied except nonadjusting needs notes flag. Return unchanged treatment.
chronology=event≥statement; requiredDual=type adjusting_subsequent Units, indexing, boundary conditions and exceptional cases are defined in the calculation rules above.
| Output field | Meaning | Value type |
|---|---|---|
| chronologyValid | Event chronology valid | boolean |
| disclosureSatisfied | Disclosure requirement satisfied | boolean |
| dualDateRequired | Dual date required | boolean |
| dualDateSatisfied | Dual date satisfied | boolean |
| treatment | Event treatment | string; one of "adjusting_subsequent", "nonadjusting_subsequent", "recognized_subsequent" |
{
"input": {
"dualDated": true,
"eventDate": "2026-02-10",
"eventType": "adjusting_subsequent",
"financialStatementDate": "2026-01-31",
"notesDisclosed": false
},
"output": {
"chronologyValid": true,
"disclosureSatisfied": true,
"dualDateRequired": true,
"dualDateSatisfied": true,
"treatment": "adjusting_subsequent"
}
}Limitations and assumptions
This blanket dual-dating rule is the embedded screen, not a complete standard: report issuance timing and auditor knowledge are absent. Recognition/disclosure facts are not verified.
Numeric inputs, where present, must be finite. Follow the calculation-specific rules for overflow, underflow and exceptional cases. Extremely large text inputs are rejected. Missing fields without a declared default, extra fields, wrong value types and violations of the calculation rules are input errors. A successfully returned false flag is an evaluated outcome; its meaning is explained above.
Alternative or Complementary methods
Use Subsequent Disbursement Postdated Check Review Window: A subsequent-payment review window has both a day-offset allowance and an explicit end date. A payment must fit both constraints. For a complementary task, use Emphasis of Matter or Other Matter Paragraph Selector: Additional report paragraphs and opinion modifications address different reporting needs. A required modification cannot be replaced by a paragraph.
References
Similar or alternative tools
- Subsequent Disbursement Postdated Check Review Window
A subsequent-payment review window has both a day-offset allowance and an explicit end date. A payment must fit both constraints.
- Emphasis of Matter or Other Matter Paragraph Selector
Additional report paragraphs and opinion modifications address different reporting needs. A required modification cannot be replaced by a paragraph.