OCR Inbox & Document Queue
Every document the AI touches gets an OCR Inbox record — the tracking slip that carries the file, the extraction, the status, and eventually the link to the invoice it became. The OCR Inbox tab is AP's morning queue: what came in, what's ready for review, what needs help.
Access you'll need. Creating and working OCR items 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.
Where the queue lives
The OCR Inbox tab is a regular tab with list views, and every record in it is auto-numbered OCR # (you never name these records; the system does). One record represents exactly one document: an email carrying three PDF attachments produces three separate OCR # records, each with its own file, its own status, and eventually its own invoice.
How a record arrives determines where it starts:
| Arrival route | Operation Type | Starting status |
|---|---|---|
| A vendor bill forwarded to the intake email address (see Email-to-Invoice) | Automation | Pending — the record waits for the next cycle of the processing loop |
| A file uploaded on the New Purchase Invoice form (see OCR Overview) | Manual | Processing — extraction runs immediately while you watch the form fill in |
Every record also carries a Document Type. Today that is Purchase Invoice — the field's own description notes it "Currently supports Purchase Invoice; Bank Statement and Expense Receipt reserved for future phases", so treat the other picklist values as placeholders, not features.
The lifecycle, by status
| Status | Meaning | Who acts |
|---|---|---|
| Pending | Received (usually via email), waiting for the processing loop | Nobody — the batch picks it up |
| Processing / Extracting | AI at work — first read done, full extraction underway | Nobody |
| Extracted | Data ready; confidence below the auto-create bar → awaiting a human | AP reviews via Create Invoice |
| Created | A draft Purchase Invoice exists, linked on the record | Normal AP flow takes over |
| Error | Something failed; the Error Message field says what | Fix the cause, Reprocess |
| Reviewed / Rejected | Bookkeeping marks for human-verified and discarded items | Your team's convention |
The full journey, in order, is Pending → Processing → Extracting → Extracted → Created, with Error, Reviewed, and Rejected as the exits along the way. The two routes join the road at different points: email-received documents travel Pending → Extracting → Extracted → Created on the processing loop, while manual uploads start straight at Processing because the extraction runs while you wait at the form.
The queue views
Five packaged list views make the tab a workflow: All OCR Items · Awaiting Review (the Extracted ones — your action list) · Errors · Pending Processing · This Month. Meridian's AP clerk lives in Awaiting Review and glances at Errors once a day.
Each view maps to one job:
| List view | What it shows | Use it for |
|---|---|---|
| REDA: All OCR Items | Every record, every status | Searching history, audits, "did that bill ever arrive?" |
| REDA: Awaiting Review | Status = Extracted | The daily action list — data is ready, a human decision is wanted |
| REDA: Errors | Status = Error | Triage and Reprocess |
| REDA: Pending Processing | Pending and Extracting | Watching the loop drain the queue; a growing list here means the loop is stopped |
| REDA: This Month | The current month's intake | Keeping an eye on volume against the monthly document allowance |
A Monday morning at Meridian
Meridian Properties Group's US entity receives its vendor bills by email, so the queue fills itself over the weekend. Priya on the AP team opens REDA: Awaiting Review first — everything there is extracted and waiting on a person:
| Record | What she sees | What she does |
|---|---|---|
| OCR #00000214 | A MetroPower utility bill; Vendor Match and Entity filled correctly, but the scan quality left the AI's confidence below the auto-create bar | Clicks Create Invoice, sanity-checks the pre-filled form, saves — the record flips to Created with the new invoice linked |
| OCR #00000215 | A bill from Skyline Elevator Services, a brand-new vendor — Vendor Match is empty because no matching account exists yet | Creates the vendor account first, then reprocesses so the match resolves before the invoice is created |
| OCR #00000216 | A tenant statement someone forwarded by mistake — extracted, but it isn't a bill Meridian owes | Marks it Rejected; the record stays as evidence of what arrived and was deliberately not processed |
Then a one-minute glance at REDA: Errors: one record failed with "AI service is temporarily rate-limited. Please try again in a few moments." — nothing on Meridian's side is wrong, so she reprocesses it after her coffee. Queue clear by 9:15.
Reading a record
- Where it came from: sender email, subject, the matched sender account, and the receiving address (email path) or the uploading user (manual path).
- What the AI concluded: the matched Vendor and Entity, the extraction result, and — after creation — the Purchase Invoice link.
- The document itself — attached as a file, one inbox record per document, so the paper trail from email to posted invoice is complete.
- Actions: Create Invoice and Reprocess — both available until an invoice exists, then politely refused ("A Purchase Invoice has already been created from this OCR Inbox record.").
Field reference
Everything below is on the record — no field here needs you to fill it in; the intake and the AI populate them, and the record then reads like a case file:
| Field | What it tells you |
|---|---|
| Status | Where the document is in the lifecycle (table above) |
| Operation Type | Automation (arrived by email) or Manual (uploaded on the invoice form) |
| Document Type | What kind of document this is — Purchase Invoice today |
| Entity | The company the bill was addressed to, as the AI matched it from the document |
| Sender Email | Who sent the email. On forwarded messages the AI looks for the original sender in the body and records that address instead — so a bill your colleague forwarded still traces back to the vendor |
| Sender Account | The account resolved from the sender's email address (via a matching contact) |
| Vendor Match | The vendor the AI matched from the document — this drives the invoice pre-fill |
| Email Subject / Email Body | The incoming email, preserved on the record |
| Receiving Email | The intake address the email was sent to |
| Source File | The filename of the document (the file itself is attached to the record) |
| Extraction Result | Everything the AI read from the document, stored for the invoice pre-fill |
| Error Message | The exact reason, when Status = Error — read it before reprocessing |
| Processed DateTime | When the full extraction finished |
| Purchase Invoice | The invoice created from this document. Once filled, the quick actions retire |
| Reviewed By | Who verified the record, for teams using the Reviewed status |
| AI Usage Period | The monthly metering period this document counted against — set automatically and locked |
The two quick actions
| Action | What it does | When it's blocked |
|---|---|---|
| Create Invoice | Opens the New Purchase Invoice form pre-filled from the extraction, ready for review and save | Toast titled "Action Not Available": "A Purchase Invoice has already been created from this OCR Inbox record." |
| Reprocess | Shows "Reprocessing document...", resets the record, re-runs the full extraction against the stored file, then opens the invoice form fresh | "Cannot reprocess — a Purchase Invoice has already been created from this record." |
The eligibility rule is one line: both actions live exactly as long as the record's Purchase Invoice field is empty. The moment an invoice exists, corrections belong on that draft invoice — not on the OCR record.
The engine behind the queue
Records don't move on their own — a processing loop moves them. On the Admin Console's Operations tab, the card "OCR Document Processing" describes itself plainly: "Automatically processes incoming documents through AI extraction and creates purchase invoices. Runs every 15 minutes when active." Unlike the other scheduler cards it has no daily run time — it is a Start/Stop loop that re-runs itself every 15 minutes while active, working the queue oldest-first, one document at a time. A document that fails simply gets marked Error with the reason, and the loop carries on with the next one — one bad scan never jams the queue.
The card's Document Queue counters — Pending / Extracting / Errors — are the queue's dashboard-at-a-distance: your admin can see work waiting and failures accumulating without ever opening the OCR Inbox tab. There is also a Run Now button for a single immediate cycle, and stopping the loop is safe: "Stop the OCR processing loop. Pending documents will remain in the queue until processing is restarted." — nothing is lost, the queue just waits.
Structured e-invoice XML
Not every vendor invoice is a PDF a machine has to read. A growing number arrive as a structured e-invoice XML — a file where each figure (the total, the tax, each line) is a labelled data field rather than ink on a page. When that file is present, guessing from a picture is the wrong tool: the data is already exact.
The Inbox now looks at every attachment on the intake record. If it finds a structured e-invoice XML, it treats that XML as the authoritative source for the invoice's data — more reliable than reading the PDF, because there is nothing to interpret. The PDF stays as the human-readable copy you and your auditors look at; the XML just feeds the numbers.
Common mistakes to avoid
| Mistake | Why it hurts | Do this instead |
|---|---|---|
| Waiting for Pending records to move while the loop is stopped | Nothing processes itself — the queue grows silently and vendors start chasing | Check the "OCR Document Processing" card on the Operations tab; press Start (or ask your admin to) |
| Working the queue from All OCR Items | You wade through Created, Rejected, and in-flight records to find the three that need you | Awaiting Review is exactly the Extracted set — your action list, nothing else |
| Deleting junk or failed records | You erase the paper trail of what arrived and why it wasn't processed — and the month's document count no longer matches the records that explain it | Mark them Rejected and move on |
| Lowering the OCR Auto-Create Threshold to shrink the review queue | Low-confidence extractions become draft invoices unreviewed — errors move downstream into AP instead of staying visible in the queue | Keep the review bar meaningful; the Awaiting Review view exists so doubtful reads get human eyes |
| Ignoring the Errors counter for weeks | Most errors are one-click retries when fresh; stale ones become archaeology, and real bills sit unpaid | Glance at REDA: Errors (or the card's Errors counter) daily — see Reprocessing Failed Extractions |
Where to go next
- Creating an Invoice from OCR — working the Awaiting Review queue.
- Reprocessing Failed Extractions — the Errors view's remedy.
- Operations Scheduler — the 15-minute loop that drives Pending → Extracted.
Frequently asked questions
The processing loop isn't running. It's a start/stop loop on the Admin Console's Operations tab ("OCR Document Processing") — ask your admin to press Start; the queue then drains on the 15-minute cycle.
Accounts Payable and Accounting Admins create and work OCR items (it's an AP tool); controllers and other roles can view. The email channel and the batch run as system contexts — no user seat consumed.
Mark them Rejected and keep them — the record is your evidence of what arrived and was deliberately not processed. It also keeps the meter honest: the document was consumed when it was read.
Its extraction confidence met the territory's OCR Auto-Create Threshold (default 80%), so a draft Purchase Invoice was created automatically and the record went straight to Created. The invoice is still a draft — review it there before posting.
How the document arrived. Automation means it came through the intake email address and was worked by the processing loop; Manual means someone uploaded it directly on the New Purchase Invoice form and the extraction ran on the spot. Handy for filtering when you're investigating one channel.
That's deliberate. When an email is a forward, the AI reads the message body to find the original sender and records that address instead — so a vendor bill your colleague passed along still identifies the vendor, and the sender-to-account match can resolve correctly.
No. The link on each OCR record is set once and locked, and the usage period's Documents Used and Documents Limit are system-maintained — manual edits are quietly reverted. The meter's integrity is the point: it must reflect what was actually processed.
Was this article helpful?