A Controlled Inbox-to-BILL Spend & Expense Receipt Workflow

Automating a Divvy receipt is not a promise that every receipt-like email should be forwarded. It is a controlled authorization to route one recognizable document pattern from one connected inbox to one destination that the BILL account has already approved. The automation decision happens before BILL receives the message.

BILL Spend & Expense owns the downstream result. Its current product pages describe card transactions, receipt capture, automatic matching, policies, approvals, reimbursements, and accounting workflows. Expensent does not determine which transaction a receipt belongs to, approve spend, create a reimbursement, or turn an invoice into an AP bill.

Start by naming the downstream record. A card receipt supports an existing BILL Divvy Card transaction. A reimbursement supports an employee claim for out-of-pocket spend. An AP document supports a supplier bill, approval, and payment process. The same merchant can send documents for more than one lane, so sender identity alone is not enough.

Current BILL pages place card receipt matching and reimbursements within Spend & Expense, but they remain distinct workflows. BILL AP separately captures, approves, and pays supplier bills. Route each document to the account-confirmed path for its intended record; do not send all financial mail to a generic Divvy destination.

Do not hard-code a legacy Divvy receipt address from memory, search results, or another company playbook. Use the destination displayed in the current BILL account or supplied by the company administrator or current BILL support instructions for the exact card, reimbursement, or AP workflow. The related branding and destination comparison explains why older Divvy names and current BILL paths cannot be treated as interchangeable.

Destination is only half of the test. BILL documents a Gmail receipt integration that searches a participating cardholder inbox after a card transaction clears, and admins choose which employees are included. That connected-mailbox boundary does not prove that an assistant, alias, shared mailbox, or forwarding service will be attributed to the same user. Preserve the original user context where the approved path requires it, and verify any alternate sending path in the live account.

Before creating a recurring rule, choose one clear receipt for one visible BILL Divvy Card transaction. Use the connected inbox and sender path that automation will use, route it to the account-verified card receipt destination, and record when it was sent. Then inspect the result in BILL.

The test has two separate outcomes. First, did the receipt arrive in the intended BILL workflow under the intended user? Second, did BILL match or attach it to the intended transaction? A successful delivery does not prove a successful match, and a matching problem does not necessarily mean the upstream route failed. Use the dedicated matching troubleshooting guide for the downstream diagnosis instead of changing routing rules blindly.

Expensent connects to the inbox where financial-document emails arrive, identifies likely receipts and invoices, and presents them by next action. A reviewer can route a clean card receipt to the verified destination, keep an ambiguous document visible, or direct an AP invoice toward the separately approved AP workflow.

That review layer must not erase mailbox ownership. Each connected inbox is a source boundary, not evidence that BILL accepts that mailbox for every cardholder. When finance reviews documents across several inboxes, preserve which inbox received the message and route only through a sender and destination combination the account has validated.

Create a recurring rule only from a reviewed message whose route has succeeded. Expensent rules use an email pattern plus a subject pattern, so the authorization can be narrower than every message from a merchant or domain. Keep the rule tied to the connected inbox, account-verified destination, and document lane used in the test.

A useful rule answers one upstream question: may this recognizable message be routed to this approved destination? It does not assert that the document is policy-compliant or that BILL will match it. Pause or revise the rule when the sender, subject, receipt shape, user, or destination changes.

A recurring rule should have a short operating record outside the email filter itself. Record the connected source inbox, actual sender pattern, subject pattern, document lane, approved destination, expected BILL user, and date of the successful test. That gives finance enough context to review the route when an employee changes roles, an inbox is reconnected, or BILL changes an account setting.

Also record the expected upstream outcome separately from the BILL outcome. The upstream outcome is that Expensent selected the intended message and sent it through the approved sender and destination path. The BILL outcome is that the platform recognized the receipt and handled it against the intended record. Keeping those fields separate prevents a match failure from being mislabeled as an inbox-routing failure.

Assign an owner for each route. The owner does not need to inspect every successful receipt, but should review exceptions and re-authorize the route when its assumptions change. This is particularly important for cardholder departures, delegated inboxes, shared finance mailboxes, entity changes, and merchants that revise their receipt subjects or attachment behavior.

A rule should return to review when its original evidence no longer applies. Stop it if the destination changes, the source mailbox is reconnected under a different user, the sender or subject pattern broadens, the merchant starts mixing document types, or receipts begin arriving under the wrong BILL user. A route that once worked is not permanent evidence for a changed account path.

Stop the route as well when the message no longer contains usable proof. Portal migrations, body redesigns, password-protected files, attachment bundles, and new refund or credit formats can turn a previously clean receipt pattern into an exception. Review one current example, confirm the document lane and user boundary again, and run a new controlled test before resuming the rule.

Some messages cannot be authorized from sender and subject alone. A portal notice may announce a receipt without containing the document. A body-only receipt may render differently after routing. A marketplace message may combine an order, split shipment, refund, or several attachments. An invoice-like document may belong to AP rather than the card transaction that prompted the search.

Keep these messages in Action Center review until a person obtains the usable document, identifies the cardholder and product lane, and chooses the approved destination. Do not infer universal support for body content, attachments, alternate senders, or file handling from one successful example; those details can vary by intake path and account configuration.