NetSuite Known Limitations

This article describes the known limitations of the Oracle NetSuite integration. These are inherent to the current design of the integration and to the capabilities of the NetSuite API, and they apply to all subscribers.

Because the integration spans many record types, the limitations are organized by feature. Each feature section links to the related mapping documentation for that feature so you can go straight from a limitation to the collection it concerns. The feature sections below span the integration's master-data records (Customer, Product and the other NetSuite item types, Reference Data, and Gift Certificate), its transactions (Sales Order, Invoice, Cash Sale, Cash Refund, and Return Authorization (Order Return / RMA)), and its Employee & TimeBill records. Integration-wide behaviors — the scope of bulk initialization and how bidirectional updates are handled — are described first under Initialization and Synchronization Behavior. A consolidated Placeholders and Control Settings to Review Before Go-Live checklist appears at the end of this article — the single pre-launch list of example values to replace and feature-control fields/settings to configure.

These behaviors apply across the integration rather than to a single feature.

Initialization (bulk transfer) is supported only for the reference-data types — Alternate Id Type, Customer Category, Location, Payment Method, and Shipping Method (all TO iPaaS.com). Customers, products and the other item types, and transactions are not bulk-initialized; they transfer on demand from the Manual Sync page or on their create/update events.

What this means for you: seed your reference data with initialization, then bring customers, products, and transactions across by Manual Sync or by enabling their automatic triggers. There is no bulk back-fill for those record types — plan an initial Manual Sync pass (or a scripted batch with your implementation partner / MiSP) for existing data.

Customers, products, and sales orders can sync in both directions. To keep one direction from overwriting data the other direction owns, the integration uses the DestinationValue approach on inbound updates — an update preserves the values already on the iPaaS.com record rather than blanking fields the incoming side does not supply (for example, the NetSuite … attributes captured from NetSuite are retained when a record updates from the other side).

What this means for you: if you customize the mappings on a bidirectional record, keep the DestinationValue pattern on any field the other direction populates, so an update from one side does not clear a value set by the other. Validate round-trip updates in a staging environment before go-live.

Some dependencies are handled for you during a transfer; others must already be in place. The integration always checks for an existing or linked record first, links a match where it can, and only then attempts to create what is missing.

Related mapping documentation: NetSuite Customer From iPaaS.com, NetSuite Customer To iPaaS.com, NetSuite Customer Company From iPaaS.com, NetSuite Customer Company To iPaaS.com, and NetSuite Customer Category and Pricing Group Mapping Documentation. The field-level requirements are in the corresponding collection descriptions in the iPaaS.com mapping configuration.

The integration recognizes an already-existing NetSuite customer (or company) by email address once the external-ID link is not yet present. The same applies to both individual customers and organizations.

What this means for you: keep the email mapping stable once customers exist — changing or un-mapping it can stop incoming records from matching their NetSuite records and create duplicate customers. Coordinate any change with your implementation partner or MiSP.

The capture (TO iPaaS.com) collections only bring in customers and companies whose NetSuite subsidiary matches the subsidiary named in the collection filter, which ships as an example value (Parent Company).

What this means for you: if you capture customers from NetSuite, update the subsidiary in the Customer TO / Customer Company TO filters to your own subsidiary (or broaden it) — otherwise customers in other subsidiaries are silently skipped. The filter is part of the collection's mapping configuration in iPaaS.com.

On NetSuite OneWorld accounts, a customer requires a subsidiary — NetSuite does not let you transact for a customer without a primary subsidiary (see NetSuite Help: Creating a Customer Record). The integration defaults to the root subsidiary (commonly Parent Company).

What this means for you: confirm the default subsidiary matches your account, or override it per customer by populating the NetSuite Subsidiary custom field.

A customer's iPaaS.com categories are derived from its NetSuite pricing group and/or price level — the things that set the prices the customer sees — controlled by the Customer Pricing Source (person) / Customer Company Pricing Source (company) setting.

What this means for you: configure the pricing-source setting in the NetSuite subscription's Subscription Settings in iPaaS.com (values PRICE_GROUP_ONLY, PRICE_LEVEL_ONLY, GROUP_THEN_LEVEL, LEVEL_THEN_GROUP, with an optional Default Price Level), and capture the pricing groups / price levels first, so customer categories resolve as expected. Categories referenced by a customer must also already exist in NetSuite.

