DocReadi

Reviewing documents

Reviewing documents

Every document that doesn't clear your auto-approve threshold — which, by default, is every document — lands in your review queue. This is where you check the extracted fields against the source, fix anything that's wrong, and decide whether a document is approved, rejected, or sent back for another pass. Nothing is written to your typed records until a document is approved, whether by your hand or automatically. The document.approved webhook and On-approval export rules fire only then. Every other export rule sends what its Send choice says — Approved documents only (the choice a new rule starts with), Any status, or only the statuses you tick — and reports and API reads can include documents still in review. Access to the review queue requires the Reviewer role or higher (see Workspace administration for roles); the settings described later in this chapter require Admin.

The review queue

Open Review from the main navigation to see the queue. It's split into four tabs:

Each row in the queue shows the source filename, document type, extracted counterparty and total, and a confidence badge. Selecting a row opens it in the pane alongside the queue, so you can page through documents (P / N, or the on-screen arrows) without losing your place.

If you've narrowed a tab — by document type, to only your own decisions, or to documents still needing a GL account — and nothing matches, the queue says Nothing matches these filters rather than implying the tab itself is empty, with a Clear filters link back to the unfiltered view.

Why this needs review

Every pending document carries a short note explaining, in plain language, why it stopped short of auto-approving:

If a document instead failed a validation check, you'll see the detailed list of checks under Why this is in review, with a Re-validate button that runs the checks again against the current values (no AI) — useful after you've fixed the underlying field or confirmed a counterparty.

Every warning card is amber. A small label above the title tells you what kind it is: Needs your decision (only a person can settle it, such as a new bank account or a file that holds several invoices) or Check against the document (figures or dates that may have been misread). A card for a file that holds more than one invoice has an Open the split editor button.

Currency gets the same treatment. When a document shows only a shared symbol such as $ and DocReadi worked it out from the currencies your workspace works in (or took a shared name such as "pounds" at its usual meaning because the seller's country wasn't clear), the Currency field is marked as uncertain so you can confirm it. The same applies when a bare $ was read as another country's dollar from the seller's country (Australian dollars for an Australian seller, say): check it was not billed in US dollars. Any other currency settled by the seller's country alone is not marked. A currency the document never shows — no code, symbol or name — is kept only when the document clearly belongs to one country that uses it (the seller's address or VAT number, an international phone number, or a web or e-mail address such as one ending in .co.za); otherwise it is left empty rather than guessed. A document in a currency your workspace has switched off is not converted to another currency; it is held with Currency isn't one your workspace works in. See Currencies you work in and the currency entries in Troubleshooting.

The document view

Selecting a document opens it side by side with the source file: the scan or PDF on one side, the extracted fields on the other. Fields the extraction was unsure about are highlighted; fields that failed a validation check are highlighted more strongly, with the specific check named. These marks, and the per-field confidence percentages below, appear on every built-in document type — invoices, credit notes, credit requests, orders, delivery notes, receipts and statements; fields from a custom template carry no marks. For a check you can turn off, an Admin or higher also sees an Adjust this check in Settings → Features link on the warning — see Common validation failures for what each check means and which ones can't be turned off. The same pane is reachable either from the review queue or by opening a document directly from your document list. On a narrow screen the two panes stack instead of sitting side by side, and the source document stays pinned in view while you scroll the fields below it.

