Bank Statement PDF to JSON: Open-Source and Open-Weight Parsing Tools Compared

This is a documentation-based comparison, checked on October 11, 2026, not a bank-statement benchmark. No models were run and no customer documents were used. BankStatementMate currently exports Excel and CSV from supported statements; it does not provide JSON export or integrate these three tools.

Document-layout JSON is not bank transaction JSON

Document-layout JSON describes what is on a page: text blocks, tables, coordinates, reading order and other elements. Transaction JSON describes what each bank row means: a date, description, money out, money in and running balance, under an explicit data contract.

A perfectly valid JSON object can still put an amount in the wrong column, omit a transaction or include an opening-balance label as a payment. A table serialized inside JSON may itself be HTML or another table notation. Its presence does not mean that Debit and Credit have been identified correctly.

The bank statement extractor overview explains the five-field extraction task. This comparison addresses the additional engineering needed when your destination requires JSON instead of a spreadsheet. Categorizing spending is a later, different task; no Category field is needed here.

The three options compared

Sources: Youtu model card, Docling repository, PaddleOCR repository and PP-StructureV3 documentation. These are capability and interface descriptions, not measured bank-statement results.

What you would deploy and inspect

Youtu-Parsing-Omni: the authored quickstart passes a page image to the document task. For that path, render a scanned PDF into ordered page images first. Inspect the returned table representation rather than treating it as transaction rows. The documented serving and Transformers environments have different dependency pins; follow the selected revision's setup. No minimum GPU memory or throughput is established by this article. Official quickstart and output format.

Docling: install the Python package, choose the PDF pipeline and OCR configuration, then convert a local document. Its installation guide explains platform-specific dependencies. DoclingDocument retains structure and provenance; use those to locate tables and trace cells back to pages. Its JSON export is a document representation, not a bank-specific schema. Installation, document model.

PaddleOCR: specify the pipeline, not just the project name. PP-StructureV3 is the concrete choice examined here. Install the matching PaddlePaddle runtime for the documented local path, configure table recognition, and inspect each prediction before saving JSON. save_to_json() serializes the result; it does not rename table columns into banking fields. PaddleOCR also offers VLM pipelines, whose interfaces and requirements should not be assumed identical. PP-StructureV3 usage, project overview.

As a workflow fit judgment, Docling is worth evaluating when you want a unified document model; PP-StructureV3 when you need explicit OCR and table intermediates; Youtu when its page-image parsing approach fits your infrastructure and its license permits your use. This is not a recommendation based on comparative accuracy. Test the complete mapping workflow on representative, authorized samples before choosing.

A practical PDF-to-transaction-JSON workflow

1. Prepare every page and preserve its identity

Inventory the statement's page count, account sections, currency and date range. Distinguish selectable-text PDFs from scans. A scan needs OCR or visual parsing; a digital PDF may allow native text extraction through the chosen pipeline.

For a page-image interface, render one lossless image per page, preserve page order, and record dimensions, rotation and scale. Choose resolution by checking that dates and decimal points remain legible, rather than assuming one setting works for every statement. Keep the original PDF. If you crop a table, retain the crop's offset so coordinates can still locate it on the original page.

Docling and PP-StructureV3 accept PDF input, so a separate manual rendering stage is not always necessary. Do not rasterize a usable text layer merely because another model expects images. The PDF extraction walkthrough covers source and row checks for the existing converter workflow.

2. Identify transaction tables, not every table

Find dated rows with transaction descriptions and monetary columns. Exclude account summaries, interest-rate tables and totals from the transaction list, while retaining totals separately for verification. Use headers, cell positions and reading order together.

Decode the selected parser's table structure before mapping values. Expand merged headers carefully; attach wrapped description lines only when their position and surrounding cells support the same row. Never assign values solely by splitting OCR text on spaces.

3. Define the five-field contract

This is a proposed downstream contract, not a universal bank standard. Keep raw values and mapping decisions alongside it. For a single signed Amount column, implement and verify the bank-specific sign mapping explicitly; do not infer it from merchant names. This does not expand BankStatementMate's supported layouts.

Use decimal arithmetic or integer minor units appropriate to the currency. If you serialize fixed-decimal strings, document that choice for consumers. Do not use binary floating-point rounding to disguise a reconciliation mismatch.

4. Reassemble across page boundaries

Preserve page and row order until validation finishes. Check whether a new page continues the same account and currency. Remove a repeated header only after identifying it as a header. A carried-forward balance is context, not automatically another transaction.

Inspect the last row on one page and the first rows on the next for split descriptions or repeated entries. Matching date, description and amount alone is not sufficient proof of duplication: two legitimate payments can match. Retain source references and flag uncertain joins instead of silently dropping rows.

