Creating an Invoice from OCR
An Extracted OCR item is the AI saying "here's my best reading — your call." The Create Invoice step turns that reading into a draft Purchase Invoice under your eyes: the form opens pre-filled, you verify against the document, fix what needs fixing, and save. Faster than typing, safer than blind automation.
Access you'll need. Reviewing OCR items and creating invoices from them requires the Accounts Payable v2 permission set (AP clerks & managers) or Accounting Admin v2 (system administrators). The Accounting Controller v2, Accounts Receivable v2, and Read Only v2 sets can view items but not act on them.
The review flow
Work the Awaiting Review list
The OCR Inbox's Awaiting Review view holds every extraction below the auto-create bar. Open one; the attached document is right there for side-by-side checking.
Create Invoice → the pre-filled form
The Purchase Invoice form opens loaded with the extraction: vendor, entity, dates, reference, currency, lines with quantities, prices and suggested GL coding (drawn from your history with this vendor). Anything the AI couldn't confidently resolve is simply blank — never guessed-in garbage.
Verify like an AP professional
The thirty-second checklist against the PDF: vendor right? invoice number and date exact? total to the penny? line coding sensible? tax profile where applicable? Then Save Draft (or post, if it's ready) — the invoice proceeds through the completely normal AP flow, and the OCR record flips to Created with the invoice linked.
What arrives pre-filled — and what stays blank
Knowing where each pre-filled value comes from tells you where to look hardest during review:
| On the form | Where it comes from | Review attention |
|---|---|---|
| Vendor | The supplier name read off the document, matched to your real vendor accounts — tolerant of abbreviations and naming variations | Confirm it's the right account, especially for vendors with similar names |
| Entity | The receiving company named on the bill, matched to your entities | Critical — a bill booked to the wrong entity is a wrong set of books |
| Invoice number, dates, payment terms | Read directly from the document header | Check the invoice number character-for-character; it's your duplicate defence |
| Currency | The currency detected on the document; the entity's default currency when none is detected | Glance — matters on multi-currency vendors |
| Lines: quantities and prices | Read from the document's line items | Foot the total against the PDF to the penny |
| Lines: GL account / Product | Your own history with this vendor — the product-to-GL choices on their previously posted orders and invoices; lines without a matched GL fall back to the Product's Default Expense GL | Sensible-coding check; this is where your corrections teach the system |
| PO reference | A detected purchase-order reference is matched, currency-aware, to a real Purchase Order | Verify the line linkage like any PO-matched invoice |
| Anything unresolvable | Left blank — text the AI couldn't confidently match to a real record is dropped, never inserted as garbage | Blank fields are honest "I don't know"s; fill them yourself |
The confidence bar: who types, who reviews
Every extraction carries the AI's own confidence rating from 0 to 100. On the automated email path, that rating is compared to one setting — a territory field called OCR Auto-Create Threshold, whose help text states the contract exactly: "Minimum AI confidence (0-100%) to auto-create invoices from OCR. Below this threshold, documents require manual review. Default: 80%."
- At or above the threshold — the draft Purchase Invoice is created automatically: always a Draft, Invoice Type defaulted to Invoice, lines in document order, the OCR record flipped to Created with the invoice linked.
- Below the threshold — the record stays at Extracted and appears in the Awaiting Review list, waiting for a person and the Create Invoice button.
- Resolution — the threshold is looked up from the document's entity to its territory, so different territories can run different bars. Uploads on the form never auto-create anything; a person is already at the keyboard, so the form simply pre-fills.
A worked review at Meridian
Two documents arrive in Meridian US's queue on the same morning:
| Document | Confidence | Against the 80% bar | What happens |
|---|---|---|---|
| MetroPower June bill — $4,180.00, the twelfth identical monthly bill | 96 | Above | Draft PI auto-created and linked; it gets its human check during the normal posting review |
| Baxter Facilities Services — first-ever invoice, $2,730.00, scanned slightly askew | 64 | Below | Stays Extracted, lands in Awaiting Review |
Dana opens the Baxter item, clicks Create Invoice, and reads the pre-filled form against the PDF. The vendor matched (she created Baxter's account last week), the total is right, but the AI left the GL account blank on one line — Baxter is new, so there is no history to code from. She codes it to Repairs & Maintenance, saves the draft, and moves on. Next month, Baxter's second invoice will arrive with that choice already suggested — her thirty seconds of coding just became a standing instruction.
The auto-created ones
Email-path extractions at or above the confidence threshold skip the button: the draft PI is created automatically, linked, done. They still deserve the same thirty-second verification before posting — the threshold governs who does the typing, not who does the approving. Meridian's rhythm: auto-created drafts get their check during the normal posting review; below-threshold items get it at Create Invoice time.
Guardrails
- One invoice per document: once created, the actions retire — "A Purchase Invoice has already been created from this OCR Inbox record." No accidental duplicates from double-clicks.
- Drafts only: creation never posts; every gate (period, approval, budget, 3-way match) still applies at posting.
- Wrong extraction? Don't fight the form — Reprocess re-runs the AI (useful after fixing master data, e.g., creating the missing vendor), or just correct fields manually; you're in an ordinary invoice form.
Messages you may meet, verbatim
| The message | What it means / what to do |
|---|---|
| "A Purchase Invoice has already been created from this OCR Inbox record." (toast titled "Action Not Available") | The one-invoice-per-document guard. Open the linked invoice from the OCR record instead of creating another. |
| "Cannot reprocess — a Purchase Invoice has already been created from this record." | The same guard on the Reprocess side: once an invoice exists, re-running extraction could contradict it. Correct the invoice itself. |
| "Document processed successfully. Fields have been pre-filled from extraction." | The happy path on the upload channel — review and save. |
| "Document processing failed" | The extraction hit an error; the reason is captured on the OCR record. See the overview's error table for the specific messages. |
| "The uploaded document does not appear to be an invoice. Please upload a valid invoice document." | The first-pass check refused a non-invoice. Only vendor bills are supported today. |
| "OCR Inbox record not found." | The intake record was deleted (or you lack access to it) between queueing and action. Check with your administrator. |
When the invoice came with structured XML
If the vendor's document included a structured e-invoice XML, the pre-filled values you're reviewing didn't come from reading a page — they came straight from the XML's labelled data fields, which are exact by construction. In practice that means the header figures and totals arrive already correct, with little to correct on review. You still confirm and create the invoice the same way; there's simply less to fix. When no XML is present, the review flow is exactly as described above, working from what the AI read off the PDF. See Structured e-invoice XML for how the Inbox chooses its source.
Common mistakes to avoid
| Mistake | Why it hurts | Do this instead |
|---|---|---|
| Typing the invoice manually because the extraction had a gap | The OCR record stays Extracted with Create Invoice still live — a colleague working the queue later can create a second, duplicate invoice | Always go through Create Invoice and fix the gaps in the pre-filled form; the record flips to Created and the guard takes over |
| Reviewing only the header total | A right total with wrong line coding books the expense to the wrong account — and teaches the AI the wrong coding for next month | Add line GL accounts to the thirty-second checklist; they're the part that compounds |
| Posting auto-created drafts without the verification pass | The threshold governs who does the typing, not who does the approving — an 85%-confidence misread can still reach the ledger | Give auto-created drafts the same check at posting time that reviewed ones get at creation time |
| Creating the invoice before creating a missing vendor | You hand-pick the vendor this once, but the extraction never linked it — no history builds for next time | Create the vendor account first, then Reprocess: the match lands and history starts accruing |
| Letting the Awaiting Review queue age | Below-threshold items are real vendor bills with real due dates — they don't age into the AP aging until created | Work the Awaiting Review view daily, like a mailbox |
Who can do this
Working the queue and creating invoices needs edit access to the OCR Inbox (the Accounts Payable or Accounting Admin permission set, as noted at the top of this article). Creating the invoice itself also requires being a licensed REDA Financials user, like any accounting document.
Where to go next
- Creating a Purchase Invoice — the form you're reviewing in.
- Reprocessing Failed Extractions — the retry path.
- OCR Inbox & Document Queue — the queue this flows from.
Frequently asked questions
Likely a first-time vendor: no account exists (or the name differs beyond recognition). Create the vendor account, then Reprocess — the match lands, and the extraction can also pull their history next time.
Yes — you're in the normal form; change anything. Detection favors the entity named on the bill, but you decide where it books.
A detected PO reference is matched to the real purchase order during extraction; verify the line linkage in the form like any PO-matched invoice — the 3-way match rules apply at posting as always.
Yes. The guard retires the action only once a Purchase Invoice actually exists and is linked to the OCR record. Abandoning the pre-filled form leaves the record in Extracted with Create Invoice still available.
No. Whether auto-created or created from review, the result is always a Draft — periods, approvals, and every other posting gate stand between extraction and the ledger. The AI types; you decide.
The created invoice is an ordinary Purchase Invoice and stands on its own. But keep the source file attached: it's your audit evidence, and it's cross-linked to the invoice at creation precisely so reviewers can compare document and draft side by side.
Was this article helpful?