Bankstatemently

High-accuracy bank statement converter from PDF to CSV, XLSX

Visit Website
March 19, 2026 I open-sourced all the edge cases I've found while building my bank statement parser, Bankstatemently

I'm doing something crazy: I'm giving everyone a chance to build their bank statement parser faster

Today, I'm releasing the Bankstatemently Open Benchmark, the world's first open benchmark for bank statement parsing 🎉

It exposes all of the challenges and edge cases that I've come across so far while building my product. All of the secrets that other companies would call their IP

After processing many bank and credit card statements at Bankstatemently, I've run into plenty of edge cases. Affectionately, I've started calling them "quirks" and cataloged 37 of them so far

They range from:
• Credit card charges shown as positive numbers
• Thai Buddhist calendar dates (year 2568 instead of 2025)
• Transaction dates hiding inside the description text
• Day and month split across two separate columns

Why give all of this away?

Because the challenges aren't actually the secret. Everybody can now build a bank statement converter

The secret is solving all of them at once, reliably, and at scale. Any SOTA vision model can pull out transactions from a PDF. Interpreting the data is the hard part

But here is the problem: you can't test any of this against real data. Bank statements are private. You can't share them, benchmark against them, or publish them. So every tool claims "99% accuracy" and there's no way to verify

That's why I built the benchmark. 5 synthetic statements from 5 countries, 14 of the 37 documented challenges, each using a fictional bank with realistic formatting. Free and open-source

Download the PDFs. Run them through your parser. Submit to the evaluation API and get a detailed accuracy breakdown. You're free to do whatever you want with them

Why does this matter to me?

I care enough about accuracy that I built the evaluation system before I built the actual product. You can't have a financial document be a little bit wrong. People build their businesses on trusting your results

I'm planning on 10 more statements. What ends up in those 10 will partly depend on your feedback. If you know a parsing challenge that's not in the list, tell me

Read more: https://bankstatemently.com/blog/bankstatemently-open-benchmark-bank-statement-parsing
Or check out the public Github repo: https://github.com/bankstatemently/bank-statement-parsing-benchmark

Comment

February 12, 2026 Bankstatemently - Bank Statement Converter 2.0

Momentum is growing for Bankstatemently

This week felt chaotic - I welcomed the first 2 paid monthly subscribers. Both immediately pushed the system and surfaced several hard limitations in the current setup. It seems like they're both small businesses with multiple accounts across multiple banks. That use case makes a lot of sense to me - They're essentially trying to get an overview of their financial health

I'm becoming more and more bullish on product-founder fit. It's just extremely cool to see statements being uploaded from all over the world. The audience is global from day one, which oddly feels like traveling while building. I’ve spent a lot of time getting the foundations right, and that’s starting to compound. The tool is language-agnostic, and simply by adding a "banking dictionary", 15 minutes later, it was able to parse a Canadian French statement correctly

Bankstatemently prend désormais en charge le français (bêta) 🇫🇷🤓

Things I'm struggling with most:

• 𝗢𝗯𝘀𝗲𝗿𝘃𝗮𝗯𝗶𝗹𝗶𝘁𝘆. Taking time to build internal mini-features that'll improve visibility. I only just now pushed my admin panel live. The lack of visibility creates unnecessary anxiety, so this is like self-care. But of course, user-facing, it also improves trust and explainability
• 𝗖𝗼𝗺𝗽𝗼𝘂𝗻𝗱𝗶𝗻𝗴 𝗘𝗻𝗴𝗶𝗻𝗲𝗲𝗿𝗶𝗻𝗴. Inspired by Every and a recent thread by the builder of Fintool.com. It's no longer about writing specs in markdown - it's about invoking that skill while building, then sharpening it through feedback loops. That’s where momentum comes from
• 𝗧𝗮𝘀𝘁𝗲 𝘁𝗿𝗮𝗻𝘀𝗳𝗲𝗿. I feel I am already building/releasing very fast, but it's still that transfer (and retention) of taste to the AI agent that's a bottleneck. I'm approving and conducting too much still. At the same time, I don't believe an extremely well-built, opinionated product can be built by AI alone yet. It needs human judgment

