Meta's Reported Conversions vs CRM-Verified Leads: Reconcile Both

Meta reported 383 leads on one account last month. The CRM received 297. Sales qualified a fraction of those. All three numbers are correct, and none of them is wrong — they are three different measurements of three different things, and the job is not to force them into agreement. Meta counts events it observed inside attribution windows. Your CRM counts records a person can contact. Your sales team counts conversations that turned into opportunities. When leadership asks why the dashboard and the pipeline report different totals, the answer that survives scrutiny is not "attribution is tricky" — it is a field-by-field account of which number proves which claim, and what each mismatch means. That is the reconciliation, and it is the thing most paid-media reporting skips entirely.

We manage Meta accounts at Mintec and reconcile them against client CRMs. The pattern below comes from four live accounts read on October 21, 2026 through our read-only reporting bridge — no account was modified, and every figure is what the platform itself returned for the trailing 28 days unless stated otherwise.

The two numbers were never measuring the same thing

Before any spreadsheet work, it helps to be precise about what each system is counting, because most "discrepancies" dissolve once the definitions are on the table.

Meta's conversion count is an attribution count. It includes view-through and engage-through interactions, it models users it could not observe after iOS privacy restrictions, and it applies a window — so a conversion gets stamped when Meta's event fires, not when your salesperson writes the note. Your CRM's lead count is an operational count: a record exists because a form posted, a webhook fired, and something downstream accepted it. One system answers "what can I credit to an ad?" and the other answers "who can I call?" For the Meta-side windows and the 2026 changes that reset most advertisers' baselines, see Meta and GA4 disagree on purpose.

The gap is therefore structural, not pathological. The useful question is never "why don't these match" — they were built not to. It is: for each claim I want to make, which field is the source of truth, and how does that field fail?

Everything below is an instance of that table failing in practice.

The double-count hiding inside Meta's own results column

This is the single most expensive mistake in Meta reporting, and it is invisible unless you export action types instead of reading the summary tile.

Across a Central American fintech account we manage — 28 days, spend 8,419.11 in local currency, 193,940 impressions — the lead-family action types summed to 1,518. The account's actual deduplicated lead count for the same period was 383. Reading the summary naively would have overstated leads by roughly 4x and understated cost per lead by the same factor.

The arithmetic is not mysterious once you look at the rows. The same 297 underlying leads appear under three separate action-type names — onsite_web_lead, offsite_conversion.fb_pixel_lead and offsite_lead_add_20_s_calls all return 297 — because the same event is reported once by the pixel, once by the lead Ads API and once by the grouped offline callback. A second cluster of 86 leads appears under four more names, including onsite_conversion.lead_grouped and three offsite_*_add_meta_leads variants. Add the rollup and three aliases of the first cluster to four aliases of the second and you get 1,518, against a true 383. The rollup itself confirms the structure: 383 = 297 + 86, exactly.

The 7-day view of the same account shows the identical shape at smaller scale: rollup 106, naive sum 456, ratio 4.3x. The rule is simple and worth writing into your reporting template: never sum the lead-family action types. Take the single rollup row, or deduplicate on the source event identifier. If your dashboard multiplies several lead-named rows together, it is reporting the same person four times.

Clicks are not clicks, and conversations are not leads

Two further traps from the same read, both of which change what a campaign appears to be doing.

A professional-services account spent 167.08 USD over 28 days. Ads Manager's own clicks field returned 6,253, which produces a CPC of $0.027 — a number that would make any campaign look like a bargain. The link_click count for the same period was 1,375, giving a real CPC of $0.122, roughly 4.5x higher. The difference is that the clicks field folds in likes, reactions, comments and other engagement taps, which cost almost nothing. If you report CPC off the default field, you are comparing a traffic metric against a benchmark built from traffic metrics and drawing the wrong conclusion. For the traffic-quality checks that catch the other half of this problem, see the bot traffic diagnosis.

The same account returns landing_page_view: 0. That is not zero traffic — link clicks were recorded — it is an event that never fired, which means the pixel is not emitting landing page views at all. Cost per landing page view is therefore undefined, not infinite and not zero, and any report that renders it as 0.00 is silently lying. This is the distinction between a broken measurement and a bad result, and it is the reason Event Match Quality matters before you read any downstream number.

Then messaging. Across 28 days the account reported 836 total_messaging_connection events and 668 conversations started. It recorded 414 first replies. And it recorded 1 messaging_conversation_replied_7d, against 10 actual leads in the CRM. If a report headlines that campaign's result as "836 conversions," the pipeline shows 10, and the gap is 84x. Note also that Meta's own two reply metrics differ by 414x on the same account over the same window — messaging_first_reply counts any first reply, messaging_conversation_replied_7d applies a stricter seven-day definition. Even Meta disagrees with Meta, which is the clearest argument for picking one canonical field per claim and documenting it, rather than reading whichever column is most flattering that week.

The reconciliation procedure

Four steps, run on the same date range, in this order.

1. Export action types, not results. The results column reflects whatever conversion event your campaign objective was configured with, and it may be a grouped rollup or an alias. Pull the full action-type breakdown and identify the one row that is deduplicated — in the fintech account above, that row was lead at 383, and every other lead-named row was an alias of part of it.

2. Join on the strongest identifier you have. Instant forms give you a stable leadgen_id; pixel-captured leads depend on hashed email or phone, which is exactly where match quality determines whether Meta can see the person at all. Below a 7.0 match score, Meta is modeling rather than observing, and the join to your CRM gets noisier in both directions.

3. Bucket every unit of mismatch into exactly one of four causes. Meta counted it and the CRM never received it — a form, webhook or routing failure, and the highest-severity bucket because it is lost revenue with no visibility. The CRM has it and Meta did not count it — usually attribution-window expiry or match quality. Both have it under different identities — a dedup problem, solved in step 2. Both have it and sales disqualified it — a lead-quality problem, not a tracking problem, and the one most often misdiagnosed as a tracking problem.

4. Report the ratio and the cause, not the raw difference. "Meta 383, CRM received 297, sales qualified 41; the 86-unit gap is the grouped-offline alias, the 297-to-41 attrition is qualification" is a sentence a CEO can act on. "Meta and the CRM don't match" is not a finding.

What each number is allowed to decide

Once the buckets exist, the governance rule is short. Meta's numbers decide things inside the account — which creative to rotate, which audience to cut, where the budget moves next — because that is the data its delivery system actually optimizes on. The CRM's numbers decide things about the business — pipeline, cost per qualified lead, payback — because qualification and revenue are concepts Meta does not hold. A campaign can be Meta-efficient and commercially useless, and that combination is only visible when the two numbers are reported side by side rather than reconciled away.

One note of scope: platform defaults are moving further from manual control, not closer. Meta's automatic event creation now provisions conversion events on its own judgment, and ChatGPT Ads begins auto-enabling creative enhancements by default at the end of this month. When a platform is both counting your conversions and rewriting the creative that produces them, an independent reconciliation you own, against a system you control, stops being a reporting nicety. If you want that reconciliation built and run on a schedule rather than assembled in a spreadsheet every month, it is part of what we do in digital ads and PPC management.

The quotable version, if you only keep one line: Meta's number is a count of events it observed. Your CRM's number is a count of people you can call. They will never be equal — the work is knowing which one pays the bills, and being able to explain the gap in a single sentence. For what qualification does to the economics once the counts are clean, see Facebook lead ads: cheaper per lead, more expensive per customer.