How processing works

This chapter explains what happens to a document between the moment it arrives (see Sending documents in) and the moment it's ready for you to look at in your review queue. You don't need to understand any of this to use DocReadi — but it helps to know why a document ends up where it does, and what determines whether it needs your attention.

Every document goes through the same five stages, in order:

1. Classify

DocReadi first works out what kind of document it's looking at — an AP invoice, a sales invoice, a credit note, a purchase order, a delivery note, a receipt, a statement of account, or one of your own custom types (see Custom templates). Where possible this is a cheap, near-instant rule-based check; only genuinely ambiguous documents need a model call. If you've already told DocReadi what a document is — by pinning its type on upload, or because it arrived through a source with a fixed default type — this step is skipped and your choice is respected.

One distinction is worth knowing about, because it decides whether a document becomes a liability in your records: a statement of account is recognised as a statement, not as an invoice, so the invoices its rows refer to aren't recorded a second time. An account-style bill titled "Tax Invoice" — a municipal, telco or utility account showing a previous balance — stays an AP invoice, because it is one. See Statements of account.

2. Parse

Next, DocReadi reads the text out of the file. Most PDFs contain real, selectable text and are parsed directly — fast, and no external service involved. Scanned documents and photos — where there's no underlying text layer, just an image — go through OCR instead, which takes a little longer. A scanned PDF always goes through OCR, even if you chose the text parser for it at upload or when reprocessing: the text parser would find nothing to read. If a "native" PDF turns out to be a scanned image saved with a text layer that doesn't actually match the page (this happens more than you'd expect), DocReadi detects that and re-routes it through OCR automatically. Either way, the output is the same: clean text and tables ready for extraction. If one of your document types consistently comes out garbled on the standard path, a workspace admin can route that type through OCR for every document going forward — see OCR routing for specific document types in Workspace administration.

3. Extract

A model reads the parsed document and fills in a structured record: invoice number, dates, parties, line items, totals, tax, and everything else that document type expects. This isn't free-form guessing — DocReadi asks for a strict, typed shape, so the fields you see in review are the fields that came back. Anything the model can't find, or isn't confident about, is left blank and flagged rather than guessed.

4. Validate

Before anything is written to your records, DocReadi runs a set of cross-field checks specific to the document type — do the line items add up to the subtotal, does the subtotal plus tax equal the total, is the tax rate plausible, does the due date fall after the invoice date, and similar arithmetic and consistency checks. Any validation failure sends the document to your review queue, regardless of how confident the extraction otherwise was. A document with a math error is never auto-approved.

Statements are held to a different standard: they carry no line items, subtotal or tax total, so none of the invoice arithmetic applies to them. What matters on a statement is its ledger — whether it walks from the opening balance to the closing balance, and whether each row agrees with the running balance printed beside it. Those checks run on every statement and are listed under Statement checks. A statement whose ledger doesn't balance goes to review, exactly as an invoice with a math error does.

5. Counterparty match

DocReadi tries to match the vendor or customer named on the document against your counterparty registry (see Master data). This is a deterministic process — DocReadi never guesses silently. It checks, in order, for an exact VAT number match, then a known alias, then a strong name-similarity match, then a keyword match, stopping at the first confident hit. If nothing matches, a new candidate counterparty is created; once the same name has appeared consistently across a few documents, it's confirmed automatically. A registered VAT number belonging to a different counterparty blocks a name-based match from going through — DocReadi won't let two different companies with a similar name collide just because they share words like "Financial Services".

A document whose counterparty isn't in your registry yet doesn't go to review for that reason alone. Comparing against a registry you haven't filled in yet would flag everything, so the check starts switched off and the candidate is simply queued for you to confirm. Once the suppliers and customers you care about are confirmed, turn on Flag documents from unknown counterparties under Settings → Features and anything unrecognised will land in review from then on.

E-invoice XML

An e-invoice XML sent as an .xml file skips most of that. The file already carries the data in a structured form, so DocReadi reads it directly instead of parsing pages and asking a model what they say.

• No model runs, and no credits are charged. The document number, the dates, both parties with their VAT numbers and addresses, the line items, subtotal, tax, total, currency and amount payable are read mechanically out of the file, so the values recorded are exactly the ones the sender wrote. Where the file carries them, DocReadi also reads the buyer's own reference, a contract reference, a delivery-note reference, the printed payment terms and invoice note, the delivery date, the billing period, the payee (when payment goes to a party other than the issuer), and each party's country, trading name, and registration number. A credit note also keeps its reference back to the original invoice, including that invoice's own date.
• The document type comes from the file, not a classifier. Invoice versus credit note is stated in the XML itself. Whether it's an AP or a sales document is decided by matching the seller and the buyer against your entity registry — the party that matches one of your own registered entities sets the direction. If neither party matches confidently, the document is filed as a generic invoice rather than a guessed direction, so registering your own entities is what makes this land correctly.
• Validation and counterparty matching still run — the same cross-field checks and the same counterparty cascade described above.
• It always goes to your review queue. An e-invoice XML is never auto-approved, whatever thresholds you have set.

A file that isn't one of the two supported e-invoice formats, or one that is but carries no document number or party name, fails with an explanation rather than being handed to a model as if it were prose — see An e-invoice XML DocReadi couldn't read.

The confidence gate — what determines review vs. auto-approve

Once extraction, validation, and matching are done, DocReadi decides whether a document is ready to write straight into your records or needs a human to look at it first.

The default is that every document goes to your review queue. Auto-approve is off until you turn it on. To let documents of a given type skip review, go to Settings → Review and approval and:

1. Tick the acknowledgement that auto-approve is an automated decision under applicable data-protection law, and that you're authorised to turn it on.
2. Set a confidence threshold for that document type.

Once both are in place, a document of that type auto-approves only if the confidence of its weakest field meets the threshold and it passed every validation check. Anything that falls short — a low-confidence field, a validation error, or a document type with no threshold configured — lands in your review queue instead. Nothing is silently dropped or held up without explanation; it's simply waiting for a decision. See Reviewing documents for what happens once a document is there, including bulk approve/reject actions and the reasons the review queue shows for why a specific document is in it.

What confidence means

During extraction, the model reports how sure it is of each field it read, as well as of the extraction as a whole. DocReadi judges a document by its weakest link: the lowest per-field confidence among the fields the document actually carries. A field the document simply doesn't have — an empty PO reference, say — doesn't count, because an absent field isn't a doubtful one. The result is never higher than the overall confidence, and on a document with no per-field figures it is the overall confidence.

This one number is what you see as Lowest field confidence in the document view and in the Lowest field column of your document list, and it's the number your auto-approve and Approve clean thresholds are compared against. A document that reads cleanly except for one smudged total therefore goes to review, even though the extraction as a whole looked confident.

What consumes credits

DocReadi charges one credit per page for a document's first, successful extraction. Re-extracting a document you've already processed (for example after fixing a source field and asking DocReadi to try again) is free the first time; a second re-extract on the same document is charged again. If your workspace runs out of credits mid-pipeline, a document is parked rather than failed — it resumes and is charged normally once you top up. An e-invoice XML costs nothing, because nothing is extracted by a model; your workspace still needs credits available before processing starts, though. See Billing and credits for plans, top-ups, and usage reporting.

A trial workspace whose admin hasn't verified their email yet parks documents the same way, before classification even starts — see Verifying your email.

Next steps

• Reviewing documents — the review queue itself, editing fields, and auto-approve thresholds in detail.
• Master data — the entity and counterparty registries that power direction and matching.
• Troubleshooting — common validation failures explained in plain language, and what to do about a stuck document.

Looking for the developer/API reference? See /api/docs-guide. Can't find an answer? Email [email protected].