Convert Airwallex Statements

Airwallex isn't a traditional bank. It's a global payments platform popular with businesses that operate across borders - e-commerce sellers, SaaS companies, marketplaces. If you've ever needed to hold, send, or receive money in multiple currencies without opening accounts at five different banks, you've probably heard of them.

Their statements reflect this modern approach. Clean design, logical layout, none of the mainframe-era baggage you see with the big banks. But even well-designed statements have their parsing quirks.

A Clean Account Summary

The statement opens with something refreshingly simple:

"USD Account Summary." Starting balance on Jan 01 2023. Total deposits and other additions. Total payouts and other subtractions. Ending balance on Sep 21 2023. That's it. No marketing copy. No fee schedules. No legal notices. Just the numbers you need.

But notice that date range - January to September. That's nine months in a single statement. Traditional banks issue monthly statements. Airwallex lets you generate statements for any period. A parser built for monthly statements might not expect hundreds or thousands of transactions spanning the better part of a year.

The Transaction Table

Below the summary, the transaction table begins:

Date. Details. Credit. Debit. Balance. Five columns, clearly labeled, with separate Credit and Debit columns. A running balance on every row. A "Starting balance" row showing 0.00 USD. This is close to ideal for parsing.

Compare this to Chase, which splits credits and debits into entirely separate sections. Or Bank of America, which uses a single ambiguous "Amount" column. Airwallex gives you everything in one chronological table with explicit columns. A parser's dream.

Almost. Look at that balance: "0.00 USD." The currency code is appended after the amount, not as a $ symbol before it. Every amount in the statement uses this format. Most number parsers expect "$1,280.00" or just "1,280.00" - not "1,280.00 USD." That trailing currency code needs to be stripped before you can treat the value as a number.

And the Starting balance row itself - no date, no credit or debit amount. It's metadata, not a transaction. Same pattern as Barclays and Santander. Include it in your export and it'll throw off your column totals.

The Ending Balance

"Ending balance" - 4,892.05 USD. Same story as the starting balance: a summary row that bookends the transaction list. Not a transaction. Needs to be handled separately.

The good news is you can use these two values to verify your extraction. If the starting balance plus all credits minus all debits equals the ending balance, you've captured everything correctly. Built-in validation.

Multi-Currency Statements

Here's the big one. The summary says "USD Account Summary" - because Airwallex accounts can hold multiple currencies. A business might have USD, EUR, GBP, and AUD balances all in the same account. Each currency gets its own section in the statement.

That means a single PDF could contain multiple transaction tables, each with different currencies. Your parser can't just find "the" table - it needs to find all of them, tag each transaction with its currency, and keep them organized. Mix up the sections and you'll have USD transactions labeled as EUR, or transactions from different currencies merged into a single jumbled list.

Modern Design, Real Quirks

Airwallex is proof that even well-designed, modern statements aren't automatically easy to parse. The layout is clean. The columns are clear. The data is well-structured. But the currency suffixes, the variable-length statement periods, the multi-currency sections, and the balance rows all need specific handling.

The difference is that Airwallex's quirks are smaller and fewer than what you'd find on a Chase or Bank of America statement. It's one of the easier formats to get right - as long as your parser knows to expect it.