Explain an affiliate payout statement

A creator affiliate payout statement shows which orders earned commission, which remain pending, what changed after returns, and how the approved balance became a payment. Give creators enough detail to redo the calculation from a private order reference. Leave customer names, email addresses, delivery addresses and payment details out of it.

Use two connected records: an order ledger that explains earnings and a payment summary that explains the transfer. A single total cannot tell a creator whether a difference came from a refund, a hold, a missed cutoff or a currency conversion. Every worked example below is hypothetical and small enough to check by hand.

State what the statement covers

Put the creator identifier, program name, statement ID, activity period, cutoff time zone and issue date at the top. Name the commission terms and their effective date. Include the support contact for questions.

Keep these dates apart:

• The order date is when the purchase happened.
• The eligibility date is when the commission can leave its hold, after the program's checks.
• The adjustment date is when a refund or correction changed earnings.
• The payment date is when the payment provider reports the transfer's status.

A statement can contain activity for orders placed in an earlier period. Use the order reference to connect a later correction to the original entry.

Give each commission one status at the statement date. These labels are a recommendation for your own ledger, and platforms may name the states differently.

If your software uses other labels, keep its labels in exports and explain how they map to this list. One order can hold a reversed amount and a remaining approved amount at the same time. Keep the original award, append each adjustment, and track payments on their own lines. Never overwrite a paid amount to pretend the transfer did not happen.

Modash's guide to paying affiliates recommends keeping each affiliate's payment history to help settle disputes. The statement below makes that history traceable without sending a customer export.

Set the hold and the payment run before the first statement

The statement can only promise dates your systems can meet. A line such as "paid monthly after 30 days" leaves three questions open. The reader cannot tell whether the clock starts at checkout or at delivery. They cannot tell whether a commission that clears today joins this month's payment. They also cannot tell whether "paid" means submitted to a processor or received in a bank account.

Shopify Collabs' payment documentation describes a default 30-day hold that merchants can set between 1 and 90 days. During the hold, Collabs cancels commission on canceled and fully refunded orders. After the hold, commissions go on the merchant's Shopify bill, which can come earlier if a billing threshold is reached. The creator's payout then depends on the bill being paid and on the creator turning on automatic payouts. That sequence does not support a promise that every creator receives money on day 30, so a Collabs program should explain the billing step to creators.

For a custom program, choose the hold first. Check when your customer return window starts. Shopify's return rules can count from the delivery of an item or of the last item in an order. A hold counted from purchase can therefore end before a delivery-based return window closes. Review shipping delays, open return requests, refund processing time and the fields your tracking system receives. Handle unresolved orders one at a time, because a longer blanket hold makes every creator wait.

Then choose how often you pay:

Each option is an operating choice that no platform requires. Modash's guide also separates time-based payments from minimum-balance thresholds. A threshold adds another delay, so state it on its own line. If you use one, say what rolls forward and how a remaining balance is handled when a creator leaves, under your terms and the law that applies. Ask finance to price the workload and provider charges for each option, and ask creators whether the wait works for them. Do not shorten the advertised hold while adding an approval delay you do not mention.

A monthly calendar you can adapt

This hypothetical schedule assumes a delivery-based hold, no minimum payout and a provider that supports scheduled batches. It is not a Shopify setting or a bank guarantee.

Publish the dates of the next few runs beside the rule, so a creator does not have to work out holiday moves.

In the following example the creator earns 10% of merchandise value after discounts and merchandise refunds. Tax and shipping do not count. The return window closes at the end of the delivery date plus 30 days, and the order becomes eligible the next day after review. All figures are hypothetical USD.

A pays $120.00 × 10% = $12.00. B pays ($80.00 - $20.00) × 10% = $6.00. The October 5 submission sends $18.00. C stays pending at $10.00 and misses the September cutoff, even though it becomes eligible on the October submission date. Under this policy it joins the November 5 run if nothing changes. Test that cash-flow cost before you pick monthly batches.

Calculate commission after returns

Reduce commission by the eligible merchandise value that a refund removes. Reverse the full commission when the whole eligible sale goes away, and keep commission on the part the customer keeps. Treat an exchange as a linked adjustment so the same purchase earns commission once. These are recommended program rules, and your published terms and tracking system must support them before you apply them.

