From Quote to General Ledger

Everything in Agentforce Revenue Management, automatically in your NetSuite books

Agentforce ✦ ✦ ✦ ✦ ✦

Revenue Cloud Advanced

Catalog

Product
Catalog

Price
Management

Quoting

Configure
Deal

Quote &
Propose

Contracts

Document
Generation

Execute
Contract

Orders

Order
Management

Decomposition &
Orchestration

Asset Lifecycle

Asset Lifecycle
Management

Billing
Schedules

Revenue Cloud Billing

Billing

Billing
Schedules

Usage
Capture

Digital Consumption
Wallets

Rating &
Charging

Invoicing

Invoice
Generation

Invoice
Grouping

Delivery

Payment & Collections

Payments

Dunning

Credits &
Disputes

Salesforce

Customers & Products

Book Order

Continuous Control

Invoices & Credit Memos

Payments & Refunds

Revenue Sync

NetSuite

NetSuite · System of Record

Accounts Receivable

Invoices

Credit
Memos

Payments

Revenue Recognition

Revenue
Plans

Recognized
Revenue

GL Accounting

Journal
Entries

General
Ledger

Balance &
Period Close

Tied out to the penny

Live in days, not months

No middleware. No custom build. No second SOW

AppExchange · Built for NetSuite · SOC 1 & 2

Partner: Continuous Control · a Salesforce AppExchange and Built for NetSuite application

Presenter notes · slide 1 · not part of the slide

Talk track (about 60 seconds)

"You just saw the full revenue lifecycle run on Salesforce, from catalog to invoice to cash. Here is what happens when your books live in NetSuite: nothing changes for your finance team. Continuous Control is a prebuilt pair of applications, one installed in Salesforce, one in NetSuite. When an order is booked, when an invoice posts, when a payment lands, the same record appears in NetSuite automatically, in real time. Customers, invoices, credit memos, payments, revenue plans, all the way through. Revenue is recognized in NetSuite, journal entries post in NetSuite, and the books balance and close in NetSuite, exactly where your auditors expect them. And this is not a point to point integration or middleware in the middle: it is one connected revenue process running across both platforms, with no integration project and no second statement of work. It is a certified product: AppExchange listed, Built for NetSuite, SOC 1 and SOC 2 audited. Customers are live in days, and at month end NetSuite equals Salesforce, exactly, to the penny."

If they ask

"Who is Continuous Control?" A Salesforce ISV partner. It is a product you install, not an integration project you commission. One package on each side, configured in clicks.
"What does our IT team have to build?" Nothing. The mappings between Salesforce revenue objects and NetSuite records ship prebuilt, and everything is idempotent, so a re-sync never duplicates a record.
"How long until we see it working?" Install on day one, first synced order on day two, first month-end close tied out within the first month.
"Do we have to replace anything in NetSuite?" No. It posts to the native NetSuite records you already close on. The next slide covers exactly that.
"What does it cost?" It is a product subscription from Continuous, separate from your Salesforce order. I will connect you with their team for pricing.

Keep NetSuite Exactly As It Is

Continuous Control adds the Salesforce story next to your books. Everything native stays native.

Added by Continuous Control

The contract, as sold

New records that give finance the full Salesforce picture inside NetSuite

Contract & Orders · the deal and every amendment, mirrored from Salesforce

Performance Obligations · what revenue is owed, and on what schedule

Billing Schedules & Periods · when every dollar bills, matched to Salesforce

Amendments & Usage · upsells, downsells, and usage billing ride the same sync

The revenue waterfall, rolled up live

Booked

Billed

Recognized

One waterfall, visible in both systems

posts native
transactions

mirrors revenue
back to Salesforce

Native NetSuite · untouched

Your books, your close

The same records and processes your finance team runs today

Customers & Items · matched to your existing records, never duplicated

Invoices, Credit Memos & Payments · real transactions in your A/R

Journal Entries → General Ledger · deferred revenue drawn down each period

Subsidiaries, Tax & Currency · your structure, unchanged

Your close process · same reports, same auditors, same sign-off

