The Thing That Notices: Daily Billing Verification
Why This Matters
SpeyBooks keeps a local record of every organisation’s subscription state, kept current by the payment provider’s event notifications. That pipeline is proven correct when events arrive. But a missed delivery, an outage window, or a manual change made directly at the provider would leave the local record confidently wrong, with nothing in the system able to say so. As of this release, something can: a daily job reads every organisation’s billing state, compares it against what the provider actually says, and writes a receipt of what it found.
What Changed
-
A daily verification run, with receipts either way Every execution writes a run receipt, including the runs that find nothing, because a check that finds nothing must still prove it ran, and a check that silently stopped running is itself a failure that must be visible. The receipt records how many organisations were examined, how many compared cleanly, and how many belong to known populations that are expected rather than alarming.
-
Two witnesses before anything counts as wrong A provider notification arriving in the same moment as the check can make the two records look briefly different by pure timing. So a first sighting of a difference is recorded as a candidate, and only a difference that persists across two consecutive daily runs is recorded as a finding. Nobody gets woken up by a race condition.
-
The checker never edits, only reports The verification job has no ability to change billing records; its entire write surface is its own receipts. Exactly one part of the system writes subscription state, and the thing that audits it is not allowed to be the thing it audits. Any correction is made deliberately, by a person, with the receipt as the evidence.
-
One interpretation of the provider’s data The comparison uses the very same reading functions the event pipeline writes with, extracted into one shared module. Two implementations of the same rules always eventually disagree; the watchdog and the writer now share one.
Operational Impact
- Every organisation’s billing state is verified against the provider daily, including ended subscriptions through their retention window
- A divergence surfaces within at most two days, classified and evidenced, never silently corrected
- The first run completed with every record verified in agreement
Files Changed
Backend:
- New verification job and its scheduled daily timer
- New receipt tables for runs and findings (one migration)
- Provider-data reading helpers extracted to a shared module; the event pipeline and billing status endpoint refactored onto it with no behavioural change
The first receipt matched the prediction written before the job existed, to the field. A verification system you can predict is a verification system you can trust.