Reporting · By GetBonus · October 18, 2026

Why CPA conversions are pending: statuses, delays and reconciliation

Understand clicks, pending actions, approved commissions and paid revenue, and build partner reporting that explains delays without misleading totals.

A click and a confirmed action are different events

A visitor can click an offer without completing its qualifying action. A completed action may then need provider validation. That is why a dashboard can legitimately show clicks while confirmed actions remain at zero. The interface should explain the distinction instead of implying that every visit earns money.

Awin’s transaction API documentation distinguishes transaction statuses including pending, approved and declined. Other systems may use different names. Preserve the original provider status alongside your normalized reporting state.

Use a small, explicit reporting vocabulary

Separate recorded clicks, pending actions, confirmed actions, declined actions and paid commission. Confirmed and paid are not interchangeable: an approved transaction is not evidence that funds have reached your account. If your earnings are calculated on funds received, show that basis clearly.

Keep adjustments and reversals visible. Quietly deleting a previously confirmed action makes historical totals impossible to explain. Instead, preserve the original transaction and record the correction with its source and effective date.

Explain time without promising a deadline

Confirmation depends on the campaign’s qualifying event and validation process. A trial-start campaign and a first-paid-month campaign measure different milestones. Do not hard-code a universal waiting period into the interface. Display a provider-specific expectation only when it is documented.

Show both the reporting period and the last successful synchronization time. An empty period can mean no eligible activity, unresolved pending actions or stale data. These states need different messages. “No confirmed actions yet” is more informative than a bare zero, but only if synchronization is working.

Choose a date basis for comparisons

A click cohort groups results by the original click date. A validation report groups results by when approval occurred. Either can be useful, but combining them without labels produces misleading conversion rates. State which date controls the dashboard and preserve the other timestamps for drill-down.

For an illustrative example, ten actions recorded in September might be approved in October. September’s click cohort changes as approvals arrive, while October’s approval report records the validation activity. That is expected, not necessarily a bug.

Reconcile delayed reports systematically

For each import, store provider, transaction ID, source timestamp, currency, status and amount. Re-import overlapping periods to pick up changes, while deduplicating stable transaction identities. If there is no API, a controlled export can use the same normalized pipeline; it should not overwrite all partner totals with spreadsheet aggregates.

• Compare counts and amounts by provider and currency.
• List transactions with no matching click or partner.
• Review status changes and negative adjustments.
• Keep a record of the imported file and processing result.
• Show stale-data warnings when synchronization fails.

For the underlying event handling, read the postback guide. Use revenue estimates for planning, not as a replacement for validated reporting.