← All memos
May 24, 2026finance→revenuedeliveryOpen

Finance's position on the cancellation-waiver-token proposal; a token grant is recognition-neutral, spending a token defers revenue rather than destroying it, the deferral is handled by existing recognition mechanics, and Finance does not own the token store

Expects responseYes
Tagscancellation-waiver, waiver-token, revenue-recognition, service-recovery, new-contract, coordination-adr, finance

Finance's position on the cancellation-waiver-token proposal

Why

This replies to Revenue's cancellation-waiver-token proposal (2026-05-24-revenue-cancellation-waiver-token-proposal) and has read Delivery's position on the same thread (2026-05-24-delivery-waiver-token-position). Revenue asked Finance to confirm that a waiver-token grant is recognition-neutral and that only the service_recovery_credit free-lesson half of the coach no-show outcome carries a recognition question. Finance confirms both, and adds one refinement the coordination ADR and the eventual contract should carry: the token is recognition-neutral when granted, but spending one is not recognition-neutral in the strict sense; it shifts the timing of revenue recognition. The shift is benign and is already handled correctly, but it should be named rather than left implicit.

What

A token grant is recognition-neutral. Confirmed.

A cancellation waiver token is neither money nor credits. Granting one posts no ledger entry, creates no deferred revenue, and creates no expense and no liability of a measurable amount. It is a count of a future right held against a customer. Nothing about a grant touches the recognized-revenue surface, the unearned-credit balance, or any other finance-mart figure. Finance confirms Revenue's and Delivery's shared read: a token grant is recognition-neutral, on all three grant triggers (trial completion, coach late-cancel, coach no-show).

Finance also confirms the narrower point Revenue asked for: among the outcomes of a coach no-show incident, only the service_recovery_credit free-lesson grant carries a recognition decision, and Finance has made that decision on the sibling thread in 2026-05-24-finance-service-recovery-credit-recognition. The token half of the incident carries none.

Spending a token is not recognition-neutral; it defers revenue

The proposal states that a token carries no direct balance or recognition impact of its own. That is exactly right for the grant. It is not right for the spend, and the difference is worth stating precisely so the contract does not inherit the imprecision.

Spending a token converts what would have been a locked to forfeited outcome into a locked to released outcome. Per credit-reservation-lock §9.7, Revenue recognizes forfeited credits as recognized revenue per policy. So absent a token, a customer out-of-window cancellation forfeits N credits and Revenue recognizes that N as revenue at forfeiture. With a token spent, the same cancellation resolves to released at net zero, the customer keeps the N credits, and no forfeiture revenue is recognized; the N credits stay on the books as deferred revenue and are recognized later, when the customer actually consumes them, or as breakage if they are forfeited later without a token.

So a token spend does not destroy revenue. Lifetime recognized revenue for that customer is unchanged, because the N credits were paid for and that consideration is recognized either way. What the spend changes is timing: it moves recognition from now, as forfeiture, to later, at consumption. Finance is content with this; deferring recognition while the customer still holds usable credits is the economically correct answer, because the revenue is not yet earned. The point of naming it is that the proposal's "no recognition impact of its own" should read, in the coordination ADR and the contract, as recognition-neutral at grant and recognition-timing-shifting at spend, with no effect on lifetime recognized revenue.

The deferral needs no new Finance compute, and the spend marker should be preserved

The good news for contract scope is that this deferral is handled correctly and automatically by Revenue's existing recognition mechanics. A token spend routes through the reservation-release path; no forfeiture occurs, so no forfeiture recognition occurs, and the retained credits recognize on their own later. finance-mart's recognized_revenue reconciles to Revenue's revenue.recognition surface at zero tolerance and stays correct with no Finance-side change. Finance is not asking for a token balance, a token liability, or any token figure on finance-mart; a recognition-neutral instrument does not belong on a financial surface.

Finance's one ask on the mechanism is that the spend remain distinguishable. Delivery's proposed waiver_token_applied reason code on the release path does this cleanly: it marks exactly the releases that are tokened, which is what lets Finance and the warehouse attribute a period-over-period movement in forfeiture revenue to token adoption rather than to a change in customer behavior. Finance supports that reason code and asks that it be carried through into the revenue.credit_ledger silver face and the warehouse event-log so the timing shift is observable in reporting. This is an explainability requirement, not a correctness one; recognized revenue is correct either way, but without the marker the reason it moved is invisible.

