GeminIQ Website Logo
Subscribe

How to Verify Financial Data Against the SEC Filing (Step-by-Step)

Chad Hartman

By

Published June 4, 2026 · Last updated June 14, 2026

You pulled up a company on your research platform of choice, noted the figure, then opened the actual 10-K — and the numbers don't match. The labels look the same. The period is the same. But the value sitting in your platform is not the value the company filed. This is not a rare occurrence. It is a structural feature of how most financial data platforms work, and once you understand it, you can resolve any discrepancy in four steps.

This post walks through that workflow. Not why the pipeline exists — that is covered in How Financial Data Reaches Investors and What Gets Lost Along the Way. Not which platforms normalize what — that question has its own answer elsewhere. This post is for the investor sitting with a discrepancy in front of them who wants to resolve it right now.

Start your 7-day free trial →

Table of Contents

Step 1: Identify the Exact Line Item in Dispute

Before you can trace a discrepancy, you need to be precise about what you are comparing. Two numbers can differ for legitimate reasons — one platform may be showing a trailing twelve-month figure while the other shows annual, or one may be displaying the value in millions while the other shows it in thousands, or one may be showing a fiscal year end while the other shows a calendar year. Rule these out first.

Confirm that you are comparing the same entity, the same period, the same fiscal year convention, and the same unit of measure. If all four align and the numbers still disagree, you have an actual discrepancy — and the source is almost certainly in how the platform handled the underlying SEC filing.

Write down three things before proceeding: the exact label as your platform displays it, the exact value your platform shows, and the exact value you found in the filing. That three-column comparison is the starting point for every step that follows.

Step 2: Find the Filing and Locate the XBRL Tag

Go to SEC EDGAR and search for the company by ticker or CIK number. Navigate to the filing type (10-K for annual, 10-Q for quarterly) and the specific period that matches your discrepancy. Open the filing index page and look for the Inline XBRL viewer link — it typically appears as a blue "Interactive Data" button on the filing index.

The Interactive Data viewer is the SEC's own interface for browsing XBRL-tagged financial data. It organizes the filing into the Income Statement, Balance Sheet, Cash Flow Statement, and Notes. Find the line item in question within the viewer. Click on the value — the viewer will display the full XBRL tag name associated with that data point, along with the exact value and the period it covers.

That tag name is your ground truth. For example, Apple's "Other non-current liabilities" carries the tag OtherLiabilitiesNoncurrent. Apple's stock repurchases appear as two separate tagged items: PaymentsForRepurchaseOfCommonStock and PaymentRelatedToTaxWithholdingForShareBasedCompensation. If your platform is showing a single combined buyback figure, that tells you immediately that two distinct XBRL-tagged line items were merged into one.

Note the tag name, the as-filed value, and the period context. You now have the source of truth from the primary document.

Step 3: Compare the Tag to Your Platform's Value

Return to the platform showing the discrepancy and ask one question: does the label on the platform correspond to a single XBRL tag in the filing, or could it represent multiple tags that were merged?

This is where most discrepancies live. A platform label of "Stock Repurchases" might combine PaymentsForRepurchaseOfCommonStock with PaymentRelatedToTaxWithholdingForShareBasedCompensation — two economically distinct items. A platform label of "Other Non-Current Liabilities" might subtract lease obligations from the as-filed value and keep the original label. A platform label of "Short-Term Debt" might combine commercial paper and the current portion of long-term debt, even though these represent fundamentally different refinancing risks.

The merger is intentional and is not unique to any single platform. Third-party data aggregators — the intermediary layer that most financial research tools license data from — design their templates for cross-company comparability. When two companies report structurally similar obligations under different labels, the aggregator maps both into a single standardized bucket. The result is data that compares cleanly across companies but no longer traces cleanly back to either company's filing. At this stage, you either find the matching XBRL value and confirm the platform is accurate, or you identify a gap. If there is a gap, the discrepancy has a type — and knowing which type determines what to do with it analytically.

Step 4: Diagnose the Discrepancy Type

Not all discrepancies are the same, and diagnosing which type you are dealing with determines what to do with it analytically. There are four patterns worth knowing.

Line-item consolidation. Two or more XBRL-tagged line items were merged into one platform label. The sum of the merged items will match the platform's value. This is the most common type. The diagnostic is arithmetic: add the individual filing line items and see if they equal the platform figure. If they do, you are looking at consolidation, not error.

Label-value mismatch. The platform preserved the same label as the filing but changed the value by adding or subtracting another line item. This is the most dangerous type because it looks correct at a glance. The documented example from Apple's FY2025 10-K is instructive: a normalized platform showed $29,946M under "Other Non-Current Liabilities" while the as-filed value was $41,549M — an $11.6 billion difference under an identical label, caused by the aggregator subtracting capital lease obligations from the line. Without checking the XBRL tag value directly, this discrepancy is invisible. This case is detailed further in the Third-Party Financial Data Problems post.