A refund calculation must use the same commission base as the original award. Settle these points in your terms before you approve sales, using the guide to choosing commission terms:

• Decide which products earn commission and at what rate.
• Decide how order discounts reduce each item's eligible value.
• Decide whether a shipping-only refund changes commission.
• Decide whether store credit, exchanges, goodwill refunds and restocking fees change the base.
• Decide what happens when a return arrives after the commission was paid.

Do not add a new deduction after a creator has earned under different terms. Under a merchandise-only policy, a shipping refund leaves commission unchanged. A refund with no item allocation needs review, because its total cannot tell you which rate or exclusion applies.

For a single-rate order, use these formulas:

Current entitlement = round(remaining eligible value × commission rate)
Adjustment = current entitlement - previously recorded entitlement
Unpaid balance = current entitlement - net commission already paid

Previously recorded entitlement includes earlier adjustments. Net commission already paid means completed payouts minus any confirmed repayments. For lines with different rates, calculate each line's entitlement and then add them. A negative unpaid balance means a post-payment adjustment needs a decision. It does not prove you recovered cash, and it does not give you permission to deduct it from a future payment.

The cases below assume 10% commission on eligible merchandise after discounts, excluding shipping, tax and fees. Exchange items stay with the original creator at the same rate, and every refund has completed. Each entitlement rounds to cents, half up. All amounts are hypothetical USD.

Case 2 started with items priced at $80 and $40. A 20% discount cut their eligible values to $64 and $32. Returning the second item reverses $3.20, based on its discounted value, and using the $40 list price would reverse too much.

In case 4, the customer pays the extra $20 and keeps the replacement. Link the outgoing and incoming items. If your system records a $6 reversal and a new $8 award, the net adjustment must be $2, and the old $6 award must not stay beside the full new $8 award.

Case 5 has already paid $6. Its current entitlement is $4, so its unpaid balance is negative $2. Keep the $6 payout entry and record the $2 adjustment. Follow the agreed late-return process, which may call for review instead of an automatic deduction. If you waive recovery, record that decision on its own line.

When several small refunds hit one order, recalculate the cumulative entitlement instead of rounding each refund alone:

Keep the currency and rounding rule on the ledger. Do not mix customer-currency refunds with store-currency sales in one calculation. For tiers that should not reward heavy-return sales, see designing commission tiers around returns.

An annotated hypothetical statement

Every identifier, amount, date and term in this statement is hypothetical. It shows a custom program and does not copy any platform's report.

The example terms pay 10% of eligible merchandise after discounts and refunds. Shipping, sales tax and gift cards do not earn commission. Each order belongs to this creator under the program's attribution rules. Commission stays pending for 14 days after the order, which is shorter than the delivery-based hold above so the example fits one month. There is no minimum payout threshold.

The activity period is August 1 to August 31, 2026, in UTC. The statement includes a September 5 payment confirmation. Opening approved, unpaid commission is USD 8.00, and opening pending commission is zero.

Order ledger

All amounts are USD. The starting base already excludes discounts, shipping, sales tax and ineligible products. The refunds happened in August and reduce that base.

The arithmetic for each order is:

Original commission = starting eligible base × commission rate
Reversal = refunded eligible base × original commission rate
Remaining commission = original commission - reversal

The ledger shows reversals as negative entries, while the formula treats the reversal as the positive amount being subtracted. For R-B, USD 80.00 × 10% gives USD 8.00. The USD 30.00 refund removes USD 3.00, which leaves USD 5.00.

Eligibility notes

Each unresolved amount needs a reason and an expected next event.

USD 20.00 remains after reversals, but only USD 15.00 is approved for this payment. The other USD 5.00 stays pending.

Balance and payment

Put manual adjustments on their own lines, each with a reason, an approval date and a reference to the corrected statement or order. Avoid an unexplained line named "other." In this example, the September payment includes a USD 2.00 correction approved on August 28. An earlier statement applied the wrong rate to private reference R-OLD, and the correction restores the missing commission without repeating a current order.

