Merchant setup fees versus ongoing platform usage fees

A non-refundable upfront setup or onboarding fee charged to a merchant is rarely a separate performance obligation because setup activities typically do not transfer a good or service to the merchant on their own; absent a distinct service, the fee is deferred and recognized over the expected period the merchant benefits from the platform, not immediately on invoicing, and getting this wrong front-loads revenue precisely during a high merchant-growth phase.

Does the setup/onboarding fee provide the merchant with a good or service distinct from ongoing platform access, or is it simply an administrative activity to activate the contract? What realistic expected customer life (based on actual renewal/churn data, not just the stated initial term) is used to defer a non-distinct setup fee? Are usage-based fees recognized as the merchant transacts, kept separate from the fixed subscription and the deferred setup fee?

1) Identify every fee element in the merchant contract (setup/onboarding, subscription, usage-based transaction fees) and assess each performance obligation separately. 2) Test distinctness of the setup activity: does it transfer a good or service to the merchant on its own (e.g., genuine custom integration/development work with standalone value), or is it merely an administrative activation task with no value if the merchant does not also receive platform access? 3) If not distinct, treat the setup fee as an advance payment for future platform access, a material right or reduction allocated across the standalone selling prices of the combined performance obligations. 4) Estimate the expected customer life realistically, using actual renewal/churn data, not just the stated initial term. 5) Recognize the non-distinct setup fee ratably over that expected life (typically once platform access begins). 6) Recognize usage-based fees as the merchant transacts and fixed subscription fees ratably over the subscription period, keeping these separate from the deferred setup fee.

Estimate the expected customer life (including realistic renewal expectations, not just the initial contract term) to determine the deferral period for setup fees; allocate transaction price between distinct performance obligations based on relative standalone selling prices where multiple elements exist; update the expected-life estimate periodically using observed churn and adjust the remaining deferral period prospectively.

Disclose: the policy for setup/onboarding fee recognition and the judgment applied to determine expected customer life; deferred revenue presented separately (current versus non-current split where material); a disaggregation of usage-based versus subscription-based versus setup-fee-related merchant revenue; and the amount of revenue recognized in the period that was included in the deferred revenue balance at the start of the period.

• Recognizing the entire setup fee as revenue immediately because it is invoiced and non-refundable
• using only the stated initial contract term rather than realistic expected renewal behavior to determine the deferral period
• failing to distinguish genuinely distinct professional services (e.g., custom integration work) from non-distinct account activation
• applying a deferral period that is never revisited even as actual merchant churn diverges materially from the original estimate
• bundling setup fee revenue with subscription revenue in disclosure, obscuring the deferred-revenue mechanics.