How to automate affiliate commission tracking that holds up to a dispute

Affiliate commission is a payment made on the basis of an attribution decision, which makes it unlike most reporting automation. Somebody receives money because your system concluded they caused a sale, and if they disagree they will ask you to show your working.

That determines the design. The calculation matters less than the record — what was attributed to whom, on what basis, and what changed afterwards — because the disputes are about the record and a system that cannot produce one loses them by default.

What we'll cover

• Commission is a payment, not a report
• Attribution windows and their edges
• Reversals, which are not optional
• Building it with CodeWords
• The record that answers a dispute
• Fraud, which exists at any scale
• Paying, and the part that is finance
• What partners actually want to see
• Making it survive
• Limits worth knowing about
• What to build first
• Frequently asked questions

Commission is a payment, not a report

Errors move money, in both directions, and both are unpleasant to correct.

Underpayment damages the relationship with the partner, who noticed before you did.

Overpayment is difficult to recover, particularly once it has been paid out.

Disputes are adversarial by nature, since the other party has a direct financial interest in a different answer.

The terms are contractual. What earns commission, over what period, at what rate, and when it is reversed should all be written down, and the automation should implement that document rather than an interpretation of it.

So build for auditability first and convenience second, which is the opposite of how most reporting automation is built.

Attribution windows and their edges

Where nearly all the ambiguity lives.

The window is how long after a click a sale still counts — days or weeks, agreed in the terms.

Last click, first click, or shared determines who gets paid when several partners touched the journey, and this is the single most disputed rule.

Cross-device breaks tracking, so somebody clicking on a phone and buying on a laptop may be attributed to nobody.

Cookie and tracking limitations mean a proportion of genuine referrals are simply not recorded, which affects partners unevenly and is not their fault.

Direct traffic that was actually referred is the mirror image, and it is invisible.

Be explicit about all of it in the terms, since a partner who believes they operate under first-click rules and is paid under last-click will eventually notice.

Reversals, which are not optional

The part most implementations bolt on afterwards.

A refunded sale should reverse the commission, and a cancelled subscription usually should too.

Chargebacks reverse, and they arrive weeks after the sale, frequently after the commission has been paid.

Fraudulent or test orders should never have earned commission and need removing.

So there is a holding period before payment — long enough to cover your refund window — and it needs to be in the terms rather than applied unilaterally.

Handle the reversal after payment explicitly: deduct from the next payout, or invoice, with the rule agreed in advance.

Report reversals to the partner with the reason, since an unexplained deduction is the fastest route to a dispute and an explained one is usually accepted.

Building it with CodeWords

CodeWords connects to more than 3,000 integrations, so orders, refunds, and partner records can be joined into one calculation without anybody reconciling spreadsheets.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder: what earns commission, at what rate, over what window, and when it is held or reversed.
3. Authorize the connections — the commerce platform, the payment provider, and wherever partner records live.
4. Describe the exceptions: an order that cannot be attributed, a refund after payment, a rate that changed mid-period.
5. Run it against a past period and compare against what was actually paid.

You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

The record that answers a dispute

The artefact the whole system exists to produce.

Per commission, record the order, the click or referral that earned it, the timestamps of both, the rule applied, the rate, and the resulting amount.

Record the rate version, since rates change and a commission calculated under an old rate needs to be explicable later.

Keep the unattributed too. Orders that earned nobody commission are what a partner asking "what about this sale" is referring to, and having the record turns a suspicion into an answer.

Timestamp everything in a stated timezone, because window-edge disputes turn on hours.

Make it available to the partner, not only internally. A partner who can see their own detail raises fewer disputes and raises better ones.

Do not recalculate history. When a rule changes, apply it forward and keep what was calculated before, or every historical figure becomes unreproducible.

Fraud, which exists at any scale

Self-referral — a partner buying through their own link — is the most common and the easiest to detect.

Coupon and brand-term bidding where the terms prohibit it, which captures traffic that was arriving anyway.

Cookie stuffing, which sets a referral without a genuine click and shows up as an implausible click-to-sale ratio.

Sudden volume changes from one partner, in either direction, are worth a look rather than a celebration.

Refund rates by partner are the clearest signal, since traffic that converts and refunds heavily is usually not the traffic you wanted.

Report the anomalies rather than acting on them. Withholding a payment is a serious step, and an automated accusation against a legitimate partner is worse than a delayed investigation.

