Skip to content
allanninal.dev/build
Collaborate

Part 4 of 7 · Tax rate updater series ~5 min read

How a rate change gets dated

A tax rate change has two dates and almost every system that watches for changes only records one. The value is not in knowing that a rate changed; you would find that out eventually. The value is in the months between the announcement and the effect, which is the only window in which anything can be done calmly.

Key takeaways

  • Two dates per change: when it was announced and when it applies.
  • A change with no stated effective date is treated as immediate and flagged as uncertain.
  • Transitional rules are read but never interpreted. They go to a person verbatim.
  • A rate that changes twice before taking effect supersedes the first notice rather than adding one.
  • The register keeps a history, so the value on any past date can be answered.

Two dates

How a detected rate change is dated and scheduledA vertical chain of five steps entered by a box labelled Value differs from the register. Step one asks whether an effective date is stated on the same page; if not it exits to Treat as immediate while saying the date is uncertain. Step two asks whether this same change with this same date has already been notified, checking a DynamoDB changes table; a revision exits to Supersede, producing one notice rather than two. Step three asks whether there is transitional text near the change, exiting to Attach it verbatim, never summarised. Step four notifies now with the checklist. Step five schedules a reminder four weeks before the change takes effect. A note says the last step is the one that turns an announcement into an action.AWS ACCOUNTValue differsfrom the registerEffective date stated?on the same pageTreat as immediateand say it is uncertainno dateAlready notified?same change, same dateDynamoDB changeswhat was sentSupersedeone notice, not tworevisedTransitional text?near the changeAttach it verbatimnever summarisedfoundNotify nowwith the checklistSchedule the reminderfour weeks before effectThe last step is the one that turns an announcement into an action.
Fig 1. How a detected difference becomes a dated, scheduled change. The supersede path matters because rates are frequently revised between announcement and effect.
  • Database
  • App integration
  • Management
  • Analytics

When there is no effective date

It happens, particularly on pages that are updated in place rather than published as announcements. The system’s response is to treat the change as effective now and to say clearly in the notice that no effective date could be found, with a link to the page and the snapshot.

Treating it as immediate is the cautious choice and it is the right one. The failure mode of assuming a future date is applying an old rate after a new one took effect, which is a filing error. The failure mode of assuming immediate is somebody looking at a page and deciding it does not apply yet, which is a two-minute check.

Transitional rules

Rate changes frequently come with rules about work spanning the change: which rate applies to an invoice raised before but delivered after, how deposits taken earlier are treated, whether continuous supplies are apportioned. These are the parts that actually cause errors, and they are exactly the parts a system must not try to summarise.

So transitional text near a changed value is extracted verbatim and attached to the notice under a plain heading, with the link. The system’s contribution is finding it and putting it in front of somebody. Interpreting it is a conversation with an accountant, and any attempt to compress it into a rule is how a business ends up confidently doing the wrong thing at scale.

Superseding

A rate announced in one budget and revised in the next before it ever took effect is not two changes; it is one pending change that moved. Sending a second notice without connecting it to the first produces two contradictory checklists sitting in somebody’s inbox, and the wrong one gets actioned about half the time.

So a pending change carries an id, and a subsequent change to the same rate with an effective date in the future supersedes it: the notice says so explicitly, the old reminder is cancelled, and a new one is scheduled. The superseded notice is kept in the history because it explains why somebody may have already edited something.

The history

The five fields of a rate history rowA horizontal row of five boxes. Value: what the rate was. From: when it started applying. Source: the stored snapshot of the page it was read from. Notified: who was told and when. Actioned: whether it was actioned and by whom. A note says this answers, in one query, what rate applied on a given date and how you knew.WHAT THE HISTORY ANSWERSValuewhat it wasFromwhen it startedSourcethe snapshotNotifiedwho, whenActionedand by whom"What rate applied on 3 March 2024, and how did we know?" -- in one query.
Fig 2. The five things a history row holds, which together answer the only question anybody ever asks about a past rate: what was it, and how did we know?
  • Storage
  • App integration
  • Machine learning
  • Analytics

Next: the reminder, and why acknowledging a notice is the only interaction the system asks for.

All posts