Extraction and upload issues

Symptom: the file upload shows an error or spins indefinitely without completing.

Cause and fix for password-protected PDFs: remove the password before uploading. Most PDF viewers have a "Save as" option that removes protection.

Cause and fix for unsupported formats: verify the file extension is one of PDF, CSV, XLS, XLSX, PNG, JPG, JPEG, or WEBP. If not, convert to a supported format.

Cause and fix for very large files: files over the size limit will fail. For large bank statement PDFs, try splitting into smaller monthly files. For CSV exports, split into smaller date ranges.

Symptom: amounts in Review look correct for some rows but wrong for others — for example, an expense shows €16.50 but the statement shows €16,50 (European decimal comma format).

Cause: Standard mode parsing of amounts uses context-aware decimal detection, but some unusual statement formats may be ambiguous.

Fix: correct amounts manually in Review by clicking the row and updating the amount field. If many rows have the same systematic error, this is best raised as a support issue with an example file.

Symptom: after upload, a large portion of rows show the "unsure" expense category or "other income" income category.

Cause: "unsure" is the fallback when no confident category match is found. This is expected for: uncommon or very local merchants not in the dictionary; transactions in a language not yet covered; or blurry/low-quality document extractions.

Fix options: (1) Reclassify individually in Review — fastest for small numbers. (2) Use bulk edit to fix many rows from the same merchant at once. (3) If the document consistently produces high fallback rates, retry with AI mode for better coverage of unusual merchants. (4) For recurring issues with a specific bank or country, the underlying merchant dictionary may need expansion — this is a known improvement area.

Symptom: you uploaded a statement with 80 transactions but only 60 appear in Review.

Cause: the parser skips rows it cannot parse into valid date + amount + description combinations. This is common when: (1) The statement has a total/balance row that does not represent a transaction. (2) The document has multi-page headers or summaries that look like transactions. (3) OCR quality was poor on some pages.

Fix: compare the upload completion summary (which shows extracted count) against the expected count from your source document. For significant discrepancies, retry the upload with AI mode to see if it captures more rows. Balance rows and header rows should be expected to be excluded.

Symptom: the same transaction appears twice (or more) in Review.

Cause: the same file was uploaded more than once, or overlapping date ranges in separate files were uploaded.

Fix: use the source file filter in Review to find all rows from the duplicate upload session. Select all rows from the duplicate batch and delete them. The original batch rows remain.

Symptom: business transactions appear in the personal view or vice versa.

Cause: the entity type toggle was set to the wrong value when the upload was performed.

Fix: switch to the entity type that incorrectly received the data in Review. Use the source file filter to find all rows from the incorrect upload. Delete them. Switch to the correct entity type and re-upload the original file.