NetSuite record reference

Twelve custom records, all prefixed customrecord_cc_, fields prefixed per record. Child records link to parents with real parent relationships, which is why each parent shows its children as native sublists.

The record graph

Customer ─┬─ RC Contract ─┬─ RC Order ── RC Order Line ──┐
          │               ├─ RC POB ◄────────────────────┘   (grouped by item)
          │               │     ├─ Obligation Detail ── invoice/CM line
          │               │     ├─ Revenue Plan ── Revenue Schedule ── Journal Entry
          │               │     └─ Billing links
          └─ RC Billing Schedule Group ── RC Billing Schedule ── RC Billing Period

Record reference

RC stands for Revenue Cloud. The RC records mirror the Salesforce Revenue Cloud order graph into NetSuite.

Record	Key fields
RC Contract `customrecord_cc_contract`	Customer link. Start and end dates, status, term months, auto-renew, renewal term. Rollups: Booked (`_total_value`), Billed, Recognized, Remaining. Subtotal, tax, tax-inclusive total, discount. Salesforce deep link, the native Sales Order flag, the rendered waterfall visuals. External id: the Salesforce Contract id.
RC Order `customrecord_cc_order`	Contract parent, customer, subsidiary, currency. Order type (New/Amendment), status, header amounts, Salesforce deep link. External id: Order id.
RC Order Line `customrecord_cc_order_line`	Order, contract, and POB parents, item. Quantity, unit/list/net prices, amount, discount, tax. Service and revenue recognition dates, billing frequency, subscription term. Salesforce order action, delivered/fulfilled flags and dates, % complete, processed flag. External id: OrderItem id.
RC POB `customrecord_cc_pob`	Contract and order parents, item. The waterfall: amount (Booked), billed, recognized, quantity. Rev rec rule, even-spread, % complete, recognition start and end dates. The % complete is typed here, or rolled up from the lines' % complete once Salesforce sends one. Delivered/fulfilled rollups, deferred/revenue account overrides. Billing-group link, plus mirrored group header fields. External id: `pob-{contract}-{item}`, one per contract and item.
Obligation Detail `customrecord_cc_ob_detail`	POB parent, transaction, item. Amount (negative for credit memos), type, document number, date, line number. One row per invoice or credit memo line. This is the evidence behind Billed.
Revenue Plan `customrecord_cc_rev_plan`	POB parent, one Actual plan each, plus contract. Method, total, recognized, deferred, % complete, status, account overrides. A hidden field remembers what the plan was built from, so Update Revenue Plans rebuilds it only when that changes. External id: keyed to the POB.
Revenue Schedule `customrecord_cc_rev_sched`	Plan, contract, and POB parents. Period and period date, planned, recognized, cumulative %, status, catch-up flag. The posting journal entry link, which marks the row as frozen. Keyed per plan and month. Recognition posts straight from the schedule to the journal; there's no separate event record.
RC Billing Schedule Group `customrecord_cc_bs_group`	Customer parent, account-scoped like Salesforce. There's deliberately no contract link. Item, group number, billing method/type, term, billed/pending, next bill, derived dates, deep link. External id: `bsg-{sfId}`.
RC Billing Schedule `customrecord_cc_billing_schedule`	Contract, order line, POB, group, and item links. Frequency, period amount, totals, billed/pending, dates, status, category (Original/Amendment), plus original-schedule chain. External id: `bs-{sfId}`.
RC Billing Period `customrecord_cc_bs_period`	Schedule, group, and POB links. Period start and end, amount, status, and, once billed, the NetSuite invoice link. External id: `bp-{sfId}`.
Engine Run Log `customrecord_cc_run_log`	Timestamp, trigger (Scheduled/Manual), user, and the stage that ran. Contracts Processed counts contracts, never POBs. Also POBs Updated, Schedule Rows Written, JEs Posted, Recognized This Run. Status: Success, Partial, or Failed. A Partial run leaves work for the next one; nothing is lost. Detail JSON has the same counts plus what's still outstanding, contract by contract. One row per engine execution.
Continuous Revenue Settings `customrecord_cc_settings`	The account-configuration singleton, created by post-install. Eleven fields: Subsidiary, Currency, Deferred Revenue Account, Revenue Account, Item Subsidiaries, Tax Schedule, Tax Item, Disable Continuous Revenue Engine, Disable Native Sales Orders, Default Revenue Rule, Auto-Recognize on Scheduled Run. See the settings reference for every field and what it does.