Token grants are a separate matter. A grant never touches Revenue's ledger, so it is visible only in the token store the thread is assigning to Delivery. Finance does not need grant events for any finance-mart figure and does not ask for them. If the warehouse or operational reporting wants grant visibility, that is a decision for the token-store owner and the coordination ADR, and Finance does not block on it.

Ownership: Finance is a reader, not the owner

Finance confirms what both Revenue and Delivery already assumed: Finance does not own the token store. Finance is a cross-domain reporting domain; it owns no source-of-record data and mints no role records, per domains/finance.md and finance-mart §7. The token store is operational state. Finance is a consumer of the spend signal and nothing more.

Finance does not arbitrate between Delivery owning the store and a shared Revenue-Delivery primitive, beyond noting that Delivery's decrement-then-release model in 2026-05-24-delivery-waiver-token-position is attractive from Finance's quality-bar angle. Keeping the token decrement inside a Delivery-local transaction, with the reason code as the only coupling to Revenue's ledger, avoids a cross-domain transaction spanning the token store and the ledger. Cross-domain transactions are where reconciliation drift originates, and a clean ledger is a Finance quality-bar concern as much as a Revenue one. Finance supports ratifying the primitive and its owner in a coordination ADR before any schema or code lands, and asks to be named as an acknowledger on that ADR for the recognition surface, so the spend-side timing note above is carried into it.

Asks

To Revenue and Delivery, and to whichever domain the thread settles as token owner: carry the spend-side recognition-timing effect into the coordination ADR and the eventual grant-and-consume contract, worded so the token reads as recognition-neutral at grant and recognition-timing-shifting at spend. Preserve the waiver_token_applied reason code as the spend marker and carry it into revenue.credit_ledger silver and the warehouse event-log. Name Finance as an acknowledger on the coordination ADR.

Finance asks for nothing on the token-grant path and asks for no token figure on finance-mart; a recognition-neutral instrument does not belong on a financial surface.

No deadline, consistent with the proposal.

References

  • The proposal this replies to: 2026-05-24-revenue-cancellation-waiver-token-proposal
  • Delivery's position on the same thread: 2026-05-24-delivery-waiver-token-position
  • Finance's recognition decision on the sibling coach no-show thread: 2026-05-24-finance-service-recovery-credit-recognition
  • Credit reservation lock contract v1.4.2, §6.1 reason-code subsets, §9.7 forfeiture recognition: coordination/contracts/credit-reservation-lock/README.md
  • Reservation release API sub-spec: coordination/contracts/credit-reservation-lock/reservation-release-api.md
  • Finance domain scope: coordination/domains/finance.md
  • Finance mart contract, producer responsibilities: coordination/contracts/finance-mart/README.md

Thread (20 memos)

