How to Reconcile Standardized and As-Reported Financial Statements to Detect Mapping Risk

Standardized financial statements make company data easier to compare, but standardization requires issuer-specific filing concepts to be mapped into a common set of financial fields. A standardized revenue value, for example, may correspond to one consolidated filing tag, several component tags, or a raw fact whose reporting context is unclear.

Those distinctions matter before the data enters ratios, screens, valuation models, or other research workflows. A numerical difference may indicate a mapping problem, but it may also reflect an aggregation, a dimensioned fact, or a value drawn from a different reporting context. A numerical match can be misleading for the same reason.

This workflow uses Claude with Financial Modeling Prep's MCP server to compare standardized and as-reported annual income statements for Apple and Microsoft. It focuses on revenue, gross profit, operating income, and net income across two fiscal years. Microsoft also includes selling, general, and administrative expenses to test a case in which one standardized line requires multiple as-reported components.

The purpose is not to prove that every standardized mapping is correct or identify every possible accounting difference. It is to separate straightforward numerical matches from aggregations, confirmed variances, unavailable data, and source-context ambiguity so analysts know which records require closer review.

Key Takeaways

• Match the company, fiscal period, financial concept, and available filing context before comparing values.
• A matching tag and value do not establish a complete reconciliation when filing and XBRL context are unavailable.
• Several raw filing tags may legitimately combine into one standardized financial statement line.
• A large apparent difference should not be labeled a mapping error until both values are shown to represent the same concept.
• Reconciliation tolerances can help prioritize exceptions, but they should not be presented as accounting materiality thresholds.
• Preserve raw tag names, component values, dates, classifications, and follow-up actions so every result remains traceable.

Why Standardized and As-Reported Values Can Differ

A standardized income statement places common concepts such as revenue, gross profit, operating income, and net income into consistent fields. That structure helps analysts compare companies and periods without interpreting every issuer's filing taxonomy separately.

As-reported statements retain the company's original filing-oriented concepts. Their tag names and level of detail can vary by company, period, and filing. One company may report a value through a familiar consolidated tag, while another may use several components that must be combined to reach the standardized line.

A difference between the two sources can arise from:

• Aggregating several raw filing concepts into one standardized field
• A dimensioned fact representing a product, service, segment, or geography
• Different duration, unit, form, or filing contexts
• A change in presentation or taxonomy between reporting periods
• A missing or unavailable raw concept
• A genuine numerical variance after the concepts and contexts have been aligned

This is why validating financial data before it enters a model requires more than checking whether two numbers are equal. The workflow must first establish that the numbers represent the same economic concept.

Define the Reconciliation Method

This example uses the latest two completed annual fiscal periods available for Apple and Microsoft as of August 25, 2026. Two periods are enough to show whether the same relationship between standardized and as-reported values persists across consecutive filings without making the review unnecessarily large.

The Apple comparison includes:

• Revenue
• Gross profit
• Operating income
• Net income

The Microsoft comparison includes the same four lines plus SG&A. The additional SG&A test shows how a standardized value may depend on combining more than one as-reported tag.

Align the Reporting Period Before Comparing Values

Company and fiscal year alone are not sufficient reconciliation keys. Where the source makes the information available, the comparison should also consider:

• Filing or accession
• Form type
• Fiscal period
• Period-end date
• Fact duration
• Unit
• Consolidated or dimensioned context

These fields help distinguish a consolidated company value from a product, service, segment, geography, or other component.

The MCP response used for this analysis did not expose every fact-level XBRL attribute. XBRL context is the metadata that identifies the filing, period, unit, entity, duration, and any dimensions attached to a reported fact. When that information is unavailable, the comparison can establish numerical agreement but cannot claim a fully context-verified reconciliation.

Analysts working across multiple datasets should also keep fiscal periods separate from publication and retrieval dates. A broader workflow for aligning fiscal periods with reporting and event dates explains why those dates should not be treated as interchangeable.

Calculate the Numerical Variance

