DEV Community: FLOW by Vestelon

The Freelancer Hidden Tax: Multi-Currency Income and Financial Blind Spots

FLOW by Vestelon — Fri, 19 Jun 2026 09:01:15 +0000

The Freelancer Hidden Tax: Multi-Currency Income and Financial Blind Spots

Remote work has created financial complexity most budgeting tools weren't designed for. If you earn USD while living in Europe, or GBP while based in Southeast Asia, you're dealing with structure that's genuinely hard to track.

I built FLOW partly because of this problem. After processing thousands of multi-currency statements from international freelancers, here are the patterns that consistently appear.

The Three Invisible Costs

1. Payment processor fees that don't look like fees

PayPal, Wise, and Stripe all convert at rates slightly worse than mid-market. The difference doesn't appear as "fee" — it appears as a slightly lower deposit than expected. Over a year of regular payments, this is typically 1-3% of total income. It's invisible unless you compare each deposit amount to the invoice amount and the mid-market rate at the time.

2. Subscription creep in the work currency

Freelancers maintain most software in USD: Figma, Notion, GitHub, AWS, Loom, Zoom. As the dollar strengthens against local currency, these subscriptions become proportionally more expensive — but the USD amount stays constant, so it doesn't feel like an increase. It only becomes visible when you calculate actual local-currency cost over time.

3. The invisible month

Annual subscriptions, domain renewals, software licenses, and insurance premiums create months that look inexplicably expensive. Because these appear once a year, they're rarely budgeted. A 12-month statement view makes them immediately obvious.

Why Standard Apps Miss This

Most budgeting apps work within one country via Open Banking. They can't see your Wise account AND your local bank simultaneously. They can't normalize across currencies to show real purchasing power trends.

The PDF approach — download statements from each service, analyze together — sidesteps these limitations. Your Wise statement, local bank statement, and PayPal history become a single unified view.

This is what FLOW does. Upload PDFs from all your financial accounts, get categorized spending across all of them with currency normalization.

Practical Fixes

1. Track FX rates on large invoices
   → Compare received rate vs. mid-market (xe.com)
   → Reveals which payment methods are actually expensive

2. Quarterly review (not monthly)
   → Annual charges only visible over longer windows

3. Download PDFs regularly
   → Most banks export 12 months at once
   → Don't wait until tax season

FLOW — PDF bank statement analyzer. First report free.

What payment processor gives you the most trouble for expense tracking? Genuinely curious what others have found.

Why Bank Statement PDFs Are Still a Mess in 2026 (And What We Did About It)

FLOW by Vestelon — Fri, 19 Jun 2026 08:56:39 +0000

Why Bank Statement PDFs Are Still a Mess in 2026 (And What We Did About It)

Every developer who has tried to parse bank statement PDFs eventually reaches the same conclusion: there is no standard.

I've been building FLOW, a bank statement analyzer that supports 8 languages and 50+ bank formats. Here's what I wish someone had told me at the start.

The PDF Standard Doesn't Help You

PDF is a display format, not a data format. The specification defines how pixels render on screen, not how tables should be structured semantically.

This means that what looks like a clean table in your PDF viewer might be stored internally as:

Floating text boxes positioned to look like a table
Actual table structures (rare, but exist)
A scanned image with no extractable text at all
A mix of all three across different pages

The same bank will often have 3-4 different PDF generations in circulation, because they've changed their banking software over the years. A customer downloading statements from 2019 and 2024 might get completely different file structures.

The Seven Failure Modes

After processing thousands of statements, these are the patterns that break naive extraction:

1. Merged cells that span transaction rows
Some banks merge the date cell across multiple transactions on the same day. Your row parser gives you a date for the first transaction and nothing for the next 4.

2. Footer rows that look like transactions
"Balance carried forward: 4,521.00" parses exactly like a debit transaction unless you explicitly filter it out.

3. Multi-page transactions
Long merchant descriptions sometimes wrap across page boundaries. The transaction starts on page 3 and the amount appears at the top of page 4.

