What's New in v4: More Reliable Statement Extraction

Some bank statements look simple to a person but are surprisingly difficult for automated extraction. A transaction can be split across several lines, a credit can be marked with a small Cr suffix, or a statement can include rate notices and summaries that look like financial rows but are not real transactions.

Version 4 focuses on those messy edge cases. The result is fewer failed conversions, fewer one-row results, and cleaner transaction data for statements that previously needed manual cleanup.

Better Recovery When Structured Extraction Falls Short

The converter now has a stronger fallback path for PDFs that contain embedded text. If the first extraction pass returns no transactions, or only a suspiciously small result, the system can inspect the PDF text directly and recover transactions from the original statement layout.

This helps with PDFs where the visible statement data is present, but the table structure is not clean enough for a single extraction pass.

Improved Support for Compact Bank Layouts

Many banks do not export statements as clean tables. Some use compact layouts like:

02 Sep FNB App Transfer From Test
1.00Cr
1.00Cr

or:

5/1/2025 List Posted Item
-880.67

The converter now handles these patterns more reliably:

• Date plus description on one line, amount on the next line
• Date, description, and amount split across separate lines
• Multi-line descriptions that continue before the amount
• Balances printed on their own line after the transaction amount

Cleaner Credit and Debit Detection

Different banks mark money movement in different ways. Some use separate debit and credit columns, while others use suffixes like Cr and Dr.

Version 4 improves amount normalization for:

• 1.00Cr credits
• 88,001.00Dr debits
• debit columns that already include a minus sign
• one-decimal amounts like 369.2
• balances with credit suffixes

This reduces cases where a debit was accidentally treated as a credit, or where a credit was missed because the marker was attached directly to the number.

Smarter Date Handling

Date parsing now looks at the document before deciding how to interpret numeric dates. If a statement includes dates like 5/13/2025, the converter treats the file as month/day/year. If it sees dates like 13/5/2025, it treats the file as day/month/year.

That prevents common date swaps such as April 1 becoming January 4.

The parser also handles month-name dates that omit the year, such as 02 Sep, by using the statement year when it is available elsewhere in the document.

Better Filtering of Non-Transaction Text

Statements often include notices, rate changes, marketing text, summaries, and closing balances near the transaction table. Version 4 is stricter about excluding rows that are not actual transactions.

For example, rate-change notices are no longer treated as transaction rows just because they contain a date and a percentage.

What This Means for You

You should see better results on:

• bank statements with compact transaction blocks
• international statements using Cr and Dr
• PDFs with embedded text but weak table structure
• one-page business account statements
• files that previously returned only one incorrect row

The goal is simple: fewer retries, fewer manual fixes, and more complete exports to Excel, CSV, JSON, and QBO.

Have a statement that still extracts poorly? Contact us and include the bank name, output format, and what looked wrong. Real-world edge cases help us improve the converter quickly.