Skip to content
Newv6.18.0Generated values for buyer deliveries, a safer Google Sheet connection, and a post log filter step that explains itself.Read the changelog
Returns

A return is a claim until you approve it.

Buyers submit returns with a reason. You approve or reject them. Only an approval touches money — and when it does, the payout correction is exact.

Start Free Trial
Book a Demo
Buyer-submitted
Admin approval
Exact payout correction
Lead returns queue showing submitted returns awaiting approval with payout adjustments
The return lifecycle

Nobody returns a lead by uploading a spreadsheet

A return starts with the buyer. They submit a request against a lead they bought and say why. It lands in your queue as Pending, where it sits — costing you nothing and changing nothing — until an admin makes a call on it. Approve, and the sale is reversed, the payouts are corrected, and the lead is marked returned. Reject, and it is as if it never arrived.

  • Pending, Approved, Rejected — three states, and only one of them moves money
  • The buyer’s reason travels with the request, so you are deciding on something specific
  • Approval reverses the ledger, marks the lead RETURNED, and can postback the traffic source
Return requestpending
LD-48213$42.00
submitted by Acme Insurance · “outside our state coverage”
admin reviews
Approve
Reject
Sale reversed · is_returned
Lead status → RETURNED
Ledger entries reversed
Source payout adjusted

Reject changes nothing — the lead and the ledger stay exactly as they were.

The payout correction

Subtract the slice, not the whole lead

A lead can sell more than once. So when one of its sales comes back, the source’s payout has to lose exactly what that sale added and nothing else. The correction is applied as a delta — each transition contributing its own amount, atomically — rather than recomputing the payout from scratch and hoping the arithmetic lands. It is floored at zero, so a correction can never leave a source owing you money.

  • GREATEST(0, source_payout + delta) — the floor is not a rounding detail, it is the guarantee
  • Two confirmations on different sales of the same lead cannot overwrite each other
  • Bulk CSV returns run through the same math, one delta per lead, not one overwrite per file
Source payoutdelta, not overwrite
Sale A · sold+$8.00
Sale B · sold+$6.00
Sale A · returned−$8.00
Sale B still owed$6.00
GREATEST(0, source_payout + delta)

Floored at zero: a correction can subtract what a sale added, but never drive a source below nothing.

What you get

A returned lead is a financial event

Datahubb treats it like one — an approval, a reversal, a correction, and a number in your reporting that still adds up afterwards.

Approve or reject, one queue

Buyer-submitted returns land as Pending with the lead and the stated reason side by side. Approving reverses the sale. Rejecting changes nothing at all — the lead and the ledger stay exactly as they were.

The payout correction is delta math

Each transition adds or subtracts only its own contribution to the source’s payout, floored at zero. Return one sale on a lead that sold twice and only that sale’s slice comes off.

Bulk CSV for volume

When a buyer sends back a month of leads at once, upload the file and process the batch together — a reason recorded per lead, the same approval outcome applied to each.

Reasons, not just counts

Every return carries the reason the buyer gave. Predefined reasons keep them groupable, so “these came back” becomes “these came back because of this”.

A return window you set

How long after a sale a return may be submitted is a policy you configure, along with the reason list and optional auto-approval for the cases you never want to hand-review.

Reversal, then postback

An approved return reverses the ledger entries, marks the sale returned, sets the lead to RETURNED, and — where the traffic source is configured for it — fires an outbound postback so the source hears about it too.

How it gets used

From claim to corrected books

The queue is the workflow. Everything else — the window, the reasons, the CSV — exists to make working it faster.

Set the return window, the reason list, and auto-approval rules per arrangement
Work the pending queue lead by lead, or upload a CSV when a buyer returns a batch
Approved returns leave the billable set immediately, so invoices reconcile
A returned lead that a buyer later re-accepts reactivates, and its source payout accumulates rather than resetting
FAQ

Frequently asked questions

Normally the buyer. They submit a return request against a lead they bought, with a reason, and it lands in your queue as Pending. An admin then approves or rejects it. Nothing financial moves until that decision is made, which is the point: a return is a claim, not a fact, until you agree with it.

It is corrected by the amount that sale contributed, and no more. The adjustment is applied as a delta — GREATEST(0, source_payout + delta) — rather than an overwrite, so a lead that sold to two buyers only loses the returned sale’s slice, and two corrections landing at once cannot clobber each other. The floor at zero means a correction can subtract what a sale added but can never drive a source below nothing.

Yes, if you want one. The return window — how long after a sale a buyer may return a lead — is a policy you configure, alongside the list of acceptable reasons and, optionally, auto-approval for the cases you would always wave through anyway. A return outside the window is yours to decide on.

Reject it. A rejected return request is marked rejected and that is the end of it: the lead keeps its status, the ledger entries stand, and the source keeps its payout. There is no partial state and nothing to undo, because approval is the only path that touches money.

Yes, and it leaves your billable numbers as it does. A returned sale is excluded from the billable set, so what a buyer owes you on their invoice drops the moment the return is approved, and a separate Returned counter keeps the volume visible rather than making it vanish. Margin and return rate move with it.

No, and conflating the two is how reporting goes wrong. A return is a clawback: the lead was sold, revenue was booked, and approving the return reverses it. A rejection on a CPA sale that was still awaiting confirmation means nothing was ever booked, so there is nothing to reverse. They are tracked as separate statuses on purpose, and returns analytics counts only real clawbacks.

Yes. The bulk returns upload can act on a CPA sale that is still pending confirmation — marking it accepted confirms it and books the revenue and payout exactly as the buyer’s own postback would; marking it rejected declines it with no ledger reversal, because none was ever made. It is useful for backfilling conversions a buyer never posted back. If a real postback lands at the same moment, one of the two wins and the other is skipped with a note, so nothing is booked twice.

Approve the returns you agree with. Reject the ones you don’t.

Start your 14-day trial. Full platform access. Card required, no charge if you cancel during the trial.

Start Free Trial
Book a Demo