Pipeline
upload
-> validate (type, size, pages, readability)
-> classify (statement, card statement, receipt, invoice, bill, expense report)
-> extract text (PDF text layer first)
-> OCR fallback (only when text is missing or unusable)
-> parse transactions
-> validate transactions
-> categorize
-> reconcile
-> complete or requires_reviewKarchu accepts a financial document, validates it, works out what kind of document it is, and extracts text before any parsing happens.
What this stage does
- Validate the file type, size and page count before processing and return a specific error when a file cannot be read
- Classify the document as a bank statement, credit card statement, receipt, invoice, bill, expense report or unknown, with a confidence score
- Ask the user to confirm the document type when classification confidence is below 0.7
- Read the PDF text layer first and only fall back to OCR when the text layer is missing or unusable
- Preprocess photographed and scanned images: deskew, orientation correction, grayscale and contrast normalisation
- Keep the uploaded original alongside the processed representation
- Process every page of a multi page document, up to 300 pages
- Record the processing state of each document: uploaded, validating, validated, extracting, ocr_processing, classifying, parsing, validating_transactions, requires_review, completed, failed
Accepted files
- PDF (digital text layer)
- PDF (scanned, image only)
- PDF (multi page, up to 300 pages)
- PNG
- JPG and JPEG
- HEIC where the browser can decode it
- CSV
- XLS and XLSX
- ODS
- TXT
Limits
- Password protected PDFs are rejected with an explanatory error rather than guessed at
- A photograph too blurred for OCR returns a low confidence result flagged for review, not invented text
- HEIC support depends on the browser being able to decode the image
Processing states
Every document carries a state you can see in the app: uploaded, validating, validated, extracting, ocr_processing, classifying, parsing, validating_transactions, requires_review, completed, failed. Each state change is recorded with a timestamp, so an administrator can tell exactly where a document stopped and why.
Retries
A failed document can be reprocessed from the stored original. Attempt count, error and stage are tracked, and there is a hard limit of five server side attempts so a broken file cannot loop.