Many optional customer attributes — phone, mobile/home/alternate phone, alternate email, title, account number, URL, ship-complete, inactive flag, subsidiary, and address details — are carried through iPaaS.com custom fields named NetSuite … (the integration's round-trip convention).

What this means for you: add the NetSuite … custom fields for the attributes you want to carry; when the custom field is absent or empty, the attribute is simply not transferred.

Related mapping documentation: NetSuite Inventory Product From iPaaS.com (writing inventory products to NetSuite), and the capture (TO iPaaS.com) documentation for each NetSuite item type — Product, Assembly Items, Non-Inventory Items, Non-Inventory Resale Items, Service Sale, Service Purchase, and Service Resale. The field-level requirements are in the corresponding collection descriptions in the iPaaS.com mapping configuration. The limitations in this section apply to all of the item types unless noted otherwise.

Several product mappings resolve a related reference record by lookup. Product inventory is posted to a NetSuite location resolved from the location's external-ID link, so the location must already have been established in iPaaS.com before inventory quantities can resolve their location and subsidiary. When capturing products from NetSuite, the alternate-id children likewise resolve the iPaaS.com Alternate Id Type (external_id / reference_name / mpn) by lookup, and related-product / nested-category mappings resolve their target by lookup — those reference records must exist first.

What this means for you: sync your NetSuite locations (and, for capture, alternate id types and any referenced categories) to iPaaS.com first. Inventory, alternate-id, related-product, and category rows are skipped or fail to resolve for any reference record not yet established in iPaaS.com.

This limitation applies only to the single standard price field. The iPaaS.com DefaultPrice field receives the first/default NetSuite price level (the price level and currency page default to the first entry) — it holds one price, so only one level can land there. (NetSuite itself supports multiple price levels through its Multiple Pricing feature.) It does not mean other price levels are dropped: the integration provides extensive price-list functionality that carries the rest of the pricing into iPaaS.com. The per-level pricing detail (price level, level name, currency, quantity) is captured into the NetSuite Price Item … custom fields, and the BC PriceLists_FormattedData field builds a combined, configurable price-list string from the item's price levels — assembled by the price-list formula and shaped by the Price List Field Separator and Price List Record Delimiter settings (in the NetSuite subscription's Subscription Settings in iPaaS.com), with optional filtering by price level and currency. Multi-level and multi-currency pricing can therefore be transferred; it simply does not all collapse into the single standard price field.

What this means for you: only the standard DefaultPrice field is limited to the first/default level. To bring additional price levels (or multi-currency pricing) into iPaaS.com, use the price-list functionality — map BC PriceLists_FormattedData (and set the price-list separator settings to match the platform that will consume it) and/or the NetSuite Price Item … custom fields. See the product mapping documentation for how the price list is built and which fields carry the per-level detail.

For variant (matrix) products, the option, option-value, and variant-option collections link to the matrix options already defined on the NetSuite item; an option or value that does not exist is rejected with an error rather than created.

What this means for you: define the matrix options and their values on the NetSuite item before transferring product options and variants.

A product requires a SKU (written to the NetSuite Item ID), a units type that resolves to a valid NetSuite units type, and — on OneWorld accounts — a subsidiary (from the NetSuite Subsidiary custom field).

What this means for you: ensure each product has a SKU and a valid units type (and the NetSuite Subsidiary custom field on OneWorld) before transferring.

Each NetSuite item type is captured by its own collection (standard inventory, Assembly, Non-Inventory, Non-Inventory Resale, and Service Sale / Purchase / Resale), selected automatically by the item's NetSuite type. The two non-inventory collections both match the NonInvtPart type and are distinguished only by accounts: an item with an Income account and no Expense account is captured as Non-Inventory Items, while an item with both an Income and an Expense account is captured as Non-Inventory Resale Items. Service items are split the same way by their Sale / Purchase / Resale subtype.

What this means for you: an item appears under exactly one item-type collection, and for non-inventory items the choice depends on how the item's accounts are configured in NetSuite — not on a setting you pick in iPaaS.com. If a non-inventory item is captured by the wrong collection (or not at all), check its Income/Expense account configuration in NetSuite. All item types capture into the same iPaaS.com product structure, so downstream mappings behave the same regardless of which collection captured the item.

Related mapping documentation: NetSuite Location To iPaaS.com, NetSuite Payment Method To iPaaS.com, NetSuite Shipping Method To iPaaS.com, NetSuite Alternate Id Type To iPaaS.com, and NetSuite Product Categories To iPaaS.com Mapping Documentation. The field-level requirements are in the corresponding collection descriptions in the iPaaS.com mapping configuration.

