RefficksBlog

Switching affiliate software without paying anyone twice

By The Refficks team · · 10 min read

Moving a partner program to new software looks like a data job: export the partners, import the partners. The partner list is the easy part. The hard part is money: commission the old system has already paid, commission it still owes, and the weeks when both systems are running and both believe a sale is theirs.

This guide is the order to do it in, so that every partner is paid once, for the right sales, and can see why. There is a checklist at the end.

What can go wrong

A switch fails in one of four ways, and each one lands on a partner:

  1. Paying twice. Both systems count the same sale while they overlap, and both pay it.
  2. Paying never. A balance the old system owed never reaches the new one, or a sale falls into a gap between the two.
  3. Losing the explanation. Old history arrives as numbers nobody can trace, and the first partner who asks "why is my balance $412?" gets a shrug.
  4. Links that stop working. A partner's link in a two-year-old article stops crediting them, and nobody notices until they ask.

Each step below closes one of them.

Step 1: Take stock of what you have

Before exporting anything, list what the program holds and decide what each piece becomes:

What Moves across? How
Partners: names, emails, companies, status Yes Imported, and checked before anything is created
Discount codes and who holds each Yes As they are, so nothing printed or recorded has to change
Links Depends where they point See step 4
Commission already paid As a record A figure per partner, labeled as the old system's, never payable again
Commission still owed As a balance One opening balance per partner and currency, checked and approved
Commission still pending Usually not Let the old system finish it, or bring it as a balance once approved
Partners' payout details No Partners enter them again, themselves
Tax forms No Partners complete them again; keep the old ones on file
Commission rates and plans No Rebuilt by hand: they are decisions, not data
Emails and automations No Rebuilt, and worth rewriting while you are at it

Two of those "no" answers are deliberate. Payout details (bank accounts, PayPal addresses) should not travel in a spreadsheet, and a partner who enters them in the new system knows exactly where they will be paid. Rates belong to you, not to an export file: rebuilding them is the moment to check they still make sense (see affiliate commission structures).

Step 2: Decide what each old status means

Every platform names its commission statuses differently: pending, approved, due, unpaid, paid, rejected, voided. Do not assume a word means the same thing in two systems. Before importing, decide for each old status which of four things it becomes:

Old status means Becomes
Waiting for a refund window or your approval Pending: the old system finishes it, or you approve it later
Approved and not yet paid Owed: part of the partner's opening balance
Paid History: a figure the partner can see, never payable
Rejected or reversed Nothing

Write the mapping down. When a partner's balance is questioned in six months, it is the first thing you will need.

Step 3: Keep paid history as history, and bring balances across on purpose

It is tempting to recreate every old commission line in the new system, so the ledger looks complete. Resist it. The new system cannot explain a line it did not calculate: there is no click, no sale and no rule behind it, only a number. A ledger that can explain every line it holds is worth more than one that holds everything.

Instead:

  • Paid history comes across as one figure per partner, labeled as the old system's. Partners keep their lifetime totals, you can answer questions, and none of it can be paid twice.
  • What is still owed comes across as an opening balance per partner and currency. Check each one against the old system's own figure, then approve it. Only then is it payable.
  • Pending commission is easiest left in the old system until it is approved or rejected, then brought across as part of the balance. Bringing it across half-finished means two systems making the same decision.

Pay what is owed from one system only. Either the old system pays its last balances before the switch, or the balances move to the new one. Never both.

Codes are the simplest part: bring them across exactly as they are, so a partner's code on a podcast recorded last year still works. Check first for two partners holding the same code. A code has to mean one partner.

Links depend on where they point:

  • Links on the old platform's domain stop working when you close that account. Partners will need new links, and the old ones in their published content will need replacing. Give them the new links in the switch email, and keep the old account open, not paying, until the cutover is done.
  • Links on your own domain, with a partner code in the address (such as yoursite.com/?ref=jane), can keep working if the new tool reads the same parameter and the same partner codes. Check that before you choose a tool. It decides whether hundreds of published links survive the switch.

Step 5: Run both side by side before you switch

Before the new system pays anything, run it in the background. It tracks every sale and works out what it would pay, and pays nothing. The old system keeps paying as usual.

Then compare the two, partner by partner. Differences are expected, and each one has a cause:

  • A page without tracking. A checkout or a landing page the new system's script is not on yet.
  • A different rule. A different window, first touch instead of last, a code treated differently. (See affiliate attribution explained.)
  • A different refund treatment. One system reverses a refund's share, the other the whole commission.
  • A genuine gap. A sale one system saw and the other did not.

Fix the first, decide the second and third (and tell partners if a rule changes), and chase the fourth until you understand it. Run side by side for at least one full cycle: a holding period and a payout. A difference you have not explained before the switch becomes a partner's complaint after it.

Step 6: Pick one cutover moment

Choose a single moment, with a date, a time and a time zone. Every sale whose money changed hands before it belongs to the old system; every sale after it belongs to the new one. "Sometime next week" is how a sale gets counted twice, or not at all.