Illustrative transaction JSON

The following array is illustrative and entirely fictional. It is hand-written, not output from Youtu, Docling, PaddleOCR or BankStatementMate. Assume a fictional USD deposit account with an opening balance of 1,000.00 and chronological rows. The added source and review fields belong to this example's downstream schema.

[
  {
    "rowId": "fictional-001",
    "Date": "2026-09-01",
    "Description": "FICTIONAL INCOMING PAYMENT",
    "Debit": null,
    "Credit": "600.00",
    "Balance": "1600.00",
    "sourcePage": 1,
    "reviewStatus": "needs_review"
  },
  {
    "rowId": "fictional-002",
    "Date": "2026-09-02",
    "Description": "FICTIONAL PAPER HARBOR",
    "Debit": "48.00",
    "Credit": null,
    "Balance": "1552.00",
    "sourcePage": 1,
    "reviewStatus": "needs_review"
  },
  {
    "rowId": "fictional-003",
    "Date": "2026-09-03",
    "Description": "FICTIONAL PAPER HARBOR CREDIT",
    "Debit": null,
    "Credit": "12.00",
    "Balance": "1564.00",
    "sourcePage": 2,
    "reviewStatus": "needs_review"
  }
]

Here, null on the unused debit or credit side means a confirmed blank, not an unreadable amount treated as zero. In a real workflow, an unreadable or missing required amount needs an explicit validation issue and remains unresolved. A parseable JSON array does not justify changing needs_review to approved.

Under this example's stated convention, each balance equals the previous balance plus Credit minus Debit. The closing check is 1,000.00 + 600.00 − 48.00 + 12.00 = 1,564.00. Adapt the convention for the actual account type, balance signs and statement ordering; credit-card statements can differ.

Validate completeness, not just JSON syntax

Before delivering transaction JSON:

• Check the JSON schema, required keys, unique row IDs, date formats and amount types.
• Compare expected pages with pages actually processed; inspect failures, page limits and truncated responses.
• Reconcile row counts against each source page, especially around continued tables.
• Check every debit/credit direction and decimal position against the document.
• Check consecutive running balances when present, then opening/closing totals. Matching totals alone can hide offsetting errors.
• Preserve unresolved rows and their source evidence; never invent missing data to make totals balance.
• Review the first and last row at each page boundary and every suspected duplicate.
• Record parser/model revision, configuration, mapping version and reviewer corrections separately from the raw output.

Official general-document benchmarks do not establish bank-transaction accuracy. A table-structure score is not a measurement of correct transaction dates, amounts, signs or completeness. A future bank-specific evaluation should report field errors, missing/extra rows and review effort on its actual sample; this article supplies no such measured result.

Licenses and privacy are separate decisions

Youtu's EU restriction matters. Its custom license includes an “Additional Territorial Limitation” and states: “Youtu-Parsing IS NOT INTENDED FOR USE WITHIN THE EUROPEAN UNION.” It also says that clause prevails in a conflict. Do not label this release OSI open source or assume an unrestricted Apache grant; describe it as open-weight with custom restrictions. An EU-related deployment needs a license review before use. Actual model license. Public availability alone does not meet the Open Source Definition.

Docling's MIT label applies to its codebase. The project explicitly directs users to the original model licenses for individual model use. Check the OCR, layout and table models selected by your configuration instead of assuming every weight is MIT. Docling license statement.

PaddleOCR's repository is Apache-2.0. Keep its notice and license obligations separate from a blanket claim about every optional model, dependency or hosted service. Review the exact artifacts you deploy. Repository license.

Local software can support a private workflow, but the complete configuration determines where data goes. Docling documents prefetched local models and explicit opt-in for remote processing; model downloads and document uploads are different network actions. Offline and remote-service options.

For any parser, protect page images, JSON, logs and temporary files as financial data. Use fictional documents in public demos. Check the data-use, retention and privacy terms before sending statements to a hosted endpoint; do not assume zero retention. BankStatementMate's browser-side conversion boundary does not extend to a third-party parser or a cloud service you choose later.

If you only need Excel or CSV

You may not need to maintain a JSON parsing workflow. BankStatementMate converts supported PDF, PNG and JPG bank statements into Date, Description, Debit, Credit and Balance, with browser-side processing and OCR for supported scans. Review the output before use, then choose Excel or CSV. It does not provide JSON export, these model integrations, or automatic transaction categorization.

Use the CSV conversion guide or the PDF-to-Excel guide for that workflow.

Convert a supported bank statement to Excel or CSV