What validation checks
Validation compares a tagged filing with a set of rules and reports where it falls short. The rules come from more than one place: the XBRL specifications, which say what a well-formed file is; the taxonomies, which say what each concept means and how it may be used; and the filing rules of the regulator, which say what a filing of a given type must contain.
The taxonomy matters more than it first appears. It does not only name concepts; it also limits how they can be combined.
The taxonomy specifies, for every concept, which dimensions are required, permitted or forbidden, and EDGAR validates each XBRL instance against the relevant taxonomies.
Every filing on EDGAR is validated before it is accepted.
That second point is the reason to validate early. A filing is checked on its way in whether or not the preparer has checked it first, so the only question is who finds the problem and when. Finding it in the working copy, days before the deadline, costs a correction. Finding it on the last evening costs a scramble.
XBRL errors and XBRL warnings
The findings fall into two classes, and the difference is about consequences, not about how bad the finding looks.
Generally, a failed validation is either an XBRL error, which may cause suspension, or an XBRL warning, which does not.
When validation of an instance produces an XBRL error, all the file attachments that make up that instance are normally removed, and whether the filing is suspended can vary.
The practical reading is simple. An XBRL error is a finding you cannot leave in a filing you intend to rely on, because the attachments that make up the instance may be removed and the filing may be suspended. Nobody can predict from the finding alone how the second part will go, so the safe course is to clear every error.
An XBRL warning is different, and it is easy to underrate.
XBRL warnings indicate that facts in the instance are incomplete, inconsistent with each other, misleading, ambiguous or unreliable, and filers should correct the data before the live filing.
A warning does not stop a filing, but the staff describes what it points to: facts that are incomplete, inconsistent, misleading, ambiguous or unreliable. Those are the faults a reader of the data would most want to know about. A warning is therefore a prompt to look, and to correct or to decide, before the live filing and not after it.
Decide what stops your approval
Between a finding and an approval there is a decision about what must be cleared first. Call it the gate. The gate is not set by the software or the regulator. It is a policy that your team sets, writes down, and applies in the same way to every filing.
A sound default is the following.
- Errors stop the work. No section is approved, and no filing is released, while an XBRL error remains open. There is no good reason to carry a known error forward.
- Warnings are resolved or explained. Each one is either corrected or left in place for a stated reason that a named person has accepted, and the reason is recorded where the next reviewer will find it.
- Nothing is dismissed in bulk. A finding cleared without being read is a finding that will come back later.
Be clear about what your own tools enforce. Tools differ in which findings they treat as stopping the work and which they only report, and a tool’s own definition of a serious finding need not match the regulator’s. If your tool reports some findings without stopping on them, your gate has to cover them in the policy, because the software will not. Decide in advance which findings your team treats as blocking, write the list down, and review it before each season.
Triage a long list
A first validation of a large filing can return hundreds of findings. Read them as symptoms and not as separate problems. One wrong concept used across forty facts produces forty findings, and one correction clears them all.
- Sort by severity first, then by section. Look at the errors, then at the warnings, and take each group a section at a time so one reviewer can hold the context.
- Group by cause. Findings that share a message and a concept usually share a fix. Fix the cause once and run validation again before touching the next group.
- Fix structure before detail. Problems with periods, units or dimensions can produce a flood of secondary findings, and many vanish when the first is corrected.
- Re-run after every batch. The list you started with is not the list you have after ten fixes, so never work from a stale one.
- Record what you leave. For each warning you decide to keep, note the finding, the reason and who accepted it.
Triage is also where a team learns. If the same kind of finding comes back every quarter, the cause is upstream, in how a table is prepared or which concept a team habitually chooses, and the cheapest fix is to change that habit.
Calculation inconsistencies
Some findings say that a total does not equal the sum of its parts. These are calculation inconsistencies, and they deserve a careful and calm reading.
The EDGAR XBRL Guide says that calculation inconsistencies have no effect on the validity of a filing.
That is a statement about validity, and it should be read for what it says. It does not say the arithmetic is unimportant. A total that differs from its parts can be a rounding effect that the table already explains, or it can be a wrong number, a wrong sign or a missing row. A reader who sums the column will notice either way.
- Check each inconsistency against the source table. If the printed figures also fail to add, the cause is rounding or an error in the document, and the tagging is faithful to it.
- If the printed figures add and the facts do not, look for a sign, a scale or a period that differs between components.
- Do not suppress a calculation finding until you know which of the two it is.
A related fault is the same fact tagged in two places with different values.
The same fact may be tagged in more than one place, and inconsistent numeric values, or non-numeric values that are not identical, produce XBRL errors.
Unlike a rounding difference, this is a plain inconsistency: one figure cannot have two values. Decide which value is correct, change the other, and make sure the table and the narrative say the same thing.
Validate early, preview late
The staff describes a sequence that is worth copying as a routine.
The staff's sequence is to validate the instance, interpret and correct the errors and warnings, preview the filing as it will be rendered on SEC.gov, and then validate the entire filing, usually as a test filing.
Read it as two habits. Validate often, from the first tagged section onward, because small lists are easy to clear and big ones are not. Preview late, once the content is stable, because the preview shows how the filing will look to a reader and that is a different question from whether the tags are legal.
EDGAR has an Inline XBRL Viewer built in, so viewing an Inline XBRL filing needs no specialized software.
Because the viewer is built in, nobody needs to install anything to look at a filing as a reader will. Put the preview on the calendar as its own step with its own owner, ahead of the deadline, and read the rendered pages with the question of whether each figure sits where a reader expects it.
Finally, treat a clean validation as the start of review and not the end of it. Validation finds the faults it has a rule for. It does not find a figure that is legal and wrong, and for that you still need a person who reads the filing as a reader would.
How Disclose IQ approaches it
- Validation runs when you choose, and the errors that block approval are listed apart from the warnings.
- Findings are grouped as errors and warnings, and a filter shows only the errors that block approval.
- An error marked Blocking stops approval. Other findings stay listed at their real severity, so your reviewers can see and decide on each one.
- A finding tied to a fact links to that fact in the document.
General information, not legal advice. Read the current form and rules.