The gap between what Marketing reports and what Finance sees isn't a communication problem. It's a measurement architecture problem.
Marketing closes the month showing $340,000 in attributed revenue. Finance closes the same month at $280,000. The $60,000 difference creates a room full of doubt—about the data, the tools, and whoever built the tracking.
The conversation that follows usually centers on which number is "right." That's the wrong conversation. Both numbers are real. They're measuring different things from different vantage points, and your infrastructure was never built to reconcile them.
The Three Gaps That Create the Mismatch
Most revenue disagreements between marketing and finance trace to three structural causes, not errors.
1. Attribution Windows vs. Cash Timing
Marketing attribution systems assign credit at the moment of conversion—the form fill, the trial start, the checkout. Finance recognizes revenue when cash changes hands. For a B2B SaaS product with a 14-day trial and net-30 invoicing, that's a 44-day gap minimum.
A deal that marketing attributes to January 28 might not appear in Finance's books until March. Comparing monthly totals without accounting for this delay means you're comparing different months wearing the same label.
It's not an error. It's a fundamental difference in what each system was designed to track.
2. Multi-Touch Credit Inflation
Most attribution models—linear, time decay, data-driven—distribute credit across multiple touchpoints in a single customer journey. Finance records one transaction. Marketing might show 2.3 attributed conversions across channels for every deal Finance logs as one.
The math is intentional. Attribution models exist to understand channel contribution, not to count unique customers. But when attributed conversion counts flow into revenue reports without normalization, you get phantom revenue that Finance has no record of.
At one company, switching from linear attribution to last-click reduced attributed revenue by 38% on paper—without changing anything about actual performance. The business didn't shrink. The model changed.
3. Refunds and Failed Subscriptions
Marketing tracking fires at the moment of purchase. Refunds, chargebacks, and subscription failures happen later. If your GA4 purchase event fires but your payment processor processes a refund 12 days later, marketing's revenue total stays inflated.
For ecommerce, refund rates between 15% and 30% are common. If your marketing data isn't accounting for refunds and Finance's books are, you have a structural overeport of 18–43% in marketing's favor—every month, automatically.
How to Audit the Gap
Before you can close the mismatch, you need to know which of these three causes is driving it.
Step 1: Calculate the attribution-to-cash delay.
Pull 90 days of marketing-attributed conversions. Match them to Finance-recorded revenue by customer or order ID. Plot the distribution of days between the attribution event and cash recognition.
If the mean lag exceeds your reporting period—30 days for monthly reporting—your numbers will never agree at the month level. You need cohort-based reporting, not period-based reporting.
Step 2: Compare conversion count to transaction count.
Export your GA4 purchase events for 30 days. Export your CRM or payment processor transactions for the same period. Compare the count.
If GA4 shows 312 purchases and your payment processor shows 289, you have a deduplication or event-firing problem. If GA4 shows 289 and Finance shows 240, you have a refund accounting problem. The counts must agree before revenue totals can agree.
Step 3: Run a refund reconciliation.
Pull your refund and chargeback volume for 90 days. Calculate it as a percentage of gross revenue. If marketing is reporting gross and Finance is reporting net, that percentage is the structural floor of your disagreement.
Anything above 5% warrants an architectural fix. At 20%, you're making budget decisions on numbers that overstate reality by one-fifth.
The Fix: A Shared Data Layer
Each gap requires a different intervention.
For attribution-to-cash timing: Switch to cohort-based revenue attribution. Instead of asking "how much revenue did we attribute in January," ask "for the cohort of customers acquired in January, what is their 90-day recognized revenue?" This isn't a different number—it's a framing that survives Finance's reconciliation.
Build a BigQuery pipeline that joins your GA4 data against your CRM or Stripe data by customer ID. Pull revenue recognized—not attributed—30, 60, and 90 days post-acquisition for each marketing-sourced cohort. Now you have revenue numbers Finance can verify.
For multi-touch inflation: Stop using attributed revenue as a business metric. Use attributed conversions as a channel-efficiency signal, and use cohort revenue as the business metric. They're different instruments measuring different things. Conflating them is the origin of the fight.
Build two separate reporting views: one for channel attribution (where multi-touch makes sense) and one for business performance (where only recognized revenue should appear). Never put both on the same dashboard.
For refund reconciliation: Your purchase events need order IDs. Your data warehouse needs a nightly reconciliation job that flags refunded orders and adjusts attributed revenue accordingly.
In GA4, this means sending a refund event with the same transaction ID as the original purchase. In BigQuery, it means a nightly join against your payment processor's refund table. It's not complex—but it has to be built deliberately. It does not happen automatically.
You cannot run refund reconciliation or deduplication without them. Transaction IDs are required for GA4's native refund events, for matching against CRM records, and for any downstream reconciliation in BigQuery. If your current setup omits them, that's the first fix.
What the Architecture Actually Requires
A measurement infrastructure that Finance will trust needs four things:
- One canonical customer ID that persists from the first marketing touch through the CRM record through the invoice. Without this, you cannot join the data.
- Event-level transaction data with order IDs—not just aggregate session counts. Sessions don't reconcile; transactions do.
- A reconciliation layer—typically BigQuery—that joins marketing events against CRM and payment processor data nightly. Not monthly. Nightly.
- Separate reporting surfaces for attribution and for recognized revenue. Attribution tells you where customers came from. Recognized revenue tells you how the business performed. One dashboard cannot serve both purposes without corrupting both.
When Marketing and Finance disagree every quarter, it's usually because someone built reporting for one team without the other in mind. The fix isn't a meeting—it's a data architecture decision made once, correctly, at the infrastructure level.
What the Disagreement Actually Costs
The mismatch isn't just an internal friction point. It has direct budget consequences.
When leadership doesn't trust the revenue numbers, they don't trust the channel recommendations. Good channels get cut based on bad data. Bad channels survive because they can't be disproved. Budget allocation degrades month over month, quietly.
The attribution window problem alone can generate discrepancies large enough to reverse a channel funding decision. A 45-day lag combined with a 22% refund rate in one channel's cohort can make a 1.8x ROAS look like 4.2x in marketing's reporting. Those aren't close to the same business outcome.
For reference on what that kind of misread costs: we've seen $280,000+ in budget reallocated away from channels that were actually underperforming once the lag and refund adjustments were applied. The channel looked profitable. It wasn't.
The Real Problem Is the Architecture, Not the Number
It's not that Marketing is right and Finance is wrong. It's that both systems were built to answer different questions, and nobody built the layer that reconciles them.
Canonical customer IDs, event-level transaction data with order IDs, nightly reconciliation against payment processors, and separate reporting surfaces for attribution versus recognized revenue. That's the build.
It's a one-time infrastructure project. It eliminates a recurring quarterly argument. And it's the kind of measurement work that changes whether leadership trusts the data enough to act on it.