A shipping label import needs four groups of columns from your ERP order export: a reference, a ship-to address, package weight and dimensions, and contact details. Your ERP may hold all of this, but it can be spread across the order header, the item lines, and the item master, so the export has to be shaped before it is useful. The checklist below lists each field, where it usually lives, and the mistakes that make rows fail.

Which fields does a label import need from an ERP export?

It needs one row per parcel, with enough data to rate the parcel, print the label, and tie the cost back to the order. The exact column names depend on the tool you import into, so treat this as a list of the data to have ready, then rename the headers to match the template you are given.

Group	Field	Usual ERP source	Common problem
Reference	Order or PO number	Sales order header	Export uses the internal ID instead of the document number
Ship-to	Recipient name	Ship-to contact or attention line	Blank when the order only has a company
Ship-to	Company	Customer or ship-to record	Billing name exported instead of ship-to name
Ship-to	Address line 1 and 2	Ship-to address	Whole address in one multi-line cell
Ship-to	City, state, postal code	Ship-to address	Leading zeros stripped from postal codes
Ship-to	Country	Ship-to address	Full country name where a two-letter code is expected
Contact	Phone and email	Ship-to contact or customer record	Missing on older customer records
Package	Weight and unit	Item master, or entered at pack	Item weight exported instead of packed weight
Package	Length, width, height	Carton master or entered at pack	Not stored in the ERP at all
Service	Requested service or deliver-by date	Ship method field on the order	Free-text ship methods that match nothing
Customs	Contents, value, HS code, origin	Item master and order lines	Only needed for international rows, often blank

Two rules cover most of the right-hand column: export the ship-to address, never the bill-to address, and export the document number a person would recognize on an invoice.

How do you turn order lines into one row per parcel?

You group the export by order (or by carton) so that each row describes one physical box. ERP exports of sales orders are often one row per item line, which is the wrong shape for labels: an order with six lines would produce six labels to the same address.

There are three workable approaches:

Export at header level. If your ERP lets you build a list or search on the order header only, each order becomes one row. This fits orders that ship in a single carton.
Export fulfillments or shipments instead of orders. If your warehouse records a shipment or pick document per carton, that document is already the right grain and usually carries the packed weight.
Export lines and collapse them in a spreadsheet. Sort by order number, remove duplicate order rows, and sum the line weights. This is the fallback, and it is the one most likely to produce a wrong weight, because item weights do not include the carton or packing material.

For multi-carton orders, repeat the same order reference on each carton's row and give each row its own weight and dimensions. One order then produces several labels that all point back to one reference.

How do you get the export out of your ERP?

You use whatever list, search, or report export your ERP offers, and what that looks like varies by platform. Two examples from vendor documentation show the range:

NetSuite: according to Oracle's NetSuite help, saved search and search results pages have an "Export - CSV" button that saves the results to a .csv file. You can build a saved search of fulfillable orders with the columns above and export it directly.
Dynamics 365 Business Central: per Microsoft's documentation, list pages such as sales orders can be exported to Excel with "Open in Excel". That is an Excel workbook, not a CSV, so add a "Save as CSV" step before importing.

If your ERP is not one of these, look for the same two things: a way to choose columns on an order or shipment list, and a way to save that list as a file. Check your vendor's own documentation for the exact feature name. If there is no usable export at all, the remaining route is the ERP's API or a scheduled report, which is a bigger project. The options are compared on the ERP shipping integration page, and NetSuite users can find platform-specific notes on the NetSuite shipping software page.

What goes wrong between the export and the import?

You may find that failures come from the spreadsheet step in the middle, not from the ERP or the label tool. Opening a file in a spreadsheet program and saving it again can silently change values. Check for these before every first import from a new export:

Postal codes. A code such as 02134 becomes 2134 when the column is treated as a number. Format the column as text before saving.
Long numeric references. PO numbers with many digits can be shown in scientific notation and saved that way. Format as text.
Phone numbers. A leading plus sign or zero may be dropped, same cause and same fix.
Multi-line addresses. An address stored as one field with line breaks lands in one cell. Split it into line 1, line 2, city, state, and postal code columns.
Units. Confirm whether weights are pounds, ounces, or kilograms, and whether dimensions are inches or centimeters. A column of weights in ounces read as pounds will rate every parcel wrong.
Encoding. Save as UTF-8 so accented characters in names and cities survive.
Header names. Match the import template's headers exactly, including spelling and order if the tool requires it.
Blank trailing rows and totals rows. Report exports often end with a totals line that is not a shipment. Delete it.

How should you test the file before importing a full batch?

You test with a small file first, then scale up. A short test costs a few minutes and catches mapping errors before they are repeated across hundreds of rows.

Here is a hypothetical example, with made-up numbers for illustration only. A distributor exports 180 open orders on a Monday morning. The export has 412 rows because it is one row per item line. After collapsing to one row per order, there are 180 rows. The operator copies the first 5 rows into a test file and imports it. Two rows fail: one because the postal code lost its leading zero, one because the country column says "United States" where the template expects "US". The operator fixes the column formats in the main file, re-imports the 5-row test, sees 5 clean rows, and then imports the remaining 175.

A sensible test file includes one of each case you ship: a commercial address, a residential address, a row with an address line 2, a heavy carton, and an international row if you ship abroad. Keep it for whenever someone changes the ERP export.

Before buying labels on the full batch, compare the row count in the import against the order count in the ERP, and spot-check three or four weights against the pack sheet.

What should the reference field carry?

It should carry the one identifier that lets finance join a shipping charge to an ERP document without asking anyone. For you that may be the sales order number or the customer PO number. Pick one and use it on every row.

Use the value the ERP prints on the invoice, and keep customer names and free text out of the field, because names are spelled inconsistently and document numbers are not.

The payoff comes at month end, when the shipping ledger can be exported and matched to orders by that reference. Getting tracking numbers and costs back into the ERP is a separate step; with a file-based workflow it is normally a manual import or a script on your side.

Where GoatLabels fits

GoatLabels accepts this kind of file through bulk CSV import: up to 500 rows per file, with errors that name the row and the field, and one bad row does not fail the rest of the batch. Larger exports need to be split into files of 500 rows or fewer. Each parcel is rate-shopped across USPS, UPS, FedEx, and DHL, and each label debits a prepaid wallet as a dated ledger entry that carries your reference. A multi-carton order produces several labels, each a ledger line with the same reference. Teams that prefer to skip the file can send the same fields through the REST API, which has test keys for trial runs.

The limits matter here. GoatLabels has no native ERP connectors: anything beyond its 13 store connectors is CSV or API, and the export and column mapping described above are work you do. It does not write tracking numbers or costs back into any ERP automatically. It does not support your own carrier accounts or negotiated rates, LTL or freight, or retailer compliance labels such as GS1-128. The Free plan covers 50 shipments a month, enough to prove the file works before committing to anything.