The pending amount must stay out of the payable subtotal. If a minimum threshold delays payment, show the approved amount carried forward and the threshold. Explain a failed transfer apart from commission eligibility.

Convert currencies once and keep the rate

Keep each sale in its transaction currency, record the commission terms, and save the exchange rate used for each conversion. Declare the rate source, effective date, quote direction and rounding rule before the payout period starts. Keep the calculated commission apart from the amount the payment provider delivers. Another person should be able to rebuild one commission without asking which exchange-rate website you opened that morning.

Name each currency on the statement:

• The transaction currency is the currency of the customer's order.
• The commission currency is the currency the program uses to record what the creator earned.
• The payout currency is the currency the payment provider sends to the creator.

Also record the merchant's billing currency and the creator's bank currency when they differ. Use codes such as USD, EUR and GBP, because a "$" sign does not identify the currency.

Start from the platform's record

Platform rules can limit your choices. Shopify's Collabs documentation says automatic payments are handled in USD and charged in the currency of the merchant's Shopify bill. A creator who cashes out in another currency pays a conversion fee. If a platform calculates and pays the commission, import its recorded amounts and currencies first and use your workbook to reconcile them. Do not replace them with a fresh conversion and call the difference an error. Ask the provider for the rate basis when the export does not explain it.

If your program controls the calculation, keep raw exports unchanged beside a workbook with these five tabs. Each imported row needs a source filename and row ID. Save approved versions so a later correction does not rewrite what a creator already received.

When a platform supplies a commission, keep that value in its own column and give your own calculation a different column name. A difference column then has one meaning. Use a unique order-and-event ID so a repeated import cannot pay the same sale twice. Keep an unresolved attribution dispute on hold, even when its currency data is complete.

Freeze the rate and its direction

Write every rate as target-currency units per one source-currency unit, such as "1 EUR buys 1.10 USD." Multiplication then converts the amount, and a column named "exchange rate" with no units cannot be read the wrong way round. Save the full precision from your source instead of a shortened display value.

The effective date tells you when the rate applies, and the retrieval date tells you when you got it. Store both, with the time zone. Choose one conversion event, such as order capture. If no valid rate exists for a row, hold the row for review instead of using today's rate.

A public reference rate is not the rate your payment provider will execute. The European Central Bank's reference-rate page quotes currencies against the euro and normally updates around 16:00 CET on working days, except TARGET closing days. The ECB publishes these rates for information and discourages their use for transactions. A missing weekend rate is therefore different from a missing order. If your policy uses a daily reference source, define what a day without a rate uses, such as the latest earlier published date, and keep both the requested date and the effective rate date. Save the rate values with the report, because a link to today's rates cannot reproduce last month's numbers.

Three orders in three currencies

The numbers, dates, rates and file name below are invented to show the method. They are not market quotes or Shopify's rules.

All three orders belong to creator C01, have approved attribution and earn 12.5%. The rate source is a saved demonstration export, demo-rates-2026-09-01.csv, effective and retrieved on September 1, 2026, at 18:00 UTC. Rates are locked at order capture, and the payout currency is USD.

The formulas are:

unrounded_commission = eligible_sales × commission_rate
unrounded_payout = unrounded_commission × locked_conversion_rate
payable_commission = round_to_USD_cents(unrounded_payout)
batch_gross_commission = sum(payable_commission)

Rounding happens once per order, after conversion, to the nearest cent, with exact half-cent ties going away from zero. The intermediate commission stays unrounded. Summing rounded rows makes the statement agree with its lines. Rounding only the batch total is another valid policy, but switching between the two can change the payment, so document one and keep it.

Refunds use the original locked rate. A full reversal cancels the original rounded commission. For a partial refund, recompute the commission on the remaining eligible amount with the original terms and rate, then subtract the previous entitlement.

Show the payment conversion on the statement

If the system converts at more than one stage, show each conversion. Record the provider, conversion date, applied rate, rate direction and any fee charged on its own. Label an estimate as an estimate until the provider confirms it. The hypothetical remittance for the August statement assumes one conversion at payment and an agreed fee paid by the creator.