4. Amount sign conventions
Some banks use positive/negative signs. Some use separate Debit/Credit columns. Some use red text for debits (invisible in text extraction). Some use parentheses for negative amounts. Some use D/C suffixes.

5. Thousand separators
1,234.56 (US/UK), 1.234,56 (German), 1 234,56 (French), 1'234.56 (Swiss). All valid. All different.

6. Date locale
"03/04/2024" means April 3rd or March 4th depending on the bank's country. You can't know without context.

7. Currency symbols vs codes
€, EUR, Eur, eur, E — all appear in the wild for the same currency, sometimes in the same document.

What Actually Works: A Defensive Pipeline

class StatementParser:
    def parse(self, pdf_path: str) -> list[Transaction]:
        # 1. Try text extraction first
        transactions = self._try_text_extraction(pdf_path)

        if self._confidence(transactions) < 0.8:
            # 2. Fall back to OCR if text quality is low
            transactions = self._try_ocr(pdf_path)

        # 3. Always validate output
        transactions = self._validate_and_clean(transactions)

        # 4. Flag low-confidence transactions rather than silently dropping
        return self._annotate_confidence(transactions)

    def _confidence(self, transactions) -> float:
        if not transactions:
            return 0.0
        # Check that amounts parse, dates are reasonable, no duplicates
        valid = [t for t in transactions if t.amount and t.date and t.date.year > 2000]
        return len(valid) / len(transactions)

The key insight: fail loudly, not silently. A transaction that couldn't be parsed should be flagged, not dropped. Users need to know when their data is incomplete.

The Maintenance Reality

New bank formats appear constantly. A bank redesigns their statement template, and suddenly your parser that worked perfectly for 3 years breaks on their new PDFs.

We run regression tests against a corpus of 500+ anonymized statement samples. Any code change that drops coverage on an existing bank format requires explicit sign-off before deployment.

This is unglamorous work, but it's what separates a parser that works in demos from one that works in production.

If you're building something that needs to parse financial PDFs, the open-source options (Camelot, Tabula, pdfplumber) are worth knowing — they're good starting points. The hard part is all the defensive logic around them.

Questions welcome. This is one of those domains where every new edge case is genuinely interesting.

FLOW — PDF bank statement analyzer, first report free.

Parsing Arabic PDF Bank Statements: What I Learned Building a Multi-Language Analyzer

FLOW by Vestelon — Fri, 19 Jun 2026 08:56:08 +0000

Parsing Arabic PDF Bank Statements: What I Learned Building a Multi-Language Analyzer

When I started building FLOW — a bank statement PDF analyzer — I assumed Arabic would be one of the harder languages to support. I was right, but not for the reasons I expected.

The Right-to-Left Problem Isn't the Hard Part

Most developers assume Arabic PDF parsing is hard because of right-to-left text direction. In practice, modern PDF libraries (pdfplumber, PyMuPDF) handle RTL text reasonably well. The text extraction itself usually works.

The real challenge is positional logic.

Column Detection Breaks

In a typical Western bank statement, you have columns roughly like this:

Date | Description | Debit | Credit | Balance

The date is on the left, balance on the right. Column detection heuristics work because the layout matches left-to-right reading order.

In an Arabic statement from ENBD or Mashreq, the layout is mirrored:

Balance | Credit | Debit | Description | Date

If you try to apply the same column extraction logic, you get the balance where you expect the date, and vice versa. Your "date" column suddenly contains AED amounts, and your amount parsing fails silently.

Fix: Detect document direction first. We check the dominant text alignment in the header rows. If the majority of header cells are right-aligned, we mirror our column index mapping before extraction.

Mixed-Direction Documents

UAE bank statements often contain both Arabic and English — Arabic for legal text and section headers, English for transaction descriptions and amounts. This creates mixed-direction paragraphs that confuse naive extraction.

# Simplified direction detection
def detect_dominant_direction(page_text_blocks):
    rtl_chars = sum(1 for c in page_text_blocks if '\u0600' <= c <= '\u06FF')
    ltr_chars = sum(1 for c in page_text_blocks if c.isascii() and c.isalpha())
    return 'rtl' if rtl_chars > ltr_chars else 'ltr'

