A partner reports more conversions. Your acquisition dashboard looks healthier. Then the approved count barely moves, and the invoice introduces another number.
Before deciding the partner is improving, underperforming, or billing incorrectly, build one reconciliation. The useful question is: which outcomes belong to this agreement, what happened to them during validation, and which charges are now due?
This is an advertiser-side commercial review. It does not require treating every discrepancy as a technical failure or every rejected conversion as misconduct.
Define the outcome before comparing the totals
“Conversion” is too broad for an invoice check. An install, a completed registration, and a first successful payment can all be legitimate conversion events while only one is payable under your agreement.
Write a short definition covering:
- App, operating system, eligible markets, and partner source
- The exact completed action and whether repeat actions count
- New-user, reinstallation, and existing-customer treatment
- Attribution rules, including the applicable window
- Acquisition dates, event dates, time zone, and reporting cutoff
- Validation period, permitted adjustments, and payment conditions
Separate the cohort boundary from the status cutoff. “Users acquired during September, reviewed through October 10” is different from “events received during September.” It is also different from the September invoice period.
AppsFlyer distinguishes events grouped by acquisition date (its “LTV” view) from events grouped by activity date (its “Activity” view), and it lists freshness, filters, time zones, and currencies as discrepancy checks. Those are reasons to align your exports before subtracting one total from another. AppsFlyer’s discrepancy guide
Keep a saved description of each export alongside the file. A comparison nobody can reproduce is unlikely to settle a commercial question.
Give every recorded outcome a place in the ledger
Start with a fixed set of recorded candidate outcomes. Use one agreed deduplication method and retain enough internal history to explain removals. Then classify each outcome at the same cutoff:
- Pending: validation has not concluded
- Approved: the relevant validation process accepted it
- Rejected: it did not pass, with a recorded reason
Scaleo’s built-in conversion statuses are approved, pending, rejected, and trash. That terminology is platform-specific; map another system’s labels rather than assuming identical behavior. Scaleo’s conversion-status guide
For a three-status ledger, recorded equals pending plus approved plus rejected. If your system also uses trash, canceled, reversed, or other statuses, include each one explicitly. Do not silently discard them to make the arithmetic work.
Add separate fields for contractual eligibility, payable amount, invoice inclusion, and settlement. Eligibility is a rule assessment; approval is a recorded status; payable is a commercial obligation under the agreement; settlement is the actual payment record. These concepts may align in your workflow, but they are not interchangeable.
An approved event might already have been invoiced. An invoice might remain unpaid. A later adjustment might change an earlier balance. None of those can be resolved by looking at the approved count alone.
For a reusable ledger, keep these columns: cohort, source, goal, recorded, pending, approved, rejected by reason, payable count, payout rate per outcome, payable amount, invoice reference, settled amount, and cutoff. Put changing status history in a linked detail view rather than overwriting the only record of the earlier position.
Work through a compatible comparison
Here is an illustrative example, not BerryGood or partner performance data. Two acquisition cohorts have each completed the same 14-day observation window. They use the same goal and eligibility rules; some validation remains open.
- Cohort A: 1,000 recorded, 100 pending, 800 approved, and 100 rejected
- Cohort B: 1,400 recorded, 350 pending, 800 approved, and 250 rejected
Recorded volume rose 40%. Approved volume did not increase. Approved as a share of recorded fell from 80% to 57.1%.
That does not establish the final approval rate. Cohort B still has 350 unresolved outcomes. Calling all of them rejected would invent a decision that has not happened.
You can also calculate the approval share among resolved outcomes: 800 ÷ 900, or 88.9%, for A; 800 ÷ 1,050, or 76.2%, for B. Label that denominator clearly. It answers a different question and can mislead if difficult cases take longer to resolve.
Now suppose all 800 approved outcomes in each cohort are contractually payable at $8 each, with no other charges or adjustments. Each cohort represents $6,400 in payable acquisition charges under those assumptions. That is an advertiser expense, not customer revenue or proof of payment.
The practical conclusion is narrow: the extra recorded volume has not yet produced extra approved outcomes, pending exposure is larger, and rejection reasons need review. You do not yet have a sound basis for extrapolating the partner’s headline growth into more payable customers.
Explain the difference before escalating it
Break discrepancies into categories you can test.
Different definitions: One export counts trial starts while another counts successful payments. Rebuild both around the contracted action.
Different dates: One report includes late purchases from older users; another includes only the current acquisition cohort. Match the date basis and cutoff.
Unresolved or changed statuses: A fresh report includes validations or reversals missing from an earlier export. Compare snapshots and status-change history.
Eligibility or duplication: A recorded event falls outside the agreed market, operating system, or new-user rule, or repeats an already counted action. Verify the actual rule and evidence.
AppsFlyer’s validation-rules documentation covers advertiser-defined restrictions such as geography and OS version, and blocked installs and events are reported in its validation-rules raw data. A blocked outcome can reflect eligibility enforcement; the label alone does not establish intentional fraud. AppsFlyer’s validation rules guide
Do not change validation rules simply to force agreement. If a rule was applied incorrectly, document the correction and the affected scope through the responsible process.
Send a discrepancy request someone can answer
A useful request specifies the population, the size of the gap, and the evidence needed. For the fictional Cohort B above, the request might read:
“Please reconcile the 1,400 recorded outcomes against the agreed acquisition cohort and 14-day observation window. Our ledger contains 800 approved, 350 pending, and 250 rejected.
“Please confirm the pending review date and provide category totals for the rejections, with the applicable rule references. We also need the invoice mapping for the 800 currently payable outcomes.”
Include report names, export timestamps, filters, and agreement version. Start with aggregated evidence. If record-level matching becomes necessary, use the approved secure channel and share only the minimum authorized references. Keep customer details, device identifiers, tokens, and unrestricted raw logs out of routine correspondence.
Assign an owner and a review date. Until the gap is explained, hold the growth decision to the evidence already established: mature approved quality, agreed charges, and bounded unresolved exposure. More reported conversions are useful only when you can explain what they became.
