Bank statement won't parse
You uploaded a bank statement and the Bank reconciliations page shows it stuck on PENDING for too long, or it flipped to FAILED with no transactions extracted, or it parsed but no transactions appear on the run. This is almost always one of five things.
1. The PDF is image-only (a scanned statement)
The parser needs a text layer in the PDF. A statement scanned to PDF from a paper printout — or downloaded from an older banking portal that exports as a flattened image — has no text the parser can read. The statement will land in FAILED with a parse error like "no transactions extracted".
Check: Open the original PDF. Try selecting text inside the transaction table with your cursor — if nothing highlights, the PDF is image-only.
Fix: Re-export the statement from the bank's online banking portal as a text PDF (the default download format on every Singapore bank's online banking) or, better, as CSV / XLSX. CSV uploads parse synchronously and skip OCR entirely, which is faster and more reliable than the PDF path.
INFO
PDF-via-OCR conversion for scanned statements is on the roadmap but not currently supported. Until it ships, scanned statements need to be re-sourced.
2. The PDF has a layout the parser doesn't recognise
Some foreign banks and some older Singapore-bank statement templates use a multi-column or fragmented-row layout the parser can't reliably split into transaction rows. The statement parses partially or flips to FAILED with "could not identify transaction columns".
Check: Open the bank statement detail page → look at Parse status and the Reason field. Multi-column layouts typically surface as either zero transactions extracted or wildly wrong amounts.
Fix: Download the same period as CSV from the bank's online banking portal and upload that instead. Every Singapore bank's online banking offers CSV export; the parser handles CSV directly without going through OCR.
3. Currency mismatch — this is a flag, not a parse failure
This is the most common false alarm. A USD statement uploaded for a client whose base currency is SGD will parse successfully — every transaction extracts cleanly — but each transaction is tagged with a NON_BASE_CURRENCY flag, and downstream matching against SGD journal entries doesn't fire. Staff sometimes read the flag on the run detail page and assume the parse failed.
Check: Open the bank statement detail page. Parse status is the truth — look there first.
| Parse status | What it means |
|---|---|
PENDING | Parser hasn't run yet |
PARSED | Parser succeeded; transactions are extracted (any flags on individual transactions are separate from parse success) |
FAILED | Parser actually errored |
If parse status is PARSED, the statement is fine. The NON_BASE_CURRENCY flag belongs to a different conversation — see Reconciliation matcher missed an obvious match cause 4.
Fix: Nothing to fix at the parse level. If you genuinely intended to reconcile a foreign-currency account, that needs a separate journal entry stream in the matching base currency.
4. The PDF is empty or only the cover page
A common upload mistake: the client (or a colleague) uploaded just the statement summary page without the transaction listing pages. The parser bails because there are no transaction rows to extract — FAILED with reason "no transactions found".
Check: Open the original PDF. Count pages — does it include the per-transaction listing, or is it just an opening/closing balance summary?
Fix: Re-upload with the full statement, including all transaction pages. If the source is a multi-file split (some banks split across multiple PDFs), upload them as separate statements covering their respective date ranges, then run reconciliation across all of them.
5. Date format ambiguity (DD/MM vs MM/DD)
If the statement uses an ambiguous date format like 04/05/2026 and the parser guessed wrong, transactions extract but with the wrong dates — leading to no matches against journal entries and an uploader who concludes the statement "didn't parse properly". Singapore-bank statements are reliably DD/MM, but some foreign-bank statements and some manually exported CSVs come through MM/DD.
Check: Open the bank statement detail page → Transactions tab. Spot-check a few transactions: do the Transaction date values match the dates printed on the original PDF?
Fix:
- For a recurring bank account, set the bank's date convention on the bank profile so subsequent uploads parse consistently.
- For a one-off, easiest is to re-export the statement as CSV from online banking — CSV exports use ISO format (
YYYY-MM-DD), which is unambiguous.
Still not parsing?
If the statement file is text-PDF, the layout looks ordinary, the date range is right, and parse status is still FAILED:
- Open the bank statement detail page → Audit tab → look for the
bookkeeping.bank_statement.parse_failedevent. - The event payload carries the parser's exact
reason. Common ones: "opening/closing balance mismatch" (the arithmetic over the extracted transactions doesn't reconcile to the printed opening + closing — usually means a transaction was missed or duplicated by the parser), "period_end before period_start" (date range entered backwards on upload), "no transactions found" (covered above).
If the reason is the balance arithmetic mismatch, the statement was almost-parsed — staff sometimes accept this as "close enough" but it can hide a real bug. Re-upload as CSV; if the same mismatch recurs, escalate via the on-call channel.