Merchant Names: Arabic vs Transliterated

This was the real surprise. UAE bank statements frequently show merchant names in two formats depending on whether the merchant registered with the bank in Arabic or English:

Arabic text: actual Arabic script for the merchant name
Transliterated: Arabic merchant name written in Latin characters (e.g., "MAKTABAT AL JARIR" for a bookstore)
English: international merchant names in English

For categorization, you need to handle all three. We built a lookup table that maps known UAE merchants in all three formats to categories. It's manual work — there's no clean automated way to do this.

Date Format Variations

Arabic dates in UAE bank statements come in at least 4 formats:

DD/MM/YYYY (most common)
DD-MMM-YYYY with English month abbreviations
DD-MMM-YYYY with Arabic month names
Hijri calendar dates (rare, but present in some government-linked banks)

We process Hijri dates using the hijri-converter Python library. Miss this and you'll silently drop transactions or misparse dates by ~600 years.

What Actually Works

After months of edge cases, our pipeline for Arabic UAE statements:

Extract raw text with PyMuPDF (better RTL handling than pdfplumber for Arabic)
Detect dominant direction per page
Apply mirrored column mapping if RTL
Normalize merchant names through Arabic → Latin transliteration
Attempt date parsing in all 4 formats, cascade until one succeeds
Fall back to OCR (AWS Textract) if text extraction confidence is low

Banks we support well now: ENBD, ADCB, Mashreq, FAB, DIB, RAK Bank.

If you're parsing UAE bank statements and hitting edge cases, drop a comment — happy to share more specifics.

FLOW is a PDF bank statement analyzer supporting 8 languages including Arabic. First analysis free.

I analyzed 500+ bank statements. Here's what I found.

FLOW by Vestelon — Fri, 19 Jun 2026 07:32:42 +0000

I Analyzed 500+ Bank Statements. Here's What I Found.

Over the past few months, while building FLOW — a PDF bank statement analyzer — we processed hundreds of anonymized bank statements from beta users across Europe, the Middle East, and Southeast Asia.

The patterns were surprising. Here's what the data showed:

Finding #1: The Average Person Has 3 Forgotten Subscriptions

Not "maybe has." Has. Reliably, across different income levels and countries.

The most common culprits:

Software tools from a job they left (Notion, Figma, Slack paid plans)
Streaming services with annual billing they forgot about
Free trials that converted to paid (average: 2.1 per person)
Insurance for devices they no longer own

Average value: €94-€158/month depending on income level.

Finding #2: High-Income Users Leak More

Counter-intuitive, but: the higher the income, the more money is "leaking."

Reason: lower financial stress → less attention to individual line items → more small charges slip through unnoticed.

People earning €8k+/month often have 5-8 forgotten subscriptions vs 1-2 for people earning €2k/month.

Finding #3: Expats Have 2-3x More Complexity

Users with accounts in multiple countries (common for expats in UAE, UK, Singapore, Germany) had significantly more:

Duplicate services active in two countries
Currency conversion fees adding up to €50-200/month
Old direct debits from a previous country of residence still running

This is the problem FLOW was originally built to solve — seeing across all your bank PDFs in one place.

Finding #4: The "Harajuku Moment" for Finance

Most people don't seek out financial tools until a trigger event:

Preparing for mortgage application
First month with a big salary decrease or job loss
Seeing a surprisingly high statement total
Moving countries and having to "reset" finances

Building for this trigger matters more than building for "everyone who has money."

How FLOW Works

Upload your bank statement PDFs → it extracts every transaction using OCR → categorizes them → finds patterns and anomalies.

Supports 8 languages and 50+ bank formats
Works with ENBD, Mashreq, ADCB (UAE), Barclays, HSBC, NatWest (UK), Deutsche Bank, Sparkasse (DE), SBI (IN), and more
First analysis free, no card required
No bank login or Open Banking connection needed