Paying, and the part that is finance

Automate the calculation and the statement; do not automate the payment without a person approving it.

Reconcile the total against your own records before anything is paid, since a calculation error at this point moves real money.

Handle tax and invoicing per partner and per jurisdiction, which varies and is a finance question rather than an engineering one.

Set a minimum payout threshold to avoid many tiny transfers, and say so in the terms.

Send the statement before the payment, with detail, so a partner can query it before rather than after.

Keep the payment records alongside the commission records, since reconciling the two is what an audit will ask for.

What partners actually want to see

The reporting half, which is cheap to build and does more for the relationship than the payment schedule.

Near-real-time attribution, not a monthly statement. A partner who can see a sale land the same day trusts the system considerably more than one who waits.

Pending against confirmed, separated, so the holding period is visible rather than looking like a missing payment.

Reversals with reasons, itemised, since an unexplained deduction is the most common trigger for a dispute.

Their own conversion rate, which helps them improve and costs you nothing to show.

What is coming, and when — the next payment date and the amount as it stands.

Consistency above all. A partner statement whose format or methodology changes month to month looks like something being adjusted, whatever the intent.

Making it survive

Make the calculation idempotent and reproducible, so running it twice for a period produces the same answer.

Version the rules and record which version each commission used.

Handle the partner with no valid payment details rather than failing the whole run.

Never silently adjust a historical figure — issue an adjustment with a reason instead.

Report the outcome. Commissions calculated, held, reversed, unattributed orders, and anything requiring a person.

Limits worth knowing about

A proportion of genuine referrals is untrackable, and it varies by browser and device in ways that affect partners unequally.

Attribution across channels cannot be resolved, only decided by a rule, and every rule disadvantages somebody.

Refund and chargeback timing varies, which is why the holding period is a commercial decision rather than a technical one.

Partner data includes payment details, which is among the most sensitive data you hold and deserves scoping and logging accordingly.

This is not tax or contract advice. Withholding, invoicing, and what your terms permit are questions for whoever advises you.

What to build first

The per-commission record: order, referral, both timestamps, the rule and rate applied, and the resulting amount, produced as part of the calculation rather than reconstructed afterwards. Every dispute is answered from it, and a system that calculates correctly without producing it will still lose arguments it should win.

Two habits make the difference. Record the rule and rate version used, since rates change and a commission from eight months ago has to remain explicable. And keep the unattributed orders too, because "what about this sale" is the most common partner question and only that record answers it.

Frequently asked questions

What is the most important part of commission automation?

The record, not the calculation. Every dispute is answered from it, and a system that calculates correctly but cannot show its working loses arguments it should win.

What should the record contain?

The order, the referral that earned it, both timestamps in a stated timezone, the rule applied, the rate and its version, and the amount. Plus the unattributed orders, which is what partners ask about.

Why do partners dispute attribution?

Because the rule decides who gets paid when several touched the journey, and every rule disadvantages somebody. Last click, first click, and shared attribution all produce different winners, so the terms must say which applies.

How should refunds be handled?

With a holding period before payment covering your refund window, agreed in the terms — plus a stated rule for reversals arriving after payment, deducted from the next payout or invoiced. Always report the reason.

What fraud signals are worth watching?

Self-referral, prohibited brand-term bidding, implausible click-to-sale ratios, sudden volume changes, and refund rates by partner. Report them for investigation rather than acting automatically.

Should the payment itself be automated?

No. Automate the calculation and the statement, reconcile the total, and have a person approve the payment. An error at this point moves real money in a direction that is hard to reverse.

Why not recalculate history when a rule changes?

Because every historical figure becomes unreproducible, and a partner comparing an old statement with a new calculation will find a discrepancy you cannot explain. Apply changes forward and issue adjustments explicitly.

What should partners be able to see?

Near-real-time attribution rather than a monthly statement, with pending separated from confirmed, itemised reversals with reasons, and the next payment date and amount. Visibility prevents more disputes than accuracy alone does.

Why separate pending from confirmed?

Because otherwise the holding period looks like a missing payment. A partner who can see the amount sitting in a stated holding window asks nothing; one who sees a gap asks immediately.

Related reading

• Lemon Squeezy and CodeWords
• Connecting QuickBooks to Google Sheets
• Automating report generation