# Ads Manager purchases vs actual sales · Postback Report > Source: https://postbackreport.cc/best/purchase-gap-calculator-ads-manager-purchases-against-network-approved-sales ## 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. **Disclosure:**We may earn a commission when you buy through links on this page. It never affects our rankings. [How we research](/methodology). Counts for the same dates Ads Manager purchases Network approved sales Network held sales Network rejected sales Do the browser Purchase and the server Purchase share an event id? Yes No Pick no when the two sends use different ids, or when you have not set an id on both. Calculate the purchase gap The counts you enter, and the gap the form works out, are stored anonymously so we can see which mismatches readers hit. No name or email is asked. The figures stay on this site for editorial review. 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](https://sweetcode.com/blog/facebook-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](https://help.affclix.com/integrations/meta-conversions-api) 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](https://doc.voluum.com/article/facebook-conversion-integration) 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](/compare/facebook-pixel-vs-conversion-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](/methodology) 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](https://help.littledata.io/integrations/facebook-capi/meta-ads-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](https://github.com/facebookincubator/Facebook-Server-Side-API-Swagger/blob/main/server-side-api.yaml). 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 Voluum homepage, with its tracking headline and a dashboard preview. 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](https://clickflare.com/blog/why-your-conversions-dont-match-across-platforms) 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? Meta is tallying attributed purchase events. The network is paying approved leads. SweetCode's troubleshooting guide calls a purchase total above real orders a technical tracking issue. Can a held sale still show up as a purchase? A Purchase that leaves while a lead is still held, or that leaves and is later cut back, can remain in the column. When those two statuses cover the difference, that is the explanation kept, provided an unmatched id was not already the fit. Do the pixel and the Conversions API double every sale? Meta keeps a single event when both copies carry the same event name and the same event id on one pixel, inside the window above. Littledata's guide also says Meta cannot deduplicate across tools, so two senders with different ids can both remain. Should the columns be compared on the day the leads arrived? Use one date range for both figures. A server event can still pair with an earlier browser event during that match period, and a postback can land before a rejection. Held and rejected belong in the form for that reason. ### What we read * [Facebook conversion discrepancies](https://sweetcode.com/blog/facebook-conversion-discrepancies) * [Littledata Meta ads tracking guide](https://help.littledata.io/integrations/facebook-capi/meta-ads-tracking-guide) * [Meta Conversions API spec](https://github.com/facebookincubator/Facebook-Server-Side-API-Swagger/blob/main/server-side-api.yaml) * [Voluum Facebook conversion integration](https://doc.voluum.com/article/facebook-conversion-integration) * [AffClix Meta Conversions API](https://help.affclix.com/integrations/meta-conversions-api) * [Why conversions do not match](https://clickflare.com/blog/why-your-conversions-dont-match-across-platforms) * [SweetCode purchase troubleshooting](https://sweetcode.com/docs/pmw/troubleshooting) ### Related reading * [Facebook pixel vs Conversions API](/compare/facebook-pixel-vs-conversion-api), what each path sends on a sale. * [How we research](/methodology), vendor docs and long-term user reports. * [Affiliate tracker pricing calculator](/best/entry-plan-picker-which-tracker-plan-your-traffic-actually-fits), showing which entry plan fits a month of traffic. * [Best affiliate trackers](/best), the ranked roundup. * [RedTrack review](/reviews/redtrack) * [Voluum review](/reviews/voluum) 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. [nadial@postbackreport.cc](mailto:nadial@postbackreport.cc) Last checked 2026-10-18 --- [ Postback Report ](/) Postback Report ranks affiliate tracking software for media buyers running Meta and Google direct response, judged on postbacks, cost and conversion API. [Contact](/contact) Postback Report We may earn a commission when you buy through links on this page. It never affects our rankings. © 2026 Postback Report. Independent and reader-supported.