Deadlines and validation periods

A pending commission is only yours to change for a while. When the network's validation period ends, whatever you have not reviewed is approved, invoiced and usually beyond reach. The Deadlines screen is the countdown: what auto-approves next, how much is riding on it, and the rule each network is counting by.

What the deadline is

Every network has a window between tracking a sale and settling it. They all call it something different — auto-validation period, locking date, validation period, transaction update window — and they all end the same way. Awin puts it plainly: "If a commission isn't reviewed before the period ends, it will be automatically approved in line with your program's auto-validation settings."¹

After that, reversing it is usually not possible. Awin says approved commissions cannot be reversed by the advertiser; impact.com says "You cannot modify or reverse actions after they lock";² CJ says cancellations cannot be processed for orders already locked or closed.³ This is why AffCheck leads with a date rather than a total.

The periods we start from

AffCheck fills in a default per network from that network's own documentation, with the date we read it shown next to the setting:

A default is a starting point, not your agreement. The number that applies to you is the one in your programme terms. Set it on the Deadlines screen and every pending transaction on that network is re-dated in the same request, so the new dates are on the page you just saved.

Where a network publishes no default, AffCheck leaves the rows undated rather than inventing a deadline, and the screen says how many rows are waiting for a period.

The longer version of this table — each network's maximum, where the number is set, and how solid each row is — is in the guide on affiliate validation periods by network.

CJ is a date, not a day count

Most networks count days from the transaction. CJ counts to a calendar date: corrections for the previous calendar month are due before the 10th of the current month.³ A transaction on 2 January and one on 30 January share a deadline of 10 February.

AffCheck has a separate rule for this rather than approximating it with a day count, so CJ dates are right at month ends, year ends and leap days. If your CJ programme is on a custom lifecycle — locking a fixed number of days after the event — switch the rule to a day count on the Deadlines screen.

Setting your own period

Each network on the Deadlines screen has its rule and its number. Change either and AffCheck re-dates that network's pending rows immediately, then re-runs the rules in the background, because the validation period is something the rules read too.

Awin's own advice on choosing the number is worth repeating: your returns period plus about a week.⁴ A period shorter than your returns window guarantees you pay commission on returns that have not happened yet.

Why the dates are UTC

A deadline date in AffCheck is the network's UTC calendar day, because that is the day the network acts on. A store in Auckland or Los Angeles sees the same day the network will use, and where your local calendar says something different, the screen says so instead of quietly rounding the deadline into yesterday.

What your store's timezone decides is today: "in 4 days" is counted from your own calendar.

Overdue rows

A pending row whose date has passed is shown as overdue rather than hidden. It may already have been approved — your next export from the network will say. The honest position is that the row is probably gone, and the overdue count exists so a short period or a missed week is visible rather than silent.

Did auto-validation catch it?

Settled rows in your imports — already approved or declined — are not suggestions and never become them. They answer a different question, on the overview: of the rows a rule would have flagged, how many did your network decline on its own, and how many did it approve anyway?