← Quantery Blog

What XBRL can and cannot tell a stock screen

October 8, 2026 · 8 min readthesis-craftsec-filingsdata-quality

XBRL turns facts in SEC filings into labeled data a machine can read. It lets a stock thesis compare revenue, cash flow, debt, and other statement values across companies without somebody retyping each filing. It doesn't make those facts automatically comparable or correct. The tag is a map to the reported fact, and maps can be incomplete or wrong.

That distinction matters whenever a rule looks precise. A ratio may be calculated perfectly from an issuer-specific tag, a mismatched period, or a value placed under the wrong statement section. The result is still arithmetic. It just isn't the arithmetic you meant to test. Build the rule from standardized fields and let missing inputs fail. When a result owes too much to one surprising number, open the filing.

What does XBRL add to an SEC filing?

XBRL, short for eXtensible Business Reporting Language, attaches machine-readable labels to reported facts. Inline XBRL embeds those labels in the filing's HTML. The SEC describes it as a way to prepare one document that is both human-readable and machine-readable.

Think of the visible filing and its structured layer as two views of the same report. A reader sees the income statement line labelled revenue. Software sees an element, a value, a reporting period, units, and a context identifying which entity the fact belongs to. With those pieces, a research tool can place the value in a time series and compare it with the corresponding field from another filer.

That machinery is why a rule can say ttm(revenue) and evaluate filed quarters across US equities. It also explains why the source document still matters. XBRL labels what the company reported. It doesn't decide whether revenue is sustainable, whether a debt balance is dangerous, or whether two business models deserve the same threshold.

The taxonomy is the common dictionary. It includes standard elements for familiar concepts such as revenue and net income. Filers can create custom tags, also called extensions, when the standard taxonomy doesn't provide an appropriate element for a company-specific disclosure. The SEC's current custom-tag analysis covers annual filings for fiscal years 2012 through 2025.

Extension doesn't mean error. A specialized contract asset or industry-specific cost may need a more precise label than the standard dictionary supplies. The trouble begins when a custom tag duplicates a standard concept or changes from one period to the next without an economic reason. A parser now has to decide whether two labels represent one continuing series. If it guesses, your trend rule inherits the guess.

How can a correct filing produce a bad comparison?

There are several links between the number printed on a statement and the feature your thesis scores:

1. The filer chooses an element.
2. The filer assigns the period and other context.
3. The fact is placed in the statement hierarchy.
4. Your data pipeline maps that fact to a field.
5. Your feature combines the field with other periods or values.

A mistake at any link can survive as a plausible number. That's what makes tagging defects awkward. A badly scaled value may be obvious. A current quarter attached to the wrong year can look normal until a year-over-year comparison jumps.

The SEC has published specific reminders because these aren't imaginary edge cases. In its guidance on tag continuity, staff said that inconsistent element selection hinders comparison across filers and across a filer's own periods. A company can use one element in a quarterly filing and another in its annual filing for the same reported item. Unless the accounting meaning changed, that split can turn one economic series into two machine-readable histories.

Context creates a different failure. In a data-quality reminder on context dates, SEC staff reported that some filers had attached incorrect dates to facts in annual and quarterly filings. A value can belong to the right line and still land in the wrong period. For a thesis that uses lag(revenue, 4), that isn't clerical trivia. It changes which facts enter the growth calculation.

Presentation hierarchy matters too. SEC staff reviewed selected annual and quarterly filings submitted during 2023 and found cash-flow elements under the wrong parent sections. Its cash-flow presentation reminder gives concrete examples: income taxes paid and exchange-rate effects placed under financing, and long-term debt repayments placed under investing. Correct structure helps data users locate and group facts. Put the fact in the wrong branch and a section-based pipeline may miss or misclassify it.

Structured filings are still fit for research. Structured data is the fast route back to a filing. It can't replace the filing.

Why do familiar metrics still need null guards?

Suppose a thesis compares earnings per share across periods. Basic EPS and diluted EPS are separate concepts even when a company prints one shared value because they happen to match. SEC staff found three tagging problems in selected filings submitted during 2024: filers created a custom combined-EPS tag, tagged the amount only once, or used an element that had been deprecated in 2022. The agency's EPS tagging reminder says those practices hurt data usability.

A weak pipeline can turn that defect into false evidence, for instance by copying basic EPS into the diluted slot whenever diluted EPS is absent. Zero-filling the gap or borrowing an older quarter's value does the same damage by a different route. Every one of those workarounds produces a number, and sometimes the number matches nothing the company reported this period.

