In September 2023, the SEC's Division of Corporation Finance published a sample letter to companies regarding their XBRL disclosures. The letter contains nine categories of illustrative comments the Division may issue when it reviews XBRL and Inline XBRL submissions. The publication was a signal: the SEC is not treating XBRL compliance as a secondary concern. Structured data is how the staff, regulators, academic researchers, and data services consume public company disclosures at scale, and errors in that data undermine the utility of the entire disclosure ecosystem.
This post maps the error categories the SEC actually comments on, what they look like in practice, and what the EDGAR Filing Manual and the SEC's own guidance require for each. The errors are not exotic. Most are the result of specific, correctable practices in how tagging work is scoped, assigned, and reviewed before submission.
What Is XBRL Tagging and Why Does the SEC Review It?
XBRL (eXtensible Business Reporting Language) is the structured data format the SEC requires for financial statement data in most periodic filings. Since the phased mandates that began in 2009 for large accelerated filers and completed in 2020 for smaller filers, all domestic public companies submitting Forms 10-K, 10-Q, and 20-F are required to submit financial statement data in Inline XBRL (iXBRL) format, where the machine-readable tags are embedded directly in the HTML document rather than submitted as a separate file.
The SEC's EDGAR system performs automated validation of every XBRL submission. The validation checks syntax, taxonomy compliance, calculation consistency, and a set of filing rules specified in the EDGAR XBRL Guide, which the SEC staff updates continuously with the most recent version as of May 2026 incorporating changes through 2026. Validation errors at the system level produce error codes and, depending on severity, can cause a filing to be rejected before it is accepted by EDGAR.
Beyond automated validation, the Division of Corporation Finance reviews XBRL submissions as part of its periodic filing review programme. Human reviewers examine element selection, element consistency across periods, the use of custom extensions, calculation relationships, and the tagging of specific required data points including the pay-versus-performance table elements mandated under the 2022 executive compensation disclosure rules. These human reviews are the source of the comment letters the 2023 sample letter describes.
The consequences of XBRL errors range across a spectrum. Minor errors that pass EDGAR validation but reflect inconsistent or non-standard tagging practices generate comment letters requiring explanation and remediation in future filings. Calculation errors that cause the machine-readable data to not foot generate stronger comments. Failure to include required iXBRL tagging at all, as opposed to incorrect tagging, can constitute a deficiency in meeting the filing requirements.
What Are the Five Categories of XBRL Errors the SEC Comments On?
The SEC's 2023 sample letter organises its comments around several error patterns. Practitioner experience with XBRL comment letters over the period since that letter was published supports grouping those patterns into five operational categories, each with its own characteristics and remediation approach.
Category 1: Missing or incomplete required iXBRL tagging
The most direct category of error is the absence of iXBRL tagging for items that are required to be tagged. The SEC's sample letter specifically calls out the pay-versus-performance table data points required under Item 402(v) of Regulation S-K, noting that filers must ensure they have provided appropriate Inline XBRL tagging for all required data points in that table.
The 2022 pay-versus-performance rules introduced specific required XBRL elements for compensation actually paid, total shareholder return, and the other data points in the PvP table. Because these requirements were new and the elements are separate from the core financial statement taxonomy, some filers failed to include the required tags or tagged incorrect elements. The SEC has continued to issue comments on incomplete PvP tagging in subsequent filing cycles.
Beyond PvP, the completeness of tagging across the financial statements is a basic requirement. Every financial statement amount that has a standard element in the US-GAAP taxonomy must be tagged with that element. Untagged amounts that have no technical explanation are a disclosure deficiency.
Category 2: Inconsistent element selection across reporting periods
The sample letter directly identifies this error: "You have used different XBRL elements to tag the same reported line item on the income statement from period to period." The comment continues: if you conclude that the change from period to period was not necessary to communicate a change in the nature of the line item, confirm that you will ensure your choice remains consistent for line items from period to period.
This error is more common than it appears. It arises when different team members are responsible for tagging in different periods, when a vendor is replaced between filing cycles, or when a new staff member makes element selections without reviewing what was used in the prior period. The machine-readable data that data consumers and the SEC use to build time-series from public company filings relies on consistency of element selection. When the same financial statement line item appears under a different XBRL element in consecutive periods, the time-series breaks.
The remediation standard is clear: the tagging team must document the element selected for each line item and review that documentation at the start of each new filing cycle before making any element changes. Where a change is genuinely warranted by a change in the nature of a reported item, the company should be prepared to explain the accounting basis for the change.
Category 3: Custom extension tags where standard elements exist
The sample letter identifies this directly: "We note that instead of using an XBRL element consistent with current U.S. GAAP in your income statement, you instead used a custom tag."
Custom extension tags are permitted in the US-GAAP taxonomy when a company has a financial statement line item for which no standard element exists. They are not permitted as a substitute for standard elements that do exist. The US-GAAP taxonomy, maintained by FASB, contains thousands of elements. The default position for any financial statement amount should be a standard element. A custom tag should be used only after the filer has documented that no standard element adequately represents the reported item.
In practice, custom tags accumulate when the tagging process is under time pressure at the back of the filing cycle. When the person responsible for tagging cannot quickly identify the right standard element, creating a custom tag resolves the immediate problem while creating a longer-term compliance issue. The SEC staff sees custom tag rates in submissions and will question high rates even when individual custom tags may be technically defensible.
The remediation approach is to build a company-specific element map that documents the standard element selected for each recurring line item in the financial statements, updated each time the taxonomy is updated. Using that map as the starting point for each period's tagging process reduces both the search time and the pressure-driven use of custom tags.
Category 4: Sign and calculation errors
Sign errors are among the most mechanically common XBRL errors and among the most consequential for the integrity of the machine-readable data. The EDGAR Filing Manual Rule 6.6.30 states that the sign of a numeric fact should be inverted only when the balance type of the element is inconsistent with the reported concept. Expenses, losses, and other deductions have negative balance types in the US-GAAP taxonomy. When those amounts are presented in parentheses in the financial statements to indicate deduction, the XBRL tag must still carry the correct sign the parenthetical presentation in the document is a display convention, not an instruction to invert the sign of the tagged value.
Calculation errors occur when the mathematical relationships declared in the company's XBRL linkbase do not match the arithmetic in the financial statements. If the tagged value of revenue minus tagged cost of goods sold minus tagged operating expenses does not equal the tagged value of operating income, EDGAR's validation will flag the calculation inconsistency. These inconsistencies most commonly arise when new line items are added to the income statement or balance sheet between periods without updating the calculation relationships.
The most reliable prevention for sign errors is automated validation before submission. EDGAR provides an online validation tool, and most professional XBRL software performs validation as part of the tagging workflow. A filing that has passed validation for sign errors and calculation consistency before submission is not immune from SEC comment on element selection or consistency, but it will not receive comments on arithmetic.
Category 5: Context, unit, and period errors
Every tagged value in an XBRL submission must be associated with a context that specifies the reporting entity, the reporting period, and the scenario if applicable. A balance sheet amount requires a point-in-time context (as of the balance sheet date). An income statement amount requires a duration context (for the period covered). Mismatches between the context type and the nature of the amount produce EDGAR validation errors.
Unit errors occur when the unit associated with a tagged value does not match the type of value. Monetary amounts must carry a currency unit. Share counts must carry a shares unit. Per-share amounts must carry a per-share unit. Ratios and percentages must carry a pure unit where appropriate. Context and unit errors typically produce EDGAR validation rejections before a filing is accepted, rather than subsequent comment letters, but they are worth including in any pre-submission review checklist because they can delay filing acceptance on the submission date.
Period errors arise when the period specified in the context of a tagged value does not match the reporting period of the filing or the comparative period. This can occur when the tagging process is copied from a prior period and the period dates are not updated, or when the comparative period presentation requires context dates that differ from those used in the primary period.
What Does the SEC's Own EDGAR XBRL Guide Require?
The EDGAR XBRL Guide is the primary technical reference for XBRL filers. As of May 2026, it has been updated through 2026 with changes incorporating current filing requirements. The Guide specifies the rules governing syntax, semantic consistency, calculation relationships, and the specific filing requirements that go beyond what the taxonomy specification alone requires.
Several Guide requirements are directly relevant to the error categories that generate comment letters.
Rule 6.6.25 requires that the value of any element in the US-GAAP taxonomy not exceed the value of any ancestor element in the same calculation linkbase. This rule formalises the mathematical consistency requirement and is the basis for the calculation consistency check that EDGAR performs automatically.
Rule 6.6.30, referenced above, governs the sign convention for numeric facts and is the regulatory basis for sign error enforcement.
The Guide also specifies the requirements for the format of context identifiers, entity identifiers, unit references, and label linkbase content. These technical requirements underlie the context and unit error category.
For companies whose XBRL preparation is performed by a third-party provider, the EDGAR XBRL Guide is the document that defines what the provider is responsible for delivering. Companies should confirm that their provider's quality review process includes verification against the current version of the Guide, which is updated periodically and does not always generate direct notification to filers.
How Does the SEC Use XBRL Data in Its Review Process?
Understanding how the SEC uses XBRL data helps clarify why certain error categories generate more attention than others.
The Division of Corporation Finance uses XBRL data to perform screening across large populations of filers. Time-series analysis of tagged financial data allows the staff to identify outliers, screen for unexplained changes in reported amounts, and compare disclosed figures across companies in the same industry. When an element inconsistency breaks a company's time-series, the company may be excluded from comparative analyses or may appear as an outlier for reasons unrelated to its actual financial performance. That is one reason the staff comments on element consistency: inconsistency in tagging makes it harder to use the data for the purposes the structured data mandate was designed to serve.
Custom tags also affect the utility of the data at scale. When a company uses a custom tag for an amount that should be tagged with a standard element, the amount is invisible to any analysis that relies on the standard element. A research tool querying for all filer values tagged with a specific revenue element will not return the custom-tagged value from a company that chose a custom extension. The company's data is incomplete in the aggregated dataset even if the human-readable document is complete.
According to XBRL US research on common filing errors, many common and preventable XBRL errors are still submitted each year at filing time. The errors that persist are largely the ones that do not cause EDGAR rejection they pass automated validation but produce non-standard or inconsistent structured data. These are precisely the errors that human review of XBRL quality identifies and that generate comment letters.
What Is the Remediation Process When the SEC Issues an XBRL Comment?
When the SEC issues a comment letter regarding XBRL tagging, the company's response process follows the same structure as any other comment letter but has specific technical requirements.
The company must provide a written response to each comment, typically within 10 business days of the comment letter date, though extensions are available. For XBRL comments, the response must address the specific error identified, explain how the error occurred, and commit to a remediation approach in future filings.
For element consistency comments, the response should confirm which element will be used going forward and provide the accounting basis for the choice. For custom tag comments, the response should either confirm that a standard element will be substituted or explain why no standard element exists and what the custom tag represents. For missing tagging comments, the response should confirm that the required elements will be included in the next filing.
In most XBRL comment letter situations, the SEC does not require an amended filing to correct historical XBRL data unless the error constitutes a material deficiency in meeting the structured data filing requirements. The more typical outcome is a commitment to correct the practice in prospective filings, with the response letter confirming that commitment.
Frequently Asked Questions
What does the SEC actually review in XBRL submissions?
The SEC's Division of Corporation Finance reviews XBRL submissions both through automated EDGAR validation and through human review as part of its periodic filing review programme. Automated validation checks syntax, calculation consistency, sign conventions, and context and unit requirements. Human review examines element selection, element consistency across periods, the appropriateness of custom extension tags, and the completeness of required iXBRL tagging including for the pay-versus-performance table elements required under the 2022 executive compensation rules.
What is the most common XBRL error that generates SEC comment letters?
Based on the SEC's 2023 sample letter and practitioner experience with EDGAR comment letters, the most common errors are inconsistent element selection across periods and the use of custom extension tags where standard elements exist. The SEC sample letter specifically calls out both: registrants who change elements from period to period without a change in the nature of the reported item, and registrants who use custom tags for income statement line items that have standard US-GAAP taxonomy elements available.
Can a company use custom XBRL tags for its financial statements?
Custom extension tags are permitted when a company has a financial statement line item for which no standard element in the US-GAAP taxonomy adequately represents the reported concept. They are not permitted as a substitute for standard elements that do exist. The default should always be a standard element, with custom extensions reserved for genuinely non-standard items. High rates of custom tag usage are a flag the SEC staff notices and may ask about, even if each individual custom tag could be individually defended.
What happens if the XBRL data does not foot?
If the calculation relationships declared in the XBRL submission do not agree with the arithmetic in the financial statements, EDGAR's automated validation will flag the inconsistency. Depending on the severity, this can prevent the filing from being accepted or generate a validation warning. If the inconsistency passes initial validation but is identified in a subsequent review, the SEC staff may issue a comment asking for explanation. Calculation consistency should be confirmed by automated validation before every submission.
Does the SEC require an amended filing to correct XBRL errors?
In most circumstances, no. The typical outcome of an XBRL comment letter is a commitment to correct the practice in prospective filings. The SEC does not typically require companies to file amendments solely to correct XBRL data unless the error constitutes a material deficiency in meeting the structured data filing requirements. The response letter should address each comment, explain the remediation, and confirm the prospective approach.
Key Takeaways
- The SEC's Division of Corporation Finance reviews XBRL submissions through both automated validation and human review. The 2023 sample letter identified nine categories of illustrative comments, covering missing tagging, element inconsistency, custom tag overuse, calculation errors, and context issues.
- The five operational error categories are: missing or incomplete required tagging, inconsistent element selection across periods, custom extension tags where standard elements exist, sign and calculation errors, and context, unit, and period errors. Each has a distinct cause and a distinct remediation approach.
- Element consistency across periods is the most consequential ongoing error for companies that have been filing for multiple years. Changing elements without a corresponding change in the nature of the reported item breaks the time-series the SEC and data consumers rely on.
- Custom extension tags should be the exception, not the default. Building a company-specific element map and reviewing it before each filing cycle is the most effective structural control against both custom tag overuse and element inconsistency.
- Automated validation before submission addresses the sign and calculation error category. Filing a submission that has passed validation for those errors does not prevent comments on element selection or consistency, but it eliminates a preventable category of comment entirely.
- When the SEC issues an XBRL comment letter, the response must address the specific error, explain how it occurred, and commit to a remediation approach. Amended filings are not typically required for XBRL errors unless the deficiency is material to the structured data filing requirement.
