NetSuiteFree worksheetPDF, Excel, Word exportNetSuiteAll NetSuite tools

NetSuite Integration Field Mapping Worksheet

Integrations fail at the field level: a date in the wrong format, a status code with no internal ID, a mandatory field nobody mapped. This worksheet puts every mapping in one table so the integration developer, the consultant and the data owner agree before anything is loaded.

Free, optional. Reopen it on any device.

Download:

Source field	Source type	NetSuite record	NetSuite field ID	Transform	Required	Rule or default	Tested

Mapped fields

Map to internal IDs, not display names, wherever a field is a list or record. Internal IDs differ between sandbox and production, so keep a separate lookup table per account. Use an external ID on every record you upsert so reruns do not create duplicates.

Review your integration design

Optional: have an expert look over your mapping and failure handling before you build.

Optional. The tool and every export work without this. No spam.

Was this tool useful?

How to use the worksheet

List every source field that has to reach NetSuite, one row each, and name the NetSuite record and field ID. Choose the transform that describes what has to happen to the value, then write the exact rule in the last column. Update the Tested column as you move through sandbox cycles. Export to Excel and share it with the source system owner for review. The count at the bottom helps you see how much remains.

Map one source field per row, even if it feeds several NetSuite fields
Use external IDs for upsert and for cross-system lookups
Flag every lookup transform so someone builds the ID table
Record the default when the source value is blank

Lookups, dates and required fields

Three things cause most mapping defects. Lookups need the NetSuite internal ID of the list value, and that ID differs per account. Dates must match the format and time zone expected by the interface you use, and the account preferences affect imports. Required fields can be mandatory in NetSuite because of a form, a role or a custom field setting, so test with the real form and role that the integration will use.

Common mistakes

Teams map by display name and then break when someone renames a list value. They also forget subsidiaries, currencies and tax settings that sit behind a transaction, and they test only the happy path. Include edge rows in your sample data: blanks, very long text, zero quantities and closed periods. Keep the worksheet under version control, since it becomes the reference for support after go-live.

Mapping to display names instead of internal or external IDs
Ignoring subsidiary, currency and tax behavior
Testing only with clean data
No owner for lookup table maintenance

Frequently Asked Questions

Why use external IDs?

An external ID lets you upsert, which means create the record if it does not exist and update it if it does, using the key from your source system. It also makes reruns safe and gives you a reliable key for reconciliation.

Are internal IDs the same in sandbox and production?

Not generally. Internal IDs for lists, custom records and some setup records are assigned per account. Keep a lookup table per environment, or look values up by name or script ID at runtime.

Does this work for CSV import mapping?

Yes. The structure is the same: a source column, a target field and a rule. Use it as your documented mapping, then recreate it in the import assistant or save the mapping there.

How detailed should the rule column be?

Detailed enough that someone else could implement it without asking you. Include formats, defaults, trimming, case rules and what to do with blank values.

If your mappings feed an AI or reporting layer as well, Netray can help build the read-only access to the same NetSuite data using the mapping you have already agreed.

Talk to an Expert Explore More Free Tools