Use these data-model references to describe the records your connection needs. They are planning examples; connector availability and supported operations must be established before implementation.
Download the mapping worksheet · CSV, no email required
Record matching
Customer / Customers
Compare whether NetSuite Customer and QuickBooks Customers describe the same customer in your business.
Planning example. Stacksync support for the required connection and record operations needs a technical review.
- NetSuite
- Documented record · Read: ✅ Supported. Write: ✅ Supported.
- QuickBooks
- Object support to establish
- Record identity
- Determine whether each customer represents an individual, a company, or a business-unit relationship before matching it to a contact or organization. Retain the source customer ID and destination ID; names and email alone are insufficient.
- Field ownership
- Separate the customer relationship from contact details, billing authority, and consent. Choose an owner for each field after identifying whether the customer is a person or company.
Fields to include
- Source customer ID
- Person/company classification
- Legal entity or business unit
- Destination identity reference
- Record dependencies
- Resolve person or company type, legal entity, business role, and any billing account before transactions.
- Validation
- Test an individual buyer, a company buyer, and one company with multiple billing relationships. Do not merge these into a single generic contact.
- Recovery
- Hold ambiguous customer matches for review and resolve customer type before retrying dependent records.
References: NetSuite: Customer documentation
Customer identity
Contact / Customers
Before linking NetSuite Contact to QuickBooks Customers, check whether the customer is an individual or a company. Match the correct record type in each system.
Planning example. Stacksync support for the required connection and record operations needs a technical review.
- NetSuite
- Documented record · Read: ✅ Supported. Write: ✅ Supported.
- QuickBooks
- Object support to establish
- Record identity
- Determine whether each customer represents an individual, a company, or a business-unit relationship before matching it to a contact or organization. Retain the source customer ID and destination ID; names and email alone are insufficient.
- Field ownership
- Separate the customer relationship from contact details, billing authority, and consent. Choose an owner for each field after identifying whether the customer is a person or company.
Fields to include
- Source customer ID
- Person/company classification
- Legal entity or business unit
- Destination identity reference
- Record dependencies
- Resolve person or company type, legal entity, business role, and any billing account before transactions.
- Validation
- Test an individual buyer, a company buyer, and one company with multiple billing relationships. Do not merge these into a single generic contact.
- Recovery
- Hold ambiguous customer matches for review and resolve customer type before retrying dependent records.
References: NetSuite: Contact documentation
Record matching
Invoice / Invoices
Compare whether NetSuite Invoice and QuickBooks Invoices describe the same customer invoice in your business.
Planning example. Stacksync support for the required connection and record operations needs a technical review.
- NetSuite
- Documented record · ✅ Supported
- QuickBooks
- Object support to establish
- Record identity
- Retain the invoice ID, issuer/legal entity, and original order reference; invoice numbers alone may overlap.
- Field ownership
- The financial system owns posting and accounting treatment. A posted invoice may need a credit or adjustment process instead of an overwrite.
Fields to include
- Source invoice ID
- Customer or supplier reference
- Line totals
- Currency
- Posting/payment status
- Record dependencies
- Resolve the customer or supplier, account codes, tax, currency, and accounting period before posting.
- Validation
- Test a posted invoice, a partial payment, tax rounding, and a closed accounting period. Compare financial totals within the same entity and currency.
- Recovery
- Determine whether a transaction posted before retrying. Follow the approved adjustment process for posted records.
References: NetSuite: Invoice documentation
Record matching
Vendor Bill / Bills
Compare whether NetSuite Vendor Bill and QuickBooks Bills describe the same supplier bill in your business.
Planning example. Stacksync support for the required connection and record operations needs a technical review.
- NetSuite
- Documented record · ✅ Supported
- QuickBooks
- Object support to establish
- Record identity
- Retain the supplier-bill ID, supplier, legal entity, and document reference; distinguish it from a customer invoice.
- Field ownership
- Accounts payable owns approval and posting; a supplier bill is not an accounts-receivable invoice.
Fields to include
- Source bill ID
- Supplier reference
- Entity
- Line amounts and currency
- Approval/posting state
- Record dependencies
- Resolve supplier, expense/account codes, entity, currency, and accounting period before bill lines.
- Validation
- Test a duplicate supplier document number in another entity, a partially paid bill, and a closed period.
- Recovery
- Verify whether the bill was approved or posted before retrying; use the approved adjustment process for posted bills.
References: NetSuite: Vendor Bill documentation
Business process
Sales Order / Invoices
Order-to-invoice handoff: NetSuite Sales Order provides context for QuickBooks Invoices. These are related records, not equivalent entities.
Planning example. Stacksync support for the required connection and record operations needs a technical review.
- NetSuite
- Documented record · ✅ Supported
- QuickBooks
- Object support to establish
- Record identity
- Link order and line IDs to invoice and line IDs; allow partial invoicing and multiple invoices per order.
- Field ownership
- Finance owns invoice posting; the order system supplies the approved commercial context.
Fields to include
- Source record reference
- Destination record reference
- Approved handoff state
- Duplicate-detection key
- Record dependencies
- Create or locate the customer and products first; resolve taxes, currency, and fulfillment references.
- Validation
- Test a partially invoiced order, tax rounding, and a repeated handoff without generating another invoice.
- Recovery
- Check for an existing destination order before retrying a timed-out create; reconcile line IDs to avoid duplicate fulfillment.
References: NetSuite: Sales Order documentation
Record matching
Customer Payment / Payments
Compare whether NetSuite Customer Payment and QuickBooks Payments describe the same payment or settlement in your business.
Planning example. Stacksync support for the required connection and record operations needs a technical review.
- NetSuite
- Documented record · ✅ Supported
- QuickBooks
- Object support to establish
- Record identity
- Preserve transaction ID, provider/source, currency, and links to invoices; one payment may settle several documents.
- Field ownership
- Keep payment authorization, settlement, and accounting allocation distinct.
Fields to include
- Source transaction ID
- Invoice references
- Amount and currency
- Settlement status
- Reversal reference
- Record dependencies
- Resolve the affected invoices and cash/account references before allocating the payment.
- Validation
- Test partial payment, one-to-many allocation, refund, and repeated delivery of the same transaction.
- Recovery
- Look up the original transaction before retrying to prevent duplicate allocation or charging.
References: NetSuite: Customer Payment documentation