For comparable values, the workflow calculates:

Variance Amount = Standardized Value - Mapped As-Reported Value

Variance Percentage = Variance Amount / Absolute As-Reported Value x 100

If the as-reported comparison value is zero, the percentage is reported as N/A. When both values are zero and the concept is otherwise supported, the result can still be treated as a numerical match.

If the as-reported value is zero and the standardized value is not, the percentage remains N/A and the row enters the review queue. An infinite percentage would not help the analyst determine why the raw value is missing or unsuitable.

The variance calculation should be applied only after the values are shown to represent comparable concepts. If the raw fact appears to represent a segment or product rather than consolidated company revenue, calculating a percentage difference would create false precision.

Classify Each Reconciliation Result

The workflow uses five result types.

Result type	When to use it
Numerical Match: Context Unverified	The standardized and raw values match, and the tag is semantically consistent, but the available MCP output does not expose enough XBRL context to claim a complete reconciliation.
Aggregation Match: Context Unverified	Clearly identified raw component tags add to the standardized value, but their shared consolidated context cannot be fully verified.
Numeric Variance	The concepts and reporting contexts are sufficiently aligned, but the values differ.
Source-Context Ambiguity	Missing context prevents the returned raw fact from being interpreted safely.
Unavailable	The required as-reported value is absent.

A result should be labeled Exact Reconciliation or Verified Aggregation only when both the financial meaning and the relevant filing context can be confirmed. Numerical agreement by itself is not enough.

Assign Exception Severity and Review Priority

The example uses a 1% reconciliation tolerance to organize context-supported numerical differences. The threshold is an exception-prioritization rule, not an accounting materiality standard.

Severity	Treatment
Low	The values match, the raw tag is semantically consistent, and no contradictory evidence is present.
Medium	Raw components add to the standardized line but their shared context is unverified, or a context-supported residual is no more than 1%.
High	The result contains source-context ambiguity, unavailable or contradictory data, or a context-supported variance above 1%.

Low-severity numerical matches remain traceable but generally do not require immediate action. Medium-priority cases require confirmation before the mapping is relied on broadly. High-priority cases should be resolved before the value enters a downstream model.

Retrieve the Standardized and As-Reported Statements

The workflow uses two financial statement sources through the FMP MCP connection.

FMP source	Role in the reconciliation	Fields used
Standardized income statement	Supplies normalized annual financial statement values	Date, fiscal year, period, revenue, gross profit, operating income, net income, and standardized SG&A
As-reported income statement	Supplies filing-oriented values and raw tag names	Period metadata and raw income statement tags, including revenue, gross profit, operating income, net income, sales and marketing expense, and general and administrative expense

The standardized values come from the Income Statement API. The raw filing concepts come from the As Reported Income Statements API.

Within Claude, the corresponding MCP tools are:

• income-statement
• income-statement-as-reported

The MCP tool names may differ from the underlying REST endpoint paths. The workflow should use the tools exposed by the active FMP connection rather than assuming that a REST endpoint name will appear unchanged inside Claude.

Connect FMP to Claude

An FMP API key and a Claude account that supports custom connectors are required. The current FMP MCP connection instructions use this remote server URL:

https://financialmodelingprep.com/mcp?apikey=YOUR_FMP_API_KEY

Replace YOUR_FMP_API_KEY with an active key. In Claude, open Settings, select Connectors, choose Add custom connector, and paste the URL into the Remote MCP Server URL field.

After saving the connection, start a new conversation with the connector enabled.

Run the Reconciliation in Claude

Copy and paste the following prompt into Claude:

Using the connected Financial Modeling Prep MCP server, build a compact standardized versus as-reported income statement reconciliation for:

- Apple Inc. (AAPL)

- Microsoft Corporation (MSFT)

This is a financial-data reconciliation exercise, not investment analysis.

Use only the latest two completed annual fiscal periods for each company.

Keep the workflow compact. Use the minimum FMP calls required and no more than one retry in total.

