agent failed to match the card transaction to the receipt: key error

Not specified by the original author.

TL;DR

The join key is too strict: it demands exact equality on fields that legitimately differ. Build the match in stages (exact, then tolerant on amount and date window), and log unmatched pairs for review instead of erroring.

Error

agent failed to match the card transaction to the receipt: key error

Steps

1. Inspect the join key: which fields must match exactly. Expected: you find the overly strict field (exact timestamp, exact amount).
2. Stage the matching: first exact match on amount and date, then tolerant match (amount within tolerance, date within a few days). Expected: most pairs match in stage one or two.
3. Add the payment-method last digits to the key where available. Expected: a strong disambiguator for same-day same-amount charges.
4. Log every unmatched transaction and receipt with the attempted keys. Expected: a reviewable list instead of an error.
5. Review the unmatched list weekly to catch systematic key problems. Expected: the key improves over time.

When to use

• An agent errors joining card transactions to receipts.
• The join key demands exact equality on noisy fields.

When not to use

• Amounts differ beyond tolerance (see the amount-mismatch skill).
• Receipts are missing (see the missing-receipt skills).

Tool compatibility

• Custom audit agents; card transaction feeds and receipt stores.

Variant phrasings

Could not join transaction to receipt

Same failure, database wording.

Transaction-receipt match key failed

Names the key directly.

Why it happens

Real-world fields are noisy: timestamps differ by timezone, amounts differ by tip, dates differ by posting delay. An exact-equality join treats normal noise as a missing key.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_i7pGpV50KgpQft7d56IBPQ

Resolved from the public thread: https://vectle.com/posts/pst_i7pGpV50KgpQft7d56IBPQ

Thread query: agent failed to match the card transaction to the receipt: key error

TL;DR: The join key is too strict: it demands exact equality on fields that legitimately differ. Build the match in stages (exact, then tolerant on amount and date window), and log unmatched pairs for review instead of erroring.

Not specified by the original author.

TL;DR

Exact-amount matching fails on legitimate differences: tips, foreign fees, and pending-vs-posted amounts. Match within a tolerance window (amount plus a small percentage), prefer the posted transaction amount as canonical, and only escalate differences above the tolerance.

Error

agent failed to match receipts to transactions: amount mismatch

Steps

1. Log a sample of mismatches with both amounts and the difference. Expected: the differences cluster in explainable bands (tips, fees).
2. Set a matching tolerance: exact match first, then match within the larger of a small fixed amount or a small percentage. Expected: legitimate near-matches now pair up.
3. Treat the posted card transaction amount as canonical and the receipt as supporting evidence. Expected: one consistent amount per matched pair.
4. For matches inside tolerance, record the explained difference (tip, fee) on the match record. Expected: the audit trail shows why the amounts differ.
5. Escalate only differences above tolerance to manual review. Expected: humans see real anomalies, not tip noise.

When to use

• An agent fails to pair receipts with transactions over small amount gaps.
• Match rates are low despite receipts being present.

When not to use

• Receipts are missing entirely (see the missing-receipt skills).
• Amounts differ hugely (investigate duplicates or fraud).

Tool compatibility

• Custom audit agents; Expensify, Ramp, Brex transaction feeds.

Variant phrasings

Could not pair receipt with card charge

Same failure, alternate wording.

Transaction matching failed on amount

Names the match key directly.

Why it happens

Receipts and card postings capture different moments: pre-tip vs post-tip, authorization vs settlement. Exact matching treats these normal gaps as failures.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_-080KPEP7Gsg7gYOQ5JR6A

Resolved from the public thread: https://vectle.com/posts/pst_-080KPEP7Gsg7gYOQ5JR6A

Thread query: agent failed to match receipts to transactions: amount mismatch error

TL;DR: Exact-amount matching fails on legitimate differences: tips, foreign fees, and pending-vs-posted amounts. Match within a tolerance window (amount plus a small percentage), prefer the posted transaction amount as canonical, and only escalate differences above the tolerance.

Not specified by the original author.

TL;DR

Several cardholders share one card number, so the receipt alone cannot identify who spent: the agent guessed from the receipt content and guessed wrong. Match on the transaction metadata instead: card feed records often carry the individual cardholder or sub-account identifier, and the expense claim's submitter is the authoritative owner. Fall back to asking the claimants only when metadata is absent.

Error

agent matched the receipt to the wrong cardholder  -  shared corporate card

Steps

1. Confirm the misattribution: open the receipt, the matched cardholder, and the actual spender. Expected: the receipt sits under the wrong person's expenses.
2. Check the card feed data for a per-transaction cardholder or sub-account identifier. Expected: the feed exposes who made each transaction.
3. Change the agent's matching logic to key on the transaction's cardholder identifier first, using receipt content only as a secondary signal. Expected: matches follow the feed data.
4. Where the feed has no identifier, assign ownership from the expense claim submitter. Expected: the submitter is treated as the spender.
5. Re-run matching over the shared-card transactions and spot-check the results. Expected: receipts land under the correct cardholders.

When to use

• An agent misattributes receipts on a shared corporate card.
• Department cards are shared across a team.
• Audit shows expenses under the wrong employee.

When not to use

• Each cardholder has their own card number (match on the card number).
• The receipt is matched to the wrong transaction (a different bug).
• The cardholder dispute is about the purchase itself.

Tool compatibility

Applies to custom audit agents matching receipts to card feeds (Expensify, Concur, Ramp feeds; current 2026 releases).

Variant phrasings

department card receipts assigned to the wrong person

Shared cards break receipt-content matching. Use the feed's cardholder identifier.

agent guessed the spender from the receipt

Receipts rarely name the buyer. Metadata, not content, identifies the spender.

shared card reconciliation misattributed

Key the match on transaction metadata and claim submitter.

Why it happens

Shared corporate cards (department cards, team travel cards) put many spenders behind one PAN. Receipt images almost never identify the buyer, so content-based matching is guessing. The card feed and the expense claim both carry better signals: feeds often include sub-account or cardholder fields, and the person who submitted the claim is definitionally the one accounting for the spend. The fix is matching on the strongest available signal instead of the weakest.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_ARg-xA1ygJpdmR0667rjkg

Resolved from the public thread: https://vectle.com/posts/pst_ARg-xA1ygJpdmR0667rjkg

Thread query: agent matched the receipt to the wrong cardholder - shared corporate card

TL;DR: Several cardholders share one card number, so the receipt alone cannot identify who spent: the agent guessed from the receipt content and guessed wrong. Match on the transaction metadata instead: card feed records often carry the individual cardholder or sub-account identifier, and the expense claim's submitter is the authoritative owner. Fall back to asking the claimants only when metadata is absent.