A number needs an identity
A database cell containing 25000000 does not by itself identify a financial fact. The number might be quarterly revenue, cash at year-end, shares outstanding or a loan balance. XBRL, the Extensible Business Reporting Language, associates reported values with concepts and context so software can distinguish these possibilities. XBRL International describes the basic components as facts, concepts, taxonomies and instance documents. [1]
A useful hypothetical fact is more specific: a particular company reports $25 million of cash and cash equivalents as of December 31. Another fact might report $25 million of revenue for the year ending on that date. The values and currency match, but their meanings and time structures differ. Treating them as interchangeable would be an analytical error even if extraction were flawless.
Entity, period, unit and dimensions
A concept defines what is being reported. Context identifies the reporting entity and period, with additional dimensions where relevant; numeric facts have units. Dimensions can distinguish geography, segment or another breakdown. A taxonomy supplies the concepts and relationships used to express these facts, and extension taxonomies can add reporting-specific definitions. [1]
In a hypothetical bank filing, $8 billion of loans for the consolidated group and $3 billion for a consumer segment may use related concepts but different dimensional contexts. They are not two conflicting answers to one question. Nor can they automatically be added: the segment could already be included in the group total.
The same trap occurs with geographic and product breakdowns. If a company reports revenue by region and separately by product, adding both tables doubles the same underlying economic activity. Each table is a different partition. Machine-readable labels make the partitions identifiable, but software still needs the analytical relationship among them.
Stocks, flows and overlapping periods
Balance-sheet amounts describe an instant; revenue and expense figures generally describe a duration. A fiscal second-quarter report may contain both three-month and six-month values, while a later annual filing repeats comparative prior-year information. The report’s filing date does not determine every fact’s measurement period.
Suppose a hypothetical company reports first-half revenue of $240 million and first-quarter revenue of $110 million. Second-quarter revenue can be derived as $130 million if scope and accounting definitions match. Adding the first-quarter figure to the first-half figure gives $350 million and counts the first quarter twice. A tag-name-only query cannot detect the mistake.
The subtraction also has qualifications. If the first-half filing restates first-quarter revenue to $115 million, the consistent derived second-quarter figure becomes $125 million. Mixing the original first-quarter value with the revised half-year value produces a different answer. The arithmetic is simple; selecting matching and definitions is the difficult part.
Inline reporting and extension tags
Inline XBRL places machine-readable tagging within a human-readable report. Financial statements often require company-specific presentation and disclosures; XBRL’s extensibility supports this diversity. XBRL International’s financial-statement overview explains that extensions accommodate reporting needs beyond a fixed standardized template. An extension is therefore not automatically an error or an attempt to conceal information. [2]
However, company-specific tags complicate cross-company mapping. Two issuers may use differently named extensions for economically similar measures. They may also use similar labels for measures with different definitions. A word such as adjusted does not identify a common accounting calculation, and a machine-readable value is not necessarily a standardized performance metric.
For an illustrative comparison, one business could define active accounts by a transaction within 30 days and another within 90 days. Even perfectly tagged counts would measure different populations. Converting the names to a shared database field would create superficial consistency while losing the definition that matters economically.
What the SEC’s aggregate APIs include
The SEC’s XBRL APIs aggregate facts using non-custom taxonomies that apply to the entire filing entity. That scope is useful for common company-level figures, but does not represent every extension-tagged or segment-specific disclosure in the original filing. The company-facts, company-concept and frames services organize information differently; the frames service aligns facts to calendar periods using defined matching rules. [3]
This creates a distinction between missing from an endpoint and missing from a filing. A product-level measure absent from a company-level API may still be present in the report’s XBRL files or narrative. Treating the endpoint as the complete disclosure universe could incorrectly suggest that an issuer did not publish a figure.
Calendar alignment also differs from identical fiscal periods. Two companies classified within the same broad quarter can have different period end dates or reporting calendars. A cross-sectional comparison can still be informative, but its economic interpretation includes those differences. Convenience of retrieval does not remove the need for a consistent time basis.
Duplicates and rounding
One report may display a number in several locations and at different precision. XBRL International’s January 14, 2025 working-group note distinguishes complete duplicates, numerically consistent duplicates and inconsistent duplicates. A different literal value is not necessarily contradictory when the values reflect different rounding precision. The note also distinguishes general XBRL behavior from recommendations for filing systems. [4]
For a hypothetical example, an income statement reports revenue of $12.34 million while a narrative paragraph rounds it to $12 million. These can represent the same underlying amount. Adding the tagged occurrences produces a meaningless total; deleting one without preserving traceability can make later reconciliation harder. Duplicate handling is therefore both a numerical and provenance problem.
A nil fact also differs from a numeric zero and from omitting the fact entirely. [6] In an analytical dataset, unavailable, not applicable and zero often have very different consequences for ratios and growth rates. Treating every missing value as zero can manufacture a loss, recovery or percentage change that the issuer never reported.
Filing history is part of the evidence
A later filing can revise a prior-period value, change presentation or provide a new comparative figure. The most recently available number may be appropriate for a current historical model, while an as-of-date backtest needs the information actually available at that earlier date. Those are different research products.
Imagine a model tested as of March using a corrected annual value first filed in June. The model has received information from the future relative to its test date. Storing the period alone cannot reveal that leakage. Filing identifiers, acceptance or publication timing and source locations make it possible to reconstruct which version supported an observation.
Technical validity is only one layer
As checked October 4, 2026, the SEC technical-specifications page links an August 2026 XBRL guide and labels its correspondence to a draft filer-manual version. The archived April 2025 guide in older references is not a safe description of the current listing. This article explains financial-data concepts rather than asserting that a draft-labelled technical listing establishes a new operative filing obligation. [5]
Validation can identify structural and calculation problems, but it cannot settle every question of economic comparability. Accounting policies, acquisition effects and the meaning of a disclosure still require the human-readable filing and its notes. XBRL’s contribution is substantial: it makes facts easier to locate, connect and process. The resulting research becomes reliable when that machine-readable structure retains, rather than strips away, the context needed to interpret it.
Sources
- XBRL International, XBRL Essentials, foundational specification overview; checked October 4, 2026SourceBack to text: ↑1↑2
- XBRL International, Financial Statements in XBRL; checked October 4, 2026SourceBack to text: ↑
- SEC, EDGAR Application Programming Interfaces, current documentation checked October 4, 2026Filing / reportBack to text: ↑
- XBRL International, Handling Duplicate Facts, Working Group Note January 14, 2025SourceBack to text: ↑
- SEC, Technical Specifications, August 2026 XBRL listing checked October 4, 2026Filing / reportBack to text: ↑
- SEC staff, EDGAR XBRL Guide, August 2026 archived documentFiling / report · PDFBack to text: ↑