Invoice vs receipt vs credit note vs bank statement
untxt. identifies what each document is by reading it, so an invoice, a receipt, a credit note, and a bank statement are recognized as different things and handled differently, even when they arrive jumbled in one upload. You do not label them.
Why the type matters before the data
Telling an invoice from a receipt takes you a second. Doing it across a few hundred jumbled documents every month is the slow part, and the type has to be right before any field is pulled. untxt. makes that call on every document as it reads it, so a mixed upload comes back already separated by type instead of a pile you re-triage by hand.
How untxt. identifies the type
untxt. reads each document and recognizes the type from its content and structure, the way you would: an invoice carries terms and an amount due, a receipt confirms a payment, a credit note carries a reversal, a statement lists a run of transactions over a period. It decides per document, so a single mixed upload comes back with every item correctly typed.
The type decides what gets extracted
Because it settles the type first, untxt. pulls the fields that matter for the documents it extracts — invoices, receipts, credit notes, bills — instead of forcing every document through one template. A bank statement is recognized as a statement and set aside rather than crammed into invoice fields, so you are not handed a wrong-shaped record, and you are not the one deciding which fields applied to which document.
When a document sits on the line
Some documents genuinely straddle types: a paid invoice that doubles as a receipt, for instance. untxt. makes its best read, attaches a confidence score, and shows the original beside the data in the review queue, so you can correct the type in one click when it matters.