The pipeline, stage by stage
Ingestion validates the file and tells you plainly when something is empty, corrupted, locked or unsupported. Classification then decides what the document is, statement, receipt, invoice, bill, payout report, expense report or spreadsheet, and reports how sure it is.
Extraction reads the content: the embedded text layer for digital PDFs, image cleanup and OCR for scans and photos, direct parsing for CSV and spreadsheets. Structure detection locates the table and maps the columns.
Validation checks the result against itself. Balances must chain. Totals must equal the sum of their parts. Dates must be real. Anything that fails, or that was read with low confidence, is marked for review.
Categorization applies your rules in a fixed order of precedence. Reconciliation removes duplicates and handles statements whose periods overlap. Insights and reporting run on top of data that has already survived all of that.
Why the stages are separate
A single model asked to go from a scanned page straight to a categorized ledger will produce something that looks right and cannot be audited. When a figure is wrong, there is no stage to point at.
Separating the stages means each one can be tested on its own, each one can report its own confidence, and a failure has a location. It also means the expensive stages only run when the cheap ones could not do the job.
Cost and speed follow from the same design
Native text extraction is free and instant compared with OCR, so it is always tried first. OCR runs only where there is no text. Heavier processing runs only where OCR confidence is poor. Extraction results are cached so re-running a document does not repeat work already done.
Large documents process in the background with visible progress, so you can keep using the rest of the application while a long statement finishes.
What stays human
The review screen shows the original document beside the extracted rows and highlights the source of the selected row where that is technically possible. You can edit any field, delete a wrong row, add a missing one and mark a row reviewed.
Corrections are recorded with the previous value, the new value, who changed it and when. When the same correction repeats, Karchu offers to turn it into a plain rule instead of quietly learning something you cannot see.
Frequently asked questions
What is document AI?
It is the use of machine reading to turn documents into structured data: classifying what a document is, extracting its fields, validating them and connecting them to other records. For financial documents the useful version is deterministic wherever it can be, with the model used only where rules genuinely cannot decide.
Where does Karchu use a model, and where does it not?
Reading a text based PDF, detecting table structure, checking balance arithmetic, detecting duplicates and applying your category rules are all deterministic. A model is used for OCR on scanned pages, for suggesting a category when no rule matches, and for phrasing an answer around figures that were already computed.
Can the AI invent a transaction?
No. Rows come from the document, not from the model. Values the reader cannot resolve stay empty and are routed to review, and a model is never allowed to supply a number that was not extracted.
Does an AI suggestion override my rules?
Never. Your explicit rules come first, then rules learned from your own repeated corrections, then deterministic merchant rules, then built in keywords, and only then an AI suggestion for rows that are still uncategorized. Human review sits above all of it.
Is my data used to train a model?
No. Karchu does not train models on your documents. Learning happens through explicit rules you can read, edit and delete.
How accurate is it?
Karchu does not claim a fixed accuracy percentage. Instead, extraction confidence, reconciliation results and manual correction rates are measured, and low confidence output is sent to review. That is a weaker headline and a more useful guarantee.