How to Email Receipts to Monarch

The current Monarch receipt email address is receipts@my.monarch.com. Forward one receipt email to that address from a sender Monarch recognizes. No special subject line or message format is required. If the receipt information is in the body instead of a file, Monarch says it can generate a visual image of the email and import that as the receipt.

The important prerequisite is sender identity. The email on the Monarch account and the emails of household members are documented as already verified. A different work, shopping, or shared inbox must be added in Monarch receipt settings and verified before it can submit receipts reliably.

Use this guide for the complete setup and handoff into Monarch. If the message never appears in the Receipts tab, use the intake troubleshooting guide. If the receipt appears but is not attached to a transaction, skip directly to the matching troubleshooting guide.

Destination: receipts@my.monarch.com. Envelope: one forwarded email is treated as one receipt. Sender: use an already accepted address or complete Monarch sender verification. Expected result: a receipt appears in Monarch, then Monarch attempts to match it to a posted transaction.

For a sender outside the Monarch account or household, open Transactions, choose Receipts, open Settings, and select Add new email. Enter the address that will actually send the forwarded receipt. Monarch sends a verification message to that controlled inbox; return to Monarch and enter the six-digit code.

Monarch currently says the code expires after 24 hours and provides a Resend option. Multiple senders can be verified. This is useful when personal purchases, a work card, and a shared billing mailbox all produce receipts, but every connected sending mailbox must be represented accurately.

Sender verification is not the same as Gmail forwarding-destination verification. Monarch sends a code to the sender inbox you control. Gmail native automatic forwarding sends a link to the destination inbox, receipts@my.monarch.com, which you do not control. Completing one check does not complete the other.

Two less common identity issues deserve care. Monarch says an address added to a different Monarch account is reassigned to the most recently added account, with notice to the prior member. Apple Hide My Email users should verify the actual Apple email address used to forward, rather than the private-relay address shown elsewhere.

Verify the exact From address, not merely an alias you expect to be equivalent. Use Resend if the current Monarch code has expired. Send a single test only after Monarch shows the sender as verified. Recheck household or account ownership if receipts start appearing in the wrong Monarch account.

Choose a recent email with one obvious receipt and a readable merchant, date, and total. Forward it from the verified mailbox to receipts@my.monarch.com. Leave the subject and body intact unless you have a specific reason to edit them. Monarch does not require a special subject, and preserving the original context gives its importer the best available evidence.

Do not use a bundled order digest or a message containing several unrelated receipt confirmations as the first test. Monarch treats one forwarded email as one receipt and does not split a bundle into several receipt records. If a vendor sends separate attachments for separate purchases, separate the workflow before the Monarch handoff.

Monarch says imports typically take a few minutes. That is an expectation, not a guarantee. Watch for an import notification, a match notification, an import-error notification, or an address-not-recognized response. Those outcomes tell you whether to troubleshoot intake or matching.

Start with one recent, readable receipt. Forward from the exact verified address. Wait for Monarch processing before resending. Confirm the receipt in Transactions > Receipts before testing automation.

Monarch's current native email-import list includes JPG, PNG, WEBP, HEIC, HEIF, and PDF. It documents a 10 MB limit for each attachment and a 30 MB total per email. It also accepts body-only receipt messages. These are Monarch ingress rules for a message that reaches its receipt importer.

Expensent currently supports PDF, JPG, and PNG attachments. A HEIC or WEBP file that Monarch can accept natively is not therefore guaranteed to pass through every Expensent path. Convert an unsupported source file or use Monarch's native upload method instead of assuming the destination's capabilities apply upstream.

Body-only evidence has a similar boundary. Monarch can render an email body as a receipt, while Expensent exposes body-as-proof as an optional visibility and new-rule preference. Enabling it shows detected body-proof items in Smart Scan and the Action Center and lets newly created rules allow body-only evidence; it does not change manual-forwarding eligibility or silently rewrite existing rules. Review body-only patterns carefully because a payment confirmation, order update, and true receipt can share similar text.

Size and clarity remain separate checks. A supported extension does not rescue an unreadable image, an encrypted document, or a message over the current limit. Preserve the original when possible and avoid adding unnecessary attachments, logos, or long email chains to the receipt envelope.

Monarch-native: JPG, PNG, WEBP, HEIC, HEIF, and PDF, subject to current limits. Expensent currently supports PDF, JPG, and PNG attachments. Body-only Monarch import and Expensent body-as-proof are different controls. Use smaller, clearer messages when diagnosing an import problem.

