Why you should record the handicap a score was played off

This is a small technical decision with an outsized consequence, and it is wrong in a lot of golf league spreadsheets and in more than one piece of golf software. We got it wrong ourselves and fixed it, which is why it is worth writing down.

The bug#

You have a members table with a handicap_index column, and a scores table with points and gross. To compute a player’s net result you look up their handicap index, convert it to strokes, and apply it.

Clean, normalised, and wrong.

In October, a member’s index moves from 14.3 to 12.1. Now:

• Every round they have ever played recalculates with 12 strokes instead of 14.
• Their Stableford points drop across the whole season.
• Their finishing positions change in rounds that were decided months ago.
• Everyone who finished near them in those rounds moves too.
• The season table shifts for players who did nothing.

Nobody edited a score. The season simply changed overnight, and there is no record of why.

The fix#

Store the playing handicap on the round, as a number, at the moment the player joins the field:

event_players:
  event_id
  player_id
  playing_handicap   ← integer, stamped when the player joins the field

The player’s current index is the default for that value, not the source of it. Once stamped, changing the index affects future rounds only.

Two related places need the same treatment, and this is where it usually leaks:

• When an admin builds the field, stamp the handicap then — not at scoring time, when the index may already have moved.
• When the official score is written from live hole-by-hole data, record the handicap the points were actually computed with, so the stored total and the stored handicap can never disagree.

Why this is not over-engineering#

The counter-argument is that normalising is correct and duplicating the handicap is denormalisation. That argument mistakes what kind of value this is.

A handicap index is a current measurement. A playing handicap on a round is a historical fact: this player received this many strokes in this competition. Historical facts get stored, not derived. It is the same reason an invoice records the price at the time of sale rather than joining to the current price list.

Once you see it that way, the alternative looks obviously wrong: you would not recompute last year’s invoices when you change your prices.

What it enables#

Beyond correctness, storing it makes three useful things possible:

• Auditing. “Why did I get 34 points?” is answerable from the round alone.
• Handicap review. You can look at how a member has performed against the handicap they were actually playing off over time, which is the only meaningful version of that question.
• Corrections that behave. Correcting a score fixes that round. Correcting a handicap fixes future rounds. Two different operations with two different scopes, which is exactly what an organiser expects.

That last point interacts with score corrections. If a handicap really was wrong on the day — the member gave you the wrong number — you correct the stamped value on that round specifically, and only that round recomputes.

How to check your own setup#

In a spreadsheet: look at the formula that computes net or Stableford. If it references the member’s handicap on a separate members sheet by lookup, you have the bug. The handicap should be a value in the round’s row.

In software: change a test member’s handicap index and then look at a completed round from last month. If their points changed, you have the bug.

That second test takes thirty seconds and is worth running against anything you are considering buying.