Payhawk Receipts Not Matching: Fix the Mailbox Handoff

A Payhawk Mailbox problem can occur at several stages, and each stage has a different fix. Start with the source mailbox, the response thread, and Payhawk Inbox. Do not resend the message, edit the attachment, or change a working rule until you know whether the failure happened during delivery, security checks, document processing, paid-expense matching, or manual review.

The Sent folder proves that the source mailbox attempted an outbound message. It does not prove that Payhawk accepted it. A Payhawk error response proves the message reached the Mailbox but failed a stated check. A Pending request means Payhawk retained a document but did not finish the desired association. A success response means Payhawk processed a result, which still needs review for the correct entity, owner, document, and expense.

Recent independent reviews include complaints about invoice or receipt matching and upload friction. Those reports support treating the problem as a real user task, but they do not reveal Payhawk's internal matching logic. The recovery steps below come from current Payhawk help rather than from reviewer assumptions.

Open the Payhawk Group dashboard and check Settings > Mailbox. Confirm that the destination in the failed message exactly matches the company-generated address shown there. Do not copy a sample address from a help article or reconstruct the value from the company name. If the message went to paid@payhawk.me or unpaid@payhawk.me, confirm that the live account still supports that legacy employee workflow before sending another document.

Check the source address configured in Payhawk. The visible From label is not enough when the company uses aliases, forwarding services, distribution lists, or an email security gateway. Payhawk can reject a message when sender security checks fail. Ask the mail administrator which address and authentication results appear on the forwarded message.

If the Payhawk Mailbox was recently reconfigured, compare the current source and destination with the values stored in Expensent, Gmail, Outlook, and any shared mailbox runbook. A rule can keep sending to an old but plausible address after an administrator changes the supported workflow. Correct the authoritative destination first, then update each upstream system once.

Use one sender, one supported document, and one destination for the next test. Keep the subject simple and do not include a large signature with extra image attachments. The goal is to establish whether the minimum valid message passes before reintroducing aliases, forwarding chains, or vendor-specific filters.

Payhawk sends a response in the same email thread for each submitted document. Search the source mailbox for the original subject and expand the entire conversation. Conversation mode in Gmail or Outlook can hide the response under the sent message, so inspect the thread before concluding that no status was returned.

In Payhawk, open Inbox, add a filter, and select Request type > Mailbox requests. Compare the request timestamp with the source message. A success entry, Pending item, or error narrows the investigation more reliably than a general search across Expenses. Record the request identifier or destination link before making a change.

If Payhawk says the paid document matched, open the linked expense and compare the original receipt with the transaction. Confirm entity, cardholder or owner, supplier, date, amount, currency, and payment status. If Payhawk created a bill, verify the bill data and owner rather than treating the success response as payment approval.

If the response says the document was not matched, follow the link to Pending. Do not interpret Pending as a disappeared email. It is a work queue for a document that needs a person to select the correct entity and expense path. Processing the retained document is safer than sending another copy.

Payhawk's current error table lists failed DKIM and failed SPF as Mailbox rejection reasons. These checks belong to the sending domain and mail path. Changing the PDF will not fix them. Preserve the error message and ask the internal mail administrator to inspect the authentication results, domain records, forwarding behavior, and any gateway that rewrites the sender.

Payhawk recommends a direct-versus-rule comparison. Send a controlled document directly from the configured finance address to the Payhawk destination. Then send the same kind of document through the normal Gmail or Outlook forwarding rule. If direct delivery creates a Payhawk record but the rule path does not, the issue is in the forwarding configuration or authentication chain.

For Gmail, confirm that the Payhawk destination completed Google's forwarding-address verification and that the custom filter points to the whitelisted destination. Review the From, To, subject, and attachment conditions. Payhawk warns that a broad rule can forward body-only messages, so do not remove every condition merely to make the test fire.

For Outlook, Payhawk documents the Forward as attachment action. Confirm the rule is enabled, applies to the intended supplier messages, and uses the current generated destination. Some Microsoft 365 tenants restrict automatic external forwarding. If the rule never produces an outbound message, check the tenant policy with the administrator before changing Payhawk.

Match the error to the current Payhawk thresholds. More than 40 attachments causes the whole message to remain unprocessed. A combined attachment size above 20 MB or a single file of 10 MB or more also causes rejection. Split a large package into controlled messages or upload the documents through the Payhawk portal. Do not lower image quality until totals, dates, tax, and supplier details become unreadable.

The current Mailbox format list includes PDF, PNG, JPG, and JPEG, plus supported eInvoice formats with separate rules. Export an unsupported or corrupt document from its authoritative source into a supported format. Renaming a file extension does not convert the content. Password-protected files must be decrypted before submission, while the original secured source should be retained according to company policy.

An email signature can add small image attachments that increase the count or create extra document candidates. Simplify the test message and remove unrelated logos or inline files where the mail client allows it. Payhawk says the current Mailbox scans attachments and processes valid expense documents, but a clean test reduces ambiguity.

If the receipt is in the email body and there is no attachment, Payhawk can parse the body. Confirm that the body contains the actual receipt evidence. A portal link, order acknowledgment, or payment reminder is not equivalent to the invoice. Download the official document or use another supported Payhawk capture path when the evidence lives elsewhere.