Product-wise, the roadmap feels pretty clear, but for next week, I'm still refining some things for higher accuracy. Correctness > features. After that, these premium features are coming up:

• A user dashboard with document history
• Multi-statement support in a single PDF
• True multi-table detection

I'm consciously not pushing a lot on distribution. There’s a healthy balance right now between things breaking (and getting fixed) and growing usage. Even with minimal effort, I’m already seeing latent demand from SEO alone. Bankstatemently is not even ranking anywhere near the top yet (≈ SERP 60 for “bank statement converter”), but it's already generating impressions and clicks

I'm also trying to reduce noise as much as possible. While it’s important to stay aware of what’s happening in the space, I’m deliberate about what I engage with and which new shiny tool dominates the public discourse 🤖

So all in all - Still early, but the signal is getting clearer 😃

12 Comments

  1. 1

    Interesting update. Bank statements are definitely one of the trickier document types because of varying layouts and multi-page tables.

    We’re also exploring bank statement table extraction while building Docuct, so I’m curious — what approach are you using for parsing the transaction tables? Is it mainly OCR-based with post-processing, or a layout-aware model?

    1. 1

      Thanks! Yeah multi-page tables are definitely one of the harder problems. We use a hybrid approach — layout-aware parsing for structure detection, then rule-based extraction tuned per bank template. What approach are you taking with Docut?

      1. 2

        In Docuct we mainly combine OCR with AI-based extraction to handle different document layouts. We also use custom blueprints so users can define the fields they want to extract. For tricky cases like bank statements or multi-page tables, the human-in-the-loop validation helps ensure the extracted data is correct.

        give it try : docuct.ai

        1. 1

          Nice, human-in-the-loop is a pragmatic approach for the tricky cases. Curious how you measure extraction accuracy across different layouts, though?

          I just open-sourced a dataset of synthetic bank statements specifically designed around these edge cases (multi-page tables, bilingual headers, inverted credit card signs, etc). Might be useful for testing your product against: github.com/bankstatemently/bank-statement-parsing-benchmark

          1. 1

            Good question! We typically measure accuracy at the field level (precision/recall for key fields like date, amount, etc.) and also check row-level correctness for tables.
            For complex layouts like multi-page statements, we combine automated evaluation with manual validation to catch edge cases...

  2. 1

    Congrats on the launch, looks solid. How are you currently thinking about acquiring early users and gathering feedback?

    1. 1

      Thanks! Mostly just making sure the product works really well for the people who do find it, and fixing what breaks. Word of mouth and SEO are doing the rest for now.

      1. 1

        That is a great decision. When are you planning to dive into the marketing world for your brand?

        1. 1

          Actually just started this week! I open-sourced a benchmark dataset for bank statement parsing and posted it across a few channels today. Trying to reach the developer community first since they're the ones who understand the problem best. Early days but it feels like the right way to build awareness without faking it. You can read more about it here https://bankstatemently.com/blog/bankstatemently-open-benchmark-bank-statement-parsing

          1. 1

            That's a smart strategy; open-sourcing something valuable is an effective way to grab developers' attention early on. Since your target audience consists of developers, you'll find that many of them are very active on Reddit, particularly in discussions about tools, datasets, and workflows. If positioned correctly, these discussions can attract relevant early users.

            I've observed that similar launches can gain significant traction on Reddit when approached in a structured manner, rather than simply posting links. If you're interested, I can share my suggested approach for utilizing Reddit effectively for this type of initiative.

  3. 1

    Congrats on the first paid subscribers! That's a huge milestone!
    Since you mentioned you aren't pushing distribution heavily yet, I’m curious; how did those first two find you? Was it purely through the SEO impressions you mentioned, or something else?

    1. 2

      Thanks Al! Yeah, both came through organic search. Bankstatemently was ranking around SERP 60 for "bank statement converter" at the time, but it was generating impressions on more specific long-tail queries — things like specific bank names + "statement to CSV". So it was SEO, just not the main keyword yet. No paid ads or outreach.

About

Financial data isn’t accessible through APIs the way people hoped. Bankstatemently is a bank statement converter that turns financial documents into structured, reliable data, across languages, layouts, and edge cases.