Company-specific item absorption. A line item unique to the company was reclassified into a generic bucket. The individual item disappears from the display entirely. The value is not lost — it reappears inside a broader category — but the analytical identity of the asset or liability is gone. Apple's $33.2 billion Vendor Non-Trade Receivables (XBRL tag: NontradereceivablesCurrent) represents trade receivables from Apple's manufacturing partners for components Apple has already purchased on their behalf. On a normalized platform, this often folds into "Other Current Assets," removing the economic signal entirely.

Retroactive taxonomy revision. The aggregator updated its data model and reclassified a historical line item across prior periods. The number on your platform today differs from the number you saw six months ago — not because the company restated anything, but because the aggregator changed its taxonomy. This is the hardest discrepancy to catch because it happens silently and affects historical data. If you notice a value that contradicts your own prior notes and the company filed no restatement, check whether the aggregator's methodology has been updated.

Why Financial Platform Data Sometimes Differs from the SEC Filing

The discrepancy you found is not a bug in any specific platform. Most financial research tools rely on licensed data from institutional financial data providers whose core product is a normalized, cross-company-comparable financial dataset. That dataset is built for breadth: tens of thousands of companies, dozens of countries, standardized templates that make any company's income statement look structurally similar to any other company's.

Building that standardization requires methodology decisions. When Apple reports commercial paper separately from term debt, the template has to decide whether those are two line items or one. When Apple reports vendor non-trade receivables separately from trade receivables, the template has to decide whether to preserve that distinction or fold it into a generic receivables category. When a company's cash flow statement separates equity award tax withholding from share repurchases, the template has to decide whether those are one cash outflow or two.

There is no universally correct answer to any of these questions for the purpose of broad comparison. But for the purpose of verifying a specific number against a specific filing, the methodology decision is the discrepancy. The platform made a choice. The filing made no such choice — it reported what the company actually recorded.

This is why the verification workflow above starts with the XBRL tag rather than the platform label. The tag is the one element in the chain that cannot be reinterpreted. OtherLiabilitiesNoncurrent means the same thing in every filing that uses it, because the SEC's GAAP taxonomy defines it. Once you have the tag and the as-filed value, you have a fixed reference point that no normalization decision can obscure.

The four-step workflow above applies regardless of which platform produced the discrepancy.

The Hardest Case: When Labels Match But Values Don't

Of the four discrepancy types, label-value mismatches deserve extra attention because they are the ones most likely to produce downstream analytical errors without ever being noticed.

When a platform displays a value under the same label as the filing but the value has been adjusted, the analyst who does not cross-check will treat the platform figure as the as-filed figure. That assumption gets built into models, metrics, and investment theses. The error is invisible at the surface level — you are looking at a label you recognize, in a period you selected, for a company you know. Nothing triggers a verification check.

The way to protect against this category is to make the EDGAR XBRL viewer a routine part of your research process rather than a one-time diagnostic. For any balance sheet or cash flow line item where the absolute value matters to your analysis — total debt, capital lease obligations, buyback figures, specific working capital items — spend sixty seconds confirming the XBRL tag value before incorporating the platform figure into a model or thesis.

The SEC's Inline XBRL viewer makes this possible in two or three clicks for any filing since 2021, and for most large-cap filings going back to 2009. It requires no account, no subscription, and no additional software.

When Discrepancies Compound Into Metric Errors

A single line-item discrepancy rarely stays isolated. Financial ratios and calculated metrics are built from multiple inputs, and a discrepancy in any one of them cascades through every calculation that uses it.

Consider Return on Invested Capital — a metric that GeminIQ's Calculated Metrics derives directly from XBRL-tagged balance sheet and income statement data. ROIC requires Net Operating Profit After Tax divided by Invested Capital. Invested Capital, in turn, is calculated from total assets, cash, total debt, and operating lease obligations — several of which are precisely the line items most likely to differ between a normalized platform and the as-filed data.

If a platform combines commercial paper with current term debt into a single "Short-Term Debt" figure and uses the combined number in its Invested Capital calculation, the result is numerically close to correct but structurally different from a calculation built on the three distinct as-filed instruments. If a platform subtracts $11.6 billion in capital leases from "Other Non-Current Liabilities" and applies that adjusted figure to a leverage ratio, the ratio is wrong by the magnitude of the adjustment — and there is no way to identify the error from the ratio output alone.

This cascading effect is why the verification workflow matters most for the inputs to metrics, not just for standalone line items. A discrepancy in one balance sheet line silently distorts every ratio that touches it.

For investors who build their own financial models, the practical implication is simple: trace every model input to a specific XBRL tag before running the model. For investors who rely on platform-calculated metrics, the implication is to understand what the platform's methodology is for the key metrics in your thesis — and whether that methodology preserves or adjusts the as-filed inputs.

