How email processing works

How email processing works

Every email that reaches Seller Oracle runs through the same pipeline, whether it came from a connected Gmail account, a connected Outlook account, or one of your forwarding addresses. The source does not change how an email is read. The same classification, extraction, and review checks apply to all of them, so an order forwarded from Outlook is handled exactly like one polled from Gmail.

An email arrives, gets classified, has the relevant data extracted, and then creates or updates an order or expense.

Stage one: classification

First, Seller Oracle reads the email and decides what kind of email it is. It works from the subject, the sender, and the body, and it handles forwarded emails by reading the original message inside the forward rather than the forwarding wrapper.

The result is one of a fixed set of types: order confirmation, dispatch, delivery, cancellation, returns, expense, payment verification (and its confirmation), customer service, personal, or irrelevant. For the full list and what each one does, see email types.

Emails classified as personal or irrelevant are skipped. Nothing is created from them, and they are marked Skipped in the email log.

Stage two: extraction

For emails that carry purchase data, Seller Oracle extracts the structured fields it needs: the order reference, retailer name, item names, quantities, unit prices, the order total, the currency, dates, and tracking or carrier details where present. For expense emails it pulls the vendor, amount, currency, payment date, and invoice number.

This extracted data is what gets written to an order or an expense. It is not a copy of the email; it is the figures and facts read out of it.

Attachments are read too

If an email carries a PDF (an invoice or receipt attached to the message), Seller Oracle extracts the text from that PDF. For order confirmation and expense emails, the attachment text is used during both classification and extraction, which is why a forwarded email whose body is just "see attached" can still produce a full order. For dispatch, delivery, cancellation, and returns emails, the attachment text is used during classification only. The attachment content is read up to the first five pages.

What happens after extraction

Once the data is out, Seller Oracle decides what to do with it based on the email type:

• Order confirmation creates a new order, normally with the status Ordered.
• Dispatch finds the matching order and moves its items to Dispatched.
• Delivery moves the matching order's items to Delivered.
• Cancellation sets the matching order to Cancelled.
• Returns records the return or refund against the matching order.
• Expense creates an expense record rather than an order.

Dispatch, delivery, cancellation, and returns emails update an order that already exists. They never create one. If Seller Oracle cannot find a matching order for one of these updates, the email is flagged for review instead, so a stray dispatch notice never invents an order out of nothing. Status updates never downgrade an order either, so a late notification cannot pull a delivered order back to dispatched.

For what each order status means and how it gets set, see the order statuses reference.

When an email is held for review

Seller Oracle does not silently trust everything it reads. Two kinds of check can hold an email or its order back for you to look at.

The first happens during processing. If an update email (dispatch, delivery, cancellation, or returns) cannot be matched to an order, or if extraction on one of those emails fails, the email is marked Needs Review in the email log. You open it, check what happened, and either reclassify it or dismiss it. Order confirmation and expense emails that fail extraction are marked Failed instead; you can reprocess them from the email log.

The second happens to the order itself, after it has been created. Seller Oracle runs deterministic checks on the extracted figures and flags the order for review when something looks off: the item lines do not add up to the order total, a EUR amount looks like it might be in cents and was not divided by 100, or the AI's confidence in the extraction was low. The order is still created, but it carries a review flag so a wrong number is never left sitting silently in your records. This is covered in full in Accuracy and review.

When processing is deferred

Sometimes an email is set aside rather than processed straight away. This is normal and the email is not lost.

Seller Oracle meters what it spends on AI. If a daily spending cap has been reached, an email is marked Deferred before any AI call is made, so it never spends against an exhausted budget. A background job re-drives deferred emails automatically once the budget frees up. An email can also be deferred if your account's trial has lapsed; it is picked up automatically once the account is reactivated.

You do not need to do anything with a deferred email. It will be processed on its own. For the meaning of every state an email can be in, see email process statuses.

The flow, end to end

1. An email arrives from Gmail, Outlook, or a forwarding address.
2. It is classified into one type.
3. If it is personal or irrelevant, it is skipped and nothing else happens.
4. Otherwise the relevant data, including any PDF attachment text, is extracted.
5. An order or expense is created or updated, or the email is flagged for review if it cannot be matched or read.
6. The figures are checked, and the order is flagged for review if anything looks inconsistent.

Every email that has run through this is visible in the email log, where you can see how it was classified, what was extracted, and reprocess it if needed.