At the top of the extracted fields, Lowest field confidence shows the confidence of the weakest field in the extraction — the lowest per-field confidence among the fields the document actually carries (an empty field doesn't count), and never higher than the overall confidence for the whole extraction. Next to each field's label, a small percentage shows that field's own confidence, so you can see which field is pulling the number down. Green means confident, amber means worth a look, red means check it against the source. This is the number your auto-approve and Approve clean thresholds are compared against, and your document list shows the same figure in its Lowest field column. Every confidence percentage is rounded down, so a document shown at 89% really is below a 90% threshold. On a custom template whose model didn't report usable confidences, the headline reads "n/a" — the fields were still extracted.

The read-only view shows every field that Edit Fields offers for the document type, as long as the field has a value or has been flagged — a validation check names it, or the extraction was unsure of it. Empty fields that nothing flagged are left out, so a sparse document stays short. The usual panels for the document type come first. Extra amounts from the totals — Discount, Charges (freight, surcharges), Gratuity / Tip, Deposit Already Paid, Rounding, Amount Payable and the like — appear as extra rows of the Financials table, next to the totals they change. Any other field appears below the panels under More fields, grouped under the same headings Edit Fields uses. A field a validation check names is tinted red and a field the extraction was unsure of is tinted yellow, the same marks Edit Fields carries, so a figure a check complains about is never hidden from the read-only view. Bank account numbers and IBANs shown here follow the same Reviewer mask as the rest of the document view (see the Bank & payment group under Editing fields). A custom template document shows its own template fields instead.

An e-invoice XML has no page image to show, so the source side instead renders the file as a readable invoice — a header strip (number, dates, type, currency), seller and buyer blocks, the line items, the tax breakdown and totals, and, where the file carries them, payment details and references. Click Show source to switch to the file's own raw XML text when you need to see it verbatim (the button then reads Show invoice, to switch back), and Download source saves the original file. Below the rendered invoice, a collapsed Full document drawer lists every element in the file with a humanised label, for the rare case the summary view is missing something you need. On the rare document whose XML this pane can't render as an invoice, it shows a one-line notice and falls back straight to the raw source instead. This rendering is for reading only — it doesn't change what was extracted, and the extracted-fields side behaves exactly as it does for a PDF, including editing and the side-by-side comparison.

Back to list (or the Esc / b shortcut) returns you to your document list exactly as you left it — the same filters and page, not the unfiltered list from the top. Opening the document from the review queue instead returns you to the review queue.

Single-key shortcuts (such as A, R, E and b) don't act while a dialog is open, so a key pressed with the reject dialog showing can't approve the document underneath. In the review pane and the fast review strip, Esc still closes the open dialog.

Once the counterparty resolver has run on the document, the view also states inline how the party on it was matched: "Counterparty matched by VAT number" (an exact match on a registered VAT number), "a saved name" (an exact match on a known alias), "its registered name" (an unambiguous exact match on the counterparty's own name, even when its VAT number differs from what's on the document), "name similarity" (a fuzzy match, shown with its confidence percentage), or "a keyword" (a substring match on one of the counterparty's keywords). If nothing matched confidently, it instead reads "Counterparty not matched yet — we'll suggest it as a candidate to confirm" — see Master data for what happens to that candidate next. This appears wherever you open the document — the review pane or the plain document view — so the same explanation is available either way.

If your workspace has GL determination switched on (see GL accounts, tax codes, and posting defaults), a document of a GL-posting type also carries a GL pill in the pane header — "GL: unassigned" or "GL: N/M lines" — showing how many of its lines have a resolved account. The pill disappears once every line is resolved.

A document carrying a Sample pill is the onboarding demo invoice — see Trying a sample invoice. It reviews and approves exactly like a real document, but never writes a typed record and never reaches a report, export, delivery, or webhook.

Zooming the PDF

A PDF opens fitted to its panel, both in the document view and in the review queue pane. To look closer, use the − and + buttons in the PDF toolbar, next to the page arrows; the percentage between them shows the current zoom, and clicking it returns the page to its fitted size. Zoom runs from 50% to 400%.

With the pointer over the PDF you can also hold Ctrl (Cmd on a Mac) and turn the mouse wheel, or pinch on a trackpad. Only the PDF zooms; the rest of the page stays as it is, and the spot under the pointer stays under the pointer. Once you've clicked on the PDF, Ctrl / Cmd with +, − and 0 do the same from the keyboard (0 returns to the fitted size). Over the rest of the page, Ctrl + wheel is left to your browser as usual.

The page is redrawn sharper a moment after you stop zooming, and anything the viewer has boxed on the page (see the next section) stays on its value at every zoom. Moving to another document in the review queue starts it at the fitted size again. Images (JPG and PNG) have no zoom controls.

Finding a value on the PDF

Open a PDF from your document list, or open one from the review queue into its side-by-side pane, and you can ask the viewer where a value is printed. Click a header field (the invoice number, a date, the vendor name, and so on) or the Subtotal, tax (for example VAT), or Total amount — or move to it with Tab and press Enter. The viewer turns to the right page and draws a box around the value. A short note in the PDF toolbar says what it found, for example "Total: found on page 2". This works for every document type, including the fields of a custom template. In either view, the figure after Current value of in the Review requirements panel can be clicked the same way.

If the value is printed more than once, the viewer reads the label on the same line as each copy and boxes only the copies labelled like the field you clicked. Due Date boxes the copy next to "Due Date", not one next to "Next Reading Date"; Total boxes "Balance Due" or "Total Due", not a figure in a line-item price column. If no copy has a matching label on its own line, every copy is boxed so you can judge which one the value belongs to — a column heading alone isn't enough to pick one. The note says how many were boxed, such as "found in 2 places on page 1". If the value is printed on more than one page and no page has it under a matching label, the viewer stays on the page you're reading when it's printed there, and otherwise turns to the first page that prints it; the note then names the other pages, such as "found in 2 places on page 1; also on page 2". A value that wraps onto more than one line, such as an address or a long name, is boxed as one block covering all its lines.

The bank account number and IBAN can be clicked too. Admins and firm admins see the full number on screen, as does a reviewer who has been granted bank number access, and the viewer looks for the full number, whatever spacing the PDF prints it with. Other reviewers only see the last four digits (for example ••••7890), so the viewer boxes any printed number of six or more digits that ends in those four, and the note says so: "Account: found on page 1 (matched on the last 4 digits 7890)". For those reviewers the document's converted text, its JSON export and its markdown download show bank account numbers and IBANs as ••••7890 as well, and so do text fields that quote one, such as an address, an invoice note or the printed payment terms. If you save Edit Fields without changing such a box, the full text is kept. If you edit it, either retype the whole field or leave the masked number exactly as shown. If an edited box still contains a masked number, Edit Fields saves nothing and tells you which field to fix. The PDF itself is shown as it is.

The viewer searches the PDF's own text, so the box shows where the value is printed, not a record of where the extraction read it. If the value isn't there as written, the note says it was not found — it may be formatted differently on the page, or calculated rather than printed.

Scanned PDFs work too. The first time you open a scan, DocReadi reads its pages in the background, which takes a few seconds; the note says "Reading the scan… the first time takes a few seconds." After that, a match is boxed on the scan and the note adds "read from the scan", or "read from the scan with low confidence, so check it" when the reading was unclear. If a value can't be read clearly, the note says it was "not found on the scan" and nothing is boxed, rather than a box on the wrong figure. If the scan couldn't be read at all, the note says "This scan couldn't be read, so there's no text to point to."

Line items can be found the same way. Click a row in the Line Items table (or Items on a delivery note, the Ledger on a statement, or a table of rows in a custom template), or move to it with Tab and press Enter, and the viewer boxes that whole line on the page — "Line 3: found on page 1". It looks for the row's description and its figures on the same printed line, so when two lines both print 100.00 it boxes the one whose description matches. A description that wraps onto a second line is boxed with it. Click a single cell instead — the quantity, the unit price, the total — and the box narrows to that value within the row: "Line 3 · Total: found on page 1". The viewer checks every page, so a line on page 3 is found even while you are looking at page 1.

The table shows a Code column (the supplier's product code) and a UoM column (unit of measure) only when at least one line has one, so a document without codes or units doesn't carry an empty column. Neither can be changed in the Edit Fields line-item editor, and saving an edit there keeps them as extracted.

A line the document prints without an amount of its own — for example a component listed under a bundle heading such as "Provision of services consisting of:" — gets a blank total, not a 0 or a guessed figure; if one slips through, the line total field is where to clear it. A row printed as 0.00, FOC or included is extracted as 0. A heading with no amount is not a line. Items on a delivery note carry a description, code, quantity and unit only; a delivery note records goods, not money.

When the page doesn't settle which line it is — the description isn't printed as extracted and the same figure appears on several lines — every candidate line is boxed and the note says how many, adding "The description wasn't found in full, so this is matched on the figures". A quantity alone never picks a line, since small numbers are printed everywhere. If the cell you clicked isn't printed on the line (a quantity the page leaves out, for example), the line is boxed and the note says "not printed on that row, so the row is shown". Credit lines printed as (250.00), 250.00- or 250.00 CR are found like any other figure. Clicking the unit of measure or the VAT rate finds the whole line.

This works for PDF documents only (not images), in both the document view you open from your document list and the review queue's pane; the Edit Fields line-item editor doesn't have it. The currency is never highlighted.

Editing fields

Click Edit Fields (keyboard shortcut E) to correct a field by hand — the usual fix when the extraction read a value slightly wrong (a transposed digit, a misread date) but the rest of the document is fine. Saved edits apply immediately; they don't consume a credit or trigger a new extraction. E opens and closes the panel, in the document view and in the review queue: press it again, or click Close, to close the panel. While your cursor is in a field, E types the letter as usual — press Esc to leave the field first. While you're picking a value from the PDF, press Esc to cancel the pick before E closes the panel.

The panel carries the same marks as the read-only view, so the fields worth checking stay easy to find. A field that a validation check names is outlined in red, a field the extraction was unsure of is outlined in yellow, and each field shows its confidence percentage next to its label. When any field is flagged, a Needs a look: line at the top of the panel lists them in order; click a name to jump to that field with the cursor already in it.

Date fields take the date in your workspace's date format — the one set under Settings → Workspace → Number and date formats (see Workspace administration). The box shows the format as a placeholder and as a small hint underneath, for example MM/DD/YYYY. When you save, DocReadi reads the date in exactly that format, or as YYYY-MM-DD. It doesn't guess at anything else, because a date such as 04/05/2026 means different days in different formats. If a date can't be read, nothing is saved and the reason appears in a red box above Save changes — for example, Invoice Date: "13/45/2026" is not a date in the MM/DD/YYYY format. Nothing was saved. Correct the date and save again. A date you haven't touched is kept exactly as it was, even when it isn't a date DocReadi can read (a custom template can hold text like "March 2026"), so it never stops you saving other fields. Amounts work the same way: an amount box shows the stored figure as a plain number (1234.56 for a document that printed 1 234,56), accepts as many decimal places as the document uses, and an amount you haven't touched is kept exactly as it was. The date column on a statement's ledger rows is the exception: it uses your browser's own date picker.

Amount boxes — the header amounts, the line-item Quantity, Unit price and Total columns, and a statement's Debit, Credit and Balance — accept 1 234,56, 1.234,56, 1,234.56 or 12,50. A value with a leading zero, such as 0,899, is always read as a decimal. A figure with one comma and exactly three digits after it, such as 1,859, could mean one thousand eight hundred and fifty-nine or one point eight five nine:

A line's VAT column takes a rate, not an amount: a percentage (15, 15% or a comma decimal such as 12,5%) or a fraction (0.15). It is saved as the fraction — 14 is stored as 0.14. A value that isn't a rate between 0 and 100% (for example "fifteen" or 150) isn't guessed at: nothing is saved and the red box says it is not a VAT rate. Correct it and save again.

A cell you haven't changed is saved exactly as it was, whatever it holds.

The same rule applies when DocReadi reads the document itself. If a line's quantity or unit price is printed that way and nothing else on the document shows which convention it uses, DocReadi leaves the figure empty and the document stays in review with the warning A figure could be read two ways, naming the line. Fill it in with Edit Fields.

A total can be caught the other way round. If the extracted total matches the document only when a point such as "60.000" is read as a decimal point, and money in the document's currency isn't printed with three decimals, the document stays in review with the warning A figure may be a thousand times too small. DocReadi doesn't change the figure: check the total against the document and correct it with Edit Fields if it's wrong.

If you've typed or picked a change and not yet saved it, DocReadi asks before throwing it away. Closing the panel (Close, Discard or E) and, in the document view, going back to the list (Esc or B) show an Unsaved edits box with three choices:

The review queue shows the same box when you move to another document — the next or previous one, or a row in the queue — and saving there moves you on once the save has gone through. Every other action you take with unsaved changes uses the same box, worded for that action: Approve (in the review queue it reads Discard edits, approve as-is), and in the review queue Reject, Reject + reprocess, Void, Flag, Reject as duplicate and changing the document type. In the document view, clicking Edit Fields again while the panel is open reloads the editor, so it offers Save edits, then reload the editor or Discard edits and reload; changing the document type and Reject as duplicate ask there too, and so does Swap buyer/seller on both screens. Save edits, then … carries out the action only once the save has gone through. The action's own step still follows your choice: Reject, Void and Reject + reprocess open their dialog, and changing the type, rejecting as a duplicate or swapping the parties still asks you to confirm. Cancel on a type change puts the type back as it was. Discarding puts every field back to its saved value, so reopening the panel never shows the edits you threw away. Leaving the page any other way — a link, your browser's Back button, closing the tab — brings up your browser's own "Leave site?" prompt. Approving records the saved values, so an edit you haven't saved is never part of the approved record.

The issuer's phone number has its own field: Vendor Phone in the Issuer (Vendor) section on AP invoices, AP credit notes and generic invoices, and Issuer Phone on sales invoices, sales credit notes and receipts. A "Tel." line that repeats it is no longer kept inside the address. On a receipt the viewer shows it as Phone in the merchant block.

Subtotal is the amount before VAT. When a document prints a pre-tax figure ("Pre-Tax Total", "Excl. VAT", "Nett"), that is the subtotal; a VAT-inclusive "Sub-total" is not used. When only VAT-inclusive figures are printed, a new extraction works the subtotal out as total minus VAT. When it cannot do that safely (the slip also shows a discount or an extra charge), the subtotal is left as read and marked as uncertain so you can correct it. A reverse-charge invoice, whose total leaves out the VAT it prints, keeps its subtotal as read. Documents already extracted or approved keep their stored subtotal.

A receipt has an Order Number field (an order, check, bill or docket number on a till slip) under Receipt Details, next to Receipt Number, and the receipt viewer shows it beside the receipt number. A slip that prints an order number but no receipt number is not treated as missing its reference.

On an AP invoice, sales invoice, generic invoice, or receipt, the field list also carries Charges (freight, surcharges), Deposit Already Paid, and Rounding, alongside Discount and Gratuity / Tip. DocReadi only fills one of these in when the document itself prints such a charge, deposit, or rounding adjustment — never to make the arithmetic balance — so on most documents they're blank. A printed service charge ("Service", "Service Charge", "SVC CHG 6%") belongs in Charges, not Gratuity / Tip. If the extraction leaves Charges empty, DocReadi reads the charge off the page itself, but only when exactly one amount on a service-labelled line makes subtotal + charge + VAT equal the total to the cent; otherwise it fills nothing and the totals check flags the document. This runs on a new extraction, never on Re-validate. Add or correct one by hand if the source states a figure that wasn't picked up; each feeds directly into the amount-due check described in Troubleshooting.

The same four types also carry a payment block, grouped under Bank & payment in Edit Fields and in the review queue. It holds Bank name, Bank account number (AP invoices and AP credit notes only), IBAN, BIC / SWIFT, Routing / sort / branch code, Routing code type, Account Holder, Payment Reference and Payee (remit to). Each is filled in only when the document itself prints it, taken verbatim; DocReadi never constructs or completes a payment detail. A US routing number, UK sort code or branch code belongs in the routing code box, not in BIC / SWIFT; Routing code type says which kind it is (ABA routing, sort code, branch code, BSB, transit, IFSC or other). Every group in the panel has a one-line help text under its heading. In the document view these sit in the vendor or issuer panel alongside the existing Bank and Account rows, with the routing code shown as Routing / sort / branch code under BIC / SWIFT when one was read. The IBAN and the bank account number are masked the same way: the last digits only for a Reviewer, the full value for an Admin or Firm admin. The mask holds in Edit Fields and in the review queue too: a Reviewer sees the bank account number and IBAN as ••••7890, read-only, and only an Admin or Firm admin can see or change the full number, unless the reviewer has been granted bank number access. In the review queue's read-only grid, Bank & payment is hidden when all its fields are empty; Edit Fields always shows it.

Alongside the payment block sits Payee (remit to) — filled in only when the document names a party to pay that's different from the party who issued it, never a copy of the issuer's own name. On an AP invoice, a filled Payee row also shows directly in the document view, in the vendor panel, so it's visible without opening Edit Fields. A filled Payee row is also, on its own, a reason the document lands in review: a printed pay-to party that doesn't match the issuer is legitimate for factoring or group treasury arrangements, but a changed payee is also a common sign of invoice fraud, so DocReadi flags it and asks you to confirm the payee with the supplier, on a phone number you already hold for them, before paying.

On an AP invoice, sales invoice, or generic invoice, Edit Fields also carries a set of reference fields alongside the invoice number and PO reference — Buyer Reference, Contract Reference, Delivery Note Reference, Original Invoice Date (a credit note's own back-reference date), Payment Terms (as printed), and Invoice Note — each filled in only when the document itself prints it, taken verbatim. A separate Delivery & Period group holds Delivery Date, Period Start, and Period End, for documents that bill a service period rather than a single delivery or supply date; like the Your account with this supplier group below, it's collapsed out of the way when the document carries none of these fields, so it never adds an empty section to a document it doesn't apply to. If the period dates don't make sense — an end date before the start date, or either one unreadable — the document is held for review; see Common validation failures, in plain language.

The vendor/issuer and buyer/customer field groups on the same three types also carry, where the document states them: Country (a two-letter code, filled in only when the printed address states or unambiguously implies it — DocReadi never guesses a country from the currency or the language), Trading Name (issuer side only, when the document distinguishes a trading name from the legal name — "t/a" or "trading as"), and Registration Number (a company registration number, distinct from the VAT number, on either side).

Picking a value from the PDF

Instead of typing a correction, you can take it straight off the page. In Edit Fields, each header field has a small crosshair button next to its label. Press it, then click the value on the PDF. One click takes the whole date, the whole amount, or the whole piece of text in that spot — an amount from the column you click only, never joined to a quantity beside it; to take several lines at once, such as an address, drag across them and they are joined with commas. While you move over the page, a dashed box shows what a click would take. The value fills the field — a date fills in your workspace's date format, whatever format the document prints it in — and the note in the PDF toolbar says where it came from, for example "Due Date: set to 14 September 2026 from page 1. Save to keep it." Nothing is stored until you click Save changes.

If the value can be read more than one way — a date such as 04/05/2026, or an amount such as 1,234 — DocReadi doesn't guess. A small chooser appears under the field listing each reading, and nothing is filled in until you pick one; Neither closes it and leaves the field as it was. If the text you clicked isn't a date or an amount when the field needs one, the note says so; press the crosshair and try again, or type the value. Press Esc to cancel a pick — while you're picking, Esc cancels the pick and doesn't take you back to the list. A drag you release outside the page image is dropped, not treated as a pick.

Picking works on scanned PDFs as well, using the same reading of the scan described in Finding a value on the PDF — including a scanned page that carries a little real text, such as a "Received" stamp: the stamp is taken as printed and everything else from the scan. On a scanned page that has no reading and won't get one, the crosshairs are greyed out, with the tooltip "Not available on this scanned page — type the value"; pressing one shows that message instead of starting a pick. This is decided page by page as you turn pages: DocReadi reads the first 40 pages of a scan, so on a 60-page scan pages 1 to 40 can be picked and pages 41 to 60 are greyed. While a scan is still being read the crosshairs stay available. Picking doesn't work on image uploads (JPG or PNG); type the value instead. It covers header fields (not line items) on the page you're viewing.

It works the same way in the review queue: press Edit (or E) and use the crosshairs against the PDF on the left of the pane. The picked value counts as an unsaved edit, so Approve offers Save edits, then approve and moving to another document asks first (Save, Discard or Cancel). The crosshairs appear only on a document still waiting for a decision — not on one that is approved, rejected or voided — and moving to another document cancels a pick you haven't finished.

A review requirement's Text, Number and Date answers have the same crosshair, with no need to open Edit Fields first; see Answering requirements as a reviewer.

Rolling-account bills

Municipal, utility and telco bills print a running account balance beside the current period's charges. DocReadi books the period's charges as the document total — including when the account is in credit and the closing balance is negative. The account figures are recorded separately, under a field group labelled Your account with this supplier on AP invoices and sales invoices. Its help line reads: the customer or account number the supplier uses for you, and the running balances a rolling-account bill prints — never the supplier's bank account, which goes under Bank & payment:

Amounts are shown exactly as the bill prints them, so a credit balance shows as a negative number. These fields are informational: editing one never changes the booked total. The group only appears in the document view when the bill actually carries account figures — on an ordinary invoice it is hidden, so it never adds an empty section to documents it doesn't apply to. It is always available under Edit Fields, so you can add the figures by hand if a bill prints them and they weren't picked up. If the account figures don't reconcile, the document is held for review with an explanation — see Rolling-account bill checks.

Reviewing a statement

A vendor or customer statement reviews differently from an invoice, because it isn't one — its rows point at invoices that exist elsewhere. See Statements of account for what a statement is and what DocReadi reads off it. In the queue and the document list, a statement shows its counterparty, its account number, the statement date and the amount due — a statement has no invoice number or invoice total, so the account and the balance stand in for them.

Opening a statement shows its parties, the account details, the opening and closing balances, any aged-balance buckets, and the ledger as a table: one row per movement, each with its type (invoice, payment, credit note, fee, interest), the document it refers to, the Amount (a single signed figure), and the running Balance. The table has no separate Debit and Credit columns — which side a figure sits on depends on whose books the statement is printed from. A caption under the table tells you which way the sign runs: a positive Amount increases what the account holder owes the issuer (or what the issuer owes the account holder, depending on which side the balance favours), and a negative Amount reduces it. Opening and closing balance rows are positions, not movements, so they show a Balance and no Amount. DocReadi computes the Amount itself, as the difference between each row's printed balance and the previous row's, rather than trusting the extraction's own sign — so it can come out with a different sign than a first read of the row's wording would suggest. Where a row's printed amount doesn't match the balance movement, the Amount is left as extracted. The opening and closing balances are treated the same way: where the ledger prints its own opening or closing row, that row is what DocReadi records. When either correction fires, a note under the table says what changed — how many row amounts were re-derived, how many rows were left alone because the printed amount didn't match the balance movement (those still need a look), and whether a balance was taken from the ledger's own row. The ledger is deliberately not shown as a line-item table — its rows are references to other documents, not charges — but Edit Fields does offer a Transactions editor built for that shape: Date, Description, Doc #, Debit, Credit, and Balance, each free text (amounts accept 1 234,56 or 1,234.56, and a figure such as 1,859 is read as money — see Editing fields above), tick the row's ✕ to delete it, and + Add row appends a blank one; an empty row is dropped on save. The signed Amount isn't one of the editable columns — you can't type a sign directly — because DocReadi re-derives it itself from the printed running balances the moment you change a row's figures, the same rule Re-validate applies. If your edited figures don't fit the printed balances, the statement is flagged for review rather than saved silently; fix the row or check the balance and try again.

If a statement was read badly, use Reject & reprocess; if the type itself is wrong (a "Tax Invoice"-titled municipal or telco bill read as a statement, or the reverse), reclassify it first. If the only issue is a row's Amount not following its printed running balance, or an opening balance that doesn't match the ledger's own opening row, try Re-validate — it re-checks the ledger and often clears the flag on its own, with no re-extraction; see Statement checks.

Approving a statement needs an account number, a statement number, or a statement date — not an invoice number. It records your decision but writes no typed invoice record.

Swap buyer/seller

On an AP invoice, AP credit note, sales invoice, sales credit note, or generic invoice, you'll sometimes see the two parties read into the wrong slots — the seller extracted into the buyer field, or vice versa. Rather than editing every name, VAT number, and address field by hand, click ⇄ Swap buyer/seller (shown on both the document view and the review pane, for as long as the document isn't approved) to exchange the two party blocks in one step. Confirm the prompt and DocReadi swaps the party names, VAT numbers, and addresses, re-resolves the counterparty from the corrected side, and re-runs the cross-field validation checks. It's deterministic — no model call, no credit charge.

On a generic invoice the swap also inverts the direction hint (inbound ↔ outbound) so it keeps facing the right party; an unknown direction stays unknown.

Swapping parties doesn't change the document's type. If the type itself is wrong too — for example, an AP invoice that was actually a sales invoice — reclassify it separately: change the document-type dropdown at the top of the document view, or select the rows in your document list and use Set type…. An approved document can't be swapped or reclassified — unapprove it first.

Re-extract

If more than one or two fields are wrong, it's often faster to have the model try again. Re-extract re-runs extraction on the already-parsed document, feeding back the specific validation errors as correction hints — it's fast because it skips re-reading the source file from scratch. Use Reject & reprocess instead when the document needs a full pipeline re-run (for example, after fixing which document type it should be), and Re-validate when the underlying values are already right and you just need the cross-field checks to run again — this option never calls a model.

In the documents list, a row's button is named for what it will do. Re-extract runs this correction pass over the text already read; it shows when the document has open checks, its read text is stored, and it is an invoice, credit note or receipt type. Reprocess runs the whole pipeline again from the file; it shows for failed documents and the other document types. Retry is used only for retrying a failed delivery, push or inbox file.

Re-extract keeps the version it replaces, so Restore previous can bring it back if the new read is worse. The document view shows this as a blue note — "This document was re-extracted. You can flip back to the previous extraction." — with the Restore previous button.

Credit lines that lost their minus sign

When the line items don't add up to the subtotal, but making some of them negative would make them add up exactly, the document view shows an amber warning: "The line items don't add up to the subtotal. N line items look like credits that lost their minus sign — applying negative signs makes the lines add up to the subtotal." Check those lines against the source; if they are credits, click Apply credit signs to make them negative in one step. The warning only appears when flipping the signs reconciles the lines exactly, so it never suggests a correction that wouldn't add up. If the lines are not credits, correct them with Edit Fields instead. While the lines still don't add up, the document keeps its Line items don't add up to the subtotal check, so approving it asks you to confirm that check.

The split editor

If a single uploaded file actually contains more than one document — a batch scan of several invoices, for instance — open Split from the document view (shown for multi-page PDFs). The split editor shows every page as a thumbnail with a divider between each pair; click a divider to toggle it between Split here and Merge, then choose Split & process to extract each resulting document separately, or Process as one if, on reflection, the file really is a single document.

Approve, reject, and unapprove

Clicking Approve again on a document that's already approved does nothing further — DocReadi treats it as already done rather than re-approving it, so a slow connection or a second click can't send it through twice.

Approving a document with open checks

A document's open checks are the validation issues that sent it to review — the list under Checks — N need attention on the document view, and Why this is in review in the review pane. You can still approve a document that has them, but not in one click. When you approve, a dialog lists each open check in plain language and ends: "Your name will be recorded on the audit trail as confirming this document is correct." The dialog has two buttons: Go back and Approve with N open checks (N is the number of checks). Press Approve with N open checks to approve; Go back stops the approval and leaves the document where it is. Pressing Esc or clicking outside the dialog counts as Go back. The checks you confirmed are recorded with your approval.

The same question appears wherever you can approve one document: Approve on the document view, the ✓ on a row of your document list, the mobile view, Approve in the review pane, Assign GL & approve, and the fast review strip. A document with no open checks approves exactly as before, with no extra step.

If the checks change between the moment the page loaded and the moment you approve — another reviewer re-validated it, say — DocReadi refuses the approval with "Not approved: this document has N open checks (…). Open the document, look at each check, and approve again to confirm it is correct." Reload the document and approve again; you are only ever asked to confirm the checks that are open now.

Save edits, then approve in the review pane works the same way. Your edits always save. Saving re-runs the checks, so if the checks open after the save are the ones you confirmed, the approval goes through; if your edits changed them, the approval waits — the message begins "Saved your edits, but approve is held." — and you approve again to confirm the checks as they now stand.

A value that could not be read

Sometimes a value is printed on the document but part of it can't be read — a smudge, a fold, a stamp across the digits. DocReadi doesn't guess: the field shows [UNCLEAR] where the characters are missing, and the check Part of a value could not be read names the field ("Invoice number is printed on the document, but part of it could not be read…").

This one is different from every other check: you can't approve past it. The approve dialog says Can't approve yet and has no approve button, and an approval that reaches DocReadi anyway is refused with, for example, "VAT number is unclear — can't approve yet. Type it, pick it from the document, or mark it not on the document." Bulk Approve and Approve clean skip the document and say so.

The check's card on the document view and in the review pane gives you three ways to fix it, under Correct … to approve:

Each of these saves the field, re-runs the checks — so the card disappears — and is recorded on the audit trail with the field and the action you took (never the value). Any field works the same way, however deep it sits — a line item ("Line 4 description"), a row of a statement ("Transaction 4 reference"), a VAT line ("VAT line 1 rate"). Each is read as its kind: an amount or a rate as a number, a date in your workspace's format, and a field with a fixed list of values (such as a statement row's type) only accepts one of them. A bank number you see masked can't be corrected from the card; the card says so, and someone who can see bank details in full can fix it. The mobile view holds the approval too, but the three actions are on the document view on a computer.

A document without its number

Every invoice, credit note, delivery note, purchase order, sales order and credit request needs its number before it can be approved — your accounting records, Xero bills and exports are keyed on it. When the number is empty, or could only partly be read, the document shows the check Document number required ("Invoice number is empty, and this document can't be approved without it…"), and approval is held exactly like an unclear value: the approve dialog says Can't approve yet, an approval is refused with "Invoice number is required — can't approve yet. Type it, pick it from the document, or use a generated reference.", and Approve and Approve clean in bulk skip the document and tell you how many they skipped. Receipts, generic invoices and your own templates need no number.

The card gives you three ways to fix it:

A generated reference is marked Generated reference next to the field on the document view and in the review pane, and the audit trail records that you chose it (never the value). It is used as the document's number everywhere — your typed records, the Xero CSV, the Xero bill and report columns carry it like any other number. To find these documents in a report, add the generated_reference_fields column (under Metadata in the report builder), which names the field whose value DocReadi generated. If you later type a different number, the badge goes.

A statement needs something that identifies it instead — an account number, statement number, statement date or the period it covers. When none of them was read, the check is Statement can't be identified; add one in Edit fields, then approve. Statements get no generated reference.

A document with no type yet

When DocReadi can't tell what kind of document it is, the document has no type, and there is nothing to approve it as. Approve isn't offered on it: the document view, the review pane and the mobile view show "No document type yet. Choose one from the document type list, then approve." in its place, and the document list row and the fast review strip show Set a type to approve. The type list reads Choose a type until you pick one (in the review pane, the Quick reclassify buttons are a shortcut for the common types). Choosing a type re-runs extraction under it; approve once that finishes. Approve and Approve clean in bulk skip such documents and say how many: "N selected documents were not approved: no document type is set. Open them and choose a type, then approve."

While a document is being re-checked

If your workspace re-checks documents automatically when validation checks fail, a document can be rewritten in the background after extraction. While that runs, the document view, the mobile view and the review pane show a banner: "Re-checking this document. You can approve it once the check has finished." Approve is disabled (the document view and review pane also hold Edit Fields and Edit), and DocReadi checks every 5 seconds whether the re-check has finished. In the documents list the status reads Re-checking and the row has no Approve button; the fast review strip and the review queue show Re-checking… for the row.

When the re-check finishes, the page reloads itself only if you aren't in the middle of something. If you have unsaved Edit Fields, a dialog open, the cursor in a text box or picker, a pick from the PDF under way, or a control you changed and haven't sent, the page stays as it is. The banner then reads "Re-check finished. Reload to see the checked figures and approve. Nothing on this page changes until you do." with a Reload button (queue rows show "Re-checked" and Reload). If you have unsaved edits, Reload asks whether to save them, discard them or cancel first. DocReadi stops checking after 15 minutes; the banner then reads "Still re-checking after 15 minutes. Reload to check again."

DocReadi enforces the hold on its side too. Approving — from the document view, the review pane, the fast review strip, or Save & approve in Edit fields — is refused with "Not approved: this document is being re-checked, and the figures on your screen may be replaced. Wait for the re-check to finish, then approve." Saving edits is refused with "Not saved: this document is being re-checked, and the re-check would replace your edits. Wait for it to finish, then edit." Swap parties, apply credit signs, restore previous extraction and promoting an earlier attempt are refused the same way (with the "Not saved" wording). Starting another run while a re-check is under way — Reprocess, Re-extract, Reclassify, Fix with AI, or reject-and-reprocess — is refused with "Not started: this document is being re-checked. Wait for the re-check to finish, then try again."

A document that is still being processed (for example after a reprocess or retry) is held in the same way, whether or not a re-check is running. Approving it is refused with "Not approved: this document is still being processed, and its figures will be replaced. Wait for processing to finish, then approve." Saving edits, or any of the changes listed above, is refused with "Not saved: this document is still being processed, and processing would replace your edits. Wait for it to finish, then edit."

Running Fix with AI yourself — or Re-extract from the documents list — puts the same hold on the document: the banner shows and Approve and edits are held until it finishes.

Bulk approve skips documents that are still being re-checked or processed and reports how many ("... still being re-checked or processed and were not approved. Approve them when they are done."); Approve clean skips them as well. Bulk reprocess and bulk reclassify skip documents that are being re-checked and report how many were skipped. The hold lapses after 10 minutes at most, even if the re-check never finishes.

If an approval or an edit does land while a background pass is still running, the pass's result is thrown away so your change stands, and a comment authored "DocReadi" is added to the document: "A background re-check finished after <reason>. Its result was discarded, so the document keeps what you did. Run it again if you still want it." After a reprocess or retry, "re-check" reads "re-extraction".

If a counterparty disputes a document you've auto-approved — DocReadi gives every auto-approved decision a contest path, in line with GDPR Article 22 and POPIA §71 automated-decision rules — the document is flagged automatically with their reason attached and returns to your queue for a fresh manual look.

Approving with unresolved GL lines

If your workspace has both GL determination and its Approval gate switched on (Require every GL line assigned before approval, under Settings → Master data → GL accounts → Defaults), the Approve button changes to Assign GL & approve on a document with unresolved lines. It opens an inline panel listing only the unresolved lines, each with a searchable account picker (the same combobox as the GL postings tab) — choose an account for every line, then Assign & approve. This applies only to document types that carry GL postings (AP and sales invoices and their credit notes, and receipts); other document types approve as usual. If the gate is off, or every line already resolved, Approve behaves as described above. Assign & approve asks you to confirm any open checks in the same way as Approve.

In the rare case where the document's line values can't be read at all (for example, amounts that didn't survive extraction cleanly), the gate also holds the document — the review note says GL completeness couldn't be checked. Fix the line items with Edit Fields first, then approve.

Comparing a suspected duplicate

Both duplicate notes — Looks like a duplicate and Matches an existing record — carry a Compare side-by-side link. It opens the document next to the one DocReadi matched it against — the "canonical" one already in your records. Each pane shows the source file (an e-invoice XML shows the same rendered invoice as the document view, with its own Show source toggle) and a short field digest (supplier or customer, document number, date, total, currency); any field that differs between the two is highlighted, which is usually the invoice date on a reissued document. The pane of the document carrying the flag is labelled Flagged as duplicate, the other Original. Use it to decide in one screen whether you're looking at the same invoice twice or two genuinely separate ones. If the document isn't flagged as a duplicate (or the match it pointed to no longer exists), opening this view just takes you back to the regular document view.

Resolving a duplicate

Only one document of a pair is ever flagged — the later one. Its pane on the compare screen, its document view and its review pane offer:

Keep this one isn't offered when the other document is already approved, or has already left DocReadi — included in an export, queued for or sent to Xero, or sent by a document.approved webhook. Swapping then could book the same invoice twice, so the screen says why instead (for example "The other document is already approved, so it stays the original.") and you choose Reject as duplicate or Not a duplicate. Each action asks you to confirm first.

A document flagged as a duplicate stays flagged after you approve it until you resolve it here. Export rules and the Xero push leave it out unless the rule's Include documents flagged as duplicates box is ticked (see Delivering documents).

Comments

Add a note to a document's activity timeline with the comment box on the document view — useful for leaving context for whoever picks up the review next, or recording why a decision was made.

Fast review

For working through a large pending queue quickly, switch to Review → fast — a dense, keyboard-driven strip of rows instead of the full split view. Approve (✓) or reject (✕) a row without leaving the list; a row flagged as a possible duplicate asks for confirmation before approving, a row with open checks lists them and asks you to confirm (see Approving a document with open checks), and a row matched as a duplicate gets a one-click Reject as duplicate (D). Fast review only shows pending documents — use the full queue for flagged, rejected, or approved documents.

Review stats

The Stats link in the queue header opens a 30-day activity dashboard — approvals, rejections, voids and reprocesses, a daily bar strip, a median time from upload to decision, and a breakdown of the reasons behind your rejects and voids. Change the window (7 / 30 / 90 days / a year) or narrow it to one document type with the filters at the top.

What you see depends on your role. A Reviewer gets Your review activity — the same page, counting only the documents you actioned yourself. An Admin gets the workspace-wide view: one row per reviewer, who was last active, and the reject reasons across the whole team.

Bulk actions in the review queue

Select multiple rows in the queue (the checkbox in each row, or select all) to act on them together:

If Save & approve in Edit fields saves your edits but the approval itself can't be saved, you see "Saved your edits, but the approval couldn't be saved — something went wrong on our side and it has been logged. Approve the document again." Your edits are kept; approve the document again.

Your document list carries a wider bulk bar — the same Approve and Approve clean, plus Set type…, Move to folder…, Combine (merges the selected PDFs into one, in list order), Re-validate, Re-validate all flagged (re-runs the cross-field checks on every flagged document in the workspace — no selection needed, and no model call), Reprocess… (runs each selected document through your workspace's default processing again, the same way an upload does), Download… and Delete.

While a bulk action is running, its buttons grey out so a second click can't queue the same action twice.

Auto-approve thresholds

Auto-approve is configured under Settings → Review and approval (admin only), and is off for every document type until you turn it on. Because auto-approve is a fully automated decision, DocReadi requires an explicit acknowledgement before any threshold takes effect:

Auto-approve marks a document as approved without human review when the confidence of its weakest field clears a threshold you set per doc-type (the "Lowest field confidence" shown on each document). Documents with open validation issues never auto-approve. Under GDPR Article 22 and POPIA §71, this kind of automated decision requires that your counterparties have been informed and have a way to contest it, and that you spot-check auto-approved documents periodically.

Click I acknowledge — enable auto-approve to turn it on; Disable auto-approve turns it off again without losing your configured thresholds — they simply stop firing until you re-enable. With acknowledgement in place, switch on the Auto-approve toggle beside each document type you want approved automatically — switching a type on fills in a sensible default confidence (0.95) you can then edit; leave a type switched off to keep reviewing it by hand indefinitely. The threshold is compared against the document's weakest field, not an overall score, so one poorly read field is enough to send a document to review. If a type is switched on but its threshold is left blank, the page flags it ("Switched on but no threshold — documents still go to review") so it can't silently sit dormant. A separate, usually lower, bulk-approve threshold governs the Approve clean bulk action. Thresholds apply prospectively only — raising a threshold doesn't retroactively approve documents already sitting in your queue.

A sibling setting, Require review through the document view, blocks approving from a surface that doesn't show you the document itself (the document list or fast review) — when it's on, only the document view or review pane can approve, and every approval records which surface it came through. The setting governs reviewers in DocReadi only: an integration using the API runs its own review workflow and is not held by it, although your auto-approve thresholds and validation checks still apply to the documents it sends.

Duplicate detection

Also under Settings → Review and approval, duplicate detection flags a document that looks like a re-upload, a reissue with a suffixed invoice number, or a heuristic match on counterparty, date, and amount. Choose a Mode:

An exact re-upload of the same file is blocked from approval in Soft and Strict mode until a reviewer marks it Not a duplicate. Tune the lookback window (how far back to compare) and amount tolerance (how close two amounts must be to count as a match) alongside the mode.

Counterparty auto-confirm

A related setting on the same page controls how quickly a new counterparty moves from candidate to a fully confirmed entry in your registry — see Master data for the registry itself.

Reject reasons and reprocess prompts

Still on the same settings page, you can maintain the list of structured reasons offered when rejecting a document, and a library of saved instructions offered when you choose Reject & reprocess — handy for repeat corrections ("read amounts in EUR, not USD" or similar) you don't want to retype every time.

Review requirements

Where auto-approve thresholds and duplicate detection are about the extraction itself, review requirements put a question in front of the human reviewer that the extraction can't answer on its own — a warehouse code that isn't on the invoice, a sign-off that someone checked the VAT number, a confirmation that the total on screen is the total on the page. A required requirement blocks approval until it's answered; an optional one is just there for the reviewer to see.

Setting up review requirements

Configure requirements under Settings → Review requirements (Admin only). Each requirement has:

A requirement row's Applies to and Kind can't be changed after you create it — a requirement's answers are tied to it as a record, and switching an Input to a Confirm (or the reverse) would leave old answers attached to a question they no longer match. Deactivate it and add a new one instead. Deactivating doesn't delete anything: existing answers stay as your audit record, and an inactive requirement simply stops appearing on documents (including ones that hadn't been answered — the requirement list a document shows is worked out fresh each time, not fixed when the document arrived). Deactivating a row created from a multi-type selection only turns off that one document type — the requirement's other rows keep working.

Answering requirements as a reviewer

A document with any resolved requirements shows a Review requirements panel on the document view and the review pane, listed in the order they're configured, with a count of how many are still outstanding. A teammate with the Reviewer role or higher can answer them:

On a PDF, a Text, Number or Date answer also has a small crosshair beside its box, so you can take the answer straight off the page without opening Edit Fields. Press it, then click (or drag across) the value on the PDF, as described in Picking a value from the PDF. A number is read as an amount and a date as a date; if it can be read more than one way (04/05/2026, 1,234) a chooser under the box asks which you mean. A picked date saves straight away, like choosing one by hand; a picked text or number fills the box and waits for the button beside it. On a scanned page with no reading the crosshair is greyed out, as in Edit Fields. The crosshair works on the document view and in the review pane, not on an approved document, an image upload, a List or Yes / no question, or a Confirm row — to fix a value you're about to confirm, use Wrong? Edit Fields and its own crosshairs.

Once you've answered an Input requirement, its row collapses to the saved value and a timestamp, with a Change link that reopens the input if you need to correct it — the same value stays visible without a form taking up space on every document you review afterwards.

A saved answer that quotes a bank account number or IBAN follows the same rule as the rest of the document: a reviewer without bank number access sees it as ••••7890, in the saved value and in the box behind Change. Pressing the button without touching the box keeps the full answer. If you edit the box and it still contains a masked number, nothing is saved and the row asks you to type the whole answer again.

Approve refuses while any required requirement is unanswered, listing the outstanding ones by name so you know what's left; optional requirements never block approval. Answering a requirement doesn't consume a credit or trigger a new extraction — it's recorded instantly and the panel updates in place.

When a confirmation goes stale

A Confirm requirement is only satisfied while the field still holds the value the reviewer confirmed. If that field's value changes afterwards — someone corrects it with Edit Fields, or the document goes through Re-extract or Reject & reprocess — the confirmation resets automatically, the panel shows changed since confirmation, and approval blocks again until someone re-confirms the new value. This is deliberate: a confirmation is an attestation about a specific value, not a standing approval of whatever the field happens to say later.

Requirement answers outside the review pane

Reviewer answers aren't only visible on the document — they can leave DocReadi alongside the document data itself. The report builder offers each active requirement as a field you can add to a report; a CSV bundle delivered through the outbox picks up one trailing column per requirement that applies to the documents in the run; and a webhook's document.approved payload (and other document events) carries the answers directly — see /api/docs-guide for the shape. A requirement created from a multi-type selection still counts as one requirement in all three places — one report field, one CSV column, one entry in the webhook payload — filled from whichever of its rows matches the document's type. In every case, a stale — changed since confirmation — confirmation exports as blank, never as the value it once attested to.

Next steps

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