ASC 855: Recognized vs. Disclosed Subsequent Events
Something happens after your balance sheet date but before your financial statements go out the door. Does it change a number in the financials, or does it just get described in a footnote? ASC 855 answers that question, and classifying a subsequent event in the wrong category is an easy mistake to make, so auditors look at it closely.
The standard splits subsequent events into two types, and the difference between them is really a question of timing: did the underlying condition already exist at the balance sheet date, or did it arise afterward?
Vendors Covered in this Article
Disclosure: We may earn a commission if you buy through some links on this page. It doesn't change what we recommend.
Type I: Recognized Events
A Type I subsequent event provides additional evidence about a condition that already existed at the balance sheet date. The event itself happens after year-end, but it tells you something about a situation that was already true on the balance sheet date, so you adjust the financial statements themselves to reflect it. A customer that was already struggling at year-end and then files for bankruptcy a few weeks later is a Type I event: the bankruptcy filing confirms a collectibility problem that existed at year-end, so you adjust your allowance for doubtful accounts to reflect it.
Type II: Disclosed-Only Events
A Type II event arises from a condition that didn't exist at the balance sheet date at all; it's genuinely new. You don't adjust the financial statements for it, but if it's significant enough that omitting it would make the financials misleading, you disclose it in a footnote describing the nature of the event and, where possible, an estimate of its financial effect. A major fire that destroys a facility three weeks after year-end is a Type II event: nothing about that loss existed at year-end, so the balance sheet doesn't change, but the footnotes need to say what happened.
A new debt issuance, a new lawsuit filed against you for something that happened after year-end, or a major new customer contract signed after year-end all fall into this same bucket: real and often significant to a reader of the financials, but not something that changes a number that was already true as of the balance sheet date.
A Worked Comparison
Say two things happen in the three weeks after your fiscal year-end: a long-standing customer with pre-existing payment problems finally defaults, and separately your company signs a brand-new, unrelated acquisition agreement. The customer default is Type I, because the payment problems existed at year-end and the default just confirms them, so you adjust your receivables and bad debt reserve. The acquisition is Type II, because nothing about that deal existed at year-end; it gets described in the footnotes with the material terms, but it doesn't change any number on the balance sheet itself.
The Evaluation Period Is Not the Same for Every Company
The window you're evaluating subsequent events through runs from the balance sheet date up to the date your financial statements are actually issued, or for a nonpublic company using a slightly different standard, up to the date they're available to be issued, which can be earlier than the date they're technically distributed. Confirm which standard applies to your company, since using the wrong end date for your evaluation period can mean missing an event you were actually required to consider.
What Auditors Look for in Your Subsequent Events Memo
A good subsequent events memo doesn't just list what happened after year-end; it documents the analysis of why each item was classified as Type I or Type II, including the date the underlying condition arose versus when it was discovered. Build this memo as part of your normal closing process, updated right up until the financials are actually issued, rather than as an afterthought written the week the audit fieldwork happens, since a late-breaking event between your draft memo and the actual issuance date still needs to be captured.
A strong subsequent events memo documents the following:
- The date each underlying condition arose, kept separate from the date you discovered it.
- Whether each item is Type I or Type II, with the reasoning behind that classification.
- The end of your evaluation period, whether that's the issuance date or the date the statements are available to be issued.
- Updates made through issuance, not only through the start of audit fieldwork.
- For Type II items, the footnote wording that describes the nature of the event.
The Mistake of Treating This as a One-Time, Pre-Audit Task
Teams often draft the subsequent events memo once, right before fieldwork starts, and then treat it as finished. But the evaluation period doesn't close until issuance, which can be weeks after fieldwork wraps up. If something material happens in that gap, a covenant breach on a loan, the loss of a major customer, a lawsuit settlement, it still needs to go through the same Type I or Type II analysis and potentially update your disclosures before the financials actually go out, even if the audit itself is technically done.
What Good Looks Like
A good subsequent events process documents every post-year-end item against a clear Type I versus Type II analysis, updated continuously through the date the financials are actually issued.
Building The Capability (5-Stage Skill Ladder)
How to Get Started
Disclosure: We may earn a commission if you buy through some links on this page. It doesn't change what we recommend.
Use it to keep your subsequent events memo and supporting documentation organized alongside your other year-end audit evidence.
Use it if your broader compliance evidence already lives in one system and you want the subsequent events review tracked with the same audit trail.
Frequently Asked Questions
What's the simplest way to tell Type I from Type II?
Ask when the underlying condition started, not when you found out about it. If the condition already existed at your balance sheet date and the later event just confirms or clarifies it, it's Type I and you adjust the numbers. If the condition itself is new and arose after year-end, it's Type II and you disclose it instead.
Do we need to disclose every subsequent event, even small ones?
No. Type II events only need disclosure when omitting them would make the financial statements misleading to a reader, which is a materiality judgment. A minor, routine event after year-end usually doesn't warrant a footnote at all.
When does our subsequent events evaluation period actually end?
It runs through the date your financial statements are issued, or for many nonpublic companies, the date they're available to be issued, which can be earlier. Confirm which standard applies to your company with your auditor, since using the wrong cutoff can mean missing an event you were required to evaluate.
About the numbers
This guide doesn't quote a sourced benchmark. Figures in it are estimates or general guidance, so check them against your own numbers.
Related Guides
ASC 205-40: When You Have to Disclose Going Concern Doubt
The specific test management has to run every reporting period for going concern doubt, what counts as a mitigating plan, and how to document the analysis.
Building a Deferred Revenue Waterfall for Multi-Year SaaS
Build a deferred revenue waterfall for multi-year SaaS contracts, from ratable recognition to seat-add modifications, and tie it to the balance sheet at close.
Building Your ASC 740 Tax Provision, Line by Line
Your effective tax rate rarely matches the statutory rate. See how to build an ASC 740 provision step by step and explain the gap in a reconciliation.
ASC 350-60: Fair Value Accounting for Crypto, and the Tax Gap It Creates
Crypto holdings now get marked to fair value on the books, but tax still follows realization. Here's what that mismatch means for your deferred tax accounting.
ASC 842: Capitalizing a Lease, Step by Step
A worked example of ASC 842 lease capitalization: calculate the lease liability, build the right-of-use asset, and handle exemptions and embedded leases.
How to Recognize Revenue on Usage-Based AI Billing
Token-metered contracts don't fit a simple monthly revenue model. Here's how to apply ASC 606 to prepaid credits, overage fees, minimums, and breakage.