Back to your communications

Council Tax bills and recovery notices

Your bill, payment reminders and any recovery action.

How we send it: Post; Change how we send this
Why we send it: Because we are required to. This cannot be turned off.
Account: CT-4471902

We use post because this is not available by text message. You did not choose this.

You cannot turn these off, but you can change how we send them.

Behind the scenes

Property names follow docs/profile-communication-subscriptions.md, which says its own spelling is illustrative. The shape is what was decided.

Usable destinations

email: no usable destination
sms: no usable destination
post: usable
in-app: usable

Seeded by seedChannel() against this fixture — §4.1, the one communication rule with real logic behind it here.

Subscription

subscriptionId: sub-ct-billing
catalogueTopicId: council-tax.billing-and-recovery
state: active
basisAtOptIn: statutory
noticeVersionAgreed: — nothing was agreed
channel: post
channelSource: catalogue-fallback
createdBy: Service
captureChannel: service-api
createdAt: 2026-06-29T08:02:00Z
context: {"originatingService":"council-tax","accountReference":"CT-4471902"}
deliveryIssue: none

Not modelled

Expiry, withdrawal history and officer-captured consent. Examples 6.3, 6.6, 6.7 and 6.8 are not fixtures, so nothing renders them.
What happens to a Subscription when the contact value it depends on is removed. Phase 1 sends to the primary confirmed destination for the channel, so there are no per-Subscription pointers to repair.
The material-change flow that forces re-opt-in. §5 lists the event; no owner and no journey exist for it.