The Shortcut: Platforms That Preserve the XBRL Layer

The four-step verification workflow above is thorough, but it is also time-consuming. For investors doing deep due diligence on a handful of positions, it is appropriate. For investors doing broad research across dozens of companies, it is not scalable.

The scalable alternative is to use a platform whose data starts at the XBRL tag level rather than at a normalized template. When the data source is the filing itself — not a third-party aggregator's interpretation of the filing — the verification step is built into the data rather than bolted on afterward.

GeminIQ pulls financial statement data directly from SEC EDGAR, preserves every XBRL tag as filed, and structures it for analysis without reclassification. The Financial Statements on GeminIQ display each line item exactly as the company reported it, with its source tag available for audit. Apple's Vendor Non-Trade Receivables appears as its own line. Apple's three debt instruments appear separately. Apple's buyback figure and its equity tax withholding figure appear as two distinct cash flow line items — because that is how they appear in the filing.

The Calculated Metrics GeminIQ pre-calculates — including ROIC, Free Cash Flow, Net Debt, Debt-to-EBITDA, and more than fifty others — are derived from those same as-filed inputs, not from a normalized template. When the metric shows a value, you can trace it to the formula, and from the formula to the specific XBRL tags that fed it.

This does not eliminate the need to read filings. Nothing does. But it does eliminate the verification overhead that comes from working with data that has already been processed before you see it. The step between "the number on my screen" and "the number in the filing" is removed, because they are the same number.

Frequently Asked Questions

Why does my financial platform show different numbers than the SEC filing?

Most financial research platforms license data from third-party aggregators who normalize SEC filings into standardized templates for cross-company comparability. The normalization process combines, reclassifies, or adjusts line items to fit a generic template. The result is data that compares cleanly across thousands of companies but no longer traces cleanly to any individual filing. The discrepancy is a feature of the normalization methodology, not a data error in the traditional sense.

How do I access XBRL-tagged data directly from the SEC?

Go to sec.gov/edgar, search for the company, navigate to the relevant 10-K or 10-Q filing, and open the Interactive Data viewer from the filing index page. The viewer organizes all XBRL-tagged financial data by statement type. Clicking any value in the viewer reveals its XBRL tag, the exact period it covers, and the as-filed amount. The SEC's CompanyFacts API also provides bulk XBRL data programmatically for every filer.

Is the discrepancy always the platform's fault?

Not always. Some discrepancies arise from legitimate definitional choices. Free cash flow, for instance, has no single GAAP definition — one platform might define it as operating cash flow minus capital expenditures, while another might subtract lease payments or include restricted cash. For metrics with established but non-universal definitions, the discrepancy reflects methodology, not error. The four-step workflow applies primarily to line items that have direct XBRL counterparts in the filing — income statement items, balance sheet items, and explicitly tagged cash flow items.

How far back does XBRL data go on EDGAR?

Large accelerated filers began tagging in 2009. All public companies were required to tag by 2012. The Inline XBRL format — which embeds tags directly in the human-readable HTML filing — became mandatory for large accelerated filers in 2020 and for all filers by 2021. For most major companies, you have uninterrupted XBRL-tagged data going back to fiscal years ending in 2009 or 2010.

What should I do if the discrepancy affects a metric I'm using in a model?

Identify which XBRL-tagged inputs feed the metric, verify each input against the filing, and rebuild the calculation from the as-filed values. For the most commonly used metrics — ROIC, Free Cash Flow, Net Debt, Debt-to-EBITDA — GeminIQ's Calculated Metrics provides pre-calculated values derived directly from XBRL-tagged source data, which removes the input verification step from the workflow.

Does this problem affect all companies equally?

Companies with simple, standard reporting structures lose less in normalization. Companies with unusual or company-specific line items — custom receivables categories, multi-instrument debt structures, non-standard working capital items, large off-balance-sheet arrangements — lose the most. The irony is that the companies where the discrepancy is largest are often the ones where accurate line-item data matters most to the analysis.

Start your 7-day free trial →

Research Faster. Invest Smarter.

Most financial websites rely on third-party aggregators that simplify or process data before you ever see it. We built GeminIQ because we believe you deserve a better fundamental analysis tool—one that goes beyond basic price charts and processed numbers. We extract our data directly from SEC 10-K and 10-Q filings to ensure that when you look at a balance sheet or a cash flow statement, you are seeing the numbers exactly how the company reported them. Our goal is to give you the tools to verify the narrative for yourself using clean, traceable data. Start researching now at GeminIQ.com.

Disclaimer: The content in this blog is for educational and entertainment purposes only and does not constitute financial, legal, or tax advice. Investing involves risk, including the loss of principal. The views expressed are my own and not intended as financial advice or a guarantee of future performance.