Once a receipt exists, Monarch attempts to match it using amount, date, and merchant information. The current Help Center says merchant name matching is case-sensitive. When the merchant matches, an eligible transaction date can fall from two days before through seven days after the receipt date. When the merchant differs, the transaction must be within one day.

Only posted transactions are eligible. A receipt can arrive correctly while the card or bank charge is still pending, leaving the receipt visibly unmatched. Monarch says it keeps retrying as new transactions post. Waiting is usually safer than creating a manual transaction immediately, because a second bank-fed transaction can later create a duplicate.

If the expected transaction is already posted and the automatic attempt still fails, open the receipt and use Find match. Use Add transaction only when a transaction genuinely needs to be created and is not expected from a connected institution. The intake layer cannot force a downstream match or override Monarch's rules.

On a match, Monarch documents a Receipt Import tag, notes, and receipt imagery. The imported receipt does not overwrite the transaction amount. Treat “sent,” “imported,” and “matched” as three separate states in any operating checklist.

Sent: the mailbox accepted the outbound message. Imported: the receipt appears in Monarch's Receipts tab. Matched: Monarch attached it to an eligible posted transaction. Reviewed: a person confirmed the downstream result is correct.

Receipt matching does more than store an image, so review the result before treating the workflow as complete. Monarch says a receipt with one extracted category adds a note but does not replace the transaction's existing category. When a receipt contains multiple categories and Autosplit is enabled, Monarch can split and update categories.

Monarch currently describes taxes as distributed proportionally across split items and delivery or other fees as distributed evenly. Those are downstream Monarch choices, not decisions made by Expensent. Confirm that the resulting category and split structure matches your own budgeting or accounting intent.

Refund line items are a current limitation: Monarch says they are not extracted. Do not infer from that statement that every refund document fails to import. It means line-item extraction can omit the refund component, so a receipt containing returns, exchanges, discounts, or mixed positive and negative lines needs human review.

Deleting a receipt and deleting a transaction are independent in Monarch. That can be useful when correcting a bad import, but it also means deleting one record does not automatically clean up the other. Keep the original email until you have confirmed the Monarch result.

Manual forwarding is the simplest supported choice for low volume. It avoids Gmail's automatic-forwarding destination setup: open the receipt, forward it to Monarch, and make sure the From address is already accepted by Monarch. The tradeoff is repeated inbox work and no historical catch-up beyond what you search manually.

Gmail's native automatic forwarding is blocked when Google asks the destination to open its verification link. Users cannot normally access Monarch's shared ingestion mailbox, and Monarch publicly confirmed this as a known limitation without giving a resolution timeline. Avoid relying on an unverified Workspace or Apps Script workaround.

Expensent uses a different sending path. It connects to the user's Gmail or Outlook mailbox with OAuth, finds likely receipt emails, presents them for review, and sends selected messages from the connected mailbox to the configured Monarch destination. Because this is an authorized outbound message, it does not configure Gmail's forwarding destination. It is not a verification bypass, and the sending mailbox still must be accepted in Monarch.

For recurring mail, Expensent rules use an email pattern and subject pattern. Start from a reviewed receipt, keep ambiguous marketplace or portal messages in review, and test the Monarch result before expanding the rule. Historical scanning can surface older receipts that Gmail filters would not process because Gmail filter forwarding applies only to new arrivals.

Low volume: manually forward after verifying the sender in Monarch. Email-heavy workflow: review and route with a connected mailbox. Repeat patterns: add a bounded sender-plus-subject rule after a successful test. Historical catch-up: scan older inbox mail, review it, and send smaller batches.

First ask whether the receipt appears in Transactions > Receipts. If it does not, the problem is intake: check the exact destination, sender verification, processing notifications, attachment clarity and size, spam handling, and batch volume. Do not investigate merchant windows or pending charges until the receipt exists.

If the receipt appears but is not attached to a transaction, intake succeeded. Check whether the charge is posted, then compare amount, receipt date, transaction date, and case-sensitive merchant text. Let Monarch retry after a pending charge posts or use Find match for an already-posted transaction.

If the receipt matches but the categories or split are unexpected, review Autosplit, the extracted line items, tax and fee allocation, and the refund limitation. That is a result-review question, not a delivery failure.

For catch-up, send smaller batches and wait for processing rather than resending the same message. Duplicate sends can create duplicate receipt records and make the matching problem harder to interpret.