OCR Overview
Vendor bills arrive as PDFs, and someone has to type them. Or not: REDA Financials' OCR invoice processing reads the document with AI and produces a draft Purchase Invoice — vendor matched, lines extracted, GL accounts suggested from your own history. You review and post. This overview maps the whole capability; the sibling articles go deep on each piece.
Access you'll need. Working OCR documents — uploading, reviewing, 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 OCR items but not act on them.
Current main release: 1.62000
OCR and configurable prompts. Multi-attachment/XML extraction work, active ordered prompts and clearer party-exemption handling. Add three missing AI Prompt document types where necessary. Review preserved subscriber prompt text against the supplied defaults; keep customer customisations.
Release notes and cumulative changes · Detailed installation and upgrade steps
Two ways a document arrives
| Channel | How it works | Best for |
|---|---|---|
| Upload on the invoice form | The New Purchase Invoice form's Document Upload card takes a PDF, JPG or PNG; a few seconds later the form is pre-filled from the document | The bill in front of you right now |
| Vendors (or your AP mailbox rules) forward bills to a dedicated address; each PDF becomes a queued OCR Inbox item, processed automatically every 15 minutes | Volume — the standing pipeline |
What documents can it read?
Every document that enters the pipeline — by email or by upload — carries a Document Type classification. The intake record offers four types, but only one travels the full pipeline today:
| Document Type | Status today |
|---|---|
| Purchase Invoice (the default) | Fully live — reading, vendor matching, line extraction, draft invoice creation |
| Expense Receipt | Reserved for a future phase — the classification exists, but no extraction runs for it yet |
| Bank Statement | Reserved for a future phase |
| Other | A holding classification only — no processing |
The automatic invoice-creation route is for vendor invoices. A document type used for statement extraction or another purpose is not automatically a purchase-invoice workflow. Choose the intended route and review the extracted result; do not assume that adding a Document Type option creates a new end-to-end business process.
What the AI actually does
Phase 1 — Read and identify
A quick pass answers: is this an invoice at all (non-invoices are politely refused — "The uploaded document does not appear to be an invoice."), who sent it, to which of your entities, invoice number, dates, currency, totals, any PO reference. The vendor and entity are then matched against your real records — tolerant of naming variations.
Phase 2 — Extract with your context
The full extraction runs with the vendor's history injected: their last posted orders and invoices, and the product-to-GL choices your team made before. That's why a MetroPower bill comes back coded to Utilities — the AI learned it from you, not from guessing. A detected PO reference is matched to the real purchase order.
Draft, then human
On the form path the fields simply pre-fill for you. On the email path, high-confidence extractions auto-create the draft PI; anything under your confidence bar waits in the Awaiting Review queue for a person (Creating an Invoice from OCR). Every created invoice is an ordinary Draft — the AI never posts.
The upload path, watched from the user's chair
Here is what the form channel looks like in real time. Dana, an AP accountant at Meridian Properties Group's US entity, has MetroPower's June electricity bill — a two-page PDF for $4,180.00 — saved from her email. She opens a New Purchase Invoice and finds the Document Upload card at the top of the form, which introduces itself plainly: "Upload a document (PDF, JPG, PNG) to automatically extract invoice details using AI." She drops the PDF in. An overlay appears — "Processing document with AI... This may take a few seconds." — and narrates five visible stages:
"Uploading document..."
The file lands and an intake record is created in the OCR Inbox behind the scenes, so the document is tracked from the first second.
"Reading document..."
The quick first read: is this an invoice, who sent it, to which company, what number, what dates, what totals.
"Identifying vendor & matching history..."
MetroPower's name on the bill is matched to Meridian's real vendor account, and that vendor's recent posted orders and invoices are gathered as context.
"Completing extraction with vendor context..."
The full line-by-line extraction runs, reusing the GL coding Meridian's team chose on previous MetroPower bills.
"Finalizing & pre-filling form..."
The invoice form fills itself in front of Dana, and the toast confirms: "Document processed successfully. Fields have been pre-filled from extraction."
Dana verifies the vendor, the invoice number, the $4,180.00 total, and the line coding against the PDF beside her, then saves. If anything had gone wrong instead, the overlay would have ended with "Document processing failed" and the reason. Two gates guard the front door of this path: the file picker accepts PDF, JPG, JPEG, and PNG only (anything else gets "Unsupported file type. Please upload a PDF, JPG, JPEG, or PNG file."), and a document that fails the is-it-an-invoice check after the first read is refused with "The uploaded document does not appear to be an invoice. Please upload a valid invoice document."
The three tuning knobs
- Auto-create threshold — the territory setting OCR Auto-Create Threshold (default 80%): extractions at or above it auto-create the draft; below it, humans review first. New implementations often start at 90+ and relax as trust builds.
- Extraction guidance — administrators can add territory-specific guidance records that steer the AI (country tax wording, local invoice conventions) without any code.
- Your field sets — fields your admin adds to the invoice's form field sets automatically join the extraction catalog: extend the form, and the AI starts filling the new field too.
Where a document can stand
Every document — either channel — lives on an OCR Inbox record with a status that tells you exactly where it is in the journey. The system's own definitions:
| Status | Meaning |
|---|---|
| Pending | Awaiting processing — queued for the next automated cycle |
| Processing | OCR running |
| Extracting | Initial extraction complete, awaiting full analysis |
| Extracted | Data extracted — this is the Awaiting Review state on the email path |
| Reviewed | Human-verified |
| Created | Invoice generated — the draft Purchase Invoice is linked to the record |
| Error | Processing failed — the reason is captured on the record |
| Rejected | Discarded |
The monthly document meter
Financials retains AI usage reporting. In 1.62000 the old custom document-cap enforcement is retired; provider billing, funding and service limits belong to your organisation’s provider account. Check the reporting period and the provider’s usage/billing view. See AI usage reporting and provider billing.
Financials retains AI usage reporting. In 1.62000 the old custom document-cap enforcement is retired; provider billing, funding and service limits belong to your organisation’s provider account. Check the reporting period and the provider’s usage/billing view. See AI usage reporting and provider billing.
When something goes wrong — the messages, verbatim
OCR failures are explicit: the document lands in Error status with the reason stored on the record, and on the upload path the message appears on screen. The ones you may meet:
| The message | What it means / what to do |
|---|---|
| AI connection or provider request failure | Read the actual failed operation or document error. Check the organisation’s Anthropic connection with Save and Test connection in Financial Admin Console → Connections, then check provider access/funding and the intended user’s permissions. Retry the affected document only after resolving its specific cause. Do not assume an old REDA monthly document cap or an expired activation key caused the failure. |
| AI connection or provider request failure | Read the actual failed operation or document error. Check the organisation’s Anthropic connection with Save and Test connection in Financial Admin Console → Connections, then check provider access/funding and the intended user’s permissions. Retry the affected document only after resolving its specific cause. Do not assume an old REDA monthly document cap or an expired activation key caused the failure. |
| "Unsupported file type. Please upload a PDF, JPG, JPEG, or PNG file." | The upload picker takes those four formats only. Convert or re-export the document. |
| "The uploaded document does not appear to be an invoice. Please upload a valid invoice document." | The first-pass check decided this isn't an invoice at all — a statement, a receipt, a contract. Only vendor bills travel the pipeline today. |
| "AI service is temporarily rate-limited. Please try again in a few moments." / "AI service is temporarily overloaded. Please try again shortly." | Transient conditions on the AI service — nothing is wrong with your document. Wait briefly and retry (emailed items are retried by reprocessing). |
| "AI service returned an empty response. Please try again." | The service replied without content — rare and transient; retry. |
| "The uploaded file could not be found. Please try uploading again." | The upload didn't stick (a dropped connection, usually). Upload the file again. |
Reading structured e-invoice XML
Alongside PDFs and images, the intake now reads structured e-invoice XML when a vendor supplies one. Because an XML states each figure as labelled data rather than as a picture to interpret, REDA treats it as the authoritative source and skips the guesswork — the PDF remains as the readable copy. With no XML, or an unreadable one, it falls back to reading the document exactly as before. Full detail is in the OCR Inbox guide.
Common mistakes to avoid
| Mistake | Why it hurts | Do this instead |
|---|---|---|
| Scanning several bills into one PDF | One document produces one extraction and one draft invoice — the second and third bills in the file are lost in the noise | One bill per file; on email, one email can carry many PDFs and each becomes its own item |
| Waiting for the email path to "auto-create everything" | The confidence threshold deliberately routes uncertain extractions to human review — an empty created-invoice list may just mean a full review queue | Work the Awaiting Review view daily; lower the threshold only as spot-checks stay clean |
| Treating extraction as posting | Nobody reviews, errors reach the ledger late, trust in the feature erodes | Every created invoice is a Draft on purpose — verify against the document before posting, like any invoice |
| Leaving the processing loop stopped | Emailed documents queue at Pending forever and vendors assume their bills were received and read | Start the OCR Document Processing loop once on the Operations tab; it re-schedules itself every 15 minutes |
| Feeding bills from vendors that don't exist as accounts yet | The vendor field comes back blank and there is no history to code lines from | Create the vendor account first (or immediately after, then Reprocess) — matching and history both start working |
Where to go next
- OCR Inbox & Document Queue — where documents live and what statuses mean.
- Email-to-Invoice Automation — the hands-free channel.
- Creating an Invoice from OCR — the review step.
Frequently asked questions
Headline fields (vendor, number, dates, totals) are strong on clean documents; line-level coding gets better with use because the vendor-history context grows. The threshold mechanism means accuracy you're not yet comfortable with simply routes to review instead of into your books.
Vendor bills → Purchase Invoices, today. (The intake object reserves types for future phases — treat anything beyond purchase invoices as roadmap, not feature.) Scanned images work on the upload path; email accepts PDFs.
Extraction calls REDA's AI service with the document and the minimal matching context described above; results and files are stored on your OCR Inbox records in Salesforce. No separate AI account is needed — the capability is included with the licence.
No — created invoices are always drafts, and the normal posting gates (periods, approvals, budget checks, your click) stand between extraction and the ledger. The AI types; you decide.
Read the actual failed operation or document error. Check the organisation’s Anthropic connection with Save and Test connection in Financial Admin Console → Connections, then check provider access/funding and the intended user’s permissions. Retry the affected document only after resolving its specific cause. Do not assume an old REDA monthly document cap or an expired activation key caused the failure.
Verify the actual execution user and access required for the scheduled job or integration in your organisation. Do not assume automation is universally exempt from native package licensing. A permission-set assignment and a package licence are separate checks.
Yes, on both knobs: the OCR Auto-Create Threshold is a territory setting, so Meridian's US territory can auto-create at 80% while the newly onboarded Brazil territory reviews everything at 95%; and administrators can add territory-specific extraction guidance records (local tax wording, invoice conventions) without code.
Was this article helpful?