Monarch Receipts Not Matching: Posted Status, Dates, and Fixes

This guide begins after the receipt appears in Transactions > Receipts. Its presence proves the sender and email intake path worked. Do not resend the same message to solve a match; another import can create a duplicate receipt record while the original remains unmatched.

The first matching check is transaction status. Monarch's current documentation says only posted transactions can match. A receipt may arrive minutes after purchase while the card charge remains pending for hours or days. In that state, an unmatched receipt is expected rather than evidence of failed import.

If the receipt is missing from the Receipts tab, return to intake troubleshooting. If it is present and the charge is posted, compare amount, date, and merchant, then let Monarch retry or use Find match.

Receipt absent: troubleshoot intake, not matching. Receipt present and transaction pending: wait for posting. Receipt present and transaction posted: compare matching inputs. Inputs plausible but still unmatched: use Find match or collect evidence for support.

Pending bank and card transactions can change date, merchant descriptor, or amount before posting. Monarch excludes them from receipt matching until that state settles. The receipt remains available while Monarch retries as new transactions post.

Do not use Add transaction simply to make the receipt appear complete when a connected account is expected to deliver the charge. Monarch warns that the bank-fed transaction can later arrive and create a duplicate. The safer sequence is wait for posting, allow automatic retry, then use Find match if necessary.

If a transaction stays pending unusually long, investigate the connected financial account or merchant rather than repeatedly sending the receipt. Expensent has no control over bank posting or Monarch's matching retry schedule.

Monarch matches using merchant, amount, and date. Its current Help Center says merchant name comparison is case-sensitive. Compare the extracted receipt merchant with the posted transaction descriptor exactly, including capitalization and the possibility that a processor or marketplace name replaced the storefront name.

When the merchant matches, Monarch currently allows the transaction date to fall from two days before through seven days after the receipt date. This accommodates authorization and posting differences. When the merchant differs, the transaction must be within one day of the receipt date.

The receipt amount should represent the posted transaction total. Tips, foreign-exchange changes, deposits, partial captures, gift cards, credits, split tenders, and later adjustments can make an otherwise related receipt look different. The imported receipt does not overwrite the transaction amount.

These matching windows and rules can change. Confirm Monarch's live documentation before relying on them in a recurring workflow or team troubleshooting checklist.

Use the dates Monarch is actually comparing. A merchant email timestamp, order date, ship date, receipt date, authorization date, and posted transaction date can all differ. Document the receipt date extracted by Monarch and the final posted date rather than assuming the day visible in the inbox subject is the matching input.

Merchant: compare exact text and capitalization. Amount: compare the posted total, not only the original authorization. Date with matching merchant: currently two days before through seven days after the receipt date. Date with different merchant: currently within one day.

Monarch says unmatched receipts continue retrying as new eligible transactions post. If the charge has just moved from pending to posted, give that process time before changing records. Check whether a match notification arrives and whether the expected transaction now carries the receipt.

For an already-posted transaction that remains unmatched, open the receipt and choose Find match. Search for the transaction, confirm the amount and date, and attach the receipt deliberately. Manual matching is the supported correction path when the automatic criteria do not connect an otherwise valid pair.

Use Add transaction only when the expense genuinely will not arrive from a connected account and a new manual record is intended. Document why the transaction was created so a later duplicate can be recognized and resolved.

After matching, Monarch says it adds Receipt Import context, notes, and receipt imagery. Confirm the resulting transaction rather than assuming a match notification proves every category and split is correct.

Resending an already imported receipt does not improve its merchant, amount, or date evidence. It creates another intake event and can leave several receipt records competing for the same posted transaction. Use the original receipt record for retry or manual matching.

Creating a manual transaction while a bank-fed charge is pending creates a different duplicate risk. When the real transaction posts, both records may remain. Wait unless there is a clear accounting reason to create the transaction now.

Track four states separately: sent from the mailbox, imported into Receipts, matched to a transaction, and reviewed by a person. A workflow that treats “sent” as complete hides both missing imports and bad matches.

Do not resend a receipt that already appears in Monarch. Do not create a transaction merely because the expected charge is pending. Use Find match on the existing receipt after the transaction posts. Review the final record before closing the exception.

A receipt can match successfully while its category remains unchanged. Monarch says a single-category receipt adds a note without replacing the transaction's existing category. That is expected behavior, not evidence that matching failed.

When Monarch extracts multiple categories and Autosplit is enabled, it can split and update the categories. Current documentation says taxes are distributed proportionally and delivery or other fees are distributed evenly. Review the result because the extracted line items and categories may not reflect your budgeting intent.

The transaction amount is not overwritten by receipt import. If the receipt total and transaction total differ, matching or manual review must address that difference; the imported document will not silently change the bank-fed amount.

Expensent does not control these results. Its role ends with upstream discovery, review, catch-up, and routing. Monarch performs parsing, matching, splitting, category handling, and notifications.

Monarch currently documents that refund line items are not extracted. A mixed purchase-and-return receipt can therefore produce an incomplete line-item picture even when the document imports. Review the receipt total, the posted charge or credit, and the extracted items before accepting a match or split.

A Monarch employee stated in a public community thread that already-split transactions are excluded from automatic receipt matching. This detail is not in the current Help Center, so treat it as a current community-channel observation rather than a permanent documented rule. Try Find match and contact Monarch support if the split transaction remains unavailable.

Do not generalize a single attachment or split complaint into universal behavior. Current official documentation says Monarch attaches receipt imagery on a match. When the visible result differs, capture the exact transaction state and receipt record for support.

Once the receipt is attached, confirm the merchant, date, amount, category, tags, notes, split lines, taxes, fees, and receipt image. Matching is a document association, not a substitute for financial review.

Monarch says deleting a receipt and deleting a transaction are independent. If you remove a bad receipt import, verify whether the transaction still exists; if you remove a transaction, verify whether the receipt remains. Keep the source email until the correction is complete.

If a posted transaction that meets the documented criteria cannot be selected through Find match, collect the receipt date and amount, exact merchant strings, transaction status, screenshots, and support timestamps. That evidence is more useful than sending the same receipt again.

When several posted transactions look plausible, do not choose one merely to clear the unmatched state. Compare the original email, payment method, final total, and transaction account, then leave the receipt unmatched until ownership is clear. A deliberate exception is safer than attaching evidence to the wrong charge.