Call reports are quarterly financial statements that banks in the US are required to file with federal regulators. In this article I use LLMs to examine a Call report.
Background
Call reports, formally known as Consolidated Reports of Condition and Income, are quarterly financial statements that banks and financial institutions in the US are required to file with federal regulators.
They are publicly available on the FFIEC website in XBRL, PDF and SDF (semi-colon delimited format).
Call reports provide some of the same information that is in SEC Form 10-Q (e.g. balance sheet, income statement), however they differ in that Call reports provide information:
- at the banking legal entity level and not a parent holding company, e.g. Wells Fargo Bank N.A. and not Wells Fargo & Company the parent holding company.
- are focused on detailed financial position and performance to monitor the financial health, stability of banks and compliance with regulations e.g. balance sheet will have a different level of detail
At a high level, Form 10-Q is reporting for investors, while Call reports are regulatory oversight reports.
In today’s article I will explore using LLMs to process and query a Call Report.
Let’s Start
The FFEIC Central Data Repository provides access to Call Reports and I can simply enter part of an Institution’s name and click Search Banks.

Which shows me 2 institutions:

And selecting the second, Wells Fargo Bank, National Association, shows the following:

With the buttons at the top of the page providing downloads of the XBRL, PDF and SDF files as well as the Taxonomy used.
We now have a decision as to which file type to use.
XBRL
We know that XBRL is an XML format designed for machine readability, but requires specialist understanding/code to view/parse and are not generally supported by LLMs.
Still let’s give it a try.
Using Claude Desktop, I dragged and dropped the file Call_Cert3511_033125.XBRL into a new prompt window and asked “what is this file?”, with Claude Sonnet 4 selected.

Nice, Claude worked out what the file was and what it contains.
On asking “are you able to extract data from this file”, I got the following:

Nice, very confident, I did not expect that.
As, while the XBRL file is XML, the names of metrics (e.g. Total Assets) and other specifics are not present in the file and require navigation to schema xsd files found on http://www.ffiec.gov (as specified in the XML), so it is impressive that Claude was able to do this.
However before getting too excited, I had better check the values by opening the PDF and comparing manually.
Let’s take the first metric it reports, Total Assets of $1,0960,107,000 or $1.96 trillion.
Opening the PDF and navigating to page 17 for the Balance Sheet, I see Total Assets is $1,711,028,000 or $1.7 trillion, see below.

Oh dear, that’s bad!
Searching for the $1,0960,107,000 claimed by Claude in the PDF, I find only one occurrence, highlighted below.

How Gross amount of Swaps FX Contracts became Total Assets is a mystery!
To be fair to Claude, when I tried using the Upload a File Menu, and navigated to my directory with Call reports, both the XBRL and SDF were not selectable (greyed out).
However once I dragged and dropped onto the window and asked it to extract data, it confidently said it could and proceeded to extract wrong numbers. That is bad behavior.
Before we move on, lets check if any of the metrics Claude found above are correct.
- All 4 Asset metrics values are wrong.
- Both the Liability metric values are wrong.
- The single Capital metric, Equity Capital is correct
- 2 out of 4 Income Statement metrics are correct
- Key Ratios, Tier 1 Capital Ratio should be 13.17% while the 15.16% reported as this is actually Total Capital Ratio, while Total risk based capital ratio of 17.72% is correct.
All in all, we clearly cannot use XBRL files with Claude.
Claude like other LLMs does not directly use XBRL/XML parsers to extract data, but will have seen a lot of examples of such files in it’s training set and will have learn’t enough about structure and patterns to be of some use but not sufficient to correctly extract data.
Gemini, when given an XBRL file, clearly responds that it cannot process and extract data and recommends using of XBRL viewers/parsers.
It would have been much better if Claude gave a similar response.
SDF
Next let’s try the Semi-colon delimited file format.

Great, this looks positive.
The 3 metrics it offered up are all correct.
So far so good.
Let’s ask for something more complex.
Create a balance sheet, not with the full detailed breakdown as in the file but a standard abbreviated form of balance sheet and present this in a well formatted table.
This returned a nice report which can be seen in full at this link, with a page for Assets and one for Liabilities and Equity.

This looks great and I can see Claude has worked out how to sum/net some rows in the larger Balance Sheet given in the document.
Unfortunately while the Total Assets is correct, the rows above do not sum to this figure but to 1,709,058,000. The difference of 1,970,000, mostly seems to come from Trading Assets being shown as $69,203,000 instead of 71,201,000.
On pointing this out to Claude, it came back with the following.

And a correct Balance Sheet.
I could probably have avoided this Accounting 101 issue by including in my prior prompt the instruction to make sure sub-totals add to totals.
Let’s move onto the next part of the Balance Sheet.

The Equity Capital section is correct but again there is some issue in the breakdown of Total Liabilities, which I again had to ask Claude to investigate and correct.
Interestingly, while it is doing this, I can see some of the javascipt (as below), which shows the rows in the SDF file it is parsing to find specific metrics.

(The RSS Identifier e.g. RCON2200 are the identifiers for metrics and used in the SDF and XBRL files as a key part of the schema).
All in all with the correct prompt, including asking it to check, I can get the information I want.
Next I asked “What regulatory capital ratios are given in the document?”

Nice, it got all those correct and I like the key observations, very helpful.
This gives me confidence that the SDF format works well enough with LLMs.
No need to try the PDF format. as we know the correctly extracting all data from tables in PDF files is error-prone.
In Summary
LLMs cannot process XBRL: While Claude could identify the XBRL file type, it extracted several incorrect values, showing that LLMs can’t yet parse XBRL reliably without dedicated tools.
LLMs can process SDF: The semi-colon delimited (SDF) format worked much better with LLMs, enabling accurate balance sheet summaries and capital ratio extraction with minor corrections.
Prompting is key: Including instructions to check totals and validate outputs significantly improved the accuracy of results.


Leave a Reply