NetSuite locations, payment methods, shipping methods, alternate id types, and product categories are captured into iPaaS.com as reference records that other collections resolve by lookup. They therefore behave as prerequisites — the Product section above describes how product inventory, alternate-id, related-product, and category rows are skipped when their reference record is not yet established in iPaaS.com. The limitations below are specific to the reference records themselves.

A category's parent is resolved to an already-captured iPaaS.com category. A category whose NetSuite parent has not yet been captured is created without its parent link, and the hierarchy stays incomplete until the parent exists.

What this means for you: capture your category hierarchy parent-first, or re-run the category sync once the parents exist, so nested categories resolve their parent. Separately, the item-side category assignment depends on the Custom List Script ID preset configured in the integration's Subscription Settings in iPaaS.com — set it before relying on product category capture.

A captured payment method's iPaaS.com payment type is derived from its NetSuite method type rather than set directly: a Payment Card becomes Credit Card (or Debit Card when flagged), an Offline method becomes A/R, and other method types pass through by name.

What this means for you: confirm captured payment methods carry the payment type you expect; the type is computed from NetSuite's method type, so a method configured differently in NetSuite will map accordingly.

Related mapping documentation: NetSuite Sales Order From iPaaS.com Mapping Documentation (writing orders to NetSuite) and NetSuite Sales Order To iPaaS.com Mapping Documentation (capturing orders from NetSuite). The field-level requirements are in the corresponding collection descriptions in the iPaaS.com mapping configuration.

NetSuite computes the order's subtotal, tax, and total from the individual order lines. The header total values carried from the source are recorded for reference and reconciliation, not used in place of NetSuite's line-based calculation. Tax amounts cannot be set directly through the API — NetSuite owns tax calculation (NetSuite calculates transaction tax from the tax configuration; see NetSuite Help: Calculating Taxes on Transactions).

What this means for you: to control an order's totals, make sure each line carries the correct amount, rate, and taxable setting. The integration carries your source tax onto transaction custom fields for a post-create override applied by the Tax Override customization described in NetSuite Connections and Settings; the NetSuite SuiteTax feature is not required.

The integration prevents duplicate orders by storing the NetSuite Sales Order's internal ID back on the iPaaS.com transaction (the external-ID link). Before that link exists, it can also match an existing order using the Sales Order Duplicate Matching Field setting — a NetSuite Sales Order field (for example otherRefNum) matched against the source transaction number. If that field's mapping is changed or stops being populated after orders exist, incoming orders may stop matching their NetSuite records and duplicate orders can be created. If the setting is left blank, only the external-ID link guards against duplicates.

What this means for you: keep the mapping that populates the matching field stable once orders are live, and coordinate any change with your implementation partner or MiSP. The matching field is configured in the integration's Subscription Settings in iPaaS.com; set it to the NetSuite field that holds your order number (otherRefNum is the typical choice).

Each order line's amount is calculated as quantity × unit price, so a discount is reflected automatically only when your source folds it into the unit price. A discount your source records separately — a separate discount amount, or a discounted extended price while the full unit price is retained — is applied to the order only through a configured NetSuite discount item.

What this means for you: if your source keeps the full unit price and records discounts separately, you or your MiSP (Managed Integration Service Provider) can map the discount to a NetSuite discount item (the template ships a placeholder discount item that must be replaced with your own). Validate order totals in a staging environment before relying on them.

Gift-certificate sale lines are matched to a NetSuite Gift Certificate item by SKU, and gift-card redemptions are matched to an existing certificate by code. A gift-certificate line must have a quantity of 1.

What this means for you: create your gift-certificate items in NetSuite before selling or redeeming them through the integration, and sell multiple certificates as separate lines (quantity 1 each). A SKU or gift-card code that does not resolve is rejected rather than auto-created.

The Cancel Sales Order collection writes a cancellation summary to the order's Memo in NetSuite. It does not change the order's status, line items, or totals, and it does not close or delete the order — those steps are handled in NetSuite.

What this means for you: a transferred cancellation makes the cancellation visible on the NetSuite order's Memo; complete any status change or closing of the order in NetSuite as part of your normal process. Line-level cancellations close the individual lines through the related Cancel Sales Order Line collection.

When orders are captured from NetSuite into iPaaS.com, only orders in Pending Fulfillment, Pending Approval, or Pending Billing status are captured; orders in other statuses are skipped. Updates captured from NetSuite preserve the values already on the iPaaS.com transaction rather than overwriting them.

