Ask any AP team what actually arrives in their shared mailbox and the honest answer is: everything. Real invoices, yes — but also monthly statements, order acknowledgements, sales orders, expense reimbursement requests, "just following up" emails, marketing, and outright spam. They all hit the same address, and the same person has to open each one and decide what it is.
That decision — what is this? — is the first real step of accounts payable, and it happens before extraction, before coding, before matching. Get it wrong at the door and the cost compounds: a statement processed as an invoice becomes a duplicate payment risk; a sales order pushed into the workflow becomes a phantom payable someone has to chase down and delete later. The cheapest place to deal with non-invoices is the moment they arrive.
Why this isn't "just OCR"
It's tempting to assume a capture engine handles this. It doesn't — and it isn't supposed to. OCR lifts text off a document; it doesn't decide whether the document belongs in your AP workflow at all. Point an extraction tool at a statement and it will happily extract a total, a date, and a "balance due," and hand you a clean-looking invoice that was never an invoice. The extraction was accurate. The triage was absent.
Triage is a classification problem, not an extraction problem. The question isn't "what does this document say?" — it's "what kind of thing is this, and where should it go?"
The categories that matter
A useful AP triage step reads the email and its attachment together and sorts each message into one of a handful of buckets:
- A genuine invoice — PO-backed or non-PO, this is the only thing that should enter the AP workflow. PO vs. non-PO routing happens downstream.
- A statement — a summary of open or recent items, not a demand for a specific new payment. Processing it as an invoice is a direct double-pay risk.
- A sales order or order acknowledgement — confirms what we ordered. It's not a bill and should never become a payable.
- A reimbursement or payment request — often belongs to a different process (expenses, one-off payment forms) and shouldn't ride the supplier-invoice rails.
- A duplicate — an invoice already in flight; it needs to be recognized as a copy, not entered again.
- A status enquiry — "did you get my invoice, when am I paid?" — which is a question to answer, not a document to process.
- Junk — marketing, spam, unrelated mail to discard.
The buckets aren't academic. Each one routes somewhere different, and the whole point is that only the first ever reaches the part of the system that creates a payable.
Reading the email and the attachment
The signal for correct triage lives in both places. The email body often says what the attachment is — "please find attached your statement," "following up on the below," "here's our order confirmation." The attachment carries the structural cues — a statement lists multiple documents and an aging balance; an invoice has a single invoice number, a bill-to, and line items; a sales order names our PO as the thing being fulfilled. Reading them together is far more reliable than reading either alone, which is exactly why a human is good at this and a naive single-document OCR pass is not.
It also matters who sent it. A message from a known supplier domain referencing an existing invoice is probably a status query or a duplicate; the same content from an internal address is a different conversation. Sender context shapes both the classification and, later, the wording of any reply.
Triage is the foundation, not a side feature
Every downstream automation gets more reliable when triage is solid. Duplicate detection only works if the thing is recognized as an invoice in the first place. Auto-replying to a status question — covered in automating "did you get my invoice?" replies from live Oracle status — depends on correctly identifying that the email was a status question and not a fresh invoice. The entire premise of supplier-email exception prevention is that you sort and resolve at the inbox, before anything becomes a workflow item or an exception sitting in someone's queue.
Skip triage and you don't avoid the work — you just move it downstream, where it's more expensive. A statement that slipped through as an invoice has to be caught at matching or, worse, after payment. A sales order in the workflow has to be hunted down and removed. Sorting at the door is the only place the cost is small.
Where EZ Cloud fits
EZ Cloud's AI email exception prevention layer reads each inbound message and its attachment, identifies what it is — invoice, statement, sales order, reimbursement, duplicate, status query, or junk — and routes it accordingly, before anything reaches the AP workflow. Only genuine invoices flow into capture, coding, and matching against Oracle EBS or Fusion; the rest are answered, redirected, or discarded automatically. The AP team stops being the inbox sorter, and the workflow stops filling with things that were never payable in the first place.