Open the Pending Mailbox request and choose Attach to expense. Select the entity on whose behalf the expense occurred. Then either add the document as a new expense or attach it to an existing expense from the list. When creating a new item, choose the correct payment method, such as Reimbursement when an employee paid personally, and confirm the resulting record under All.

Before selecting an existing expense, compare entity, owner, transaction, supplier, amount, date, currency, and payment method with the original source. The current public Mailbox documentation does not publish a complete scoring formula for every matching decision. Do not change factual values merely to force a match. Correct OCR only when the source document proves the correction.

A document sent as an unpaid invoice may correctly create a bill instead of matching a card expense. Conversely, a paid document may require a card transaction that is not yet visible or is owned by someone else. Confirm the business state before deciding that matching failed. The desired outcome must reflect how the expense was actually paid.

Keep the source email linked in the investigation notes until the manual association is complete. If Expensent routed the message, its sent record can help confirm source mailbox, destination, and time. That evidence narrows the handoff, but only Payhawk can determine or change the downstream association.

When Payhawk attached a receipt or invoice to the wrong expense, first capture the current state. Record the source email, Mailbox response, incorrect expense, intended expense, entity, owner, supplier, amount, date, currency, and payment status. Verify that the target record is the real transaction, not merely another charge with the same amount.

In the Payhawk web portal, use Move to another expense on the document. Payhawk says the dialog can attach it to an existing expense or create a new one. Complete the move through the supported interface and inspect both records afterward. Do not delete the source document or resend the email as a substitute for correcting the existing association.

Repeated subscription charges, similar travel purchases, and several transactions at one supplier can produce plausible candidates. Use order references, receipt timestamps, cardholder details, location, currency, and final total to distinguish them. If the correct target is uncertain, leave the document visible and escalate rather than creating a clean-looking but false accounting record.

After the move, check whether a duplicate document or empty expense remains and follow the organization's normal Payhawk review policy. The document move solves attachment ownership; it does not automatically settle approval, coding, payment, or accounting sync. Confirm those states separately.

Payhawk processes multiple email attachments as separate documents instead of merging them automatically. A contractor message with one invoice and several receipts can therefore create several review items. This is expected behavior, not necessarily OCR failure. Identify which attachment is the accounting document and which files are supporting evidence.

Where appropriate, Payhawk recommends combining supporting documents into one PDF behind a summary invoice. Do this only when the resulting package accurately represents one expense line or bill and follows company policy. Keep distinct invoices separate even when the contractor sent them in one email. Document structure should follow the accounting event, not the convenience of one message.

Duplicates can also come from overlapping routes. A supplier may email the Payhawk Mailbox directly while Gmail, Outlook, and Expensent all forward the same source message. List every active route for the sender and choose one owner. Disable a redundant rule only after proving the retained path, then watch the next billing cycle for duplicate or missing results.

For historical catch-up, search Payhawk before forwarding older inbox documents. A receipt may already exist through mobile capture, web upload, a prior rule, or Agent Fetch. Route in small batches and reconcile each set. A large backlog send can multiply the same ambiguity that caused the first mismatch.

Escalate when the current destination and configured sender are correct, a supported document is within current limits, direct delivery passes authentication, and the retained Payhawk request still cannot be associated safely. Also escalate a repeated wrong match when the source evidence clearly identifies another existing expense and the supported move path does not resolve it.

Include the Payhawk group and entity, configured sending address, generated destination, send timestamp, subject, attachment names and sizes, Mailbox response, request identifier, Pending or success state, incorrect and expected expense identifiers, owner, supplier, amount, date, currency, and payment status. Include the direct-versus-rule test result when a forwarding rule is involved.

Redact unrelated personal, employee, bank, and card information before sharing outside approved support channels. Preserve the original source email and document. If the problem involves DKIM or SPF, have the mail administrator provide authentication results without exposing private message content more broadly than necessary.

Describe the expected result in one sentence, such as: “The configured finance address sent one 2 MB PDF to the current Payhawk Mailbox, Payhawk retained it in Pending, and the correct existing card expense is identifier X.” That is more useful than saying only that matching is broken. Until the case is resolved, avoid repeated sends, deletion, or speculative field edits.

Classify the cause after resolution. Destination causes include a stale generated address or legacy employee address. Sender causes include an unconfigured alias, failed DKIM, failed SPF, or restricted external forwarding. Document causes include size, count, format, encryption, or fragmented attachments. Association causes include the wrong entity, owner, payment state, target expense, or duplicate route.

Fix the narrowest control. Update the one stale destination, repair the one sender authentication path, split the one oversized supplier package, or tighten the one broad filter. Avoid rebuilding every route around a single exception. Keep a small runbook that names the source mailbox, Payhawk group destination, rule owner, expected document pattern, and fallback.

Monitor the first full billing cycle after the change. Count direct successes, Pending requests, sender errors, document errors, wrong matches, and duplicates. Sent-message volume is not the success metric. The useful measure is how many source documents reach the correct Payhawk record with a reviewable trail.

Recheck current Payhawk help when the Mailbox interface, address model, limits, or product modules change. The difference between older paid and unpaid addresses and the current group-level Mailbox shows why this review matters. Update stored destinations and public guidance only after the live account and current official documentation agree.