Duplicate charges are one of those problems that sounds like it should be easy to solve. Same vendor, same amount, similar date — how hard can it be to write a query that catches that? In practice, the detection problem is significantly harder than it looks, and corporate card programs make it worse in several specific ways that aren't obvious until you're staring at the raw transaction data.
We've built duplicate detection into Spendaq because GL miscoding and duplicate charges often travel together: a duplicate charge that gets auto-coded, posted, and never flagged will show up as a budget variance, get investigated, and ultimately require a journal entry reversal and vendor credit chase — adding close week work that should never have happened.
How Duplicate Charges Actually Occur
There are three main categories of duplicates in corporate card programs, and they have different detection requirements:
True merchant errors — the vendor processes the authorization twice, or a network issue causes a dual-posting. These are the simplest case: same amount, same merchant descriptor, one or two days apart. A basic matching rule catches most of these.
Split-tender or partial-void situations — a transaction gets declined, the cardholder retries with a different card or after fixing the card limit, and both the decline and the successful charge appear in the feed. The decline may have already been partially processed. These are trickier because the amounts may differ slightly and the descriptors may not be identical.
Subscription re-billing errors — SaaS vendors, insurance carriers, and other recurring-charge businesses sometimes generate duplicate billing cycles, especially around renewal dates, plan upgrades, or payment method changes. These may be 30 days apart and have slightly different invoice reference numbers in the descriptor. Rules-based systems almost always miss these because the time window looks too wide and the descriptors look like normal recurring charges.
The third category is both the most common and the most expensive, and it's where corporate card programs specifically create a visibility problem.
Why Corporate Card Data Is Structurally Harder to Deduplicate
When a vendor duplicates a charge on an ACH payment or a wire, both transactions show up in your bank feed with consistent reference data — bank reference numbers, trace IDs, and originating account details that a skilled Controller can use to identify the duplicate. The paper trail is relatively clean.
Corporate card transaction data is messier. The merchant descriptor is set by the vendor, not the payment network, and it's not standardized. When a SaaS vendor processes your monthly subscription charge, the descriptor might be ADOBE*CREATIVE CLD in March and ADOBE SYSTEMS INC in April after they updated their merchant account. Same charge, same amount, 30 days apart — but a rules-based deduplication system that uses exact descriptor matching sees two different vendors and clears both.
Add to this the problem of multi-card programs. A company running both Ramp and Amex Commercial cards for different departments may have the same subscription charged to both cards during a transition period, or different employees each carrying a card charged independently for the same tool before someone consolidates the vendor accounts. These cross-program duplicates are almost invisible in ERP-native reporting because the transactions come in through separate feeds and land in separate reconciliation workflows.
What the Detection Logic Actually Needs to Do
Effective duplicate detection for corporate card programs needs to work across at least three dimensions simultaneously:
Vendor normalization first. Before comparing transactions, you need to resolve ADOBE*CREATIVE CLD and ADOBE SYSTEMS INC to the same canonical vendor. This is the same vendor normalization layer we use in the GL mapping pipeline — it's prerequisite work for accurate deduplication, not just for categorization.
Fuzzy amount matching within a tolerance band. Exact amount matching misses duplicates where a small service fee or currency conversion creates a one-cent difference. A tolerance of ±0.5% on amounts above $50 catches most of these without generating false positives.
Configurable time windows by vendor category. A 2-day window catches true merchant errors on one-time purchases. A 32-day window (slightly longer than a billing month) catches subscription re-billing duplicates. The detection window should vary by vendor type — not be a single global setting.
We're not saying that every flagged pair is actually a duplicate — some vendors legitimately charge similar amounts in adjacent periods, and any system that flags too aggressively creates review fatigue that causes real duplicates to get cleared alongside false positives. The goal is to surface high-probability duplicates for human confirmation, not to auto-void charges based purely on algorithmic matching.
A Scenario That Illustrates the Scale
Consider a professional services firm with 45 employees, running corporate cards through two programs — Brex for the administrative team and Amex Business for the partner group. They have approximately 180 SaaS subscriptions active across the company, managed by different department heads who historically signed up for tools independently.
During a software audit in Q3, their Controller found that 11 of those subscriptions had been billed twice during the audit window — some due to card transitions, some due to billing system errors on the vendor side, one because two partners had independently signed up for the same tool under different email addresses. Total duplicate billing across the audit period: roughly $28,000.
The subscriptions had been billing correctly in the ERP — they were coded accurately to 7410 Software Subscriptions. The duplicates were invisible in the GL because they looked like normal recurring charges. No variance flag would catch them because the budget for software subscriptions was tracking high, but not anomalously so — they'd grown the team and added legitimate tools. The duplicates were hidden inside the noise of legitimate growth spend.
This is the detection failure mode that rules-based systems are most susceptible to. When duplicate charges are camouflaged by legitimate spend in the same category and time window, variance analysis won't surface them. You need detection logic that operates at the individual transaction level, not at the budget line level.
How Spendaq Handles This
Our duplicate detection runs in the categorization pipeline, before transactions are cleared for ERP sync. When a transaction arrives, we check it against a rolling 35-day window of prior transactions from the same normalized vendor, looking at amount proximity, descriptor similarity, and card program source. High-probability matches — same normalized vendor, amount within 0.5%, within the configured window — surface as DUPLICATE — REVIEW flags in the review queue rather than auto-approving to the ERP.
The flag carries the matched transaction reference, the time delta, and the amount comparison so the reviewer has enough context to confirm or clear in a single view. We also run a monthly cross-card deduplication pass specifically for subscription-class vendors — checking for the same vendor charged to multiple card programs in the same billing period, which catches the multi-program subscription overlap case that in-period detection misses.
Duplicate detection isn't glamorous product work, and it's not the reason most companies initially come to us. But it's consistently one of the first things Controllers mention when they describe what the ERP isn't doing for them — and the dollar amounts recovered in the first few months frequently exceed the annual subscription cost. That's the kind of payback that makes the conversation with the CFO straightforward.