What this means for you: if you capture orders from NetSuite and an order is not appearing in iPaaS.com, check its NetSuite status — only the pending statuses are captured. The order's shipment and tracking are captured separately as Transaction Tracking (see the Sales Order To mapping documentation).

Related mapping documentation: NetSuite Invoice Mapping Documentation. The field-level requirements are in the Add/Update NetSuite Invoice TO iPaaS.com (and its Line, Address, and Note children) and Add/Update NetSuite Customer Payment FROM iPaaS.com collection descriptions in the iPaaS.com mapping configuration.

Before an invoice is captured into iPaaS.com, the integration checks that the invoice's line quantities match the originating sales order and that the order total matches the invoice total (the order total is read from a NetSuite custom field set when the order was created). An invoice that fails either check is not captured, and the error appears in Dashboard / Integration Monitoring / Error Logs.

What this means for you: make sure invoices reconcile with their originating order. If an invoice legitimately differs from its order, the validation will stop it — review the invoice and order in NetSuite.

A fully paid invoice (amount paid equal to the total) is not captured, and an invoice with no amount paid is not captured — only invoices with an outstanding balance are transferred.

What this means for you: if you expect an invoice in iPaaS.com and it is not there, check whether it is fully paid or has no recorded payment.

The Customer Payment collection records a payment against a NetSuite invoice that must already exist; a payment total greater than the invoice total is rejected, and a transaction that already carries a NetSuite Customer Payment ID is skipped to prevent duplicate payments.

What this means for you: ensure the invoice has reached NetSuite before its payment is sent, and that payment amounts do not exceed the invoice total.

Related mapping documentation: NetSuite Cash Sale From iPaaS.com Mapping Documentation. The field-level requirements are in the Add/Update NetSuite Cash Sale FROM iPaaS.com collection description in the iPaaS.com mapping configuration.

NetSuite computes the cash sale's subtotal, tax, and total from the individual lines. The header total values carried from the source are recorded for reference, not used in place of NetSuite's line-based calculation. Tax amounts cannot be set directly through the API — NetSuite owns tax calculation (see NetSuite Help: Calculating Taxes on Transactions).

What this means for you: to control a cash sale's totals, make sure each line carries the correct amount, rate, and taxable setting. The integration carries your source tax onto transaction custom fields for a post-create override applied by the Tax Override customization described in NetSuite Connections and Settings; the NetSuite SuiteTax feature is not required.

The integration prevents duplicate cash sales by storing the NetSuite cash sale's internal ID back on the iPaaS.com transaction (the external-ID link). Before that link exists, it matches an existing cash sale using the Other Reference Number field, populated from the source transaction number.

What this means for you: keep the mapping that populates Other Reference Number stable once cash sales are live — changing or un-mapping it after transactions exist can cause incoming transactions to stop matching their NetSuite records and create duplicates. Coordinate any change with your implementation partner or MiSP.

Each line's amount is calculated as quantity × unit price, so a discount is reflected only when your source folds it into the unit price. A discount your source records separately — a separate discount amount, or a discounted extended price while the full unit price is retained — is not reflected on the cash sale line.

What this means for you: if your source keeps the full unit price and records discounts separately, the cash sale line will not reflect the discount. Validate cash sale totals in a staging environment before relying on them; you or your MiSP (Managed Integration Service Provider) can adjust how discounts are mapped for your source.

Gift-certificate sale lines are matched to a NetSuite Gift Certificate item by SKU, and gift-card redemptions are matched to an existing certificate by code. A gift-certificate line must have a quantity of 1.

What this means for you: create your gift-certificate items in NetSuite before selling or redeeming them through the integration, and sell multiple certificates as separate lines (quantity 1 each). A SKU or gift-card code that does not resolve is rejected rather than auto-created.

Related mapping documentation: NetSuite Cash Refund From iPaaS.com Mapping Documentation. The field-level requirements are in the Add/Update NetSuite Cash Refund FROM iPaaS.com collection description in the iPaaS.com mapping configuration.

Cash Refunds share the transaction-level limitations described under Cash Sale above: NetSuite calculates the refund's totals and tax from the lines (the header totals are reference only), duplicate prevention depends on the Other Reference Number matching key, and a discount is reflected only when your source folds it into the line unit price. The following is specific to cash refunds:

