cs.AIAug 24, 2026
SaveFinixDoc: Rethinking Financial Document Parsing Beyond Saturated Benchmarks
Organizations: Ant Group, Hangzhou, China
Abstract
Financial document parsing requires accuracy, structural consistency, and verifiability that current benchmarks often fail to reflect. We present FinixDoc, an end-to-end agentic parsing system for real-world financial documents, with FinixDoc-VL, a 4B-scale vision-language model built on Qwen3-VL-4B, as its core parser. To characterize the gap between benchmark and deployment performance, we introduce a Document Parsing Capability Matrix organized along two practical axes: visual quality and document scale. Guided by this matrix, FinixDoc-VL is trained with a domain-adapted recipe combining homoglyph-aware contrastive learning and multi-stage reinforcement learning with composite domain-specific rewards. To better leverage our accumulated advantage in low-quality financial-document data and support large-scale, high-quality data production, we further build a human-in-the-loop Data Factory pipeline with confidence-aware expert review. For evaluation, we construct FinixDocBench, a financial-domain evaluation suite covering digital-native, camera-captured, ultra-large-page, and internal-workflow scenarios, with a compliance-reviewed subset released alongside this technical report. On its main subsets, FinixDoc-VL achieves the highest overall score (81.43) among evaluated baselines, outperforming the next-best open-source model by 5.13 points, with the largest gains on internal financial workflows (FinixInner: 84.08 vs. 78.73).
Figures & tables
Figure 2: Document Parsing Capability Matrix. The horizontal axis represents decreasing document quality, ranging from digital or scanned documents to camera-captured documents affected by perspective distortion, creases, and blur. The vertical axis represents increasing document scale, ranging from single-page or single-image inputs to ultra-long documents and ultra-large images. Based on this matrix, document parsing scenarios can be categorized into the Benchmark-Converged Zone, Low-Quality Zone, Underexplored Large-Scale Zone, and Ambiguous-Unrecoverable Zone.
Figure 3: Overall architecture of FinixDoc. The output format (JSON or Markdown) is specified by the user prompt.
Figure 4: Parsing output examples on example.pdf : Markdown (top) vs. JSON (bottom).
Figure 5: Overall training framework of the proposed financial visual representation adaptation method via contrastive learning. Given a document image and its ground-truth text, hard negative texts are generated through financial homoglyph substitution. The model is then optimized with dual-path contrastive objectives over both visual and multimodal generative representations, jointly with the supervised fine-tuning objective.
Figure 6: Overview of reinforcement learning fine-tuning with domain-specific rewards. The RL stage jointly optimizes JSON and Markdown generation through multi-stage sub-capability calibration followed by unified GRPO alignment. Task-dependent reward masks combine text fidelity, detection quality, and reading-order consistency according to the output format.
| Source | Dataset / Document Type | Size |
| Out-of-domain | DocLayNet | 45k |
| Out-of-domain | Infinity-Doc-55K | 55k |
| In-domain | Identity Documents | 20k |
| In-domain | Medical Examination Reports | 10k |
| In-domain | Financial Research Reports | 10k |
| In-domain | Insurance Policies | 10k |
Table 1: Composition of the training data used in the reinforcement learning stage.
| Task | ||||||
| JSON | 0.5 | 0.4 | 0.1 | 1 | 1 | 1 |
| Markdown | 0.5 | 0.4 | 0.1 | 1 | 0 | 1 |
Table 2: Reward hyperparameters and mask settings for the JSON and Markdown tasks.
Figure 7: Overview of the Data Factory pipeline.
| Document Type | Source Type | Evaluation Track | Volume (Pages) |
| Financial Reports & Insurance Clauses | Digitally Native | FinixDigital | 500 |
| Medical Receipts | Mobile Captured | FinixPhoto | 300 |
| Large-Scale Financial Pages | Mixed Quality | FinixHuge | 200 |
| Identity Documents | Mobile Captured | FinixInner | 800 |
| Medical Examination Reports | Mobile Captured | FinixInner | 800 |
| Claim Medical Records | Mobile Captured | FinixInner | 800 |
Table 3: Data composition of FinixDocBench.
| Model | Document-level Accuracy ( ) |
| Donut | 0.922 |
| MinerU | 0.924 |
| Qwen3-VL-2B | 0.917 |
| Qwen3-VL-4B | 0.929 |
| Qwen3-VL-4B (ViT-only adapted) | 0.935 |
Table 4: Ablation results on the internal driving license recognition task. Performance is measured by Document-level Accuracy.
| Model | |||||||
| Qwen3-VL-4B | 86.90 | 86.78 | 0.055 | 86.55 | 79.29 | 84.26 | 0.084 |
| FinixDoc-VL | 92.65 | 87.40 | 0.042 | 76.89 | 89.50 | 92.76 | 0.055 |
| Specialized Models | |||||||
| DeepSeek-OCR-2 | 90.35 | 89.17 | 0.049 | 86.85 | 85.60 | 90.06 | 0.060 |
| Dots.OCR | 90.99 | 88.41 | 0.048 | 83.22 | 86.78 | 90.62 | 0.053 |
| MinerU 2.5 | 91.97 | 90.93 | 0.045 | 88.86 | 88.44 | 92.42 | 0.044 |
Table 5: Performance on OmniDocBench v1.5.
| Model | |||||
| Qwen3-VL-4B | 80.18 | 0.145 | 76.04 | 81.23 | 0.210 |
| FinixDoc-VL | 93.19 | 0.039 | 92.07 | 93.67 | 0.086 |
| Specialized Models | |||||
| DeepSeek-OCR-2 | 82.80 | 0.139 | 90.00 | 92.32 | 0.277 |
| FireRed-OCR | 83.10 | 0.119 | 87.10 | 89.14 | 0.259 |
| PaddleOCR-VL-1.5 | 85.41 | 0.116 | 86.12 | 88.26 | 0.183 |
Table 6: Performance on FinixDigital.
| Model | |||||
| Qwen3-VL-4B | 54.28 | 0.408 | 50.13 | 63.04 | 0.465 |
| FinixDoc-VL | 67.03 | 0.276 | 69.08 | 77.69 | 0.404 |
| Specialized Models | |||||
| PaddleOCR-VL-1.5 | 41.28 | 0.512 | 34.54 | 46.72 | 0.595 |
| MinerU 2.5 | 43.08 | 0.513 | 35.54 | 48.58 | 0.550 |
| DeepSeek-OCR-2 | 43.20 | 0.459 | 30.69 | 43.52 | 0.552 |
Table 7: Performance on FinixPhoto.
| Model | Success Rate | |||||
| FinixDoc | 0.92 | 68.23 | 0.357 | 57.09 | 60.10 | 0.167 |
| Qwen3-VL-235B-A22B-Instruct | 0.68 | 34.85 | 0.847 | 47.05 | 63.20 | 0.578 |
| GLM-OCR | 0.34 | 38.06 | 0.816 | 59.39 | 62.43 | 0.636 |
Table 8: Performance on FinixHuge. FinixDoc denotes the complete system, including the Document Preprocessing Tool Layer’s split-then-merge (tiling-and-merging) module.
| Model | Overall | Claim Medical Records | Expense Statements | Expense Receipts | Medical Examination Reports | Identity Documents |
| Qwen3-VL-4B | 66.42 | 50.24 | 64.85 | 70.55 | 60.21 | 86.26 |
| FinixDoc-VL | 84.08 | 85.42 | 80.79 | 85.15 | 78.38 | 90.64 |
| Specialized Models | ||||||
| DeepSeek-OCR-2 | 52.77 | 42.40 | 54.37 | 66.92 | 53.64 | 46.51 |
| FireRed-OCR | 64.93 | 50.23 | 62.67 | 66.24 | 69.45 | 76.08 |
| PaddleOCR-VL-1.5 | 61.06 | 45.17 | 65.19 | 62.86 | 56.30 | 75.79 |
Table 9: Performance on FinixInner.
Appendix figures & tables9 assets
Supplementary material from the paper’s appendix.
Appendix
Figure 8: Internal pipeline of the split-then-merge strategy in the Document Preprocessing Tool Layer. The strategy follows a three-stage process: Dynamic Routing, Structure-Aware Segmentation, and Reconstruction. Depending on token feasibility and structural complexity, an input page is processed either by direct VLM parsing or by a split-then-merge path for ultra-large-page handling.
| Target Character | Example Homoglyphs | Target Character | Example Homoglyphs |
| 0 | O, 8, 6, 9, D | 维 | 唯, 淮, 推, 准 |
| O | 0, Q, D | 清 | 靖, 情, 请, 洁 |
| I | l, 1, | , ! | 请 | 情, 清, 谱, 讲, 证 |
| l | I, i, | , ! | 组 | 细, 织, 绪, 级, 纸 |
| | | I, l, !, 丨 | 痛 | 疼, 病, 痹, 痪 |
| 1 | I, l, 7, ! | 靖 | 情, 晴, 清 |
Table 10: Representative examples from the financial homoglyph vocabulary.
| Stroke Count | Example Characters |
| 1 | 一, 丨, 丶, 丿, 乙 |
| 2 | 丁, 七, 乃, 九, 了, 二, 乜 |
| 3 | 万, 丈, 三, 上, 下, 久, 义, 亡, 个, 丫 |
| 4 | 不, 丑, 专, 中, 丰, 乌, 书, 云, 互, 五 |
| 5 | 且, 世, 丘, 业, 东, 丝, 乎, 乏, 乐, 主 |
| 6 | 丞, 丢, 两, 争, 亘, 亚, 交, 亥, 亦, 产 |
Table 11: Representative examples from the stroke-count lexicon.
Figure 9: FinixDigital Sample 1. Comparison of parsing results for an insurance clause page containing a two-column disease list table and footnote references. FinixDoc correctly preserves the two-column table structure for the 15 infectious diseases, maintains proper heading hierarchy ( ## , ### ), and retains superscript footnote references ( 11 , 12 ). In contrast, MinerU 2.5 collapses the table into a flat list, fails to encode the heading hierarchy, merges neighboring text around the disease-list introduction, and introduces OCR errors. Qwen3-VL-235B-A22B-Instruct preserves the table layout more completely than MinerU 2.5, but still fails to encode the heading hierarchy, changes domain terms in the disease-list entries (e.g., 特定传染疾病定义 becomes 特定传染病定义 ), and introduces a footnote-level OCR error (e.g., 入住医院 becomes 入往医院 ).
Figure 10: FinixDigital Sample 2. Comparison of parsing results for an insurance product specification page containing a financial illustration table and section headings. FinixDoc preserves the numeric table grid, reconstructs the heading hierarchy ( ### 3 , #### 3.1 , #### 3.2 ), and maintains consistent list formatting with (1) and (2) numbering. MinerU 2.5 fails to render the circled section marker and subsection hierarchy as Markdown headings and mixes bullet styles in the notes. Qwen3-VL-235B-A22B-Instruct misinterprets the first numeric data row as a table header and introduces an HTML/dataframe-style table with an extra index-like column.
Figure 11: FinixDigital Sample 3. Comparison of parsing results for an insurance contract page with nested headings, a structured table, and footnote references. FinixDoc accurately reconstructs the heading hierarchy ( ### 3.3 , ### 3.4 , ## 4 , ### 4.1 – ### 4.4 ), preserves the table with proper headers, and retains superscript footnote references ( 12 , 13 ). MinerU 2.5 flattens the heading hierarchy, loses or inconsistently renders superscript footnotes (e.g., 12 becomes plain text), and degrades the page-ending footnote area. Qwen3-VL-235B-A22B-Instruct preserves the table but inserts spurious spacing between Chinese characters, appends extraneous AI commentary after the parsed page, and shows inconsistent heading formatting.
Figure 12: FinixPhoto Sample 1. Per-field comparison on a Shanghai inpatient receipt captured under challenging conditions. Four fields are highlighted: the fee-detail table, the total amount ( 51206.15 ), the medical-insurance payout ( 23069.33 ), and the payee-unit number ( 1600206215 ). FinixDoc parses all four correctly. Youtu-Parsing reads the total as 161206.15 , the insurance payout as 230893.33 , drops the payee-unit number, and produces a heavily garbled fee table. Kimi-K2.5 gets the numeric fields right but its fee table is missing most of the 14 items present in the original.
Figure 13: FinixPhoto Sample 2. Per-field comparison on a Chongqing outpatient medical receipt. Four fields are highlighted: the invoice number ( 0559817 ), the Chinese-capital total (肆佰叁拾叁圆捌角整), the payee (龙邱渝), and a synthetic “back-page area” box at the bottom strip of the receipt. FinixDoc gets the invoice number, the Chinese total, and the payee correct, and crucially does not hallucinate any content beyond what is visible on the front of the receipt. Youtu-Parsing renders the Chinese total as a plain “ 433.80 ” and drops the payee. Both Youtu-Parsing and Kimi-K2.5 hallucinate extra back-page items (e.g., CT, 重症监护, 中医治疗) that are not visible in the input image.
Figure 14: FinixPhoto Sample 3. Per-field comparison on a Hubei outpatient medical invoice. Four fields are highlighted: the receipt code ( 1420601 ), the unified social-credit code ( 00000507 ), the issue date ( 2020-08-12 09:52:59 ), and the cashier code ( 1890266 ). FinixDoc gets all four correct. Youtu-Parsing truncates the receipt code to 20601 , prefixes the social-credit code with an extraneous 123 , drops the issue date, and reads the cashier code as 1890260 . Kimi-K2.5 reads 0000507 (one leading zero missing) for the social-credit code and 2020 06 12 09 52 59 (wrong month, lost separators) for the issue date.
More in this topic
Document Parsing
Document parsing converts PDFs and page images into structured, machine-readable text, tables, formulas, layouts, and reading order.
See all 63 papers