USD 25.00 × 0.9000 gives EUR 22.50, and subtracting the EUR 1.00 fee gives EUR 21.50. The fee reduces the cash received, while the transfer still settles USD 25.00 of commission. In this example each order commission rounds half up to two decimals before the sum, and the conversion applies to the payment total before the fee. State your own system's method, because rounding at another stage can change totals. Do not reuse these invented rates or fees as defaults, and show the provider's record on the statement.

Report creator costs in one currency

A brand or agency often needs the same discipline for campaign costs. A total such as USD 900 + EUR 1,000 + GBP 801 has no single value until you convert it. After conversion, a reader still needs to know whether the number is a budget, an approved cost or settled cash. These are reporting conventions for campaign managers, and finance may need other rules for the books.

Keep these views in separate columns, and change the label when a settled number replaces an estimate. A partial payment leaves the remaining approved amount in outstanding costs. Agree the date policy with whoever owns the budget. Formal accounting, tax and exchange gain or loss treatment follow your finance team's requirements. Modash's creator-payment guide starts manual tracking with spend per creator and campaign, then invoice checks. For an affiliate creator, use the approved amount from the statement above as the input.

Each ledger row should hold these fields:

• The row names the campaign, creator and invoice, plus the payment or refund ID where one exists.
• The row keeps the original amount and its currency code.
• The row states the cost type, such as creator fee, usage rights or transfer fee.
• The row records the reporting currency, rate direction, rate value, source and effective date.
• The row shows the invoice date, settlement date and paid or outstanding status.
• The row stores the converted amount and the rounding rule applied.

Use a separate fee row when its currency or rate date differs from the invoice.

The next example uses a USD report with a frozen rate set dated 2026-09-01. In it, 1 EUR buys 1.10 USD and 0.88 GBP, so 1 GBP buys 1.10 / 0.88 = 1.25 USD. Each transfer fee uses the invoice currency and rate. The report covers creator fees and transfer fees only. Every amount, fee and rate is hypothetical.

The rule keeps the stored rate precision, multiplies each cost component, rounds each converted component to USD cents with halves away from zero, and then sums. Record C can be checked with no outside data:

Creator fee: GBP 801.00 × 1.25 = USD 1,001.25
Transfer fee: GBP 8.01 × 1.25 = USD 10.0125, rounded to USD 10.01
Record total: USD 1,001.25 + USD 10.01 = USD 1,011.26
Campaign total: USD 909.00 + USD 1,111.00 + USD 1,011.26 = USD 3,031.26

Wise's fee documentation explains that transfer cost depends on the amount, payment method and exchange rate. Use the fee on your own payment record instead of one percentage copied into every row. Keep three amounts apart: the creator's agreed amount, any fee deducted from what the creator receives, and the amount your business pays. If a fee is already inside the settled debit, do not add it again.

Suppose record C later settles at USD 1,010.00 for the creator payment plus a USD 10.25 fee. Its settled cash cost is USD 1,020.25, which is USD 8.99 above the reference estimate:

Principal difference: 1,010.00 - 1,001.25 = USD 8.75
Fee difference:         10.25 -    10.01 = USD 0.24
Total difference:                          USD 8.99

Keep both columns. The USD 8.99 explains the gap between two reporting bases, and this example does not classify it as an accounting exchange loss. For a refund, add a linked negative row with its own date and basis, and keep the original invoice visible. For a batch payment, record how shared fees are split and check that the split fees add up to the statement total. To count costs beyond creator payments, use the complete campaign cost ledger, and for gifted products use the seeding-batch cost guide.

Check what your platform does with refunds

Shopify Collabs documents only part of this. Its payment documentation says canceled and fully refunded orders lose their commission automatically during the hold. The page does not describe automatic proportional adjustments for partial refunds, exchange handling or recovery after payout, and it does not set a partial-refund formula. Confirm those cases in your own integration before you rely on them. The return cases above show a policy and do not describe tested Collabs behavior.

The same documentation separates the hold, merchant billing and creator payout. A commission that reaches the merchant's bill is not proof that the creator was paid. Shopify's Refund API documentation adds another check. A refund record does not guarantee that money reached the customer, so check the linked transaction status. Refund data also separates product lines, shipping and other parts, which stops you from applying a commission rate to an unrelated refund amount.