Retrieve:

- Standardized annual income statements from income-statement

- Raw annual income statements from income-statement-as-reported

For both companies, reconcile:

- Revenue

- Gross Profit

- Operating Income

- Net Income

For Microsoft, also reconcile:

- Selling, General & Administrative Expenses (SG&A)

The Microsoft SG&A check is included to test whether a standardized field requires aggregation of multiple as-reported tags.

PERIOD AND CONTEXT ALIGNMENT

Do not align records using only company and fiscal year.

Where available, verify:

- Filing or accession

- Form type

- Fiscal year and fiscal period

- Period-end date

- Fact duration

- Unit

- Consolidated versus dimensioned context

A small difference in statement-date metadata may be reported as a metadata pattern only when the remaining available evidence supports period comparability.

Do not assume a date difference is harmless merely because the numerical values match.

Do not combine different fiscal years or incompatible reporting contexts.

XBRL CONTEXT SAFEGUARD

Never treat an as-reported tag and value as the counterpart of a standardized line based only on tag name, company, fiscal year, or numerical agreement.

Before reconciling a raw value, verify that the semantic concept and available filing context represent the same financial concept as the standardized field.

In particular:

- Distinguish consolidated facts from segment, product, service, geography, or other dimensioned facts.

- Do not treat a dimensioned revenue fact as consolidated company revenue.

- Inspect context or dimension metadata when the MCP output exposes it.

- If the MCP output does not expose enough context, do not guess.

When sufficient XBRL context is unavailable, reflect that source limitation in the classification rather than treating it as evidence that the standardized mapping is incorrect.

For Microsoft revenue, use these primary-statement validation benchmarks:

- FY2026 consolidated revenue: $331.839 billion

- FY2026 product revenue: $64.696 billion

- FY2026 service and other revenue: $267.143 billion

- FY2025 consolidated revenue: $281.724 billion

- FY2025 Microsoft Cloud revenue: $168.9 billion

Use these figures only as validation benchmarks when interpreting raw FMP facts.

MAPPING RULES

For each standardized line item:

1. Identify the corresponding as-reported filing field or tag for the same fiscal period.
2. Preserve the exact as-reported tag name.
3. Evaluate whether the tag is semantically consistent with the standardized concept.
4. Verify the available filing and context attributes before treating the comparison as fully reconciled.
5. If one standardized field requires multiple raw tags, show every tag and value.
6. Do not combine raw fields unless their concepts clearly support the aggregation.
7. If missing context may have caused a non-comparable fact to be returned, classify the row as Source-Context Ambiguity.
8. Do not estimate, normalize, or invent missing values.
9. Preserve the original sign.

CALCULATIONS

Variance Amount = Standardized Value - Mapped As-Reported Value

When the mapped as-reported value is non-zero:

Variance Percentage = Variance Amount / Absolute As-Reported Value x 100

If the as-reported comparison value is zero:

- If both standardized and as-reported values are zero, report Variance Percentage as N/A.

- If the as-reported value is zero and the standardized value is non-zero, report Variance Percentage as N/A and escalate the row for review.

DIFFERENCE TYPE

Use only:

- Numerical Match: Context Unverified

- Aggregation Match: Context Unverified

- Numeric Variance

- Source-Context Ambiguity

- Unavailable

Use Numerical Match: Context Unverified when the standardized and raw values match and the tag is semantically consistent, but the MCP output does not expose enough XBRL context for a complete reconciliation.

Use Aggregation Match: Context Unverified when identified raw component tags add to the standardized line, but their shared consolidated context cannot be fully verified.

Use Numeric Variance only when the mapping and context are sufficiently established but the values differ.

Use Source-Context Ambiguity when missing context prevents the returned raw fact from being interpreted reliably.

Do not classify source-context ambiguity as a numerical discrepancy simply because the apparent values differ.

EXCEPTION SEVERITY

Use the illustrative 1% reconciliation tolerance only for context-supported numerical comparisons.