A cash refund requires the NetSuite Accounts Receivable feature; without it, NetSuite cannot create the refund. NetSuite requires Accounts Receivable to be enabled before the cash refund record can be used through its REST web services (see NetSuite Help: Cash Refund).

What this means for you: confirm Accounts Receivable is enabled in your NetSuite account before transferring refunds. If it is not, the cash refund will fail to create in NetSuite, and the transfer will report an error in Dashboard / Integration Monitoring / Error Logs.

Related mapping documentation: NetSuite Return Authorization From iPaaS.com Mapping Documentation. The field-level requirements for returns are in the Add NetSuite RMA FROM iPaaS.com and Update NetSuite RMA FROM iPaaS.com collection descriptions in the iPaaS.com mapping configuration.

How the return workflow is divided between iPaaS.com and NetSuite. For returns, the integration's role is to create and update the Return Authorization in NetSuite and keep it linked to its originating order. Credit memo creation, customer refunds, refund calculations, and the physical item receipt are handled in NetSuite — by your standard returns process and any NetSuite automation you have in place. This division is intentional: it keeps financial refund processing and inventory receipt under NetSuite's control, where your accounting rules, approvals, and automation apply. The limitations below describe the behavior of the Return Authorization step that the integration owns.

The integration creates and updates the Return Authorization in NetSuite and links it to its originating order. It does not create credit memos, issue customer refunds, or calculate refund amounts.

What this means for you: the return is recorded in NetSuite as a Return Authorization; the actual refund (credit memo, customer refund) is completed in NetSuite using your normal returns process. This keeps refund handling under NetSuite's control, where your accounting rules and approvals apply.

A Return Authorization is created by transforming the order it came from — in NetSuite, a linked return authorization is created from the original sales order (or cash sale / invoice) and copies its items (see NetSuite Help: Entering a Linked Return Authorization). If the originating Sales Order is not yet linked in NetSuite, the integration creates it automatically from the source as a prerequisite — you do not pre-create it. It must, however, have been fulfilled before the return is created, because NetSuite only allows a returnable quantity from fulfilled items.

What this means for you: make sure the original order has been fulfilled before sending its return. The integration will create the order itself if it is not yet in NetSuite, but a return against an unfulfilled order cannot be created and will report an error in Dashboard / Integration Monitoring / Error Logs.

The integration does not set the status of the Return Authorization it creates. Each new return takes the default Return Authorization status configured in your NetSuite account. An administrator sets this default under Setup > Accounting > Accounting Preferences, on the Order Management subtab (see NetSuite Help: Preferences for Customer Returns). The default depends on whether your company uses the return-authorization approval process: Pending Approval when the approval process is in use, or Pending Receipt (Pending Fulfillment) when it is not. Choosing Pending Receipt lets the return skip the approval step and proceed directly toward receipt.

What this means for you: decide how returns should start in NetSuite and set the default accordingly under Setup > Accounting > Accounting Preferences (Order Management subtab). If your company uses the approval process, transferred returns start at Pending Approval and wait to be approved in NetSuite; if you want returns to skip approval and move straight toward receipt, set the default to Pending Receipt. You can also override the status on an individual return in NetSuite. The integration honors whichever default your account is configured with.

NetSuite computes the return's subtotal, tax, and total from the individual return lines (each line's amount, rate, and taxable flag). The return's header total is carried for reference only and is not used in place of NetSuite's line-based calculation.

What this means for you: to control the return's totals, make sure each return line carries the correct amount, rate, and taxable setting. A value placed only on the header total will not override what NetSuite calculates from the lines.

The integration does not cap a return quantity that is larger than the quantity on the original order. The Return Authorization is created for the quantity that is sent.

What this means for you: NetSuite enforces how much can actually be received and refunded later in its own process (at the Item Receipt stage, which is performed in NetSuite). Do not rely on the Return Authorization step to limit over-returns — review return quantities at their source if that is a concern.

Because the return is created by transforming the originating order, NetSuite copies every line from that order onto the Return Authorization. Lines that are not being returned are set to a quantity of zero.

What this means for you: seeing all of the original order's lines on the return (with zero quantity on the lines that are not being returned) is expected. Only the lines with a non-zero quantity are part of the return.

The integration does not calculate a new tax rate for a return. It carries the originating Sales Order's tax rate — recorded on a NetSuite custom field by a NetSuite customization — onto the Return Authorization, and applies it to each return line according to that line's taxable setting. A return line is treated as taxable when the line itself carries tax, or, failing that, when the originating transaction carried tax. This approach does not require the NetSuite SuiteTax feature.

