Pleo Fetch Not Working? Isolate the Failed Receipt Layer

"Pleo Fetch is not working" can describe six different failures. The connection may be denied before Pleo can access the mailbox. Fetch may be connected to a different work email than the one receiving the receipt. A manual forward may leave from an unlinked sender. The document may reach Pleo without matching an expense. A possible match may wait in Receipt Inbox. Or the email may contain body-only or portal evidence that behaves differently from an attachment.

Choose one recent receipt and trace it in order. Record the merchant message, receiving mailbox, connected Pleo email, forwarding sender and destination if used, expected Pleo expense, and every visible error. Do not test several receipts at once: different messages can fail at different layers and produce a misleading result. Once you can prove the receipt crossed a layer, stop changing that layer and move to the next observable point.

Keep one concise evidence note with the expected result, actual result, last proven checkpoint, timestamp and timezone, and the relevant message, error, or screenshot. A missing item on the expense does not by itself distinguish failed collection from uncertain matching, so work through the symptom-specific checks below before escalating.

Pleo enables Fetch from My Account, Power-ups, then Fetch. Its current guidance says the user must connect an email account and grant the requested permissions. Pleo also says company administrators can restrict Fetch through Microsoft Outlook or Google Workspace because those restrictions are not managed inside Pleo.

Collect the exact provider screen or error code, the signed-in mailbox, the Pleo account email, the time of the attempt, and whether the failure affects one user or a company group. Ask IT whether the Pleo connection is allowed for that user and mailbox. Avoid claiming that one provider always requires admin approval: tenant policy determines whether the user can grant access.

Stop at this layer when the provider grants access and Pleo shows Fetch connected. If the provider denies consent, stop Pleo retries and escalate with the captured error to the email administrator. If access succeeds but the test receipt is still absent, continue to the mailbox-identity layer.

Pleo says Fetch is currently limited to one work email address. Confirm the connected address in Pleo, then open the original merchant message and confirm which mailbox actually received it. A personal address, old work address, group inbox, or alias can make the email visible to the employee while still placing it outside the connected mailbox.

Record the original To and Delivered-To values when available, the mailbox where the message can be opened, the connected Pleo address, the merchant sender, subject, timestamp, and Message-ID. Use one known receipt that is present in the connected mailbox as a control. This establishes whether the problem follows the mailbox or the individual message.

Stop at this layer when the original receipt is proved to exist in the mailbox currently connected to Fetch. If it arrived elsewhere, correct the connected mailbox or use a Pleo-supported manual path; matching changes cannot repair a mailbox mismatch. If the receipt is in the connected mailbox, move to collection-path diagnosis.

Treat Fetch collection and manual forwarding as separate tests. Pleo documents forward@fetch.pleo.io as a fallback for receipts sent from the work email linked to the Pleo account. A successful Fetch connection does not prove that a manual forward used the linked sender, and a sent email does not prove that Fetch collected the original merchant message.

For a manual-forward test, inspect the actual From address rather than the display name. Save the sent timestamp, destination, message subject, Message-ID, and any delivery or rejection notice. Aliases, shared mailboxes, delegated sending, and automated relay systems can produce a From address different from the user-facing account name.

Stop changing the email path once the message was sent from the linked work email to Pleo and there is no delivery rejection. Check the intended expense and Receipt Inbox next. If the sender is not the linked work email, stop: the test does not meet Pleo's documented forwarding condition.

Pleo says Fetch attaches a receipt when it matches the expense. Its privacy article identifies exact amount and currency, purchase date, and receipt or invoice wording as matching conditions. Compare those fields on the evidence with the expected Pleo expense; do not diagnose this stage from the merchant name alone.

Then check the user's private Receipt Inbox. Pleo says a receipt that could match an expense but remains uncertain can appear there, where only the user can view it until attaching it. Pleo documents automatic deletion after 30 days. Its privacy article also says scanned receipts that fail to match are not stored, so Receipt Inbox is not a complete log of every rejected candidate.

Stop all mailbox and forwarding changes when the receipt is visible on an expense or in Receipt Inbox. The remaining action is in Pleo: attach the Receipt Inbox item to the intended expense or upload the evidence directly. If neither location contains it, return only to the first collection layer for which evidence is missing.

Pleo says Fetch either retrieves an email attachment or converts the body of an email into a PDF, depending on how the receipt was sent. That supports a focused Fetch test for a body-only receipt: preserve the original message and check whether the rendered evidence appears in Pleo.

Do not apply that statement automatically to manual forwarding. The current official Fetch and forwarding guidance does not separately establish that forwarded body-only emails receive the same conversion. Also distinguish a receipt printed in the email body from a message that merely links to a receipt in a merchant portal; a portal notice may not contain the evidence Pleo needs.

Stop at this layer when an attachment works but the body-only control does not. Preserve a screenshot or PDF of the original body and use Pleo's direct receipt-addition path rather than repeatedly forwarding the same message. If both attachment and body-only examples fail, return to the earliest unproved connection or collection layer.

When the evidence is valid but Fetch or forwarding still does not place it correctly, finish the expense in Pleo. Pleo instructs users to open Expenses, select the expense, and upload a file from the device or take a photo in the mobile app. Review the merchant, date, amount, and required accounting details before saving.

If the receipt is genuinely unavailable, use the organisation's missing-receipt process in Pleo instead of treating another email retry as evidence. If direct addition fails, Pleo's troubleshooting guidance recommends trying the browser when the mobile app fails and contacting Pleo support with the device make, model, and installed app version if the problem persists.

When escalation is necessary, send the email administrator the provider-consent evidence and send Pleo support the Pleo-side reproduction, expense reference, device or browser details, and last proven collection checkpoint. Keeping those packets separate makes the responsible layer clear.

The investigation ends when the correct evidence is attached to the intended Pleo expense, the organisation records a missing-receipt outcome, or Pleo support receives a reproducible product failure. Keep the evidence record with the outcome so the same symptom can be classified quickly next time.