- Low: Exact numerical match with a semantically consistent tag and no contradictory evidence.

- Medium: Numerical aggregation match whose component context cannot be fully verified, or a context-supported non-zero variance within 1%.

- High: Source-context ambiguity, unavailable or contradictory data, or a context-supported variance above 1%.

The 1% threshold is a reconciliation-prioritization rule, not accounting materiality.

OUTPUT

Return one reconciliation table with these columns:

- Company

- Fiscal Period

- Statement Type

- Standardized Line Item

- As-Reported Line Item or Tag

- Standardized Value

- As-Reported Value

- Variance Amount

- Variance Percentage

- Difference Type

- Exception Severity

- Review Priority

- Analyst Follow-Up

Use Income Statement for Statement Type.

For aggregation matches, show every raw tag and value used.

For Microsoft revenue, explicitly state whether the MCP output exposes enough context or dimension information to establish that the returned raw fact represents consolidated revenue.

Keep each analyst follow-up short and specific to the reconciliation issue.

After the table, provide no more than four bullets covering:

- Whether the available period and context attributes support comparison

- Which fields numerically match

- Which fields require aggregation or contain source-context ambiguity

- Which items enter the analyst review queue and why

Do not provide investment or company commentary.

Review the Reconciliation Results

The workflow produced 18 reconciliation rows across Apple and Microsoft.

Difference type	Number of rows
Numerical Match: Context Unverified	15
Aggregation Match: Context Unverified	2
Source-Context Ambiguity	1
Confirmed Numeric Variance	0
Unavailable	0

The results contain no confirmed numerical variance in a context-supported comparison. The unresolved cases involve an aggregation that still requires context confirmation and a Microsoft revenue fact that does not represent consolidated revenue.

Apple Reconciliation Results

Apple provides the simplest result in the sample. Revenue, gross profit, operating income, and net income match their corresponding as-reported values across both fiscal periods.

All values below are in millions of dollars.

Fiscal period	Standardized line	As-reported tag	Standardized value	As-reported value	Variance
FY2025, ended Sep. 27, 2025	Revenue	revenuefromcontractwithcustomerexcludingassessedtax	$416,161	$416,161	$0
FY2025, ended Sep. 27, 2025	Gross profit	grossprofit	$195,201	$195,201	$0
FY2025, ended Sep. 27, 2025	Operating income	operatingincomeloss	$133,050	$133,050	$0
FY2025, ended Sep. 27, 2025	Net income	netincomeloss	$112,010	$112,010	$0
FY2024, ended Sep. 28, 2024	Revenue	revenuefromcontractwithcustomerexcludingassessedtax	$391,035	$391,035	$0
FY2024, ended Sep. 28, 2024	Gross profit	grossprofit	$180,683	$180,683	$0
FY2024, ended Sep. 28, 2024	Operating income	operatingincomeloss	$123,216	$123,216	$0
FY2024, ended Sep. 28, 2024	Net income	netincomeloss	$93,736	$93,736	$0

Each row has a variance percentage of 0.00%. The raw tag is also semantically consistent with the standardized line.

The results are classified Numerical Match: Context Unverified rather than Exact Reconciliation because the MCP response does not expose enough filing and XBRL context to prove that each fact belongs to the same consolidated, non-dimensioned context. All eight rows receive Low exception severity and Low review priority.

No numerical correction is indicated. If the values are intended for a control process that requires source-level proof, the remaining action is to confirm the form, filing, duration, unit, and dimensional context from the underlying filing.

Microsoft Reconciliation Results

Microsoft produces three different reconciliation patterns: direct numerical matches, two-tag SG&A aggregations, and one ambiguous revenue result.

All values below are in millions of dollars.

