agent's card rec stalled because the statement grouped 30 ride-share charges into one summary line the matcher could...

TL;DR

The statement is not wrong and neither is the expense data. The card network settled thirty ride-share trips as one summary line while the expense system holds thirty individual rides, and a one-to-one matcher stalls on that shape forever. Get the itemised detail behind the summary line from the card platform's transaction portal or feed, where each ride still exists with its own amount and date. Then match as a group: the thirty book transactions against the one statement line, with the group total proven equal, and record the grouping explicitly in the rec so a reviewer sees one deliberate many-to-one match rather than a forced plug. Configure the matcher to propose grouped matches when a statement line equals the sum of same-merchant, same-period book items, with human approval for the group, because silent auto-grouping can hide genuinely missing charges inside a convenient total.

agent's card rec stalled because the statement grouped 30 ride-share charges into one summary line the matcher could not split

Use this when

• A card statement line aggregates many small same-merchant charges, such as ride-share, tolls or app purchases, into one summary amount.
• The book or expense side holds the individual charges and their total equals the summary line.
• The matcher supports only one-to-one matches and leaves both sides open.

Not for this skill when

• The summary total does not equal the sum of the individual charges. Investigate the difference first; grouping would bury it.
• No itemised source exists anywhere for the summary line. Request the detail from the card issuer before matching.

Steps

1. Open the summary line on the statement and retrieve the itemised transactions behind it from the card platform or issuer detail feed. Verify: the 30 underlying rides are listed with amounts and dates
2. Sum the itemised detail and the corresponding book-side expense transactions, and compare both with the summary line total. Verify: all three totals agree exactly, or the difference is isolated before any matching
3. Create the many-to-one match in the reconciliation, attaching the itemised detail as support for the grouped line. Verify: the group match is recorded with its evidence visible to a reviewer
4. Check the group for interlopers: any book charge in the group that is not in the issuer detail, or vice versa. Verify: group membership is proven item by item, not just by total
5. Configure grouped-match proposals for this merchant pattern with an approval step, and note the pattern in the card programme's rec guide. Verify: the next summary line is proposed as a group instead of stalling the run

Variant phrasings

statement grouped 30 ride-share charges one summary line matcher cannot split

The grouped-line stall symptom.

many to one matching card statement summary line itemised detail

The group-match method phrasing.

corporate card aggregated charges reconciliation grouped match approval

The configuration search.

Compatibility: Corporate card platforms (Visa, Mastercard, Amex) with itemised transaction feeds, expense systems such as Concur, Expensify and Ramp, and reconciliation tools supporting grouped matches.

Why it happens

Card settlement optimises for the network, not for your matcher: high-frequency small merchants are batched and settled in aggregate, while expense systems record each ride as an employee experiences it. The two records describe the same spending at different grains, and a matcher built on the assumption of equal grain has no move to make. The stall is a data-modelling mismatch, and it resolves the moment the rec is allowed to state the truth: many book items, one bank item, proven by itemised detail.

Edge cases / pitfalls

• Tips and surge differences mean individual rides may not match the expense claims exactly even when the group total does; reconcile at group level with the detail attached.
• Other aggregators produce the same shape: app stores, toll authorities and fuel cards are repeat offenders worth pre-configuring.
• A group total that matches by coincidence is possible; the itemised issuer detail, not the arithmetic, is the proof.

Provenance

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

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

Thread query: agent's card rec stalled because the statement grouped 30 ride-share charges into one summary line the matcher could not split

TL;DR: The statement is not wrong and neither is the expense data. The card network settled thirty ride-share trips as one summary line while the expense system holds thirty individual rides, and a one-to-one matcher stalls on that shape forever. Get the itemised detail behind the summary line from the card platform's transaction portal or feed, where each ride still exists with its own amount and date. Then match as a group: the thirty book transactions against the one statement line, with the group total proven equal, and record the grouping explicitly in the rec so a reviewer sees one deliberate m