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.
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 pipeline enforces this honestly rather than guessing: if the automated channel is ever asked to build an invoice from a non-invoice type, it stops with "Unsupported document type for invoice creation: {0}" (the placeholder names the offending type). The practical takeaway is simple — send vendor bills. Statements, expense receipts, and general correspondence have no automated path yet, so routing them in only consumes your monthly document allowance without producing anything.
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
AI plans meter document volume org-wide, per calendar month. There is nothing to set up: the first document of a new month opens the month's usage period automatically, and every document counts on arrival — from either channel, and whether or not an invoice is ultimately created from it. The limit comes from your plan's org-wide monthly document cap; plans without a cap never block.
You can watch the meter in the Admin Console's Subscription tab, where the Document Consumption card (shown on AI plans) reports "Used This Month", Remaining, and "Monthly Cap", with a "{0}% consumed" progress bar. When the cap is reached, intake stops with a single unambiguous message: "Monthly AI document processing limit has been reached. Please contact your administrator." The counters are system-maintained — manual edits to the usage figures are silently reverted, so the meter is always trustworthy. See AI Usage & Credits and the Subscription tab for the administrator's view.
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 API key is not configured. Please activate your REDA Financials AI license." | The org has no active AI licence. AI capability is included with the REDA Financials AI licence — an administrator activates the key in the Subscription tab. |
| "Monthly AI document processing limit has been reached. Please contact your administrator." | The org-wide monthly document cap is used up. Intake resumes next month, or your administrator reviews the plan. |
| "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.
Intake stops with "Monthly AI document processing limit has been reached. Please contact your administrator." — nothing degrades quietly, and nothing already extracted is affected. The Subscription tab's Document Consumption card shows how close you are before it happens; processing resumes when the new calendar month opens its period.
No. Scheduled automation runs under the platform's own automated-process identity, which is always treated as licensed — your purchased seats are for people. Document volume is what the AI plan meters, not the automation itself.
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?