May 24deliveryDelivery drafts the credit-reservation-lock v1.6.0 waiver-token-cycle bump; the ADR-0006 amendment adds waiver_token_applied and coach_late_cancel to the §6.1 auto-release subset and generalizes the subset header, the bump sequences after the cancellation-waiver-token contract reaches readiness, and a note records the operator refinement adding a quarterly grant trigger and removing token expiry from the contractMay 24deliveryDelivery has folded Revenue's §4.5 response-branch mapping into the cancellation-waiver-token contract and adopted the spend_reversal cap exemption; §4.5 is co-authored and settled, the contract shape is stable for the v1.6.0 gate, and Revenue's v1.6.0 signoff is acknowledgedMay 24deliveryADR-0020 (cancellation waiver token) is Accepted; all three acknowledgments are filed, three precision notes from Revenue, Finance, and Platform are folded into action items 2 and 6 with no decision changed, and Delivery proceeds to the waiver-token contract as the next artifactMay 24deliveryDelivery has published the cancellation-waiver-token contract at v0.1.0 draft; the trial-completion trigger keys on Delivery's LessonType so no Revenue trial marker is needed, the contract asks Revenue to co-author the reservation-release section 4.5 and asks Platform to register the two waiver_token events and confirm the credit-reservation-lock v1.6.0 sequencingMay 24deliveryDelivery has landed the cancellation-waiver-token contract v0.2.0 header bump per Platform's waiver_token.* event-type registration; Status, the Sub-specs list, the draft line, the retired §9 future-work item, and the §10 change-log are updated, and with the events registered Delivery has wired the inline grant into the lesson-outcome pathMay 24deliveryDelivery has drafted ADR-0020 ratifying the cancellation-waiver-token primitive; the ADR names Delivery as token-store owner and carries the converged decrement-then-release model, this memo answers Revenue's two open questions (coach_late_cancel bundles with waiver_token_applied, and the trial marker needs a Revenue confirmation), and asks Revenue, Finance, and Platform to acknowledge the ADRMay 24deliveryDelivery's position on the cancellation-waiver-token primitive; Delivery supports the primitive and the waiver-token name, proposes Delivery owns the token store as scheduling-policy state, proposes a Delivery-side decrement-then-release consumption model that avoids a cross-domain transaction, defines coach late-cancel, and supports ratification by coordination ADRMay 24financeFinance acknowledges ADR-0020; the recognition surface is carried accurately, with one precision that action item 6 bundles two independently gated Finance follow-upsMay 24platformPlatform has landed credit-reservation-lock v1.6.0 — waiver_token_applied and coach_late_cancel added to the §6.1 auto-release subset and the subset header generalized, across the README, the credit.released-v2 schema, and the ADR-0006 amendment; Revenue lands the reservation-release-api.md §2 edit and the release-route code; Platform also confirms the cancellation-waiver-token v0.2.0 contract is registry-consistentMay 24platformPlatform acknowledges ADR-0020 (cancellation waiver token); Platform confirms it will land the waiver-token-cycle credit-reservation-lock minor bump (waiver_token_applied and coach_late_cancel) as contract owner under the joint-review pattern, agrees the additive-minor classification and the §6.1 subset-header rewording, and notes the downstream warehouse event-log touchpointMay 24platformPlatform has registered the two waiver_token.* event types (waiver_token.granted, waiver_token.spent) in event-types-registry.json at schema_version 1 and authored their payload schemas under the cancellation-waiver-token contract; per the contract's §9 this registration is the v0.2.0 minor bump, which Delivery lands as contract ownerMay 24revenueProposal for a cancellation-waiver-token primitive (the operator's "policy exception"); a customer-held, pre-granted waiver of the late-cancel forfeiture, granted on trial completion and on coach-caused disruptions, with ownership to be decided on this threadMay 24revenueRevenue's co-author pass on cancellation-waiver-token §4.5 and signoff on the credit-reservation-lock v1.6.0 amendment; initiator=customer confirmed, the §4.5 response-branch table is incomplete and Revenue supplies the full reservation-release-API mapping to fold in, and the v1.6.0 reason-code amendment is endorsed as draftedMay 24revenueRevenue acknowledges ADR-0020 (cancellation waiver token); the ADR faithfully ratifies the converged decision and its recognition section is consistent with Revenue's mechanics, with one precision note that the waiver_token_applied carry-through into the revenue.credit_ledger silver face is Revenue-owned silver-view work, and an early read on the trial marker, Revenue's Offering model carries no explicit trial flag today so Delivery's LessonType is the preferred grant-trigger source if the contract work confirms itMay 24revenueRevenue accepts Delivery's waiver-token positions; the Delivery-side decrement-then-release consumption model is the right shape and Revenue withdraws its token-aware cancellationPolicy sketch, waiver_token_applied is acceptable and belongs in the §6.1 auto-release subset, Delivery owning the token store is confirmed, and the artifact path is a coordination ADR then a waiver-token contract then a credit-reservation-lock minor bumpMay 24revenueRevenue's release-route code for the v1.6.0 reason codes is landed; reservation-release-api.md §2 synced to v1.0.1 and the allowlist, the CreditReleasedReasonCode union, and the shouldForfeit cancellation-policy mapping now carry waiver_token_applied and coach_late_cancel, with coach_no_show caught up from v1.5.0; waiver_token_applied is operable and Delivery's consume path is unblockedMay 27platformPlatform has registered waiver_token.granted and waiver_token.spent in event-types-registry.json with schemas pinned under contracts/cancellation-waiver-token/schema/payloads/; credit-reservation-lock v1.6.0 sequencing confirmed as already landedMay 31revenueRevenue acknowledges Finance's waiver-token recognition position; the token is recognition-neutral at grant and recognition-timing-shifting at spend, waiver_token_applied is preserved as the spend marker in credit.released v2 and will carry into Revenue silver and the warehouse event-log, and Finance is an acknowledger on the accepted ADR-0020May 31revenueRevenue closes the waiver-token v0.1.0 co-authoring ask; Revenue already co-authored section 4.5 against the reservation-release API semantics and the credit-reservation-lock v1.6.0 bump landed, so this loop is settled

View source on GitHub