At the cutover:

  • the old system stops recording new commission;
  • the old system's balances are paid out, or moved across as opening balances (one or the other);
  • the new system starts paying from that moment, and not before.

Decide in advance who handles a refund that arrives after the cutover for a sale made before it. The simplest rule: whoever paid the commission takes it back, as an adjustment against the partner's balance if the old account is closed.

Then, for the first month, watch each partner's earnings for a sudden drop. A partner whose sales stop being credited on the day of the switch is more likely missing a link or a code than having a bad month.

Step 7: Tell partners, in this order

Partners do not need to hear about the side-by-side run. They do need to hear about the switch before it happens:

  • Two weeks before the cutover: what changes (where they sign in, their links if they change), what does not (their rate, their codes, what they are owed), and the date.
  • At the cutover: their new sign-in, their links, their opening balance and how it matches the old system's figure, and two requests: add payout details, and complete their tax form.
  • After the first payout: a short note confirming it went out from the new system.

A template for the first email:

Subject: We're moving our partner program on {date}

Hi {first_name},

On {date} our partner program moves to a new system. Your rate, your discount code and what you are owed all stay the same.

What changes: you will sign in at a new address. [If links change: You will also get new links to use from that date.] We will send everything on the day, with your balance as it stands, so you can check it against your current dashboard.

One thing to do then: add your payout details in the new portal. We are not moving bank details between systems, so nobody but you ever types them.

Any question, just reply.

{sender_name}

Step 8: Mind the tax year

If you are a US business switching partway through the year, the 1099-NEC threshold applies to everything you paid a partner in the calendar year, whichever software sent it. For payments made after December 31, 2025, the threshold is $2,000.

So a partner paid $1,500 through the old system from January to June and $800 through the new one from July needs a 1099-NEC: $2,300 in the year, even though neither system shows them over the threshold on its own. Keep the old system's payment totals for the year, and add them when you prepare the forms. If the old platform paid partners itself and filed their forms, ask it what it will report, so nobody is reported twice. How to pay affiliates covers the forms themselves.

Migration checklist

Before you start

  • Inventory: partners, codes, links, paid history, balances owed, pending commission
  • Status mapping written down: pending, owed, paid, nothing
  • Codes checked for duplicates
  • Where your links point, and whether they can keep working
  • Rates and plans rebuilt by hand in the new system

Side by side

  • New system tracking every page and checkout, paying nothing
  • Partner-by-partner comparison for at least one full cycle
  • Every difference explained: tracking, rules, refunds, genuine gaps

Cutover

  • One cutover moment: date, time, time zone
  • Old balances paid out or moved as opening balances, never both
  • Opening balances checked against the old system and approved
  • Refunds of pre-cutover sales: who handles them, decided
  • Old account kept open until old links are replaced

Partners

  • Announcement two weeks before
  • Cutover email: sign-in, links, balance, payout details, tax form
  • Earnings watched for drops in the first month
  • Old system's payment totals kept for the tax year

How Refficks handles a switch

Refficks is a new partner program platform, and its migration follows the steps above.

  • It reads your program, then waits. Upload any spreadsheet with a header row, or connect Rewardful, FirstPromoter, Tolt, Tapfiliate, UpPromote, GoAffPro, LeadDyno, Refersion or Everflow with your key. Refficks reads partners, commissions and, from most of them, codes, and holds them aside: "None of it is in your account yet." The preview shows which partners will be created, which are already there, and which rows cannot go in and why.
  • Partners already in Refficks are left alone, or have only their empty fields filled in, as you choose. Running the import again skips what came across before.
  • You say what each old status means: "Still owed to them", "Already paid", or "Cancelled, or never owed". Nothing is added up until each one has an answer.
  • Paid history stays history. It sits on the partner's page under "Before Refficks", labeled as your previous platform's figure, and is never payable.
  • Balances owed become opening balances. They arrive pending, nobody is paid until you approve them, and confirming them says in as many words: "Do not also settle this on your old platform."
  • Codes come across as they are. A code somebody in Refficks already holds waits for you to give it a new one or leave it out.
  • Links get new codes. Each imported partner gets a new link. If your old links are on your own domain, you can rename Refficks's link parameter to match yours (names used before keep working), and a developer can recreate each partner's old code through the API, so those links keep crediting.
  • Payout details are never read. Partners add them in their own portal.
  • Nobody is emailed during the import unless you choose to invite them, so partners hear about the switch when you decide.
  • The side-by-side run. While your old platform still pays, Refficks works out what it would pay for each sale and pays none of it. For a connected platform it compares the last 28 days every morning, partner by partner, with a reason for each difference: "Not seen by Refficks", "Credited to somebody else", "Only Refficks would pay", "A different amount" or "Refunded since". From a file, you run the same comparison when you choose.
  • One cutover moment. "A sale is judged by when it happened, not when Refficks heard about it." The key you gave for your old platform is deleted at the cutover, or 60 days after you gave it, whichever comes first.
  • After the switch, Refficks emails you if a partner earns much less than your old platform paid them.
  • For US tax, the 1099-NEC year export counts payouts made through Refficks, so add your old platform's totals for the year you switch.

Start free. No card needed.

Sources