Continuous Control · Session run of show

Billing, Explained

Why NetSuite customers need Revenue Cloud Billing, and how Continuous Control makes it land. A working session for Salesforce AEs and SEs.

Deck · Where Should Billing Live · 15 slides (punch cut) Length · 15 min content, the rest Q&A Presenters · Thane · Jen · Owen

The presentation at a glance

Audience

Salesforce AEs and SEs who sell Revenue Cloud into accounts where NetSuite is the ERP.

Purpose

Arm sellers to win the billing architecture conversation against BOTH competitive voices: "standard sales orders will be fine" and "we'll keep, or buy, a billing tool on NetSuite" (SuiteBilling, ZoneBilling, 360 Subscription Billing).

Outcome

Sellers can spot the account, reframe "do we need billing software?" into "where should billing live?", walk the five gaps, rebut the named NetSuite-side tools with "two of everything", answer the audit/ASC 606 objection, and run the displacement play: "we're your billing attach."

Format

30 minutes of content, then 10 to 15 minutes for Q&A and live deal talk.

Agenda

Why billing, period

Every subscription and usage company runs a billing engine. The only question is where it lives.

2 min

The five gaps

Scenario, NetSuite-can't vs RCB-can, and a competitive strip on every slide.

6 min

The billing-tool objection

One slide: the named vendors and the "two of everything" rebuttal.

2 min

The Continuous close & your play

Books stay in NetSuite, the bridge, the prebuilt/derisk proof, the play.

5 min

Q&A and deal talk

Open floor: live accounts, objections, next steps.

10–15 min

Slide by slide

Chapter 1

Why billing, period

~5 min

12 min

Every subscription and usage company runs a billing engine

Sets the premise before any product talk: an order is a promise made once, the bill is computed every period, and someone has to do that math. There is no "no billing solution" option, only a choice of where it runs.

TakeawayReframe the sale. Not "do you need RCB?" but "where should the billing engine you already need live?"

23 min

Two schools of thought

The honest version of both architectures. School 1: billing near the asset lifecycle, reading amendments, renewals, and usage natively, one proration source, and the ERP gets clean documents. School 2: billing near the ERP, which sounds simpler (billing and revenue together, close to the GL) but means the ERP recomputes proration on deals it did not price, and subscription plus usage management split across two systems.

TakeawaySchool 2 keeps billing next to revenue by moving the whole subscription into the ERP. Present it fairly; the customer has heard its pitch.

Chapter 2

The five gaps

~11 min · ~2 min each · each slide ends with a "NetSuite-side pitch vs the answer" strip

Invoice proration for partial periods

Proration is not a quote feature: pricing prorates once, billing prorates every partial period after every change, forever. Native NS: fixed lines, no schedule behind them, manual credit and re-bill. RCB: Billing Schedules live on the order and regenerate automatically.

TakeawayOne proration source, quote to invoice. Strip: "our tool prorates" is a second proration engine, recomputing deals it did not price.

Amendment lifecycle

Upgrades, downsells, negative orders, quantity changes. The sharpest fact in the deck: NetSuite cannot post a negative document total, so a downsell has no natural document. RCA amendments are delta orders with history; schedules reshape from the effective date.

TakeawayAsk how a mid-term downsell posts in their design. Strip: "change orders handle that" is one change order, one change; negative totals are a platform wall no tool removes.

Consolidated invoicing & grouping

Customers buy many times and want to pay once. Native NS is one order, one invoice; consolidation is a scripting project. RCB grouping rules combine charges by account, period, currency, or custom keys.

TakeawayFelt by the customer's customer, and a quiet DSO story. Strip: "we consolidate" covers only charges living in their tool; the feed is the problem.

Ramped deals

One contract with stepped economics. Native NS: static lines, so either three fragmented orders or the wrong bill, plus hand-built revenue schedules. RCA/RCB: ramp segments on one contract drive billing and rev rec from the same data.

TakeawayRamps are where "just use sales orders" collapses fastest. Strip: a second system re-modeling the CRM-authored ramp is two sources of truth for one contract.

Usage & consumption billing

Raw usage has no price until a rating engine applies entitlements and tiers. Native NS has no rating engine and no wallets; reality is spreadsheets and keyed summary invoices monthly. RCB: usage capture, wallets, rating & charging on the platform that sold the entitlement.

TakeawayFor consumption businesses this slide alone decides the architecture. Strip: rating belongs where the entitlement is sold; usage in the ERP pulls the seller's day into NetSuite.

Chapter 3

The billing-tool objection

~5 min

82 min

You'll hear this pitch