The safer thesis makes missingness visible. This illustrative shape uses statement fields supported by the DSL, but the bundled templates remain the reference for exact fields:

# Filing continuity check: illustrative
params:
  min_history: 5
  growth_floor: 0.05

features:
  revenue_now: newest(revenue)
  revenue_year_ago: lag(revenue, 4)
  revenue_growth: if(revenue_year_ago > 0, revenue_now / revenue_year_ago - 1, null)
  cash_now: newest(operating_cash_flow)

quality:
  required:
    revenue_now: no_current_revenue
    revenue_year_ago: no_year_ago_revenue
  flags:
    - { when: "history_periods < $min_history", flag: short_history }

criteria:
  growth:
    rules:
      - { when: "is_null(revenue_growth)", score: 0, flag: no_comparable_growth }
      - { when: "revenue_growth >= $growth_floor", score: 2 }
      - { when: "revenue_growth > 0", score: 1 }
      - { else: 0 }
  cash:
    rules:
      - { when: "is_null(cash_now)", score: 0, flag: no_current_cash_flow }
      - { when: "cash_now > 0", score: 2 }
      - { else: 0 }

gate:
  mode: strict

The thresholds are proposed research parameters. No prior-year revenue means no growth score. No current cash-flow fact means no cash score. A thesis shouldn't turn a broken series into a confident ranking.

This extends the null policy in the Piotroski F-score walkthrough: missing data earns no point. It also explains why trailing and same-quarter comparisons need enough filing history before they mean anything. XBRL makes those comparisons scalable. The quality rules decide when the scale has outrun the evidence.

How should you audit a surprising stock-screen value?

Start with the feature, then walk down. Don't begin by searching for a story that makes the output sound sensible.

Open the matched criterion and confirm the rule that awarded the score. Then expand the calculated feature into its inputs. Check the field name, fiscal period, period end, filed date, units, and source. A trailing value should unfold into the periods that were summed. A ratio should expose both sides. If the filing identity is available, open the EDGAR document and find the visible statement line.

Quantery's number-audit workflow follows that chain from gate to rule to feature to filing. It also separates the value saved with a run from a current re-evaluation. Keep that distinction. A later backfill may repair a mapping, but today's repaired value isn't proof of what an older run saw.

Pause when the visible statement has a line that the standardized field shows as null, or when a feature jumps while the neighboring statement lines barely move. If a year-over-year comparison is pulling fiscal periods or filing dates you didn't expect, go back to the context-date problem above before you trust it.

These discrepancies are prompts to inspect the tags and context. They aren't evidence that the company did something suspicious. A tagging defect is a data-quality finding, and an unusual accounting choice is an accounting finding. Neither gets you anywhere near a fraud claim.

If the value can't be resolved, remove that company from this version of the test or remove the feature until coverage is defensible. Don't patch one ticker by hand and continue calling the rule market-wide. A manual exception changes the procedure and can't be replayed cleanly in a backtest.

What does this change in thesis design?

Concepts with broad, stable definitions travel best. Revenue, total assets, and net income aren't free from mapping problems, but they have a stronger common vocabulary than management-defined measures such as organic sales or adjusted operating profit. Keep company-specific measures in the reading layer unless you can define a repeatable mapping across the intended universe.

Coverage deserves its own test, and it should come before any return figure. Count whether each required value exists on every historical decision date. Break missingness out by period and industry. A great result from the subset with clean tags can be a result about clean-tag coverage.

Then there's provenance. A calculated feature should lead back to the exact periods used, with the filing date attached. That's how you distinguish a genuinely new fact from a remapped old one. Every number showing its work is useful here because the audit trail belongs to the result itself.

Backtests remain hypothetical and exclude costs. They add another limit: historical parsing quality can change as taxonomies and mappings improve. Point-in-time values stop future filings from leaking backward, but they don't make an incorrectly tagged fact correct. That's why coverage and outliers come before the return line. If a material data repair lands later, rerun the preserved thesis so the old report keeps meaning what it meant.

A machine-readable filing lets you ask the same question across a market. It doesn't relieve you of defining the question or checking the strange answers. Lean on the standard field as far as it holds and let the rule return null past that point, so every score can still be traced to the report that supplied it. Then the rules stay yours all the way down to the source.

Want to try this on your own rules? Quantery is free for 14 days: the full app, no card required.

← All articles