Why purchases outrun paid sales
Ads Manager can show more purchases than the network will pay for. The Purchases column counts conversions Meta attributed to your ads, not the approved sales on the ledger. Enter both for the same dates.
The gap and its likely cause appear here after you submit the counts.
What each field is counting
The first number is the Purchases figure in Ads Manager for one date range. SweetCode's write-up of conversion discrepancies describes Ads Manager as applying attribution modeling to raw events, then counting the conversions it attributes.
Approved sales are the leads the network will pay for in that same range. Held sales are still waiting on a decision. Rejected sales are leads the network has already turned down. Buyers run into this when Ads Manager purchases do not match sales, because the two columns record different decisions.
A postback records that decision in the tracker. A Meta Purchase is a separate event. AffClix's Conversions API guide says to send only approved conversions. Pending, rejected, and what AffClix calls cut-back conversions are excluded from Meta Purchases. A later approval is sent when the network approves the lead.
Voluum's Facebook conversion article states Meta's domain rule: for Meta to register a conversion, it has to occur on a domain the advertiser owns. Affiliates usually verify the lander they control. The offer itself sits on the network's domain.
The question is whether those two Purchase events share one event id. The guide Facebook pixel vs Conversions API shows how to add that id to both events.
How the percentage and the label are chosen
The result is an estimate. Nothing here signs in to Ads Manager or to the network. The estimate rests on vendor docs and long-term user reports. How we research describes that method.
Subtract approved sales from the Purchases figure. Divide that difference by approved sales and you have the percentage. Approved sales have to be at least 1, because they are the base. Four checks run in order. Whichever check fits first sets the label you see.
The opening check looks for mismatched event ids on the browser Purchase and the server Purchase, plus a gap of at least 10 percent of approved sales. When both are true, the form labels the gap as a duplicate count, because the pixel and the Conversions API each counted the sale. Littledata's tracking guide says Meta keeps one event when a browser event and a server event share the event name and the event id for the same pixel, within 48 hours. That matching rule is also documented in Meta's server-side spec. Voluum's article recommends disabling the Pixel Redirect URL when the Conversions API postback is active. With both left on, the conversion is sent twice.
The next check looks for a positive gap that held sales and rejected sales can account for. Their total has to be at least as large as the gap. The form flags that gap as held or rejected sales reported to Meta as Purchases before the network settled them. ClickFlare's note on mismatched conversions says postbacks run in real time, so a tracker can list more conversions than the network's final count after a later rejection or adjustment.
A third check applies when the event ids match, the gap is still at least 10 percent, and held plus rejected sales total less than the gap. The label for this case is attribution overlap, and it is the secondary reading. Media buyers have described a single order getting credit from more than one campaign even when those ids match.
If the Purchases count is lower than approved sales, the form flags the gap as reporting lag in Ads Manager, or as an attribution window that credits fewer sales than the network pays out. Every other result points to the date ranges, or to a difference small enough to treat as ordinary noise.
Two worked examples
Start with 120 purchases in Ads Manager, 100 approved sales, and mismatched event ids. Held and rejected stay at zero. The difference is 20, which is 20 percent of approved sales. That check is met, so the form assigns the duplicate count label.
Start with 108 purchases in Ads Manager, 100 approved sales, 6 held, 2 rejected, and matching event ids. The difference is 8, which is 8 percent. Held and rejected add up to 8, so the second check fits. The 10 percent check does not apply.
My take
I'd judge a surplus by whichever check fits first. I would start by putting the same event id on both Purchase events, and I would leave attribution settings alone until that id matches. A Purchase should go to Meta only after the network approves the lead.
The overlap calculation uses these five fields. It cannot tell which campaigns were credited.
Questions
Why does Facebook report more purchases than sales?
Can a held sale still show up as a purchase?
Do the pixel and the Conversions API double every sale?
Should the columns be compared on the day the leads arrived?
What we read
- Facebook conversion discrepancies
- Littledata Meta ads tracking guide
- Meta Conversions API spec
- Voluum Facebook conversion integration
- AffClix Meta Conversions API
- Why conversions do not match
- SweetCode purchase troubleshooting
Related reading
- Facebook pixel vs Conversions API, what each path sends on a sale.
- How we research, vendor docs and long-term user reports.
- Affiliate tracker pricing calculator, showing which entry plan fits a month of traffic.
- Best affiliate trackers, the ranked roundup.
- RedTrack review
- Voluum review
Written by
Nadia Lindqvist
Affiliate tracking
Nadia covers affiliate tracking software for people who buy Meta and Google traffic. She reads vendor pricing pages, documentation and long-term user reports, and she writes about which tracker fits a given buyer.
Last checked 2026-10-18
Comments
No comments yet. Questions and your own experience are welcome.
Thank you. Your comment will appear once it has been reviewed.