The three named NetSuite-side products, presented honestly: SuiteBilling (Oracle, native module, the baseline), ZoneBilling (Zone & Co, the strongest player: usage mediation, consolidated invoicing, ASC 606 inside NetSuite), and 360 Subscription Billing (Moss Adams, implementation-led). Two customer voices, same instinct: "standard sales orders will be fine" and "we'll keep or buy a billing tool on NetSuite."

TakeawayThey are right that the books belong at the GL. Concede it immediately; the fight is about what else has to move. Never disparage NetSuite or these products.

93 min

Two of everything

The centerpiece rebuttal. Billing on the platform is one of everything: catalog, price book, proration engine, lifecycle owner, usage rater. Billing in the ERP is two systems learning one job: a second catalog and price book synced forever, two proration engines with finance reconciling the difference, the lifecycle moving into the ERP (to bill an amendment the ERP engine has to own it), and two usage raters. The sync tax: catalog, price, amendment, and usage sync.

TakeawayThat is not an integration, that is a permanent project. Bill where the lifecycle lives; account where the books live. Room question: "what happens to a mid-term upsell on a Friday afternoon?"

Chapter 4

Why the books stay in NetSuite

~6 min

103 min

Why native transactions in NetSuite

The audit-evidence argument. Most billing platforms and connectors land as summary journal exports: the GL gets a number, the drill-down dead-ends at a batch, native A/R cannot operate on documents that do not exist, and finance reconciles subledger to GL every close. Continuous lands every invoice, credit memo, payment, and refund as a real NetSuite transaction posting through NetSuite's own tax, currency, subsidiary, and period logic.

TakeawayTeach the drill-down test: "show me the invoice behind this revenue line." One click or one week. This separates Continuous from every "we integrate with NetSuite" claim.

113 min

Revenue recognition belongs next to the ledger

The ASC 606 five-step strip: steps 1 to 3 (identify contract, identify performance obligations, determine price) are born in Salesforce where the deal happens; Continuous carries the obligations across; steps 4 and 5 (allocate, recognize) post in NetSuite where the ledger, closed periods, and auditors already are. Recognition away from the GL means revenue posted from outside the books, a second control environment to build and audit, and a permanent deferred-revenue reconciliation.

TakeawayAuditors audit the books. Recognition next to the GL keeps one control environment and one audit. Don't claim rev rec on Salesforce is impossible; claim that for a NetSuite customer this split is the simplest compliant architecture.

Chapter 5

The Continuous close and your play

~4 min

121.5 min

Bill on Salesforce. Book in NetSuite.

The pivot: everything red in chapter 2 turns green with RCB, and Continuous makes it land in NetSuite as if native. Mini architecture (Salesforce ARM, the Continuous sync band, NetSuite accounting) plus positioning: AppExchange partner AND Built for NetSuite SuiteApp, not a billing system, tied out to the penny, live in days.

TakeawayThe only partner application purpose-built for both platforms. RCB bills, NetSuite books, nobody has to lose.

131.5 min

Prebuilt. Weeks, not quarters.

The derisk beat: the countable prebuilt proof (17 objects mapped on day zero, 11 Flow actions plus a sync card on 9 objects, a 9-step wizard with a live NetSuite health probe, no installation key, no middleware), the status-quo cost it replaces (roughly $411K conservatively over three years), and the with-Continuous side: one product subscription, every document native, tied out to the penny.

TakeawayA product license, not a services contract. The integration line disappears from the SI proposal, and it never becomes a science fair project. Say "weeks, not quarters"; never invent a day count.

141 min

The play

Deal mechanics: the minimum bar, spot-the-account triggers (now including SuiteBilling/ZoneBilling/360 Subscription Billing installed or in evaluation, and finance objecting to RCB early), how to frame the question, and the proof to bring: the architecture slide, the capability chart, a live demo.

TakeawayLoop Continuous in early. The closer: "We're your billing attach." Without us the CFO pulls billing into NetSuite and Zone gets the deal; with us RCB bills, the books tie out, and the Zone deal never happens. Contacts: jen.larco@continuoustech.com · thane@continuoustech.com

Leave-behinds after the session

RCA/B + Continuous architecture slide · customer-facing, Salesforce-branded, for their decks
"Why NetSuite Customers Need RCB" field-guide chart · internal, row-by-row proof
Customer-facing why-billing arc · Sales Order gap grid / Billing Follows the Asset Lifecycle / Billing Isn't Accounting, for prospect meetings
Continuous contact · deal support and joint demos

Open build items

Punch cut to 15 slides / 15 min for the AE audience: done (2026-09-01); the 30-min version is preserved as -30min-full.html.
Feedback board round 3: regenerate screenshots + rows for the new/changed slides.
Final deck to be rebuilt natively in Google Slides from the mockup, same pattern as the architecture slide.