If you're building something in fintech or personal finance, happy to share more about what we've learned from parsing international bank PDF formats (it's... not fun, but doable).

Data is anonymized and aggregated from opt-in beta users. Individual values vary significantly by country and income.

How expats in Dubai (and the Gulf) are losing money without knowing it

FLOW by Vestelon — Fri, 19 Jun 2026 07:32:14 +0000

How Expats in Dubai Are Losing Money Without Knowing It

If you're an expat living in Dubai (or anywhere in the Gulf), you probably have bank accounts in at least two countries. Maybe three.

UAE account for your salary. A UK, German, or Indian account back home. Maybe a third somewhere for savings or family transfers.

And every month, money slips through the cracks.

The Problem No One Talks About

When you live across multiple financial systems, your expenses become invisible. You can't see the full picture from any single banking app.

Forgotten subscriptions still charging your UK card
Currency conversion fees eating 2-3% on every transfer
Duplicate services in two countries (Netflix UAE + Netflix UK somehow active)
Insurance you cancelled that's still being charged

Most expats I've talked to are shocked when they actually analyze all their statements together.

What I Built

FLOW is a PDF bank statement analyzer. You upload your bank PDFs — from any country, any language — and it categorizes every transaction, finds patterns, and shows you exactly what you're spending and where.

It supports 8 languages: English, Arabic, German, French, Spanish, Slovak, Czech, and Hungarian. Useful if your UAE bank statement is in Arabic and your home country one is in another language.

No bank login required. You just upload the PDF. It works with ENBD, ADCB, Mashreq, HSBC UAE, Barclays UK, Deutsche Bank, SBI, and most other banks.

The Numbers That Surprised Users

When we ran our first beta with expats:

Average €137/month in forgotten or duplicate subscriptions found
Average time to find: 8 minutes to upload and analyze
Most common finding: subscription services active in home country still running

Who It's For

FLOW works well for:

Dubai/UAE expats managing accounts in 2+ countries
Finance professionals who review client bank data
Small business owners wanting clear expense visibility
Anyone getting ready for a mortgage application who needs to understand their own spending

Try It Free

First analysis is free, no card required: vestelonflow.com

If you're an expat with PDF bank statements from multiple countries, I'd genuinely love to hear if it helps — and what it misses. Still adding banks and improving categorization.

Built with Python, AWS Textract, and a lot of edge cases from international bank formats.

How I built a PDF bank statement analyzer in 8 languages (and what I learned)

FLOW by Vestelon — Thu, 18 Jun 2026 20:16:07 +0000

I spent months building FLOW (vestelonflow.com) — a tool that analyzes bank statement PDFs and finds forgotten subscriptions, hidden fees, and recurring charges.

Here's what I learned building it in 8 languages.

The Problem

Most personal finance apps require you to connect your bank account. For many people (especially in Europe), that's a dealbreaker. GDPR concerns, privacy fears, and simply not trusting third-party apps with banking credentials.

My insight: the data people need is already in their PDF bank statements. Every bank generates them. Most people never look past the total.

The Tech Stack

The core flow:

User uploads PDF bank statement
PDF text extraction (pdfplumber + fallback OCR)
Transaction parsing — this is the hard part
LLM categorization pipeline
Subscription detection (recurring charges with same merchant)
Report generation

The trickiest part was transaction parsing. Every bank formats their PDF differently. German banks look nothing like Slovak banks. We ended up building bank-specific parsers for the most common formats and a fallback generic parser.

The 8-Language Challenge

Supporting Slovak, Czech, German, French, Spanish, Polish, Arabic, and Chinese wasn't just about translating the UI. The financial terminology varies significantly:

"Permanent order" in English = "Trvalý príkaz" in Slovak = "Dauerauftrag" in German
Subscription detection keywords differ by region
Date/amount formats are locale-specific

We ended up with language-specific merchant dictionaries for common subscription services in each market.

What Actually Matters

The biggest lesson: people don't want a budgeting dashboard. They want a specific, actionable number.

"You're spending €137/month on forgotten subscriptions" converts. "Your spending breakdown by category" does not.

The product is live at vestelonflow.com — first report is free, no card required, no bank connection needed.

Happy to answer questions about the PDF parsing approach, the LLM pipeline, or the localization challenges.