Google Ads + Meta: why seven conversions can mean six orders

A combined dashboard should help you make a decision, not make incompatible totals look identical. Start with the question the business needs answered: how many eligible orders did we receive, what did the advertising platforms credit, and what can we actually reconcile?

Is this overlapping credit or a duplicate event?

A buyer might interact with a Meta ad, later click a Google ad and place one order. Each platform may credit that order under its own rules. That is overlapping attribution: two claims about one purchase. It can happen even when both tracking implementations send the purchase correctly.

A duplicate event is a different problem. A confirmation page might fire the same purchase again, or browser and server tracking might send two copies without working deduplication. Inspect event delivery and the documented integration settings before blaming attribution.

Google’s transaction ID helps recognise repeated conversions for the same conversion action. It does not remove Meta’s credit for that purchase. Nor does adding that ID create a standard order-by-order Google Ads attribution export. Keep your own permitted first-party evidence when order-level reconciliation matters.

Make the comparison fair before explaining the gap

Freeze copies of the reports and note when you retrieved them. Check the settings that were actually used rather than assuming that the same column label means the same thing.

Google offers conversion-time columns to help compare with the date orders happened; the usual conversion columns follow the ad interaction’s date. That choice can move results between periods. It does not make two attribution systems equivalent.

Meta announced a change in March 2026: website and in-store click-through attribution would use link clicks, with other social interactions moving to engage-through attribution. Rollout timing differed by advertiser. Check the definitions present in your account and historical exports, especially across a change.

1. Period and date basis: identical boundaries, time zone, and interaction date versus order/conversion date.
2. Outcome: the same purchase or lead stage, with the selected conversion actions and counting rules recorded.
3. Attribution: actual windows, model and click, view or engagement categories; keep incompatible categories separate.
4. Value: one currency and a stated treatment of tax, shipping, cancellations and refunds.
5. Completeness: export time, reporting lag, modeled figures and missing matching evidence.

A six-order example you can check line by line

The fictional ledger below contains six paid orders worth €700. We deliberately supply order-level credit flags for this example. They are not a claim that a standard advertising export reveals every matched order. Each flag describes supplied credit, not proof that advertising caused the sale.

Google credits four orders worth €570. Meta credits three worth €300. Adding them gives seven credits and €870, but orders A100 and A103 appear in both sets: two orders worth €220.

Subtract that known overlap and the platforms cover five distinct orders worth €650. A104, worth €50, has no supplied credit from either platform. Add it back to obtain all six business orders: €570 + €300 − €220 + €50 = €700.

The tempting shortcut is wrong: seven platform credits minus six business orders gives one, yet the actual overlap is two. The uncredited order changes the gap. You can only calculate the overlap here because compatible, complete order-level flags were supplied; aggregate or fractional modeled totals do not provide those flags.

Which number belongs in the management report?

Use distinct eligible order IDs from the order or CRM ledger for the business total. Define eligible first: paid orders, qualified leads or another agreed stage, with a clear cancellation and refund policy. A CRM count is only as sound as its scope and duplicate handling.

Keep Google Ads and Meta attributed counts and values in their own columns, with their definitions beside them. A platform view supports work within that platform. The business total answers a different question. Neither alone measures incremental sales that would not have happened without advertising.

Where permitted first-party records support matching, retain the order ID and evidence reference, then mark matched, overlapping and unresolved records. Where the data is aggregated, modeled or incomplete, report the unresolved remainder. Do not invent a cross-platform allocation or label missing evidence as proof of no advertising influence.

Can AI reconcile the report for you?

AI can suggest column mappings, highlight a missing time zone, or draft commentary from checked figures. Use fixed calculations for totals and tests, then have the report owner verify the underlying definitions and consequential claims.

A language model cannot recover order identities that an export never supplied. It cannot infer the exact overlap from two totals or decide which ad truly caused a sale. Ask it to distinguish observed records, proposed explanations and unknowns rather than force the numbers to agree.

For a first reporting pilot, test the six-order example, a deliberately repeated order, an unknown credit flag and a refund case. These are proposed acceptance tests, not results from a live client system. Keep customer names and email addresses out of the worksheet and any AI input; use the minimum approved data.

Start with one report and one accountable owner

Download the worked CSV to inspect the arithmetic, then use the blank CSV for your own approved local records. A blank credit cell means unknown; it must not silently become zero. Keep the source extracts and evidence references with the working file.

Agree who owns the business total, who checks tracking and who approves the final commentary. A useful reporting pilot leaves a repeatable method and an honest exception list. Its success is a report someone can check, not a perfectly aligned pair of platform totals.