Login and use the form below to provide general feedback on the public exposure drafts for these rules.
Data Quality Rules
Latest Rules (works with Arelle)
- Approved Rules (v27.0.9)
Test cases, documentation & scripts
(Travis CI) - Public Review Rules (v28.0.0RC7)
includes Approved Rules
Test cases, documentation & scripts
(Travis CI) - Rules Dev Team workspace
Developer Resources
- DQC Rules Validator (part of the XULE plugin for Arelle)
- XULE Editor extension for Visual Studio Code (What is XULE?)
- DQC Reference Implementation Code
Travis CI status -
- Global Rule Logic
Short summary: We suggest tightening up the applicability conditions of financial statement related rules.
Medium summary: The performance hit of the DQC rules running in EDGAR is considerable, but is not warranted for validation of instances like 8-K’s (our most voluminous instance by far) that could, but normally don’t contain financial statements, or other instances that may use a handful of us-gaap axes or members but aren’t financial statements.
Long version: As we reviewed FASB’s proposed DQCRT 2026 additions to EDGAR validation, we observed that in DQC_0159.xule there is this condition
$NonFinancialStatement = set(‘PRE-14A’,’PRE 14A’,’DEF-14A’,’DEF 14A’,’DEF-14C’,’DEF 14C’,’11-K’,’11-K/A’).contains([covered @concept.local-name =’DocumentType’]);
As the set of instance types continues to expand to new submission types and exhibits, we think that set could be updated, and in any other rules where the same could be tested.
We suggest you to consider using the EDGAR Filer Manual chapter 6 “instance type” codes which distinguish between instance that could have financial statements and those which definitely do not. Since these codes are used in the EXG to define non-DQC validations, that seems like a natural fit. They are defined in terms of underlying submission types and exhibit types, and are kept up to date, as we are likely to see many more “multi-instance” EDGAR filings going forward, so our own validity rules have to be scoped that way. Consistency would be beneficial.
Note also that instance contexts may incidentally touch one or two us-gaap or srt abstract axes or members, as a result of our effort to not duplicate concepts – but the instances don’t contain financial statements, and the performance hit is actually a discouragement to that reuse effort. (Reuse of us-gaap and srt elements complicates taxonomy-specific EXG rules as recently noted with respect to the SPAC validations).
It’s possible to tighten conditions even further, if it is possible in XULE to look at the set of roleTypes declared in the DTS. If there are NO presentation relationships with a role whose link:definition text contains the string ” – Statement – ” as per EXG 10.2, then there really isn’t anything that the filer would have considered a financial statement.
Whether you want to have a general approach that each rule should positively state “only apply to instance types a, b, and c” or negatively state “does not apply to instance types x, y, and z” probably depends on the nature of the rule itself; it would be difficult to enforce a blanket style for every rule. Partitioning the rules into blocks with shared applicability conditions would be helpful.