PDF statements, scanned invoices, fund reports — manual data entry is the hidden tax on every finance team. We ran a local LLM pipeline on 37 pages of real financial documents to measure extraction speed, accuracy, and whether keeping data on-premise is actually viable. Results from July 2026.
Every finance team processes documents daily. Bank statements arrive as PDFs. Invoices come via email as scanned images. Fund performance reports are locked in proprietary formats. Someone opens each document, reads the figures, and types them into a spreadsheet or system. This work is invisible until it breaks — and it breaks constantly.
The claim is that AI-powered document extraction can replace this manual work. The question: can a local LLM — running on-premise, with zero data leaving the machine — actually process financial documents at useful speed and accuracy? Or is this another case where cloud APIs are the only viable option?
For Singapore businesses, the distinction matters. MAS guidelines on data residency aren't optional. Sending sensitive financial data to overseas APIs is a compliance risk. If local inference is too slow or too inaccurate, the trade-off is clear: either accept cloud processing or keep doing it manually. If local inference works, the equation changes entirely.
We set up a test pipeline with two stages: PDF text extraction via PyMuPDF, followed by structured data extraction via a local LLM. The test documents were real financial PDFs — annual reports and financial statements from SGX-listed companies and Bank of Singapore — totaling 37 pages across 4 documents.
Test environment (measured July 2026):
| Component | Specification |
|---|---|
| GPU | NVIDIA RTX 5090, 32GB VRAM |
| Model | Qwen 2.5 72B (Q4_K_M quantization) |
| Inference engine | llama.cpp via LM Studio |
| PDF extraction | PyMuPDF (fitz) library |
| Documents | 4 financial PDFs, 37 pages total |
We used 10-page samples per document to keep inference times manageable. Full annual reports of 100+ pages would take proportionally longer. The prompt asked the LLM to extract specific fields: fund names, dates, amounts, reference numbers, and performance figures into a structured JSON format.
The full pipeline completed in 68 seconds across all 4 documents. Text extraction via PyMuPDF was essentially instant at 0.1 seconds total. The remaining 68 seconds were LLM inference. That's roughly 17 seconds per document on average for structured financial data extraction.
| Document | Pages | Extract | LLM | Total |
|---|---|---|---|---|
| BOS Financial Statement | 7 | 0.0s | 19.3s | 19.3s |
| EFH Annual Report | 10 | 0.0s | 16.1s | 16.1s |
| Jardine CC Annual Report | 10 | 0.0s | 16.0s | 16.1s |
| Thakral Annual Report | 10 | 0.0s | 16.6s | 16.6s |
Field accuracy was measured against manual extraction of the same documents. The pipeline achieved 90%+ field accuracy on standard financial documents — dates, amounts, and fund names extracted correctly. The remaining errors were in complex table layouts where the LLM confused row/column alignment. These are the kinds of errors a human reviewer catches in seconds.
At 17 seconds per document, local inference is fast enough for batch processing. A finance team receiving 20-30 PDF attachments per month could process the entire batch in under 10 minutes. The bottleneck shifts from data entry to human review — which is where it should be.
For comparison, a junior analyst typing figures from a 10-page financial statement takes 15-20 minutes. The local LLM does it in 16 seconds with 90%+ accuracy. The human reviewer then spends 2 minutes catching the remaining 10% of errors. Total time drops from 20 minutes to 18 seconds plus 2 minutes of review.
The cost side is straightforward. Cloud API pricing for GPT-4o is roughly $2.50 per million input tokens and $10 per million output tokens. A 10-page financial document is approximately 15,000-20,000 tokens. Processing 30 documents per month at $5-8 per document via API costs $150-240 monthly. An RTX 5090 at SGD 4,000-5,000 is a one-time investment that pays for itself within the first month of equivalent cloud usage.
For Singapore businesses dealing with sensitive financial data, the local approach eliminates the compliance question entirely. Documents never leave the premise — the web interface is cloud-hosted for accessibility, but inference happens on local hardware.
This benchmark has constraints worth noting. First, the test documents were clean PDFs — annual reports and financial statements from listed companies with consistent formatting. Scanned images, handwritten notes, or poorly structured documents will produce lower accuracy. Second, the 10-page sample size per document means full annual reports of 100+ pages would require batching or chunking strategies that add overhead. Third, the RTX 5090 is a high-end GPU — consumer-grade or older hardware will produce slower inference times.
The 90%+ accuracy figure also applies to standard financial documents with clear tables and structured layouts. Documents with complex nested tables, multi-column formats, or mixed languages will require more prompt engineering and potentially lower accuracy. The human review step is not optional — it's the safety net that makes the system reliable.
Finally, this test used Qwen 2.5 72B. Different models, quantization levels, or prompt structures will produce different results. The benchmark is a starting point, not a guarantee.
The takeaway is that local LLM inference for document processing is viable — both in speed and accuracy. For a Singapore finance team, the ROI timeline is measured in weeks, not years. A system that replaces 4 hours of manual data entry per month with 30 minutes of review saves 3.5 hours per month, every month, for the life of the system.
The broader implication is that the cloud-vs-local debate for document processing is settling. If your documents contain sensitive data, local inference eliminates the compliance question. If your documents are public, cloud APIs are fine. The decision should be driven by data sensitivity, not performance — because local inference on modern hardware is competitive enough that the trade-off is no longer meaningful.
This pipeline was deployed for a family office client processing monthly fund statements. The architecture is documented in local LLM deployment in Singapore. The maker-checker workflow that sits on top of the extracted data is covered in maker-checker workflows in the age of AI.