Sonic asks a workspace to pick a billing mode because subscription billing and freight billing are not the same problem wearing different labels — they have different catalogs, different bill-to parties, and different recognition rules underneath.
Subscription mode answers "what did this account owe for this period." The chain runs contract → schedule → invoice, with phases, seat balances, usage meters, and activation gates as the moving parts. The customer is both the contracted party and the bill-to. Revenue recognises over the term the schedule describes, deferred and released as the period passes.
Shipment mode answers a different question: "what moved, under which carrier deal, at which published rate, for which shipper." Shippers and carriers are deliberately separate catalogs — the shipper is who gets billed, the carrier is who hauled it, and conflating them into a single Customer record is the most common modelling mistake we see when a logistics team tries to force freight into a subscription shape. The contract here is the carrier deal: term, billing frequency, and the mapping that turns an export row into a rated charge. Revenue recognises on the shipment date, not the invoice date, even when billing happens later.
Most organisations know immediately which one they are — a SaaS company is never confused about this. The genuine edge case is a logistics-adjacent business that also has a handful of retainer contracts, or a subscription company that occasionally bills a one-off freight charge. In our experience the right call is still to pick the mode that matches the majority of your revenue and volume, and treat the minority case as a manual exception rather than trying to run both grains natively in one workspace from day one.
If you are not sure, the fastest way to find out is the same as everything else on this platform: bring your actual contracts to a demo and we will tell you, honestly, which grain your revenue actually is.