Rules Development Process

The Data Quality Committee publishes approximately three rulesets per year. With every ruleset, a stringent 10-step development process is followed in order to ensure that the errors triggered by the rule are true errors that filers need to address before they submit their financial statements.

Step 1. Create draft rules.

Members of the DQC are corporate issuers, filing agents, database providers, academics, XBRL experts, accountants, and securities analysts, each with different expertise to contribute to the process of identifying problem areas and drafting rules to address them. Data consumers and analysts provide input on errors they find in filings. Database providers review and weigh in on errors they find in their own datasets. XBRL US staff copies all SEC filings into the XBRL US Database of Public Filings and analyzes the filings for common errors. Filing agents and XBRL tool providers review their work with clients. The DQC also meets with standard setters and the regulators on a regular basis to review the draft rules. Guided by input from these formal and informal channels throughout the business reporting supply chain, the DQC creates and prioritizes rules to be developed, exposed for comment, and released.

Each problem area is tackled in a single rule, for example negative values (that should be positive), or invalid use of combinations of axes and members are addressed in separate rules. Sometimes, the DQC researches and develops guidance for filers on specific accounting topics (eg. revenue, cash flow) and several rules are written to support the guidance

Step 2. Consider potential problems with each draft rule.

Once the prioritized draft rules are established, the DQC undergoes a process to evaluate the utility of each rule.

• What is the impact of the draft rule?
  Repercussions of an error must be significant enough that it merits flagging to filers.
• Does the error occur frequently among multiple filers?
  It might just be an anomaly that only affected a single filer and therefore may not be worthwhile to include in the ruleset.
• Is the rule clear and unambiguous and does the error message provide clear instructions to an issuer?
  If not, a rule should not be written.
• Might the rule result in “false positives”?
  Validation rules must be written considering every possible situation. For example, some concepts in the US GAAP Taxonomy should always be reported as positive values, except when certain dimensions are used with these concepts. Instances where dimensions are used may be rare, but it’s important that the rules handle all of these situations. The DQC rule for these kinds of concepts includes a list of exceptions so that if a filer uses one of these concepts without a dimension, he or she will get a negative value warning. But if he or she uses a concept with one of the “exception dimensions”, no warning will be triggered.Similarly, when a filer uses the 2019 release of the US GAAP Taxonomy, an error flag will appear if the filer uses a concept deprecated from the 2019 release. But if the filer is preparing a filing using the 2018 Taxonomy, and that concept was valid for the 2018 release, no error will be triggered.The DQC researches every rule for false positives using SQL queries against the XBRL US Database of Public Filings – a copy of all XBRL SEC filings that also includes historic data quality issue records. This is because the risk is too high that a filer will be led astray and waste time attempting to correct something that was right in the first place, and potentially introduce a new error into their filing.

Step 3. Write clear, unambiguous error messages.

Each rule must provide simple instructions that issuers can easily follow to correct their filing. It is important that each rule can be easily explained. Below are examples of error messages that filers receive when running the rules. These messages explain the error for the incorrect tagging found within a filing. Example #1 states that a fact reported for a certain concept must always be positive. Example #2 states that the value tagged for Assets must equal the value tagged for the element Liabilities plus Equity.

Step 4. Test the rules.

After the logic of the rule is finalized by a rule development team, it is converted to code (https://xbrl.us/xule) operable on an XBRL data model. Every draft rule is tested by running it against historical corporate filings. Reported values that trigger the draft rule are analyzed in detail to make sure that they are flagging errors appropriately and not generating false positives.

Step 5. Conduct public review of each rule.

The DQC makes all draft rules available to the general public as human-readable ‘rule submission forms’ (https://xbrl.us/public-review) for at least 45 calendar days. During that period, XBRL US schedules, promotes and hosts at least one public webinar to review the rules (and/or guidance) available. In addition, a tool on the XBRL US website (https://xbrl.us/check) is updated so that filers can run the software code for the draft rules themselves to check if their filing (historical or not yet submitted) triggers a draft rule. The public can also download the open source reference code for the rules from a github repository (https://xbrl.us/dqc-releases), test cases and .zip files to test rules with filings using desktop software (Arelle). The public can provide feedback (discussion, email, phone, online public review comment form) to the members of the DQC when an error has been triggered incorrectly or if the error message is not clear. This type of input is invaluable to ensure that the rules are clear, unambiguous, and accurate at identifying mistakes. Issuers, data providers, analysts, filing agents, and accounting professionals are strongly encouraged to review the rules and provide their input.

Step 6. Incorporate market feedback.

After the public review, which usually runs 45 days, all submitted comments are reviewed by the DQC and revisions may be made.

Step 7. Set Effective Rule date for each rule.

Each rule is assigned an effective date, typically 60-90 days after the approval date. Rules are expected to be implemented after the rule effective date.

 

Step 8. Approve rules through DQC. Publish the final ruleset.

Once the DQC formally approves the rules and the effective date is set, they are made freely available and can be used by filers directly on the XBRL US web site (https://xbrl.us/rules-guidance/), or are incorporated into filing agent processes and tool provider software.

XBRL US also certifies software that has been proven to successfully run the rules, flagging errors where appropriate. The DQC certification process is equally rigorous. The entire ruleset is incorporated into the software being tested, and run against historical XBRL SEC filing. Results generated through the software are analyzed to determine if errors are triggered in filings that are known to contain errors. If the results are not accurate, the XBRL US team works with the filing agent or software provider to make corrections, until the rules run smoothly and successfully, producing expected results.

The DQC also continuously receives market feedback on previously approved rules. If there is a need for a previously approved rule^[1] to be updated, the DQC reviews this feedback and the update to the rule is put through the entire process. Rules with an update are indicated as such on https://xbrl.us/rules-guidance and the rule submission form may also have an appendix to summarize the change(s).

Step 9. FASB Taxonomy team reviews rules and incorporates into DQCRT.

The Financial Accounting Standards (FASB) reviews each rule set and incorporates it into the DQC Rules Taxonomy which is included with the US GAAP Taxonomy.

 

Step 10. SEC adopts DQCRT with US GAAP Taxonomy.

The Securities and Exchange Commission (SEC) adopts the US GAAP Taxonomy which has the DQC Rules Taxonomy incorporated. Filers are alerted when their filing triggers an error from a DQC rule.

---

[1] Previously approved rules are updated as needed for updates to the taxonomy or if a false positive result is found.