Re-processing & out-of-order uploads

Statements don’t always arrive in order. You load an earlier month after a later one is already scored, and the later period was scored against a baseline that has since changed — its results are stale until re-scored.

CommissionSight fixes this for you automatically. Whenever a statement is processed (a normal upload, a replace, or a retract), CommissionSight re-scores the one immediately-following period whose baseline just changed — so backfilling February after March is already loaded auto-corrects March, no action needed. It re-scores only that single next period, never a silent cascade across the whole book. The detection flag and manual endpoint below are a fallback for the rare case the automatic pass didn’t cover (e.g. the next period was still processing) or when you want to trigger a re-score yourself.

Note

This page is about re-scoring a period whose baseline changed. If a carrier sends a corrected file for a period you’ve already loaded, that’s a replace, not a re-score — see Fixing a bad file. A replace retracts the old data and re-ingests the correction (so dropped members don’t linger), then auto-re-scores the next month.

How staleness is detected

When you list files, each one carries a rescoreSuggested flag. A period is flagged when the month immediately before it had records ingested more recently than this period was last scored — i.e. its baseline changed underneath it (the classic “February uploaded after March” case). In practice the automatic re-score above usually clears this before you’d see it; the flag is your signal for any period the auto-pass left behind.

curl "https://api.commissionsight.com/v1/files" -H "Authorization: Bearer $TOKEN"

{
  "data": [
    { "id": "…", "carrierId": "…", "periodYear": 2026, "periodMonth": 3,
      "originalFilename": "Humana - 0326.csv", "rescoreSuggested": true }
  ]
}

Re-score a period

curl -X POST "https://api.commissionsight.com/v1/files/$FILE_ID/rescore" \
  -H "Authorization: Bearer $TOKEN"

{ "jobId": "…", "fileId": "…", "status": "queued", "mode": "rescore" }

This recomputes that period’s statuses and deltas against the now-current baseline. It does not re-read or re-upload the file — the records are already ingested; only the scoring is refreshed. Poll the returned jobId like any other job; when it completes the period’s grid, rollup, and the rescoreSuggested flag all update.

If the period hasn’t been successfully processed yet, the call returns 409 (nothing_to_rescore) — upload the statement first.

Blast radius

Re-scoring is deliberately narrow. Scoring a period reads the previous month’s records as its baseline, so backfilling an earlier month makes only the one following period stale — not a cascade. Re-scoring it clears the flag without falsely flagging the months after it.

The operation is idempotent and deterministic: re-running it yields identical statuses and deltas, so it’s always safe to trigger.