Ask the integration owner to run approved test transactions and record what happens:

This article recommends these tests and reports no results from them. Compare the commerce record, the affiliate export and the payout record. Save the event or refund ID so a repeat import cannot create a second deduction. Resolve exceptions before release. Modash's affiliate-management article stresses reliable tracking and a clear payment schedule, and for returns that means an order-level record linking each adjustment to its payout. For each adjustment, keep the order ID, creator ID, refund ID, item amounts, currency, rate, old entitlement, new entitlement, reason, source event time and processing date. The two times tell a late refund apart from a missed import.

Keep customer details off the statement

Give each order a creator-specific private reference that support can map to the internal order, and restrict that mapping. Leave out customer contact fields, order-access links, full basket descriptions and free-text refund notes. A reason such as "partial eligible-item refund" explains the adjustment without repeating a customer's message.

This is a recommended field design. In the UK GDPR context, the ICO's data minimisation guidance says personal data should be limited to what the stated purpose needs. The ICO marks the page as under review after the Data (Use and Access) Act. Private references still need controlled access, and replacing a name does not make the ledger safe to publish. Show each creator only their own rows.

Tell creators about a late payment before they chase it

Assign one person to compare planned submissions with provider records on every payment day. Treat an approved batch with no accepted transfer as unsent. A sent transfer with no confirmed receipt needs tracing.

When a run will slip, follow these steps:

1. Notify the affected creators as soon as you know, before the promised submission time where possible.
2. State the amount, the original date, the current payment state and the cause you have confirmed.
3. Give a new submission date only when finance can support it, and otherwise give the time of the next update.
4. Name the person handling the issue and any action the creator must take.
5. Send the update at that time even with no fix, and close the issue with the transfer reference and a new arrival estimate.

Here is a hypothetical notice for the calendar example:

Your $18.00 payment scheduled for October 5 has not been submitted. Our finance approval missed the bank cutoff. We plan to submit it on October 6 and will confirm the transfer reference by 16:00 UTC that day. No action is needed from you. Your program manager is handling this with finance. If submission fails again, we will still send the update at that time.

Do not describe a payment as sent to make a delay sound smaller. Keep other approved balances moving where your payment system and terms allow it.

Keep disclosure and tax apart from the ledger

Confirm payout setup and any invoice process during onboarding, before the first payment is due. Have a qualified adviser decide tax documents, reporting and withholding for the countries involved. Shopify's tax note for Collabs payments also sends merchants to local tax authorities or tax professionals. None of the templates here is tax or legal advice.

Put disclosure instructions in onboarding too, even while commissions are pending. For endorsements that reach US consumers, the FTC's influencer disclosure guidance calls for clear disclosure of financial relationships with brands, placed with the endorsement. Posting from another country may not remove that duty. The FTC's endorsement guides FAQ asks for clear, conspicuous disclosure of the retailer relationship near the recommendation, and warns that the label "affiliate link" alone may not explain it. A private payout statement does not tell the audience about the relationship, and the payout date should not be what triggers a disclosure.

Check the statement before you send it

Run these checks on every batch before it goes out:

• A second person rebuilds one order, one reversal and the transfer total from the saved records and reaches the same cents.
• That person also rebuilds one order per currency from the saved rate export through to the transfer record.
• Every amount has a currency code, and every rate has a direction.
• Rows with missing rates, unclear currency fields or open approvals stay on hold instead of turning into zero or one.
• Every adjustment points to an original order, and every commission appears in only one payment batch.
• Pending, approved, reversed and sent amounts appear on separate lines.
• Gross commission, creator-paid fees and the amount sent appear apart, and merchant-paid fees stay out of the creator deduction column.
• Each fee appears once, including a fee already inside a debit.
• Every pending amount has a next review date, and every deduction has a reason the creator can question with its private reference.

Before you publish your schedule, take one order that clears the day before cutoff and one that clears the day after it, and write the expected payment date for both. Send those two examples with the dates of the next three payment runs and the name of the person who handles delays. For questions creators ask about edge cases, add answers to your affiliate program FAQ.