Two Records of the Same Sale
Somebody clicks your link at 14:02 on a Tuesday and buys. Two systems write that down.
The network writes a row with a status on it. On Affise that status is one of four published values: Approved is 1, Pending is 2, Declined is 3, Hold is 5. On Everflow it is approved or rejected, with an On Hold label sitting in front of both, which their documentation describes with unusual honesty as "only nominally called Conversions since the sale hasn't been fully accounted for."
Your tracker writes a row with a timestamp on it. Then it fires a pixel and a server-side event, and moves on.
Over the following four weeks, the network's row moves. Yours does not. That is the whole article. I have started calling yours the frozen conversion, because that is precisely what it is: a record that was accurate at the instant it was created and has been drifting away from the truth ever since, with nothing in the system aware that drift is possible.
The network's row carries a mutable status; the affiliate's row carries a timestamp, and nothing in the affiliate's stack is designed to learn that the first one changed.
Why the Ad Platform Cannot Fix This For You
The obvious question is why the ad platform does not just find out. It has an entire attribution apparatus. Surely it notices.
It does not, and the reason is structural rather than negligent. A conversion event sent to Meta's Conversions API carries a value, a currency, an order ID, content IDs, a predicted lifetime value and a handful of other fields. It is a report of something that happened at a moment. There is no lifecycle attached to it.
I want to be precise here, because there is a trap. Meta's custom_data parameter list does contain a field literally named status. Read the definition and it is the status of a registration event, not a mutable state on a purchase, and there is no documented mechanism for changing it after the event has been sent. So the accurate statement is not "Meta has no status field". It is that Meta has no concept of a purchase event whose truth value can be revised later by the entity that reported it.
There are correction mechanisms. Google Ads documents conversion adjustments, retractions and restatements. Meta accepts custom refund events. TikTok has a CancelOrder standard event. All three exist. All three require somebody to fire them.
And nobody in the chain is assigned that job. The network is not going to, because your ad account is not part of its record and it has no credentials for it. The ad platform is not going to, because it was told once and has no channel to be told again. Which leaves the affiliate, who in most setups does not know the status changed.
The Switch You Do Not Own
Here is where it stops being a design accident and starts being a specific, documented, findable configuration.
Affise's affiliate postback documentation contains this sentence: "The system sends affiliate postbacks for the conversion statuses selected in Settings > Affiliates > General > Conversion status in Affiliate panel's statistics."
That single selection governs two things at once. It decides which statuses an affiliate can see in the panel, and it decides which statuses fire a server-to-server callback to the affiliate's own tracker. If Declined is not in the selection, a declined conversion is not just missing from a dashboard you rarely open. It never reaches your software.
Everflow's version is a three-way control called On Hold Partner Visibility, and the middle setting is the one to sit with. Restricted: partners can see approved conversions and on-hold conversions, "but not rejected ones."
Approved, yes. Pending, yes. Rejected, no.
I do not think that is malicious, and I want to say so clearly rather than letting an implication do the work. Everflow's own documentation gives the reason a network turns visibility down, which is that partners seeing pending status "may cause confusion", and anyone who has run an affiliate program knows that is a genuine support cost rather than a cover story. The setting exists for a real reason.
But the consequence is indifferent to the reason. On both of the major network platforms, the middle option, the reasonable-sounding one, hides exactly the outcome that costs you money.
Everflow's Restricted setting shows approved and pending conversions and hides rejected ones; on Affise, a status you are not shown is a status your tracker is never sent.
The Arithmetic
I am not going to invent a decline rate, because I do not have one and neither does anyone else who publishes a number for it. What I can do is show you the shape of the function, which is the useful part anyway.
Let d be the share of your conversions that get declined or reversed after firing. Your reported conversion count is inflated by a factor of 1 ÷ (1 − d), and so is any ROAS you calculated from it.
That is the reporting damage and it is the smaller half. Here is the larger half, and it is the reason I think this is worth an article rather than a footnote.
Every one of those declined conversions was sent to Meta, Google or TikTok as a positive training example. Not a number in a report. An instruction. The lead whose phone number was disconnected became a labelled example of a person worth finding more of, and the bidder has been dutifully finding more of them ever since, with your money, at auction speed, for as long as the campaign has been running.
A wrong number in a dashboard is embarrassing once. A wrong label in a training set is expensive continuously, and it gets more expensive the better the optimiser is.
Which produces a result I did not expect when I started writing this down. The affiliates most exposed to this are the ones running the most sophisticated automated bidding, because they have delegated the most decisions to a model that is being fed the corrupted signal. The person still bidding manually on a spreadsheet is, for once, less damaged.
Why It Got Worse Recently
Three things moved at the same time, and none of them looked like this problem when they happened.
Automated bidding stopped being optional. When you set bids by hand, a wrong conversion produced a wrong report that you read on Monday and corrected. When a model sets them, a wrong conversion produces wrong spending, continuously, without ever surfacing as a report anyone reads.
Tracking moved server-side. This was the right call for every reason people made it. It also moved the conversion payload out of a tag manager container someone occasionally opened into a pipeline nobody looks at again after setup day. Better data, less visible.
Network platforms got better at holds, not at telling you. Everflow's on-hold tooling has genuinely improved: bulk approve and reject, editable notes that carry through, Potential On Hold Revenue on the partner dashboard, flowchart integration showing unrealized revenue. That is real work and it makes the network operator's life better. The affiliate-facing half of it is still one global visibility setting with three options.
What Good Looks Like
Strip out the vendor names and the requirements are short.
Your record of a conversion should be mutable, because the network's is. A row that can only be created and never revised is a row that will be wrong and cannot know it.
Your tracker should be able to receive a status change, in whatever vocabulary the network speaks, and not just a refund. A declined lead is not a refund. Nobody was charged and nobody was reimbursed. Something that was worth $89.10 became worth zero, and if your ingestion only understands the word "refund" then the most common form of reversal in performance marketing has no name in your system.
And a status change should propagate outward, automatically, to every ad platform that was told about the original. Google takes an adjustment. Meta takes a custom event. TikTok takes CancelOrder. The mechanisms are all documented and none of them are hard. The only reason it does not happen is that no piece of software in the standard affiliate stack has decided the job belongs to it.
So What Do You Do About It
Ask one question, in one email, to your affiliate manager: which conversion statuses is my account configured to see and to receive postbacks for?
On Affise that is a single named setting and the answer is a list. On Everflow it is Invisible, Restricted or Visible. Either way it takes them thirty seconds to look up and it is not confidential. If the answer is that you only receive approved conversions, you have learned something exact: your tracker holds a permanently optimistic record, every reconciliation has to come from their reporting rather than yours, and the gap between the two numbers is the money you have been optimising on and were never paid.
Here is how the answer maps to what you should actually do next.
Three questions separate a closed loop from a permanently optimistic record, and the second one is answered by a setting in somebody else's account.
Then close the loop in whatever direction you can. ClickerVolt will push a reversal out to Google as a conversion adjustment, to Meta as a refund event and to TikTok as CancelOrder, which turns a monthly reconciliation into a signal instead of a spreadsheet. I will also tell you exactly where it is short today, because I checked the code before writing this: its ingestion accepts refund and chargeback wording and does not yet accept a bare "declined", so a network status change needs mapping before it routes. That is on our list, and the reason it is on the list is that writing this put it there.
Even if you never automate a single part of it, ask the question. Knowing whether you are on Restricted changes how you read every number you have.