What this means for you: returns are taxed at the same rate as the order they came from; the integration does not recompute tax independently for the return. This relies on the NetSuite customization that records the original order's tax rate on the transaction — confirm that customization is in place in your NetSuite account. If a return needs a different tax treatment than its original order, adjust it in NetSuite after the Return Authorization is created.

When a return includes a shipping amount, the integration adds a shipping-refund line to the Return Authorization using a designated shipping-refund item. That item must exist in NetSuite as an Other Charge item of subtype For Sale.

What this means for you: if you intend to refund shipping, create the shipping-refund item in NetSuite (Other Charge / For Sale) and set it in the integration's mapping configuration. If a shipping amount is sent without a valid shipping-refund item, the return reports an error rather than silently dropping the shipping refund.

A returned line uses the line's full unit price. Discounts that the source records separately from the unit price — for example, as a separate line discount amount or a discounted extended price while the full unit price is retained — are not carried onto the Return Authorization.

What this means for you: each return line's amount is calculated as quantity × unit price, so a discount carried in the unit price is reflected correctly. If your source instead keeps the full unit price and records the discount separately, the return line will not reflect it. Review how line discounts are mapped from your other connected data sources: you or your MiSP (Managed Integration Service Provider) can confirm whether the discount lands on the unit price, and where it does not, add a Dynamic Formula that derives the return line's unit rate from the discounted line total — for example, the discounted extended price divided by quantity — so the line posts the amount you intend to refund in NetSuite. Validate return amounts in a staging environment before relying on them.

The integration creates and updates the Return Authorization only. Receiving the returned goods (the Item Receipt) is performed natively in NetSuite.

What this means for you: after the Return Authorization is created, complete the physical receipt and any downstream steps in NetSuite as part of your normal returns workflow.

Related mapping documentation: NetSuite Gift Certificate To iPaaS.com Mapping Documentation. The field-level requirements are in the Add / Update NetSuite Gift Certificate TO iPaaS.com collection descriptions in the iPaaS.com mapping configuration. (Gift-certificate behavior on transactions — selling and redeeming — is covered under Sales Order and Cash Sale above.)

A captured gift card is identified by its gift-certificate code (the Number field), which is the business key used to match an existing card.

What this means for you: keep the code mapping stable once gift cards exist — changing or un-mapping it can stop incoming certificates from matching their existing card and create duplicates.

The Add collection captures only gift certificates whose remaining balance is greater than zero; a fully redeemed certificate is not newly created. The Update collection keeps an existing card's balance and status current, setting the status to Redeemed when the balance reaches zero.

What this means for you: a brand-new certificate that has already been fully redeemed will not appear in iPaaS.com; existing cards are kept up to date by the Update collection.

Related mapping documentation: NetSuite Employee From iPaaS.com and NetSuite TimeBill From iPaaS.com Mapping Documentation. The field-level requirements are in the corresponding collection descriptions in the iPaaS.com mapping configuration.

When employees are written to NetSuite, the subsidiary is resolved by name and the transfer fails if the name does not exist. The integration ships an example subsidiary name (HEADQUARTERS) and a base-currency value that each account must confirm.

What this means for you: set the subsidiary name in the Employee mapping to a real NetSuite subsidiary (replace the HEADQUARTERS placeholder) and confirm the employee currency matches your account before transferring employees. An invalid subsidiary name reports an error in Dashboard / Integration Monitoring / Error Logs.

A time bill is attached to an employee — created automatically as a prerequisite if it is not yet in NetSuite, otherwise resolved by its external-ID link — and any location on the time bill must belong to that employee's subsidiary.

What this means for you: transfer employees before their time bills, and use a location that is valid for the employee's subsidiary — otherwise the employee or location will not resolve.

The integration creates and updates employees and time bills; it does not include delete collections for them, so removing one in iPaaS.com does not remove it in NetSuite.

What this means for you: deactivate or remove employees and time bills in NetSuite using your normal process.

The integration's templates ship with example / environment-specific values that each subscriber must replace, and with feature-control fields and settings that must be configured for the associated feature to work. This is the consolidated pre-launch checklist; the full context for each item is in the feature sections above and in the linked mapping documentation. Settings noted as Subscription Settings are configured in the NetSuite subscription's Subscription Settings in iPaaS.com.

For the field-level detail behind any limitation or checklist item, follow the Related mapping documentation links in each feature section above and the corresponding collection descriptions in the iPaaS.com mapping configuration.