The title is the question the whole session answers, and the question you want AEs asking in accounts. Frame for the room: education first, product second. The first twenty minutes work even if Continuous is never mentioned.

Read the titles, tease nothing: each chapter lands its own punchline. Timebox hard: chapter 2 is where rooms want to rathole. Park deep questions to the Q&A block.

Set the frame before any product talk, and say the three beats out loud (they are no longer on the slide): the ORDER is a promise, signed once, then reality changes: seats, upgrades, usage, cancellations. The BILL is a computation, recomputed every period through prorations, amendments, usage, and ramps; that computation is what a billing engine does. And billing lives WHERE CHANGE IS BORN: every change starts on Salesforce, so put the engine anywhere else and every change becomes a sync. If they are not buying a billing engine, they are building one out of scripts and spreadsheets. That is the why-Salesforce argument in one breath, and the rest of the deck earns it.

This slide only presents the two arguments; it does not pick a winner. Present School 2 respectfully: it is the popular default, and its three objectives are legitimate. Do not fight the objectives, and do not reveal the resolution yet. The "you do not have to choose" punchline lands in chapter 5, after the gaps, the billing-tool chapter, and the books chapters have earned it. The named products under School 2 are deliberate: chapter 3 takes them head-on, so here just acknowledge they exist and are legitimate.

This is the map for the next five slides; name them fast and move. Each one gets its own slide with a concrete scenario. If the room is short on time, ask which two they hit most in their accounts and go deep on those.

The trap to correct: people hear "proration" and think of the quote. Quote proration happens once. Billing proration happens on every partial period for the life of the contract, recomputed every time the subscription changes: seats added on the 10th, upgrades mid-quarter, cancellations mid-month. That is why Billing Schedules living on the Salesforce order matters: the period math stays attached to the thing that changes.

The sharpest single fact in this deck: NetSuite cannot post a negative document total. Ask the customer how a mid-term downsell posts in their ERP-billing design and watch the whiteboard session start. In RCA the amendment is just another order carrying negative deltas, and everything downstream recomputes from it.

This one is felt by the CUSTOMER'S customer: nobody wants five invoices for one relationship. It is also a quiet DSO story: consolidated invoices are easier to approve and pay. Native NetSuite's one-order-one-invoice path makes consolidation a scripting project rather than a setting.

Ramps are where "just use sales orders" collapses fastest, because the workarounds are all bad: three orders fragment the contract and the renewal, and static lines bill the wrong amount. Note the rev rec half: the segments that drive billing are the same segments rev rec needs, which is exactly what flows through to NetSuite.

For consumption businesses this slide alone decides the architecture: a billing location without a rating engine is not a candidate. If the account is adding usage pricing (most are), the monthly spreadsheet ritual is the pain to ask about. Nuance for the strip: ZoneBilling genuinely does usage mediation; SuiteBilling needs an ETL feed. The rebuttal is not "they can't rate," it is "rating away from the entitlement splits the seller's world in two."

Vendor facts if asked: SuiteBilling is Oracle's native module, the baseline; ZoneBilling (Zone & Co) is the strongest player: usage mediation, consolidated invoicing, ASC 606 inside NetSuite; 360 Subscription Billing is now Moss Adams, implementation-led. Never disparage NetSuite or these products; their instinct (books at the GL) is correct, and the name is "360 Subscription Billing," never "Subscription 360." The rebuttal works on both customer voices ("standard sales orders will be fine" and "we'll keep or buy a billing tool on NetSuite"). Put billing in the ERP and you have to teach it everything Salesforce already knows: you sync the catalog, the prices, every amendment, every usage record. Two systems doing one job, two proration engines, and finance reconciles the difference. The killer question for the room: "ask what happens to a mid-term upsell on a Friday afternoon" · the seller asks finance to change the deal, and the Salesforce record stops being the truth. The customer thinks they are choosing where invoices are generated; they are actually choosing which system the sales team lives in. And the integration project does not go away, it relocates: Zone & Co's own SuiteBilling guide says connecting to CRM and CPQ "requires careful orchestration through middleware platforms or custom API development." Camp math for the objection "this is a shorter project": compare the two statements of work · ours is a package install and a mapping review; theirs is a billing implementation plus the CRM integration they still owe you.

This slide separates Continuous from every "we integrate with NetSuite" claim: most platforms and middleware land as summarized journal exports, so the GL gets a number, the drill-down dead-ends at a batch, and finance reconciles subledger to GL every close. Continuous lands every document as a real NetSuite transaction through NetSuite's own tax, currency, subsidiary, and period logic. If finance goes deeper: the ASC 606 five steps split naturally · steps 1-3 (contract, obligations, price) are born in Salesforce, Continuous carries the obligations across, steps 4-5 (allocate, recognize) post in NetSuite next to the ledger, closed periods, and auditors. Recognition away from the GL means a second control environment and a permanent deferred-revenue reconciliation. Never claim rev rec on Salesforce is impossible; claim this split is the simplest compliant architecture for a NetSuite customer.

This is where the two-schools tension resolves: call back to chapter 1 explicitly. School 2 wanted the familiar finance system, billing and recognition that never drift, and A/R in the ERP. All three are met here, and billing never left the platform. The pivot line: "everything red in chapter 2 turns green with RCB, and Continuous makes it land in NetSuite as if it were native." Emphasize what Continuous is NOT: not a billing system, does not move accounting. For the customer-facing version of this picture, use the RCA/B + Continuous architecture slide.

This is the time-to-value beat, and the quotable is: "the integration to NetSuite never becomes a science fair project." Every number on the slide is countable in the shipping package, so it holds up under an SE's scrutiny. Say "weeks, not quarters" and let the demo do the talking · we do not have a named customer time-to-live proof point yet, so never invent a day count. The certs line (AppExchange certified, Built for NetSuite certified SuiteApp, SOC 1 / SOC 2) is verified and citable. The $411k figure is the business-case one-pager's conservative three-year status-quo cost across four buckets (build, iPaaS, third-party billing/rev-rec, run & maintain); at published high-end rates the same stack exceeds $1M. Procurement framing: a product license, not a services contract · two native apps, nothing new for security to chew on.

The deal mechanics, plainly: without this argument, the billing conversation defaults to the ERP and the RCB line item dies. With it, billing lands in phase 1 on Salesforce, and Continuous removes the "but our books are in NetSuite" veto that would otherwise kill the whole platform deal. The displacement math for the AE: money that would have gone to a NetSuite billing app becomes RCB consumption · "the Zone money becomes RCB money." And when finance is already running a billing eval ON NetSuite, the counter is a real product working in ARM plus NetSuite in the first call, with no third-party billing or revenue products. Questions or deal support: jen.larco@continuoustech.com and thane@continuoustech.com.