From the first blueprint to the next stage of growth.
Give your systems a shared picture of the business.
Give people the right NetSuite-connected experience for their work.
Focused applications for specific operational challenges.
Start with the workflows that make your industry different.
Useful answers for choosing, implementing and improving NetSuite.
What changed, why it matters, and what to review next.
Meet the people and approach behind CuriousRubik.
Sharing customer and vendor records across NetSuite subsidiaries can reduce duplicate maintenance, but it needs a clear distinction between shared identity and subsidiary-specific transactions. Confirm who the counterparty is, which subsidiaries may use it and what users can see. A single record does not make all balances, terms or access rights interchangeable.
Start with one counterparty used by two subsidiaries and follow both sales and purchasing activity. That example exposes defaulting, permissions and reporting questions that a record-count cleanup alone will miss.
Use legal identity and reliable supporting references to decide whether records represent the same organization. Similar trading names can belong to different companies. Conversely, one legal counterparty may use several addresses or brands.
Document the chosen authoritative record and the data owner. Specify which attributes are genuinely shared, such as a legal name, and which need a subsidiary-specific design. Avoid merging or sharing records simply because a name-matching report suggests it.
Keep customer hierarchy, multi-subsidiary sharing and customer-vendor relationships conceptually separate. A parent customer with subcustomers is a different relationship from one customer used by multiple subsidiaries, and a counterparty that is both customer and vendor creates another set of considerations.
The Multi Subsidiary Customer feature in OneWorld allows a customer to have a primary subsidiary and assigned secondary subsidiaries. On a transaction, the primary subsidiary is the default, and an assigned secondary subsidiary can be selected where supported.
Each subsidiary must be assigned individually; child subsidiaries do not automatically inherit customer sharing. The selected transaction subsidiary persists through the relevant sales workflow. Test the actual order-to-invoice chain rather than assuming the user's preferred entity overrides the default.
Removal has restrictions when customer or related vendor transactions already exist for the subsidiary. Therefore, evaluate the sharing perimeter before opening live activity. Treat later removal as a controlled change, with the documented limitations reviewed first.
Vendor records can have a primary subsidiary and secondary subsidiaries for the procure-to-pay workflow. The record can show aggregate outstanding and unbilled balances in the primary subsidiary's currency, while transaction review still needs the correct subsidiary and currency context.
NetSuite provides a Vendor-Subsidiary Relationship record for relevant integration and import operations. Do not assume that editing one vendor header through any API automatically maintains every subsidiary relationship in the intended way.
Check the document output too. The documented vendor behavior distinguishes advanced templates, which can use transaction subsidiary details, from basic layouts that source the primary subsidiary's logo and address. Confirm the actual forms used for purchase and payment communication.
List fields that can affect several subsidiaries and assign an owner for changes. Contact details, addresses, tax information, payment instructions and defaults deserve deliberate review. A local team updating a shared record can affect another team's next transaction. Include an impact check in the change request: which subsidiaries use this counterparty, which open transactions are relevant, and which external systems receive the updated value? Record the approved effective date rather than relying on an informal message.
Determine which terms, credit controls or local tax details belong on the supported subsidiary relationship or another approved design. Do not promise that every field is subsidiary-specific. Verify storage and defaulting for each material requirement.
Keep sensitive payment-data changes under the organization's authorization and verification process. Record sharing should not weaken the controls used to confirm supplier banking changes or broaden who can make them.
Assume a fictional shared customer owes Subsidiary A USD 12,000 and Subsidiary B EUR 7,000. The two transaction-currency balances cannot be added into a meaningful total without a stated conversion basis.
For an illustrative management view only, converting EUR 7,000 at USD 1.10 per EUR gives USD 7,700. The combined translated view is USD 19,700. This is a hypothetical calculation, not a claim about the rate used by a particular NetSuite customer balance field.
The receivable controls still need reconciliation in each entity and transaction currency. A USD 12,000 payment to Subsidiary A should not be assumed to settle Subsidiary B's EUR balance merely because both invoices use the same customer record.
If the same counterparty also supplies goods, keep payable balances and settlement rights separate. Any offset or cross-entity settlement requires an approved legal, accounting and supported system process. Shared identity alone does not authorize netting.
Check local finance users, shared-service teams, administrators, integration users and customer-center access separately. Review record visibility, editing, searches, reports, exports and transaction visibility. A user may have access to the shared master record while having a narrower authorized transaction scope.
The documented customer behavior includes specific effects from Allow Cross-Subsidiary Record Viewing and Customer Center role configuration. Test those settings with representative roles. Do not infer the result from the name of the preference alone.
Use negative tests: can a local user see another entity's balances, transactions or attachments when they should not? Verify the configured reporting routes as well as the standard screen. Preserve the evidence and any approved cross-subsidiary audience.
Require an explicit subsidiary mapping for incoming transactions where the design calls for one. A shared customer record's primary subsidiary can create a plausible but wrong default if the source entity is missing.
Test one customer used by two subsidiaries, an unassigned subsidiary, a changed primary reference and an inactive relationship. Confirm the intended error or transaction result before deploying the integration change.
Preserve stable identifiers when consolidating approved duplicates. Update external mappings through a controlled plan and reconcile the open transaction population. A successful record change does not prove that every source system stopped sending the old identifier.
Maintain a register of shared counterparties, assigned subsidiaries and data owners. Review new entity launches, acquisitions and exits for required changes. Keep historical transaction evidence intact even when a relationship is no longer used for new business.
A CuriousRubik NetSuite support review can trace one shared counterparty through order entry, purchasing, reporting and access. The objective is less duplicate maintenance with clearly preserved entity boundaries.
No. The documented Multi Subsidiary Customer process requires each sharing subsidiary to be assigned individually. Test the intended population and do not infer access from the parent-child subsidiary hierarchy.
No. Transactions still need the correct subsidiary and currency context. Aggregate displays can be useful, but each entity's balances and any approved settlement process require their own reconciliation.
Do not assume so. Review the supported vendor relationship fields, shared header attributes and document defaults individually. Design any additional local requirements explicitly rather than silently overwriting shared information.
Customer sharing has documented restrictions once transactions exist for that relationship, including relevant vendor activity for a dual-type entity. Review the supported process before planning removal or restructuring.
Send a valid shared counterparty with a missing or incorrect subsidiary mapping. Verify that the process rejects or handles it according to the approved design instead of silently posting to the primary subsidiary.
