Refunds, edits and balances

The ledger is append only. Nothing that has been recorded is ever edited or deleted; a correction is a new row that nets against the old one. That is what makes a creator’s balance auditable: you can always see what was earned, what was reversed, and why.

Refunds

When Shopify reports a refund, the app finds the rows that line originally wrote, for each rule that earned on it, and writes a negative row for the refunded fraction. If two of three copies are returned, two thirds of the original row is reversed.

Refund handling is a switch on the agreement (Handle refunds), on by default. Turned off, a rule keeps its earnings when the sale is refunded.

Two guarantees worth knowing:

• Repeated partial refunds cannot over-reverse. The app tracks how much of a line has already been reversed and caps each new refund to what is left, so a sequence of partial refunds can never take back more than the sale earned.
• A sale that never earned is never reversed. A rule that was excluded at the time of the sale, or that did not exist yet, wrote nothing to reverse, and the refund is a no-op for it rather than an invented negative.

Refund rows are dated to the refund, not the sale, so they land in the period the refund actually happened in.

Timing, and what a refund can and cannot undo

A refund recorded while the period is still open, or after it closed but before the batch is sent, simply reduces what that creator is owed in that batch.

A refund recorded after the money has been sent cannot be clawed back. The negative row stays unbatched and nets against whatever that creator earns next. If nothing more is ever earned, the overpayment stands. This is the one real cost of paying a period out early, and the confirmation dialog on Pay out current period early says so.

Manual overrides on a batch

Occasionally a figure needs a human correction: a contract term the rule cannot express, a negotiated one-off. On a batch that is still pending approval you can open a line and adjust an earned amount, giving a reason.

That does not edit anything. It writes a correcting row for the difference, tagged as an override with your reason attached, and adjusts the batch line and the batch total to match. Once a batch is approved the door closes: overrides are refused on approved, processing and paid batches, both in the interface and on the server.

Excluded entries

Order lines dropped by a carve out (an excluded tag, a B2B exclusion, a rule’s order criteria) are recorded separately, with no amounts attached to them. They exist so a creator’s statement can say that some entries in the period were not eligible, rather than the period silently coming up short. Nothing reads them but that count.

How this reaches the balance

A creator’s statement of account is built from the ledger plus the two ways money reaches them:

• Payout batch lines that are marked paid count against the period their batch belongs to.
• Recorded payments carry no period, so they are applied to the oldest period with an outstanding balance first, then the next, and so on.
• Rows imported as already settled count as both earned and paid in their own period, so pre-app history shows up in lifetime earnings without inflating what is owed.

A period’s outstanding figure is never negative. If a refund or an overpayment leaves a creator having been paid more than a period earned, the surplus is shown separately as unallocated credit rather than being netted invisibly against another period. The balance you see is therefore never an overstatement of what is genuinely still owed.