Performance Obligation=ARM Revenue Element

Built to graduate. Each obligation maps one to one to NetSuite Advanced Revenue Management. Start simple, move to full ARM when revenue gets complex, with no rebuild.

Booked · Billed · Recognized→Salesforce Contract

One set of numbers. Revenue flows back onto the contract in Salesforce, so sales and finance read the same books, every day.

Partner: Continuous Control · a Salesforce AppExchange and Built for NetSuite application

Presenter notes · slide 2 · not part of the slide

Talk track (about 60 seconds)

"The first question your controller will ask is: what happens to our NetSuite? The answer is nothing. Your customers, items, invoices, payments, and journal entries are the same native NetSuite records they are today. Your subsidiaries, your tax setup, your close process, all unchanged. What Continuous adds sits beside them: the contract as it was sold in Salesforce, its orders, its performance obligations, and its billing schedules, so finance can see exactly where every dollar came from without asking sales. If you use NetSuite Advanced Revenue Management, each obligation lines up one to one with a native revenue element, so you can start simple and adopt full ARM later without a rebuild. And the numbers flow back the other way too: booked, billed, and recognized revenue appear on the contract in Salesforce. Sales and finance stop reconciling spreadsheets, because they are reading one set of books."

If they ask

"We already use ARM with our own revenue rules." Keep it. Continuous coexists with ARM; the obligation-to-element bridge means nothing is thrown away and nothing is double-counted.
"We have heavy NetSuite customizations and scripts." Continuous is an additive SuiteApp. It creates its own records and posts standard transactions; it does not modify your existing records, forms, or workflows.
"Who owns the invoice?" Salesforce bills the customer; NetSuite books it. Every Salesforce invoice lands as a native NetSuite invoice with the same totals, so A/R and collections work exactly as they do now.
"Does finance have to change how they close?" No. Same reports, same auditors, same sign-off. What changes is the reconciliation work that disappears before the close starts.

A Sales Order Records the Deal Once

Subscription billing recomputes it every month. Six things a static order can't do:

Proration

Pricing prorates the quote once. Billing must prorate every partial period after every change. Billing Schedules on Salesforce keep that math with the order.

Amendments

Upgrades, downsells, and negative orders reshape every future invoice on the contract.

Usage

Consumption has no fixed amount to put on an order. The bill exists only after the month closes.

Ramps

Stepped pricing bills a different amount each year from one signed contract.

Consolidation

Many orders, one invoice. Grouping rules do not live anywhere on an order.

Collections

Dunning, credits, and disputes happen long after the order is booked and filed.

A billing engine exists because change is the normal case. The only question is where it should live.

Presenter notes · slide 3 · not part of the slide

Talk track (about 60 seconds)

"Before we talk about systems, one question: what actually happens after a customer signs? The order is recorded once. But the relationship changes every month. Someone upgrades mid-quarter and needs a partial-period bill. Someone downsizes and every future invoice changes. Usage has no fixed amount at all until the month closes. Ramp deals bill a different amount each year from a single contract. Ten orders may need to land on one consolidated invoice. And collections work starts long after the order is filed. A sales order is a snapshot. Billing is a moving picture. That is why every subscription company runs a billing engine. The only real question is where it should live, and that is the next slide."

If they ask

"We only sell simple annual subscriptions." Even annual deals amend mid-term. The first prorated upsell is usually the moment the spreadsheet appears.
"Can't we build proration ourselves?" You can, and then you maintain a rules engine forever. Mid-month starts, leap years, credits, co-term dates: every edge case becomes your backlog.
"Our ERP can generate invoices." Printing the invoice is the easy part. The hard part is computing the right number through constant change, before any invoice exists.

Billing Follows the Asset Lifecycle

Everything that changes a bill is born on the platform. Bill where it happens, or sync it forever.

Billing on the platform

Billing reads the lifecycle natively

Asset Lifecyclethe living record of what the customer owns

AmendRenewUpsellUsage

Billing on Salesforceone catalog · one price book · one proration engine