Fiscal period	Standardized line	As-reported tag or components	Standardized value	As-reported value	Variance
FY2026, ended Jun. 30, 2026	Revenue	revenuefromcontractwithcustomerexcludingassessedtax	$331,839	$331,839	$0
FY2026, ended Jun. 30, 2026	Gross profit	grossprofit	$225,465	$225,465	$0
FY2026, ended Jun. 30, 2026	Operating income	operatingincomeloss	$155,237	$155,237	$0
FY2026, ended Jun. 30, 2026	Net income	netincomeloss	$133,749	$133,749	$0
FY2026, ended Jun. 30, 2026	SG&A	sellingandmarketingexpense $26,710 + generalandadministrativeexpense $7,956	$34,666	$34,666	$0
FY2025, ended Jun. 30, 2025	Revenue	revenuefromcontractwithcustomerexcludingassessedtax	$281,724	$168,900	N/A: values are not comparable
FY2025, ended Jun. 30, 2025	Gross profit	grossprofit	$193,893	$193,893	$0
FY2025, ended Jun. 30, 2025	Operating income	operatingincomeloss	$128,528	$128,528	$0
FY2025, ended Jun. 30, 2025	Net income	netincomeloss	$101,832	$101,832	$0
FY2025, ended Jun. 30, 2025	SG&A	sellingandmarketingexpense $25,654 + generalandadministrativeexpense $7,223	$32,877	$32,877	$0

The review classifications show which rows can remain low priority and which require further investigation.

Fiscal period	Line item	Difference type	Severity	Review priority	Analyst follow-up
FY2026	Revenue	Numerical Match: Context Unverified	Low	Low	Confirm the raw fact's consolidated context if source-level verification is required.
FY2026	Gross profit	Numerical Match: Context Unverified	Low	Low	Retain the matching tag and value with the context limitation.
FY2026	Operating income	Numerical Match: Context Unverified	Low	Low	Retain the matching tag and value with the context limitation.
FY2026	Net income	Numerical Match: Context Unverified	Low	Low	Retain the matching tag and value with the context limitation.
FY2026	SG&A	Aggregation Match: Context Unverified	Medium	Medium	Confirm that both raw components share the same consolidated filing context.
FY2025	Revenue	Source-Context Ambiguity	High	High	Locate a consolidated raw revenue fact or inspect the filing's XBRL contexts.
FY2025	Gross profit	Numerical Match: Context Unverified	Low	Low	Retain the matching tag and value with the context limitation.
FY2025	Operating income	Numerical Match: Context Unverified	Low	Low	Retain the matching tag and value with the context limitation.
FY2025	Net income	Numerical Match: Context Unverified	Low	Low	Retain the matching tag and value with the context limitation.
FY2025	SG&A	Aggregation Match: Context Unverified	Medium	Medium	Confirm that both raw components share the same consolidated filing context.

FY2026 Revenue Matches the Consolidated Total

Microsoft's standardized FY2026 revenue is $331.839 billion. The as-reported MCP value matches that amount.

The value also agrees with Microsoft's FY2026 income statement, where product revenue of $64.696 billion and service and other revenue of $267.143 billion add to total revenue of $331.839 billion.

That external agreement supports the interpretation that the raw value represents consolidated revenue. However, the MCP response itself does not expose the complete XBRL context, so the row remains Numerical Match: Context Unverified rather than being elevated to an exact reconciliation.

SG&A Requires Two Raw Components

Microsoft's standardized SG&A line does not correspond to one raw tag in this example.

For FY2026:

Selling and Marketing Expense: $26.710 billion

General and Administrative Expense: $7.956 billion

Combined SG&A: $34.666 billion

For FY2025:

Selling and Marketing Expense: $25.654 billion

General and Administrative Expense: $7.223 billion

Combined SG&A: $32.877 billion

The component sums match the standardized SG&A values in both periods. The numerical relationship is clear, but the MCP response does not expose enough dimensional context to prove that both components share the same consolidated scope.

Both rows are therefore classified Aggregation Match: Context Unverified and assigned Medium review priority. The analyst does not need to recalculate the values. The remaining task is to confirm the components' shared filing context before treating the aggregation as fully verified.

