Why Google Ads and Meta both claim the same sale — and how to reconcile them
Google Ads and Meta can both attribute a conversion to the same customer purchase. Adding their reported sales or revenue does not produce a unique business total. Keep each platform’s report for optimization, keep a deduplicated sales ledger for business totals, and state the attribution rule used when assigning sales to channels.
On this page10 sections
Are both reports counting the same event?
The first question is not “Which dashboard is lying?” It is “Are these reports counting the same event, on the same date, under the same rules?” A discrepancy can come from legitimate attribution overlap, a tracking defect or a mixture of both.
This guide provides a reconciliation method, including what you cannot determine from aggregate reports alone. Every transaction in the worked example is fictional.
One sale can have more than one advertising touch
Consider a customer who clicks a Meta ad, later clicks a Google ad and then buys. Under measurement settings that credit those interactions, both platforms can associate the sale with advertising they delivered. Your business still has one sale.
Attribution is an allocation of credit under a model. It is not a global receipt number shared between dashboards, and it does not by itself establish that the customer would not have purchased without the advertising.
Google’s attribution documentation describes how credit is assigned among ad interactions. Its discrepancy guide also identifies differences in conversion settings, windows, dates and other reporting conventions. Matching the date picker alone does not align the measurement systems.
Separate three different problems
| Problem | What is being repeated? | Where to investigate |
|---|---|---|
| Duplicate event collection | The same business event is sent repeatedly within a measurement setup | Tags, integrations, event identifiers and conversion actions |
| Cross-platform attribution overlap | Two platforms associate the same sale with their own advertising | Attribution definitions and a business-level reconciliation |
| Duplicate business records | The CRM or payment export contains repeated representations of one sale or customer | Lead, order, invoice and payment identifiers |
One fix does not necessarily solve the other problems. For example, Google’s transaction-ID mechanism helps avoid recording a repeated purchase event as another conversion in its measurement setup. It does not turn two platforms' attribution reports into a single deduplicated business ledger.
Likewise, Google’s “One” counting setting concerns counting after an ad interaction. It is not a universal “one customer across Meta, Google and the CRM” rule.
A seven-sale example: nine platform claims are not nine customers
Assume the following invented ledger. “Claimed” means that the example supplies that information; it is not a claim that every ad platform lets you export an order-by-order attribution list.
| Unique sale | Revenue | Meta claim in the example | Google claim in the example |
|---|---|---|---|
| S101 | $300 | Yes | Yes |
| S102 | $500 | Yes | No |
| S103 | $200 | No | Yes |
| S104 | $400 | Yes | Yes |
| S105 | $600 | Yes | No |
| S106 | $1,000 | Yes | Yes |
| S107 | $250 | No | No |
| Platform totals | 5 sales / $2,800 | 4 sales / $1,900 | |
| Unique business total | $3,250 / 7 sales |
Adding the platform reports gives nine conversion claims and $4,700 of claimed revenue. The business actually recorded seven unique sales and $3,250 of revenue.
Three sales appear in both platform columns. One appears in neither. That produces a useful warning:
You cannot reliably calculate the overlap by subtracting business sales from summed platform conversions. Here, 9 − 7 = 2, but the actual overlap is three sales. The unmatched sale changes the arithmetic.
Real reporting can be harder still: actions may be fractional, modeled or defined differently. The example assumes comparable, whole-sale events and an observed ledger. Do not apply its set arithmetic to incompatible conversion totals.
Download the seven-sale reconciliation example.
A practical reconciliation you can run before the next report
1. Choose the business event
Are you reconciling unique leads, signed deals, paid orders, individual payments or new customers?
One order paid in three instalments can mean one sale and three payment events. A customer who buys twice can mean two orders and one newly acquired customer. Pick the event before comparing totals.
Write the definition at the top of the report: for example, “unique paid orders, excluding refunded orders, by payment date.”
2. Establish a reliable business total
Use the system that records the chosen outcome: an order system, payment ledger or appropriately maintained CRM. Check identifier uniqueness, test records, cancellations and refunds.
Record the extraction time. A correctly deduplicated but stale CRM export is not a complete statement of today’s business.
Do not collapse all records with the same email into one sale. One person can make multiple legitimate purchases. Conversely, several payment records can belong to one order. The identifier must match the event you chose.
3. Align definitions before comparing numbers
| Setting or convention | What to record |
|---|---|
| Event | Purchase, lead, qualified lead or another action |
| Revenue | Contract value, invoice value or received payment |
| Date basis | Ad interaction, business event or acquisition cohort |
| Time zone | The one used by each export |
| Credit | Attribution model and eligible interaction windows |
| Counting | Actions counted once or repeatedly after an interaction |
| Included outcomes | Primary actions, additional actions and other columns |
| Money | Currency, refunds, tax and discounts |
Google’s primary and secondary action documentation explains why conversion columns can include different sets of actions. Compare the intended outcome, not whichever total is easiest to export. For the Meta side — attribution windows and how its settings change the numbers — see Facebook Ads attribution settings.
4. Keep three separate views
Platform view: preserve Meta and Google reports with their own definitions. These help explain what each system observes and optimizes toward.
Business view: count unique outcomes and actual revenue once. Include unattributed outcomes rather than forcing them into an advertising channel.
Channel-assignment view: apply a documented rule to the evidence available in your own data. Examples include a recorded first enquiry source or a recorded last eligible touch. Keep “unknown” when the evidence is missing.
In the third view, show the portion of outcomes with adequate source information. A tidy channel chart covering only half the business is not a complete channel comparison.
5. Investigate events that really are duplicated
If a test purchase creates two purchase records in the same setup, inspect the implementation rather than dismissing the problem as attribution. Check whether multiple integrations send the same action, whether a page reload sends another event, and whether identifiers are generated correctly.
Do not manufacture a different transaction ID every time the same order is resent. Do not reuse one static ID for different orders. Google’s transaction-ID instructions distinguish purchase deduplication from its per-interaction counting setting.
Use each platform’s current implementation documentation for its own deduplication mechanism. A fix verified in Google does not verify the Meta integration.
What if you cannot see the individual overlap?
Say so. Aggregate platform reports often cannot identify exactly which business outcomes overlap, and missing or modeled attribution should not be replaced with invented order-level certainty.
You can still report useful facts:
- Unique sales and revenue from the business ledger.
- Each platform’s conversion claims, shown separately.
- Spend across the selected platforms, with consistent currency treatment.
- Outcomes assigned by your business rule and the unassigned share.
- Known tracking defects and the date they were corrected.
A business-level revenue-to-ad-spend ratio can help monitor overall efficiency, but it includes the effects of other demand sources and returning customers. It does not assign causal credit to a particular platform.
A reconciliation still does not measure incrementality
An attribution rule answers “Where do we place credit?” An incrementality question asks “How many outcomes would disappear if this advertising were absent?”
A last-touch assignment can be perfectly consistent without answering the second question. Avoid turning the channel-assignment view into a causal budget verdict. The budget allocation guide uses bounded decisions and explicitly separates forecasts from observed effects.
Ask Variafy for a reconciliation brief
Use Variafy to bring supported ad-account readings into your assistant, then add an appropriately prepared business export. Keep private customer details out of a worksheet when internal identifiers are sufficient.
Try this request:
Show Meta and Google conversion totals separately for this period. Do not add attributed conversions or revenue into a unique business total. Compare them with this deduplicated sales export. List event, date, attribution, currency and freshness differences. Where individual overlap cannot be established, mark it unknown.
Variafy is not a guarantee of perfect cross-platform attribution. The useful output is a report whose evidence and limits are clear. See the connection guides and the existing explanation of Google Ads versus GA4 conversions.
How we checked
Questions
Does double attribution mean Meta or Google is overcharging me?
Not by itself. A disagreement in reported conversion credit is a measurement issue. It does not establish that the media charge is incorrect.
Will server-side tracking make the platform totals match?
Not necessarily. Better event collection does not make attribution definitions identical or produce a shared unique-sales ledger.
Is GA4 automatically the correct channel answer?
It is another measurement system with its own event collection and attribution settings. Use it for the questions it can answer; reconcile actual business outcomes separately. Google’s GA4 attribution settings also distinguish event-scoped reporting from user- and session-scoped dimensions.
Can I add Meta and Google spend together?
Yes, if they are separate expenses for the same defined reporting scope and you align currencies and accounting treatment. That does not mean you can add their overlapping attributed outcomes.
Should I divide overlapping revenue equally between platforms?
Only if you deliberately choose that as a reporting convention and label it. Equal allocation is not evidence that each platform caused half the sale.