The Real Cost of Manual Reporting Reconciliation

The real cost of manual reporting reconciliation is not the hours any single cycle takes. It is that the same hours get spent again next cycle, forever, because nothing you did in the spreadsheet changed why the platforms disagree. Google Ads and Meta count different things, on different clocks, with different windows, using their own conversion models. A reconciliation is a patch applied to one reporting period. It expires the moment the period closes. Multiply hours per cycle by cycles per month by loaded hourly cost and you have a recurring line item that nobody put in a budget.

Here is what makes it worse than a normal recurring task. Most repeated work gets faster with practice. This one does not, past a point, because the bottleneck is not your skill at matching rows. It is a disagreement between two companies about what a conversion is, and no amount of practice makes them agree. You get faster at exporting. You never get faster at the part where someone asks which number is right.

Why don't the numbers reconcile in the first place?

Four separate mechanical reasons, and they stack. Each one alone would produce a gap. Together they produce a gap large enough that a reasonable person can look at two dashboards and conclude someone is lying.

Different attribution windows

Google Ads uses a 30-day click window by default for most conversion actions. Meta's default is 7-day click. So a purchase 12 days after a Google click and a Meta click counts once for Google and zero times for Meta. Change the Meta window to 28 days and it now counts for both. Nothing about the customer changed. You changed a dropdown.

This is why "we set both to 7 days so they match" is a trap. Matching the windows makes the two numbers comparable to each other. It does not make either correct, and it silently discards conversions Google would otherwise have credited.

Overlapping credit claims

The customer saw an Instagram ad Tuesday, searched your brand Thursday, clicked the Google ad, and bought. Both platforms claim the conversion. Both are telling the truth about what they observed. Neither is wrong. Add them together and you have 200% of one sale.

This is the single biggest source of executive confusion, because it is the one that looks like error. It is not error. It is two systems each answering the question "did an ad I served appear on the path to this purchase?" and both correctly answering yes.

What this is NOT: de-duplicating overlapping credit is not the same as deciding which platform deserves the credit. De-duplication gets you to one sale. Deciding whether the Instagram impression or the brand search earned it is an attribution-model question, and it does not have a mechanically correct answer.

Modeled conversions

Neither platform reports only what it directly observed. Both fill gaps, cross-device journeys, consent-restricted sessions, iOS traffic after App Tracking Transparency, with statistically modeled conversions. This is a defensible engineering response to a real measurement problem. It also means part of the number you are reconciling was produced by a model, using that platform's assumptions, in service of that platform's reporting.

You cannot reconcile a modeled number against an observed one and expect them to land on the same value. They are different kinds of object, and forcing them to agree is where a lot of reconciliation time disappears.

Different clocks

Three separate clock problems, usually discovered in that order:

• Time zone. Ad account time zones are set when the account is created and are not something you change casually. If your Google account is on one time zone and your Meta account on another, their "Tuesday" covers different hours.
• Back-dating. Both platforms report a conversion against the date of the ad interaction, not the date of the purchase. A sale today gets written back to a click 19 days ago. Your numbers for three weeks ago are still moving.
• The CRM disagrees with both. Your order system records revenue on the order date, and GA4 records the event when it happens. So the same sale sits on three different dates depending on which system you ask.

Point 2 is the one that causes the most avoidable damage. If you exported Monday's report on Tuesday and someone re-exports it Friday, the numbers will differ, and you will spend the meeting defending a discrepancy that is just the platform doing what it always does.

Four systems. Four answers. None of them broken.

What does one reconciliation cycle actually involve?

The mechanical sequence, which is roughly the same in every team that does this by hand:

• Export Google Ads. Export Meta. Export Microsoft or TikTok if they are running.
• Export the CRM or order system for the same period, on the CRM's dates, which do not match the platforms' dates.
• Normalize currency and time zone, because the exports do not agree on either.
• Match conversions, usually on a UTM convention that works right up until someone launches a campaign without tagging it properly.
• De-duplicate the overlaps by hand, applying a rule that is rarely written down anywhere.
• Flag what still does not tie out.
• Write the explanation.
• Present it, and spend part of the meeting defending that step rather than discussing performance.

The export and matching steps are labor. Flagging is judgment. Writing the explanation and presenting it are the expensive part, and they are the ones nobody logs as reconciliation time.

What does the labor actually cost?

Build the model, then throw out my numbers and use yours. This is illustrative arithmetic, not a measured finding.

Say the cycle takes 4 hours, exports, normalization, matching, de-duplication, and writing the explanation. Say you run it weekly, so roughly 4.3 cycles a month. Say the person doing it costs $85 an hour loaded, salary plus employer costs plus overhead, not their take-home rate.

