Case study · Financial-statement extraction

SEC filings turned into spreadsheets, automatically.

Analysts who compare companies need the numbers in rows and columns. The filings that hold those numbers are written to be read, not to be parsed. We built the system that closes that gap — with up to 98% extraction accuracy across all five statement types.

← All cases

Context

A financial-information service with a manual step in the middle of it.

The client runs a financial-information service: what they sell is SEC filing data, delivered to their users as structured, analyst-ready output. Every model, comparison, and screen those users build starts with figures that are sitting inside 10-K and 10-Q documents.

Getting those figures out was the manual step in the middle of that service. What had to come out the other end wasn't a summary of a filing and wasn't a chatbot on top of it — it was the statements themselves: complete, in a consistent structure, in the spreadsheet format their users' analysis already lived in.

Domain: Financial data · SEC filings
Documents: 10-K and 10-Q filings
Coverage: All five statement types
Output: Excel, consistent structure

What happened

Challenge, solution, result.

Challenge

The numbers were locked inside hundreds of pages of prose.

A 10-K is a narrative document with tables in it. The financial statements sit somewhere in the middle of hundreds of pages, and every company lays them out its own way — different section ordering, different labels for the same line item, different table structures, footnotes that change what a figure means.

So the work fell to a person: open the filing, find the statements, and re-key the figures into a spreadsheet, filing by filing. It was slow, it capped how fast the service could deliver, and every manual step was a chance to put a number in the wrong row — the kind of error that survives all the way into a user's conclusion because nobody re-checks a figure that looks plausible.

The bar the client set was uncomfortable on purpose: the extraction had to hold across all five statement types, not just the headline income statement. Anything less and their user still has to open the filing — which means the service hasn't removed the manual step, only moved it.

Solution

An extraction pipeline built around what a statement means.

We built a system that reads a filing end to end, locates the financial statements inside it, works out which of the five statement types each one is, and pulls the figures out into a consistent structure — the same shape for every company, regardless of how that company chose to present its own accounts.

Layout was the hard part, so the system doesn't rely on it. It works from what a line item is rather than where it sits on the page, which is what lets one pipeline handle filings from issuers that share no common template. Validation runs on the way out: totals that don't reconcile and figures that contradict each other are surfaced rather than silently exported.

The last mile was deliberately unglamorous. Output lands as an Excel workbook in the structure their users already work in, so the result plugs into existing models instead of asking anyone to adopt a new tool. Under the hood it runs on Python with a FastAPI service and a PDF-parsing layer — the interesting engineering is in the statement recognition, not in the stack.

The five statement types the pipeline covers

Income statement
Balance sheet
Cash flow statement
Statement of shareholders' equity
Statement of comprehensive income

Result

Up to 98% extraction accuracy across all five statement types.

Accuracy was measured against filings that had been verified by hand, and it held across all five statement types rather than only on the statement that is easiest to parse. That is the number that mattered: coverage without a soft spot, because a soft spot is what sends a user back into the PDF.

The output landed directly in the spreadsheet format their users already worked in, so extraction stopped being a step somebody performed and became something that had already happened by the time a user opened the data. The manual re-keying — and the transcription errors that came with it — came out of the service.

We publish the figure as "up to 98%" on purpose. Extraction accuracy depends on the source documents, and we would rather quote a number we can stand behind on a fresh set of filings than one that only describes a good day.

Have a document type your team still re-keys by hand? Let's look at a real sample.

Show me on my data

Outcomes

What changed for the people doing the work.

The point of the project was never the pipeline. It was what the client's service stopped having to do by hand once the pipeline existed.

Complete statement coverage

All five statement types extracted, not just the income statement — so no filing has to be reopened for the parts the tool skipped.

Up to 98% accuracy, measured

Scored against manually verified filings rather than estimated. The number is what the extraction did, not what we hoped it would do.

Consistent structure across issuers

Every company's accounts come out in the same shape, which is what makes comparison across filings possible without a cleanup pass.

Output in Excel, not in a new tool

Results land in the spreadsheet format their users' analysis already lives in, so nothing about how those users work had to change.

Transcription errors designed out

The step where a figure gets typed into the wrong row is gone. Contradictions and totals that don't reconcile get flagged instead of exported quietly.

Expert time back

The hours previously spent finding and re-keying figures go back into the service itself, rather than into work a pipeline can do.

One thing we don't claim: a processed-volume figure. We can't verify it from records we hold, so it stays off this page — the accuracy number is the one we can stand behind.

Where this applies

Financial filings are one flavour of a very common problem.

Nothing in this project was specific to the SEC. The shape of the problem — figures that matter sitting inside long documents that no two issuers format the same way — is the same one behind invoices from a hundred different suppliers, contracts drafted by a hundred different lawyers, and tender packs assembled by a hundred different buyers.

If your team is re-keying numbers out of documents into a spreadsheet, the approach here transfers: work out what "done" looks like in numbers first, build extraction that reads meaning rather than layout, measure accuracy against a set you sign off on, and deliver the output into the tool your people already open.

Our AI document processing service →

Next step

Let's see what this looks like on your documents.

Tell us the one document type that eats the most of your team's time. We'll come back with what AI can realistically do with it — on your data, and with the accuracy number we'd be willing to publish.

Start a conversation

← Back to all cases