NetSuiteA/R · Revenue Recognition · General Ledger, via Continuous Control

Billing in the ERP

Two systems learn one job

Salesforcecatalog · quote · order · asset

catalog sync · price sync · amendment sync · usage sync

ERP billingsecond catalog · second price book · second lifecycle

Two proration engines. Pricing prorates the quote one way, ERP billing prorates the invoice another. Finance reconciles the difference.

The lifecycle moves. To bill an amendment, the ERP engine has to own it. Your asset lifecycle drifts out of the CRM.

A permanent integration. Every lifecycle event becomes a sync to build, monitor, and maintain.

Bill where the lifecycle lives. Account where the books live.

Presenter notes · slide 4 · not part of the slide

Talk track (about 60 seconds)

"So where should the billing engine live? Everything that changes a bill starts on this platform: the amendment, the renewal, the upsell, the usage on the asset. When billing runs here too, it reads those events natively. One catalog, one price book, one proration engine, and the result flows into NetSuite as clean accounting. Now look at the other path. 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. You now have two systems doing one job, and two proration engines, because your pricing prorates the quote one way and the ERP prorates the invoice another way, and finance gets to reconcile the difference. And since an ERP billing engine has to own the contract to bill it, your asset lifecycle slowly moves into the ERP. That is not an integration. That is a permanent project."

If they ask

"Our ERP vendor says billing is included." Included is not connected. Ask how a mid-term amendment reaches their engine, and who prorates it when it does.
"Isn't Salesforce-side billing the same problem in reverse?" No. Billing consumes lifecycle events, and the lifecycle already lives here. Accounting consumes finished documents, and documents are easy to hand over. That is the next slide.
"We already own the ERP billing module." The license is not the cost. The second catalog, the second lifecycle, and the integration team are the cost.

Billing Isn't Accounting

Billing runs next to the lifecycle. The books never leave NetSuite.

Salesforcelifecycle · billing calculations · the invoice

NetSuiteA/R · Revenue Recognition · General Ledger

Billing is computing the right number through change and producing the invoice. Accounting is A/R, revenue recognition, and the close.

Continuous Control lands every invoice, credit memo, and payment in NetSuite as native transactions. Finance closes the books exactly where they do today, tied out to the penny.

Capability	Native NetSuite Sales Orders	RCA + RCB + Continuous
Invoice proration for partial periods	Not supported	Supported
Amendment lifecycle, incl. negative orders	Not supported	Supported
Consolidated invoicing & grouping	Not supported	Supported
Ramped deals, billing & rev rec	Not supported	Supported
Usage & consumption billing	Manual / custom build	Supported
Payments, dunning & collections in Salesforce	Manual / custom build	Supported
One-time hardware invoices	Supported	Supported
Revenue recognition in NetSuite	Custom project	With Continuous

Supported out of the box Manual work or custom build Not supported natively

Presenter notes · slide 5 · not part of the slide

Talk track (about 60 seconds)

"One important distinction before anyone worries: putting billing on Salesforce does not mean accounting moves to Salesforce. Billing is calculating the right number through change and producing the invoice. Accounting is A/R, revenue recognition, and the general ledger, and those stay in NetSuite. Continuous Control carries every invoice, credit memo, and payment into NetSuite as native transactions, so your finance team closes the books exactly where they do today. And here is the practical evidence, line by line. If you try to run subscription billing on native NetSuite sales orders: proration, amendments, consolidation, and ramps are simply not supported. Usage billing, payments, and dunning become manual work or custom builds. With Revenue Cloud Billing plus Continuous, every row is supported, and the books never leave NetSuite."

If they ask

"Does finance have to work in Salesforce now?" No. Their day stays in NetSuite: same A/R, same close, same reports. What disappears is the reconciliation between the two systems.
"Who owns revenue recognition?" NetSuite, full stop. Every obligation lands there with the schedule it needs, and recognized revenue is visible back on the Salesforce contract.
"What do our auditors see?" The same general ledger and audit trail they see today, with every invoice reconciling to Salesforce to the penny.