• 4 hours x 4.3 cycles = 17.2 hours a month
• 17.2 x $85 = $1,462 a month
• x 12 = roughly $17,500 a year, per account set

Now stress the model. Add a third and fourth platform and the matching step does not grow linearly, because every new platform adds a new pairwise overlap to resolve. Run the cycle monthly instead of weekly and the per-cycle hours go up, not down, the period is longer and more of it has been restated by back-dating since anyone last looked.

If you want a real number instead of a model, log it for three cycles, tracking explaining the discrepancy separately from deciding what to do about performance. The explaining half is usually larger than teams assume, and it is the half that produces no decision.

What does it cost past the hours?

Three second-order costs. None of them appear in a budget line, which is exactly why the total stays invisible.

Decisions delayed while the numbers are argued about. The meeting that should open with "here is what changed and what we are doing about it" opens with "here is why these two dashboards disagree," and the decision slips a week. In a paid media account, a week of delay on a budget shift is real money, and it never gets attributed to the reporting process that caused it.

Decisions made on a number that turned out to be wrong. This is the costlier one. Back-dating means the figure you acted on Tuesday may not be the figure that exists Friday. Pause a campaign on a Tuesday CPA that looked bad, and if the conversions that were still landing would have fixed it, you killed something that was working. The damage is invisible because the counterfactual never gets reported.

Credibility with finance. This one compounds. When marketing presents a figure and finance's system says something different, the specific discrepancy gets resolved, and a small amount of trust does not come back. Do that quarterly for a year and you arrive at the position every marketing lead wants to avoid: the budget conversation starts from "convince us these numbers are real" rather than from the numbers. The cost of that is not hours. It is the next budget request.

What can be automated, and what genuinely cannot?

The distinction matters, because tools get sold as if the whole problem is mechanical. It is not.

Automatable, the assembly: pulling every platform and the CRM continuously instead of on export day; normalizing currency and time zone; matching on a consistent key; applying one de-duplication rule the same way every time; re-pulling when back-dating restates a prior period so the report updates itself rather than going stale.

Not automatable, the judgment: deciding which source is ground truth. That is a business decision about what your company counts as a sale, and it belongs to a human. For most ecommerce and most lead-gen, the order system or CRM is the honest answer, because it is the only system with no incentive in the outcome. But there are real exceptions, an app install business where the platform SDK genuinely observes more than the backend, or a long-cycle B2B account where the CRM records an opportunity months after the ad did its work.

Here is the part most vendors skip. Automation does not make the platforms agree. It makes the disagreement get resolved the same way every time, automatically, and on the record. That is a smaller claim than "solved," and it is the only honest one. The value is not that the gap closes. It is that you stop paying a person to re-derive the same resolution every week, and that the rule they were applying inconsistently is now written down where finance can inspect it.

A consistent wrong rule also beats an inconsistent right one. If your de-duplication logic is documented and applied identically every cycle, the trend line is trustworthy even if the absolute level is debatable. Hand-matching produces the opposite: defensible individual numbers, untrustworthy trends.

When is this not your problem?

Say it plainly: if you genuinely run one platform, this post is not about you. One ad account, one attribution window, one clock, one currency. There is no cross-platform overlap to de-duplicate because there is no second platform claiming credit. Your reporting problem, if you have one, is a platform-versus-CRM question, real, but a different and much smaller problem.

Two near-misses worth checking before you decide you are in that category:

• "Google is 95% of spend." That remaining 5% still shows up in the blended number finance sees, and it is usually the piece nobody has reconciled. Either fold it in properly or exclude it explicitly and say so.
• "We only report monthly, so it is only twelve times a year." Monthly cycles are longer and more restated, not cheaper. Run the model on your actual per-cycle hours before concluding the frequency saves you anything.

What is the first move if you are not changing anything this quarter?

Two things, both free.

Write down your de-duplication rule. Not the ideal rule, the one you are actually applying. Most teams discover, writing it out, that different people apply different rules, which means the month-over-month trend they have been presenting is not comparable to itself. Fixing that costs nothing and removes a class of discrepancy immediately.

Name your ground truth, once, in public. Pick the system that counts a sale, declare it, and report every platform number as a variance against it rather than as a competing figure. "The order system shows 540 sales; Google claims 412 of them, Meta claims 288, here is the overlap" is a sentence finance can work with. "Google says 412 and Meta says 288" starts an argument. Same data, the difference is that you decided what was true before the meeting rather than during it.

FAQ

Related reading

• Your ROAS Is Lying: Cross-Platform Numbers - why the platform-reported number itself cannot be taken at face value.

If your reporting cycle still opens with why the numbers disagree, that is the cost this post was about. Explore Adlyse.