Source Org is a free-text field, formatted <host> (<org id>). It's stamped on every record above except Engine Run Log and Continuous Revenue Settings, since those two are NetSuite-side records with no single owning Salesforce org.

The same field also rides the native records Continuous writes. It's custentity_cc_source_org on Customer and Contact, and custitem_cc_source_org on every item type the sync creates except download items, which can't carry the field. On transactions it's custbody_cc_source_org. It covers Sales Order, Estimate, Cash Sale, Return Authorization, Invoice, Credit Memo, Customer Payment, and Journal Entry. Customer Refund gets it too, on accounts whose NetSuite version supports the field there.

See Several Salesforce orgs, one NetSuite account for what Source Org is for and how to filter on it.

Pointing a node at any record type

The records above are what Continuous adds to NetSuite. They aren't the list of what a sync can write. The wire format is open, and neither side keeps an allow-list. An object in a call can point at any record type your account actually has, including one your team created this morning.

Two checks decide whether a record type is allowed, and they're the same two on both sides.

Shape. The target has to look like a NetSuite record type id: lowercase, starting with a letter, such as salesorder, customer, or customrecord_my_type. A sublist row is written <record type>.<sublist>. Anything else is refused as malformed, with an example.
Existence, proved live. The type is read from your account with a metadata probe that creates nothing. That's the same read the Check button makes. The wizard runs it before it creates the object, so an unknown record type is refused instead of saved as a node that would fail on every run. NetSuite runs the same check again at sync time, once per type per request, catching a type that was deleted since Activate.

The verdict comes back in plain language, not a status code: NetSuite knows this type - 214 fields, or NetSuite has no record type called <name>. Something less conclusive, like missing credentials or a briefly unreachable account, isn't treated as a refusal. The object is created with a warning that the check couldn't be made, because an unreachable account isn't evidence that a record type is wrong.

The same distinction holds on the run. An unknown type is refused by name, with the message "… is not a record type in this NetSuite account", and every other entry in the payload still lands.

The curated catalogue is a convenience

The target picker still offers a list, read live from your account and grouped by family: Entities, Items, Transactions, Billing, Other records. Each entry is filtered against the NetSuite features that account has switched on, and each transaction names the sublist its lines land on.

That list is a shortcut for the common cases, not a boundary. An Other record type box with its own Check sits beneath the chips. A type the catalogue doesn't mention works the same way as one it does.

The feature filter deliberately fails open. When the account can't be asked whether a feature is on, the type is offered anyway. Listing a type you can't use is a small annoyance. Hiding one you can use is a bug you'd never find. Only the feature gates the package already depends on are applied, so a handful of types are offered ungated.

Admissible is not the same as wired. A few types NetSuite writes as documents, like purchase order, vendor bill, and journal entry, are legal targets now, but this release has no Salesforce wiring for them. That wiring assumes a customer lookup and a line child. Validate warns instead of blocking, since the type genuinely exists. NetSuite will refuse the document on every run until the object targets one of the six wired transactions: Sales Order, Estimate, Invoice, Cash Sale, Credit Memo, or Return Authorization.

The same live read powers the editors too: field ids and their types, the fields NetSuite won't save the record without, and the record's sublists. See the RESTlet actions reference for the request and response shapes.

Native-record additions

On NetSuite's own transactions, the package adds contract, period, and amount body fields on recognition journal entries, plus Salesforce deep-link fields on synced documents. Invoice and credit memo lines carry a hidden SF Line Id (Continuous) column, so a re-sync can match each line instead of replacing it. It adds a POB column on journal lines, which powers the per-POB JE sublist, and a GL Impact tab that lists each posted transaction's general-ledger lines. It also adds the recognition-method list: Straight-Line, % Complete, Event-Based, Delivery, and Fulfillment.