Notes
What is field mapping? How data moves between a store and an ERP
Field mapping is the written list that says, for every field, where a value from one system lands in the other and what happens to it on the way. A field is copied, transformed or looked up, and almost every store to ERP integration needs all three.
Updated
Field mapping in two sentences
Two systems rarely store the same fact the same way. Shopify knows a customer by email address and NetSuite by an internal ID; Shopify sends an amount as the text "18.40" and a time in UTC, NetSuite wants a number and a posting date in the company's time zone. Field mapping is the list that says, field by field, how one becomes the other.
One rule from such a list:
{
"source": "shopify.order.lineItems.sku",
"target": "netsuite.salesorder.item",
"kind": "look up",
"rule": "find the item whose itemid equals the SKU; use its internal ID",
"empty source": "line to review list: Shopify sku is optional",
"no match": "order to review list with the SKU"
}
The empty source line is there because Shopify's GraphQL Admin API documents LineItem.sku as an optional string. A custom item or a variant created without a SKU sends no value, and a lookup on nothing finds nothing.
Copy, transform or look up
Every rule is one of three kinds.
| Kind | What happens | Example | What goes wrong |
|---|---|---|---|
| Copy | The value moves unchanged | poNumber to otherrefnum |
The target field is shorter than the value |
| Transform | The value changes form | "18.40" to 18.40; UTC to Eastern; Massachusetts to MA |
Rounding, time zone, decimal separator |
| Look up | The value is replaced by a key from a table or from the target | email to customer internal ID 2291 | No match, or two matches |
Copy looks like the safe kind, and it still has a limit. NetSuite's records browser gives the sales order number field tranid a maximum of 45 characters. A store order name such as #4127 fits; an order number built from a channel prefix, a store code and a marketplace order ID can pass 45, and a copy rule without a length check sends it anyway.
Look up is the kind a first draft most often leaves out. The target expects its own key and the source does not have it. There are two forms. A search asks the target which record belongs to a value: which customer has this email. A translation table is a list someone maintains: the Shopify gateway name Shopify Payments becomes NetSuite payment method Credit Card, the shipping title UPS Ground becomes the ship method the account set up for it. When the store adds a new payment provider, the table needs a row before the first order with it arrives.
Worked example: one Shopify order into NetSuite
Ridgeline Mechanical orders 12 pieces of item HX-2210 at 18.40 each through a Shopify B2B store. The order is created at 11:30 pm on September 30 in New York. Shopify records createdAt as 2026-10-01T03:30:00Z, because Shopify's DateTime is ISO 8601 in UTC and New York is 4 hours behind UTC in daylight saving time.
lineItems.quantityandpoNumberare copied.- The price is transformed. Shopify serializes money as a decimal string,
"18.40", and NetSuite'sratetakes a number. The rule parses the string as a decimal with two places, so 12 times 18.40 is 220.80 in both systems. The tax on top is its own rule, worked out in money, tax and rounding. createdAtis transformed. Taking the date part of the UTC value gives October 1. Converting to Eastern time first gives September 30, the day the customer ordered. At a month end that is the difference between Q3 and Q4. The full case is in dates and time zones.emailandlineItems.skuare looked up. NetSuite's records browser marksentityon the sales order anditemon each line as required, and both take an internal ID only NetSuite knows.namegets a prefix and goes toexternalid. That gives every order one stable key, so a retried write updates the order instead of creating a second one. The mechanism is in duplicate customers and orders.
Lookups cost requests. A store with 300 orders a day and 3 lines per order looks up 1 customer and 3 items per order: 300 times 4 is 1,200 lookups a day, only to find IDs. NetSuite's REST web services return collections in pages of up to 1,000 results. An integration that reads the 8,000 items once a night in 8 pages, and the 25,000 customers in 25, does 33 requests and resolves the rest locally. How that budget fits NetSuite's account limits is on NetSuite concurrency limits.
What happens when two fields feed one field
A target field holds one value. When two source fields map to it, the rule has to say which wins. Without that rule, the last assignment usually wins, including an empty one.
An example on the shipping label. The addressee is filled first from the billing address and then from the shipping address:
| Step | Source | Value | addressee after this step |
|---|---|---|---|
| 1 | billingAddress.company |
Ridgeline Mechanical | Ridgeline Mechanical |
| 2 | shippingAddress.company |
empty | empty |
The buyer left the company blank on the shipping address because it is the same company. Step 2 overwrites a good value with nothing, and the parcel leaves without a company name. The fix is one sentence: take the shipping company, and if it is empty, the billing company. The rest of the address fields are on address field mapping.
The same happens between systems. If price comes from NetSuite and someone also edits it in Shopify, the two overwrite each other on every run. The leading system is set per field, not per system.
Required fields the source never sends
Every target has fields it will not save a record without. NetSuite's records browser marks these as required on the sales order: entity, trandate, currency, orderstatus and, per line, item. Shopify sends a value for none of them in NetSuite's terms. NetSuite fills trandate with today and orderstatus with the account's default when they are left out, which is a problem of its own: an order imported a day late gets the wrong posting date without an error.
Then there are fields NetSuite does not require and the finance team does: department, class and location drive the reports and, for location, the warehouse that ships. For each of these the mapping states one of three things:
| Approach | When | Example |
|---|---|---|
| Look up | The value exists in the target | customer internal ID by email |
| Fixed value | Same for every record | department Web Sales for every store order |
| Derive | From another field | location from the shipping state: east of the Mississippi ships from Ohio |
A fixed value works until it does not. When a second warehouse opens, every order still goes to the first one. The full list per ERP is in required fields the source never sends.
The nine classes of mismatch
Field mapping problems fall into nine classes. Each has its own note with the details for US systems.
| Class | Typical US case | Details |
|---|---|---|
| Identity and keys | SKU in the store, UPC-12 at the supplier, internal ID in the ERP | SKU, UPC and GTIN |
| Money and tax | Sales tax per jurisdiction, calculated in two places | money, tax and rounding |
| Units | Sold by the each, bought by the case of 24 | units of measure |
| Stock | On hand against available, per location | which stock counts |
| Dates and times | UTC against Eastern; 03/04 read as two different days |
dates and time zones |
| Addresses | State name against code; ZIP code 01608 that lost its zero |
address field mapping |
| Files and content | Windows-1252 text, a column renamed in Excel | supplier CSV and Excel files |
| Orders and status | Three status vocabularies; partial shipments | order status mapping |
| Structural rules | Leading system per field; retries without a key | duplicate customers and orders |
Validation belongs to every rule. A record that fails the mapping lands on a review list with the field and the reason. It is not skipped, and it is not written with a guessed value.
What this means for your integration
The mapping is the part of an integration that belongs to your business. We write it down with you, field by field, including the translation tables, the rule for empty values and the leading system per field. The integration is built on that list, and the first runs are dry runs: you see per record which values would land in NetSuite or your ERP before anything is posted.
When something changes later, a new payment provider or a second warehouse, we change the mapping and the dashboard shows which records it affects. The order flow as a whole is on orders, customers and shipping. Tell us which systems you want to connect, and we show you where the mapping work sits for them.
Frequently asked questions
Is field mapping the same as data mapping?
In an integration the two terms mean the same thing: a rule per field from source to target. Data mapping is also used for larger exercises, such as a data migration or a data warehouse model. Field mapping is the narrower term for the rules an integration runs on every record.
Who decides which system leads for a field?
The business does, per field and not per system. Price may come from the ERP, stock from the WMS and the product description from the PIM. The integration enforces the choice, so a value edited in the wrong system is overwritten on the next run instead of drifting.
What happens to a record that does not fit the mapping?
It goes to a review list with the field and the reason, for example "SKU HX-2210 not found in NetSuite". It is not skipped silently and not written with a guessed value. After the fix the record is processed again from the original payload.
Can a standard connector do the mapping?
A standard connector ships a default mapping for the common fields and a screen to change some of them. The rules specific to one business, such as a second warehouse, a customer matched by tax ID instead of email or a price list per customer group, are usually where the default stops. Those rules are the part of the mapping that takes the time.
How many mapping rules does an integration have?
A store to ERP integration that moves customers, items, orders, addresses, payments and tax has a few dozen rules. Most are one line. A handful, such as tax, customer matching and units of measure, carry most of the work and most of the incidents.
Tell us what you need
Tell us which systems you use and what needs to work better. We reply personally within one working day. We help you define the work, then agree the price and timing before you commit.
- You know the price and the timeline before you commit to anything
- We work out the connection that takes the work off your hands
- We handle the build, hosting, monitoring and maintenance
- Your team has less information to retype and fewer discrepancies to chase