A Controlled Inbox-to-Rydoo Receipt Workflow

A Rydoo automation route crosses several systems, but each decision needs one owner. Treating the whole flow as an email rule makes it difficult to tell whether a failure belongs to inbox selection, sender identity, the configured environment, receipt processing, or card reconciliation.

Use this map as the operating contract. Expensent owns the upstream inbox work. The route owner chooses where approved messages go. Rydoo uses the sending address to accept the email into the user workflow, turns the submitted content into expenses, and runs its configured processing controls. Finance owns the exceptions and the final accounting decision.

Rydoo documents different receipt-email destinations for production and sandbox. The automation owner should store one intended environment per route, label it clearly, and make changing that destination an owned configuration change. Expensent routes to the destination the team configures; it does not infer which Rydoo environment should receive a message.

Environment testing, evidence, production promotion, and rollback are a separate operational job. Use the dedicated Rydoo sandbox-to-production runbook linked at the top and end of this guide for those steps. This article assumes the route owner has already selected and approved the destination.

Rydoo requires receipt and invoice emails to be sent from the email address associated with the Rydoo account. Its current secondary-email instructions let a user add another address in Personal settings by editing the expense settings section, choosing add email, and saving.

That sender relationship is the attribution control for an email route. Connect and route from a mailbox that belongs to the intended Rydoo user as the primary account email or an added secondary email. Do not assume that access to a shared finance inbox authorizes that address for every Rydoo user, and do not describe a secondary address as verified when Rydoo does not use that term in the documented setup.

If one person manages expenses for another, do not solve the ownership question by changing an email rule. Rydoo separately documents linked-account access for delegated expense work. Use Rydoo account controls or administrator guidance for delegation; Expensent does not assign a routed receipt to another Rydoo profile.

Rydoo documents three outcomes for forwarded email. With no attachment, it converts the email body into a receipt. With one JPEG, PDF, or PNG attachment, it uses that attachment as the receipt. With multiple attachments, it creates a separate expense for each attachment in the email.

Make that behavior part of the routing contract. A complete body receipt can use the body path. A single supported receipt file can use the attachment path. A message with several attachments should be routed only when separate Rydoo expenses are the intended result, or after the reviewer selects the receipt evidence that should continue.

These are email-forwarding behaviors. Do not import limits from Rydoo's separate additional-attachment or web-upload documentation into this path. Expensent can review and route supported documents, but Rydoo decides how the received email becomes an expense.

Rydoo's body-only behavior does not establish that Rydoo can sign in to a vendor portal or retrieve a file behind an account-specific link. Keep portal notifications in review until a person downloads the actual receipt or confirms that the message body itself is the receipt evidence to submit.

Use the same exception lane for messages whose accounting meaning is unclear: booking confirmations, credits, refunds, statements, delivery notices, card alerts, support threads, and emails with unrelated or repeated attachments. Expensent can surface these messages and keep them visible for review; it should not turn ambiguity into a Rydoo expense automatically.

The reviewer's output should be explicit: route the body, route selected supported attachment evidence, download and submit a document through the appropriate path, or take no action. Only the first two outcomes belong in the recurring inbox-to-Rydoo route.

Delivery to Rydoo is the end of Expensent's responsibility, not the end of the expense workflow. Rydoo documents creating expenses from receipt inputs and using OCR to extract date, merchant, amount, and currency. Its Processing status means the system is reading those fields; To be verified means required manual information remains; Unreadable means the receipt details could not be read.

AI Autofill may prefill country, tax rate, and category when enabled for the account, and Smart Audit behavior depends on configuration. Those are Rydoo capabilities and controls. Expensent does not populate Rydoo fields, resolve an unreadable result, clear a duplicate, or decide whether an expense is ready to submit.

Rydoo says that after a receipt is uploaded it automatically looks for a match to the corresponding corporate card feed. The feed itself depends on provider or card-company transaction data reaching Rydoo in the required format. A routed receipt therefore cannot guarantee that a transaction exists or that Rydoo will reconcile it automatically.

Rydoo documents non-match cases including different basic information such as amount, transactions older than two months, an incorrect payment method, and one transaction that needs to cover several expenses. Those cases belong in Rydoo's matching and reconciliation workflow, not in Expensent's routing logic.

Measure the two outcomes separately: first, whether the correct receipt reached the correct Rydoo user; second, whether Rydoo matched it to the intended transaction. Resending a correctly delivered receipt to solve a matching problem can create duplicate work.

Expensent rules use an email pattern plus a subject pattern and can be created from a reviewed message. That recurring authorization should answer one upstream question: may this recognizable inbox message be routed to the already approved Rydoo destination?

It should not answer Rydoo-side questions about user ownership, expense validity, policy, duplicates, OCR quality, payment method, transaction matching, approval, or reimbursement. Keep those controls in Rydoo and preserve the exception lane for any message that no longer matches the reviewed receipt shape.

A concise control record lets finance separate delivery from processing. Record the connected mailbox and intended Rydoo user, the approved environment and destination owner, the message shape authorized for routing, and the reviewer responsible for exceptions.

For each investigated item, preserve the source message identifier, sender, subject, selected receipt evidence, routing result, resulting Rydoo expense identifier when available, and whether card matching was expected. This is an operational recommendation, not a Rydoo product requirement.

Some teams do not need an upstream inbox layer. If users already send receipt evidence from recognized addresses, Rydoo mobile and web intake cover the relevant sources, and portal or ambiguous messages are rare, the native Rydoo workflow may be enough.

Expensent is useful when receipt evidence first needs to be found and reviewed across connected inboxes, when finance needs an explicit exception queue, or when approved email and subject patterns should route recurring receipt messages without depending on personal Gmail filters.

The durable division is hybrid: Expensent handles inbox discovery, review, and routing; Rydoo handles the resulting expense, OCR, configured audit controls, card matching, approvals, reimbursement states, exports, and policy.