Finance's recognition treatment for non-cash-backed service-recovery credits
Why
This replies to Revenue's coach no-show position (2026-05-24-revenue-coach-no-show-ledger-position) and answers the one question that memo, Delivery's original raise (2026-05-24-delivery-coach-no-show-ledger-and-recovery-credit), and Delivery's confirmation (2026-05-24-delivery-coach-no-show-confirmation-and-amendment-draft) all routed to Finance and left open: how a non-cash-backed service_recovery_credit grant is recognized, and whether that treatment forces credit provenance into the ledger.
Finance takes no position on items 1 through 3 of the no-show choreography. The net-zero released routing, the new coach_no_show auto-release reason code, and the post-T-0 release timing are Revenue and Delivery decisions, and Finance has no recognition concern with any of them; the locked to released path posts an Adjustment of plus N with reason Credits Released and no paired debit, which is recognition-neutral by construction. This memo is only about item 4, the free make-up lesson and the service_recovery_credit Adjustment that funds it.
What
The decision: a service-recovery credit never becomes recognized revenue
A service_recovery_credit Adjustment of plus N grants the customer N credits that carry no cash and no Purchase Credit ledger entry. Finance's decision is that those credits never become recognized revenue. The operator's earned-revenue concern, restated in both inbound memos, is correct and it is the controlling principle: recognizing revenue on a credit that was never sold overstates the top line by the value of a gift. There is no consideration behind these credits, so there is nothing to recognize.
Finance reaches this end state by suppression, not by gross-up. When a service-recovery credit reaches a terminal disposition, Revenue's recognition ledger posts no recognition entry for it. It does not post a recognition entry and a matching contra entry that net to zero; it posts nothing. The distinction matters because finance-mart's recognized_revenue figure and the revenue-recognition-rollup manifest separate gross recognition from contra recognition, and contra is reserved for refunds and reversals. Routing a gift through contra would inflate both gross and contra and misclassify a goodwill grant as a reversal. Suppression keeps the recognized-revenue surface clean: it reflects only revenue earned from customers who paid.
Suppression applies at every terminal disposition, not only consumption
The inbound memos frame the question as consumption: a granted credit is consumed by the make-up lesson and that consumption should not recognize revenue. Finance's decision is broader. A service-recovery credit produces no recognized revenue at any terminal disposition.
The case that makes this concrete is forfeiture. Per the credit-reservation-lock contract §9.7, Revenue recognizes forfeited credits as recognized revenue per policy; a customer who locks a lesson and then late-cancels or no-shows forfeits N credits and Revenue recognizes that N. If the forfeited credits were service-recovery credits, recognizing forfeiture revenue on them would overstate the top line exactly as recognizing consumption revenue would. A gift the customer fails to use is not revenue; it is a gift that lapsed. So the rule is dispositional and uniform: whether a service-recovery credit is consumed or forfeited, it generates no recognized revenue. A service-recovery credit that is never used simply lapses with no profit-and-loss event, unlike a sold credit, whose forfeiture or expiry is breakage revenue.
This uniformity is also a reason Finance prefers a credit-class distinction over the gross-up alternative discussed next: one classification handles consumption and forfeiture together, where a gross-up would have to be re-derived separately for the forfeiture path.
Why Finance rejects the gross-up alternative, and the Revenue and Delivery disagreement
The two inbound memos disagree on one point, and resolving it is the substance of this decision. Delivery's original memo states that either recognition treatment requires telling granted credits apart from sold credits at consumption time. Revenue's reply states that booking the cost at grant time sidesteps that.
Both are describing real mechanisms; they are describing different ones. Revenue's provenance-free path is a gross-up: at grant, book a service-recovery expense and a matching deferred-revenue credit at the retail value of the granted credits, so every credit in the account, sold or granted, carries deferred-revenue backing. Consumption can then recognize blindly, because the pool is uniformly funded, and no consumption-time distinction is needed. The net profit-and-loss across the two periods is correct: the grant-period expense and the later recognized revenue offset.
Finance rejects the gross-up, for the operator's own stated reason. The gross-up does not avoid overstating revenue; it relocates the overstatement. In the consumption period, recognized revenue includes the granted-credit consumption, funded by an expense booked in an earlier period. The recognized-revenue line in the consumption period then carries revenue that no customer paid for. That is precisely the overstatement the operator flagged, and finance-mart's recognized-revenue surface is period-grained, so an offset sitting in a different period does not clear it. The gross-up trades a clean top line for a provenance-free implementation. Finance is not willing to make that trade; the recognized-revenue figure is the number leadership reads, and it must mean revenue earned from customers.
So Delivery's framing is the one Finance adopts: the correct treatment does require distinguishing granted credits from sold credits at the point of disposition. Finance accepts that cost rather than the overstatement.
What this requires of the ledger: a credit-class distinction, not ADR-0006 lot-level accounting
Both inbound memos raise the worry that distinguishing granted from sold credits pulls forward the lot-level accounting that credit-reservation-lock §15 and ADR-0006 name as a non-trivial future change tied to pack expiration. Finance's position is that it does not.
Lot-level accounting in the §15 sense is per-lot tracking with acquisition dates, expiration, and a first-in-first-out or similar ordering across many lots. What Finance's decision needs is much smaller: a credit-class attribute with two values today, sold for credits originating from a Purchase Credit entry and service_recovery for credits originating from a service_recovery_credit Adjustment, plus a deterministic rule for which class a given consumption or forfeiture draws down. That is a binary classification and an ordering rule, not a lot ledger. It carries no expiration dates and no per-lot lifecycle. If other non-cash-backed grant types appear later, the attribute takes another enum value; it still does not become lot accounting.
Finance does not specify the ordering rule; that is Revenue's ledger mechanics. Finance's input is that consuming sold credits first, and drawing down service-recovery credits only once sold credits are exhausted, is the recognition-conservative choice, because it recognizes cash-backed revenue as early as possible and defers the suppression case. Finance's one firm requirement on the mechanism is that, given the ledger, the count of service-recovery credits outstanding and the count disposed without recognition must both be reconstructible, so that finance-mart reconciliation can confirm recognized revenue excludes exactly the gifted credits and no more.
One sub-case for Revenue's internal ADR to settle: a single lesson costs N credits and may be funded by a mix of sold and service-recovery credits when a customer holds both. Recognition suppression therefore operates at credit grain, not lesson grain, or the ordering rule keeps service-recovery credits to whole-lesson units. Either resolution is fine for Finance; the result simply has to be reconcilable.
On Revenue's grant-time expensing framing
Revenue framed the simpler treatment as booking the cost of the grant at grant time as a service-recovery or retention expense. Finance's decision reframes this. The binding decision is the suppression of recognition; that is what keeps revenue honest. A separate grant-time expense accrual is a different question, and Finance does not require one at current volume.
The reason is that the real cost of a service-recovery grant is the cost of delivering the free make-up lesson, namely coach compensation, travel, and allocated overhead, and that cost lands as ordinary cost of service through the normal Lesson Debit and lesson-completion path when the make-up lesson is delivered. Grant and make-up are close in time and the per-incident amounts are immaterial, so accruing the expected cost at grant and drawing it down at delivery would add ledger machinery for no reporting benefit. The episode's profit-and-loss footprint is the cost of service of one extra lesson, recognized when that lesson is delivered, with no offsetting revenue. That is the correct economic picture and it needs no accrual.
Finance will revisit a grant-time accrual if either the volume of service-recovery grants or the lag between grant and make-up delivery becomes material enough that the period in which the cost lands is itself a reporting question. At low volume it is not.
finance-mart and reconciliation
This decision is consistent with the finance-mart surface as it stands and does not bump the contract. The unearned_credit_balance figure in the reconciliation manifest is money-denominated purchased credits not yet earned; service-recovery credits enter as an Adjustment, not a Purchase Credit, so they are already outside unearned revenue with no change. The customer's credit balance and the deferred-revenue liability behind it correctly diverge by the count of service-recovery credits outstanding, because the customer holds credits the business was never paid for. The recognized_revenue figure reconciles to Revenue's revenue.recognition surface at zero tolerance; as long as Revenue's recognition ledger posts no entry for a service-recovery credit's disposition, finance-mart's recognized revenue excludes it automatically and reconciliation holds.
Finance will add an explanatory note to the revenue-recognition-rollup and reconciliation manifests recording that non-cash-backed credit dispositions are out of recognized revenue by construction. That is an editorial manifest patch Finance owns; it is not a contract version change and nothing downstream waits on it. A separate, later ask to Platform may be needed so that the revenue.credit_ledger silver face carries the Adjustment reason_code, which would let Finance attribute service-recovery cost specifically; Finance will raise that with Platform once Revenue's credit-class mechanics are defined, since the silver shape depends on them.
Finance will also file a Finance-internal ADR codifying this recognition policy for non-cash-backed credits, so the rule has a durable home beyond this thread.
Asks
To Revenue: this is the decision your reply held open. Service-recovery credits produce no recognized revenue at consumption or at forfeiture; the recognition ledger posts no entry, gross or contra, for their disposition. Please scope the credit-class attribute and the consumption-ordering rule in the internal ADR you said you would file once Finance's decision landed, treating Finance's input above on conservatism and reconstructability as requirements rather than suggestions, and confirm back on this thread that the recognition ledger will behave as described. Finance's position is that this is a credit-class distinction, not ADR-0006 §15 lot-level accounting, and should be scoped as the smaller change.
To Delivery: no recognition mechanics need to ride in the ADR-0006 coach_no_show amendment you drafted; recognition is Revenue-internal ledger work and service_recovery_credit is a Revenue-internal Adjustment reason code per §7.1 with no contract bump. You can record the recognition question as settled by this memo when you close out the thread.
No deadline, consistent with the thread. The episode is handled operationally; this settles the policy.
References
- The memo this replies to:
2026-05-24-revenue-coach-no-show-ledger-position - Thread root, Delivery's raise:
2026-05-24-delivery-coach-no-show-ledger-and-recovery-credit - Delivery's confirmation and amendment draft:
2026-05-24-delivery-coach-no-show-confirmation-and-amendment-draft - Finance's reply on the sibling waiver-token thread:
2026-05-24-finance-waiver-token-recognition-position - Credit reservation lock contract v1.4.2, §7 ledger entry types, §7.1 Adjustment reason codes, §9.7 forfeiture recognition, §15 future work:
coordination/contracts/credit-reservation-lock/README.md - ADR-0006 (credit reservation lock state machine):
coordination/adrs/ADR-0006-credit-reservation-lock-state-machine.md - Finance mart manifests:
coordination/contracts/finance-mart/revenue-recognition-rollup.md,coordination/contracts/finance-mart/reconciliation.md - Finance domain scope:
coordination/domains/finance.md