The Rule Travels with the Date — What a Deadline Board Does Not Store

Stated up front. In June 2026 this magazine ran a piece about an accounting practice's deadline board. This is not a specific firm. We constructed the shape exactly as it actually works, and we do not name where. What follows was built to that shape, and the clients and filing items are invented.

The difficulty in this domain is not arithmetic. It is that a rule and a date are different things, and the office always loses the rule.

Suppose a spreadsheet cell says 2026-04-27. Whoever reads it has no way of knowing whether that is the statutory date, a date pushed because of a weekend, or a typo from copying last year's sheet.

So this board stores no deadline at all.

What it stores is rules

/// A filing obligation, as a rule rather than a date.
class Duty {
  const Duty(this.client, this.name, this.dayOfMonth, this.monthOf, this.note);

  /// Statutory day of the month.
  final int dayOfMonth;

  /// Which month it lands in, relative to the period being filed.
  final int monthOf;
}

No date. Only the rule that says which day of which month. The date on screen is computed from that rule every time.

And the verification confirms it. If a deadline on screen exists as a string in the source, it fails.

for D in $(grep -o "20[0-9][0-9]-[0-9][0-9]-[0-9][0-9] D-\?[0-9]*" captures/run.log | awk '{print $1}' | sort -u); do
  if grep -RIn --exclude-dir=captures -F "$D" deadline_server/bin deadlines.mbd bundle_host/lib; then
    echo "   due date $D is a literal in the sources — it must be computed"
    exit 1
  fi
done

This check actually caught something. The first run failed, and the cause was 2026-04-27 that I had written as an example in a doc comment. A false positive — it is a comment, not a stored date.

But fixing it turned up a real one alongside. The state response had 'today': '2026-04-20' hard-coded as a string, and that value and _today further up the file were two places that had to agree.

// Derived, not typed twice. Two places that must agree eventually
// disagree.
'today': _fmt(_today),

What the check caught was a comment, but going to look fixed a real one. A check producing a false positive and a check being useless are different things.

If it slipped past a weekend, it says so

The signature trap of this domain. Everybody knows the rule and every spreadsheet forgets it.

/// Shift a statutory date off a weekend, and say that you did.
///
/// This is the rule everyone knows and every spreadsheet forgets. Returning
/// the shift as text rather than silently moving the date is the whole point:
/// "25th, moved to Monday" is checkable, "27th" is not.

The execution log.

2026-03-31 D-20  Dodam   Corporate tax        [day 31 of month 3]
2026-04-10 D-10  Hanbit  Withholding — March  [day 10 of month 4]
2026-04-10 D-10  Seum    Withholding — March  [day 10 of month 4]
2026-04-27 D7    Hanbit  VAT — Q1   [day 25 of month 4 · statutory 25th fell on Saturday]
2026-04-27 D7    Dodam   VAT — Q1   [day 25 of month 4 · statutory 25th fell on Saturday]
2026-04-30 D10   Seum    Local income tax     [day 30 of month 4]

04-25 really was a Saturday, so it moved to 04-27, and the reason is in the brackets. Note that the rows that did not move carry their rule too — explain only the moved ones and leave the rest as bare dates, and a row with a rule and a row without become indistinguishable on screen.

The verification looks at both.

grep -q "statutory 25th fell on Saturday" captures/run.log || exit 1
grep -q "\[day 10 of month 4\]" captures/run.log || exit 1   # rules on unmoved rows too

Narrow it to one client and the rules follow unchanged.