FY2025 Revenue Is a Source-Context Exception

The most important result is Microsoft's FY2025 revenue row.

The standardized value is $281.724 billion, while the as-reported MCP response returns $168.9 billion. The raw number is not a slightly different version of consolidated revenue. Microsoft reported consolidated FY2025 revenue of $281.724 billion, while its 2025 annual report identifies $168.9 billion as Microsoft Cloud revenue.

The raw value therefore appears to represent a narrower business metric rather than consolidated company revenue. Because the available MCP output does not show the XBRL dimension or other context that explains why that fact was selected, the row is classified Source-Context Ambiguity.

The variance amount and percentage are reported as N/A because the two values do not represent comparable concepts. Subtracting them would produce a mathematically correct number but an analytically misleading result.

This row receives High exception severity and High review priority. The correct next step is to inspect the FY2025 filing's XBRL facts or retrieve another raw revenue fact that can be established as consolidated revenue.

The result is not evidence that FMP's standardized revenue value is incorrect. It shows why a raw tag should not be accepted as the counterpart of a standardized field until its source context is understood.

Turn the Reconciliation Into a Repeatable Review Queue

Once the mapping rules are established, the same process can be repeated whenever a new annual filing becomes available.

A practical refresh process is:

1. Retrieve the latest standardized and as-reported annual statements.
2. Align the company, period, form, filing, unit, and available XBRL context.
3. Apply the approved field mappings and aggregation rules.
4. Recalculate context-supported numerical variances.
5. Identify new raw tags, ambiguous facts, unavailable values, and changed aggregations.
6. Route Medium- and High-priority cases to an analyst.

The process does not need to run continuously because it compares completed financial statements. It can be incorporated into a post-earnings data refresh process after a new filing and statement update become available.

For a larger company universe, the same rules can be applied in small batches. The field mappings, tolerance, severity definitions, and review requirements should remain fixed so that a new result is evaluated consistently with prior periods.

The review queue should preserve:

• Company and fiscal period
• Standardized field and value
• Exact as-reported tag names
• Raw component values
• Available filing and context metadata
• Variance calculations
• Difference type
• Severity and review priority
• Analyst decision and supporting evidence
• Date of the review

This record allows downstream users to see not only which value was accepted, but why it was accepted.

Know When Analyst Review Is Required

Automated comparison works well when the financial concept is clear and the values match. Analyst judgment is still required when:

• One standardized line could correspond to several raw tags.
• A standardized field requires aggregation but the raw components do not reconcile cleanly.
• A raw fact appears to represent only part of the standardized concept.
• Filing, duration, unit, or dimension metadata is missing or contradictory.
• A context-supported variance exceeds the selected tolerance.
• A required filing value is unavailable.
• An amended filing, restatement, or classification change may explain the difference.

The analyst's first task is to determine whether the two values represent the same concept. Only then does the size of the numerical difference become meaningful.

Microsoft's FY2025 revenue illustrates that sequence. The apparent difference is large, but the more important finding is that the raw value represents Microsoft Cloud revenue rather than consolidated company revenue. The row must be resolved as a source-context problem before it can be evaluated as a numerical variance.

Keep Mapping Risk Out of Downstream Models

A useful reconciliation process does more than compare two columns of numbers. It preserves the relationship between a standardized field, the raw filing concepts behind it, and the context needed to interpret those concepts correctly.

The Apple results show how numerical matches can be identified and retained without overstating what the available source metadata proves. Microsoft's SG&A results show how several raw concepts may combine into one standardized line. The FY2025 Microsoft revenue result shows why an apparently large discrepancy should not be labeled a mapping error until the raw fact's scope is established.

Used this way, standardized and as-reported data serve complementary roles. Standardized statements support consistent analysis across companies and periods. As-reported statements provide the filing-level concepts needed to inspect how those standardized values were formed.

The reconciliation connects those two views and directs analyst attention to the small number of records that cannot be resolved safely through numerical comparison alone.