Pleo Receipt Workflow Without Fetch Mailbox Access

If your company cannot or chooses not to grant Pleo Fetch access to employee mailboxes, the replacement is not one finance-owned forwarding rule. It is a controlled handoff that preserves the relationship between the receipt, the cardholder, and the work email linked to that person's Pleo account.

Pleo currently documents forward@fetch.pleo.io for receipts sent from the work email linked to the user's Pleo account. That sender requirement makes ownership part of the architecture. An upstream reviewer can decide whether a message contains usable receipt evidence, but the approved message should leave through the linked user's work email and the user should own the resulting Pleo task.

This page assumes mailbox access is already off the table. For connection diagnosis, use the Fetch troubleshooting guide. For choosing between native capture and forwarding, use the comparison. The workflow here begins with the no-access constraint and defines how a team operates within it.

Maintain a small ownership register with the Pleo user, the work email linked to that account, the inbox where their receipts arrive, and the person allowed to clear their exceptions. This prevents a shared mailbox, alias, or delegated reviewer from silently changing the sender relationship Pleo documents.

When a receipt arrives outside the linked mailbox, do not hide that mismatch inside a broad rule. Assign the message to the cardholder, move the evidence through an approved company process, and send it from the linked work email. If the company cannot produce that sender relationship, leave the item as an ownership exception and use Pleo's direct receipt-addition path instead of claiming the email fallback is valid.

Expensent can support the upstream decision by surfacing likely receipt emails and routing selected or rule-approved messages toward a configured destination. The configured sending connection still needs to correspond to the Pleo user your control register expects.

The upstream gate should answer two questions: is this usable expense evidence, and is it ready to travel through the correct user-owned path? A receipt or invoice attached to the original merchant message can pass after the reviewer confirms the intended cardholder and transaction context. Confirmations, delivery updates, account alerts, and payment-failure notices should not pass merely because they contain receipt-like language.

Body-only messages require a separate decision. Pleo's privacy article says Fetch may convert an email body into a PDF, but that statement does not establish identical behavior for manual forwarding. Preserve the original message, test the result in Pleo, and keep the pattern under review unless the evidence arrives intact and can be associated correctly.

A portal notice is not the receipt. Route it to an approved person to retrieve the evidence, then use Pleo's documented upload or user-owned forwarding path. Refunds, credit notes, split shipments, and multi-transaction threads also remain exceptions until the reviewer can identify the intended Pleo expense.

Use one queue with a reason, owner, required action, and Pleo outcome. Do not collapse email-selection problems and Pleo-matching problems into a generic “needs review” state. The reason should tell the assignee what must happen next.

For each item, record the merchant, message date, expected Pleo user, linked sending email, evidence location, suspected expense date and amount, exception reason, assignee, due date, and resolution. Record the final Pleo expense reference when the receipt is attached. Those fields let finance distinguish an unreviewed email from evidence that was sent correctly but still awaits the user's Pleo association.

Close an upstream exception only after the approved evidence has been sent from the linked work email or added directly to the intended Pleo expense. Close a Pleo-side exception only after the user confirms the attachment, resolves Receipt Inbox, or records the company-approved missing-receipt outcome.

An email marked sent is not a completed receipt control. Pleo may associate the evidence with an expense, or the item may require user action in Receipt Inbox. Pleo says Receipt Inbox is private to the user and that finance can see the receipt after the user manually attaches it to an expense.

The Pleo user should compare the intended expense with the receipt evidence and confirm the attachment. Where the result is uncertain, the user should resolve Receipt Inbox or add the receipt directly to the expense. Pleo's current receipt guidance also tells users to review key details when adding a receipt and correct them when needed.

Finance should monitor completion rather than perform invisible matching on the cardholder's behalf. A useful control report shows sent items awaiting Pleo confirmation, Receipt Inbox items awaiting user action, direct uploads completed, and missing-receipt cases still open.

Expensent rules use an email pattern and a subject pattern. In this fallback model, a rule is acceptable only when reviewed examples share the same Pleo owner, linked sending connection, evidence shape, and transaction meaning. Stable sender text alone is not enough.

Keep the rule narrow enough that portal notices, credits, refunds, and account messages remain visible. Body-only evidence should remain manual until your team has confirmed that the forwarded result preserves usable proof in Pleo. A rule should route a known receipt pattern; it should not decide which employee owns an ambiguous charge or which Pleo expense receives it.

The final association remains in Pleo even when upstream routing is automated. That separation lets finance automate repetitive evidence handoffs without transferring cardholder responsibility to an opaque mailbox rule.

Document these controls as operating evidence, not as informal team knowledge. The checklist should be reviewable by finance and usable by the cardholder who receives the Pleo task.