Financial document extraction for Bridge

Bridge runs a marketplace where businesses ask for financing and lenders respond. Before a lender sees anything, a borrower fills in a long request with company basics, sponsors, and pages of numbers from balance sheets and income statements. Almost all of this is already in documents the borrower has, so the borrower ends up typing it in a second time. We wanted to prefill those requests accurately enough that borrowers could trust and check the results.

How a borrower uses it

Borrowers submit these financials under their own names, so each extracted value includes its source line and confidence score for review before submission.

Initial extraction pipeline

The first version used IBM Docling to parse PDFs, spreadsheets, Word files and slides, then passed the text to an LLM for field extraction. Field accuracy was 40 to 52% against hand-checked answers.

In the failed extractions, the model sometimes chose an old year-end statement over current figures or copied only part of a liability. Empty year-to-date columns led to incorrect revenue, and missing fields were sometimes filled with estimates that appeared nowhere in the documents.

Table extraction and validation

The revised pipeline extracts values directly from tables and reserves the LLM for fields that require reasoning. Reducing the LLM's role improved accuracy without requiring a larger model.

The balance-sheet identity, assets = liabilities + equity, provides an arithmetic consistency test for the extracted totals. If a total doesn't match its parts, the pipeline recomputes the parts in proportion and lowers the confidence score, so the borrower knows to check that field. We also made the pipeline always prefer the most recent document. That change alone fixed a surprising number of errors.

Making it faster

Every request originally sent the whole document to the model, taking 67 seconds per document. We considered embedding-based retrieval, then found a simpler way to choose the context. Requests for financial fields only needed the tables, while requests for company details needed the opening, where names and addresses appear. Restricting the inputs improved accuracy and made processing three to four times faster, with no vector database to run.

Architecture and field-level provenance

Supabase edge functions handle authentication, uploads and job creation. A FastAPI service handles document parsing, schema population, confidence scoring and field-level provenance. Source references and confidence scores remain attached to each field through the review UI.

We also started filling gaps from public data, such as SEC filings and company records from People Data Labs. We respected robots.txt and stuck to public sources. We wanted to use LinkedIn data but couldn't.

What we learned

Several of the first version's errors came from choices we could make explicit. The model sometimes preferred an older statement or filled a missing field with an estimate. Recency rules and direct table extraction reduced how much of that work we left to the model.

Accounting checks gave us another way to challenge the output. Assets had to equal liabilities plus equity, but a balance sheet that balanced could still contain an incorrectly extracted value. We kept source lines and confidence scores on every field so borrowers could verify and correct the extraction, even when the arithmetic was consistent.