Pleo Fetch vs Manual Forwarding: Choose the Right Intake Route

The first decision is whether the email contains a card receipt or a supplier invoice. Pleo documents Fetch and forward@fetch.pleo.io as receipt routes tied to a user and work email. It documents a different forwarding address, found inside Invoices, that can be shared with suppliers for invoice intake. Those destinations serve different downstream records and should not be treated as interchangeable.

Next decide who should own intake. Fetch makes the cardholder's connected mailbox the source. Manual forwarding keeps each choice with that user. Supplier-direct forwarding moves invoice delivery to AP and the supplier. A reviewed upstream workflow gives finance or operations a control point before anything is handed to Pleo.

Fetch fits a cardholder whose online receipts arrive in one work mailbox and who is comfortable authorizing Pleo to connect to it. Pleo says Fetch is currently limited to one work email address. It can attach a matched receipt to an expense; a possible but uncertain match can remain in the user's private Receipt Inbox for 30 days. Pleo separately says scanned receipts that fail to match are not stored.

The access scope is broader than forwarding one email because Pleo connects directly to the account and parses messages to identify receipts. Pleo says explicit consent and provider authorization are required, and access can be revoked. It also says administrators can restrict Fetch through Microsoft Outlook or Google Workspace, so admin dependency varies by tenant rather than by a universal Gmail-versus-Outlook rule.

Fetch has one documented format advantage that matters to this decision: depending on how the receipt was sent, Pleo says Fetch can retrieve an attachment or convert the email body into a PDF. That makes it a stronger documented choice than manual forwarding when merchants regularly send receipt proof in the message body.

Pleo documents forward@fetch.pleo.io as a fallback for receipts sent from the work email linked to the user's Pleo account. This route avoids a Fetch mailbox connection and exposes only the message the user chooses to forward. It is a clear fit for an occasional missing receipt or for a user whose company does not permit Fetch.

Its main limitation is ownership, not speed. The cardholder must notice the email, send it from the recognized account, and confirm the result in Pleo. A shared mailbox, assistant, personal address, or supplier is outside the sender model described in Pleo's current receipt instructions unless Pleo gives that account different instructions.

Do not infer Fetch's body conversion behavior for this route. Pleo's Fetch privacy article describes converting an email body to PDF for Fetch, but the current official receipt-forwarding instructions do not provide the same separate guarantee for manual forwarding. If proof exists only in the body, test the exact message or use Fetch when its access model is acceptable.

Pleo's current supplier-invoice documentation says an organization can share the invoice-forwarding email address with suppliers and find that address inside Invoices. This is the documented supplier-direct path. It is separate from the user-linked Fetch receipt address and is relevant only when the company uses the applicable Pleo Invoices workflow.

Supplier-direct intake reduces mailbox access: Pleo receives what the supplier sends rather than connecting to an employee inbox. It also shifts maintenance to finance. Someone must own the destination, tell suppliers when it changes, distinguish invoices from statements or credit notes, and make sure the invoice enters the correct company workflow.

This choice is strongest for recurring suppliers that send a complete invoice document to a stable billing contact. It is a poor substitute for card-receipt capture, employee context, or messages that merely announce a document behind a supplier portal.

An upstream workflow fits when the main risk is deciding which inbox messages should reach Pleo. That can include shared operational inboxes, mixed supplier traffic, messages needing download or review, and teams that want finance rather than each cardholder to own the handoff. The tradeoff is another authorized service and another set of routing rules to govern.

Expensent is one such upstream option. It connects supported inboxes, identifies likely invoice and receipt emails, and lets a user route selected or rule-approved messages to a configured destination. Its rules use email and subject patterns. Expensent does not decide the final Pleo match, create the Pleo expense policy, approve spend, pay supplier invoices, sync accounting records, or replace Pleo's retention and compliance controls.

The privacy comparison should be made service by service. Fetch grants Pleo direct access to one work mailbox. Manual and supplier-direct forwarding expose selected messages. Reviewed routing grants the upstream provider access needed to classify and route mail, then sends chosen content onward. A team should compare those scopes and owners instead of labeling one route generically safer.

A cardholder with one permitted work mailbox should start with Fetch. A cardholder who forwards a receipt only occasionally should use the documented manual route. An AP owner receiving recurring supplier invoices should use the invoice address shown inside Pleo when that workflow is available. A finance or bookkeeping team that must select, review, and route messages across inboxes should evaluate a reviewed upstream workflow.

Hybrid ownership is valid. A company can use Fetch for employee card receipts, supplier-direct forwarding for Pleo invoices, manual forwarding for exceptions, and reviewed routing for inboxes that require centralized control. The routes solve different intake problems; the decision is not a contest to select one mechanism for every document.