A NetSuite saved search can act as your shipping export: build a search that returns the orders ready to fulfill, add the ship-to and reference columns a label tool needs, and export the results as CSV. That file then goes into whatever buys your labels. It is a manual handoff, but it is quick to set up, easy to audit, and it does not depend on a carrier module inside the ERP.

Why would a NetSuite team export orders instead of using built-in shipping?

Because the built-in carrier integration is closed to new accounts. NetSuite does have a native "Shipping Label Integration" feature that generates tracking numbers and labels inside the account once FedEx, UPS, or USPS/Endicia accounts are registered, per Oracle's NetSuite help. But Oracle's help also states that "The Shipping Integration with FedEx, UPS, and USPS/Endicia is not available to new customers. It is available with limited support only for existing customers" (source).

That leaves a newer NetSuite account with three practical routes:

Install a shipping app from SuiteApp.com, NetSuite's marketplace. Listed options include ShipStation Native and Descartes Pacejet Shipping.
Build an integration against the API. Oracle documents SuiteTalk REST web services as a REST-based interface to NetSuite.
Export orders as a file and import that file into a label tool.

The third route is the subject of this post. It suits teams that ship a steady but modest number of parcels, that want to start this week instead of next quarter, or that want a fallback for the days an integration is down. Our build vs buy comparison covers how the routes differ in cost and upkeep.

What should the saved search return?

One row per shipment you intend to label, and nothing else. The search is a filter plus a column list, and both matter.

The filter should answer "what can leave the building today". In plain terms: orders that are approved, not on hold, have stock committed or picked, ship by parcel (not LTL or will-call), and have not already been labeled. How you express each condition depends on how your account is configured, so work with your NetSuite administrator instead of copying criteria from a blog. Write the intent down first, then translate it.

Watch the row grain. If your search returns one row per item line, a five-line order shows up five times and a label import will try to buy five labels. Either restrict the search to order-level rows or summarize it so each order appears once. If an order ships in several cartons, decide on purpose whether that is several rows (one per carton, each with its own weight) or one row that you split later.

Which columns does a label import need?

It needs a deliverable address, a package description, and a reference that ties the label back to the order. A workable column list looks like this:

Column group	What to include	Why it matters
Reference	Order number, customer PO number	Joins the label and its cost back to the order
Recipient	Company name, attention or contact name, phone, email	Commercial deliveries often need both a company and a person
Address	Line 1, line 2, city, state, postal code, country	Keep each part in its own column, not one combined block
Package	Weight, length, width, height	Rates depend on weight and dimensions
Service intent	Requested ship method or delivery deadline	Lets you apply a rate rule instead of guessing
Origin	Warehouse or location	Needed when you ship from more than one building

Two habits save the most rework. First, export the address as separate components. A single formatted address field looks fine on screen and is painful to parse in a spreadsheet. Second, pick one reference convention and keep it. "SO number, a hyphen, PO number" is as good as any; what matters is that the same string appears on every label for that order, so finance can match shipping cost to revenue later.

Weight is the usual gap. Your ERP may hold item weights but not packed carton weights. If your search can only return the sum of item weights, treat it as an estimate and expect carrier re-weigh adjustments; if the pack station records actual weight, export that instead.

How do you get the results out as CSV?

Run the search and use the export option on the results page. Per Oracle's help, saved search and search results pages have an "Export - CSV" button, and on most search pages "Export" saves the results to a .csv file (source).

Before the file goes anywhere, check it the way you would check any export:

Open it in a text editor, not only a spreadsheet, and confirm the header row and delimiter are what you expect.
Confirm postal codes kept their leading zeros. A spreadsheet will turn 02134 into 2134 if the column is treated as a number.
Confirm the row count matches the count the search showed on screen.
Look for commas and line breaks inside address fields; they should be quoted, not splitting rows.
Rename the headers, or map them once, to the names your label tool expects.
Save the file with a name that includes the date and batch, so you can find it again when someone asks which orders went out Tuesday.

What does a day of this look like? (worked example)

Here is a hypothetical example; the company and every number are invented for illustration. A plumbing-parts distributor releases orders twice a day. At 10:00 the shipping lead runs the saved search and gets 64 rows. The search is order-level, so 64 rows means 64 orders. Six of them are flagged for LTL by ship method and are excluded by the filter already, which is why they do not appear.

She exports the CSV, spot-checks three New England postal codes for leading zeros, and imports the file into the label tool. Sixty-one rows produce labels. Three fail: two have no weight and one has a PO box on a service that will not deliver to it. She fixes those three in the file, re-imports only those rows, and has 64 labels. Each label carries the reference "SO-number-PO-number". At the end of the day she exports the tracking numbers and costs and hands that file to whoever updates the orders in NetSuite.

The point of the example is the shape of the routine, not the numbers: one search, one file, a short exception list, and one file coming back.

How do you keep orders from being exported twice?

Give the search a way to know an order was already handled. The simplest approach is a status or checkbox that changes once the order is fulfilled or labeled, with the search filtering on it. If nothing in your process updates the order until the end of the day, use the batch discipline instead: export on a fixed schedule, name each file by date and batch, and never re-import a whole file to fix a few rows.

Tracking numbers have to travel back, too. With a file-based process that is a second import or a manual update, and someone must own it. If that return trip becomes the bottleneck, it is the signal to move from files to an API integration, where your script reads orders, buys labels, and writes tracking back in one pass. Use an idempotency key on label purchases if you go that way, so a retry does not buy a second label for the same order.

Where GoatLabels fits

GoatLabels is one place the exported file can go. Its bulk CSV import accepts up to 500 rows per file, names the row and field for each error, and does not fail the whole batch because of one bad row. Every parcel is rate-shopped across USPS, UPS, FedEx, and DHL from one account, and each label debits a prepaid wallet as a dated ledger entry that carries your reference, which is why the reference column above is worth getting right. Multi-carton orders produce several labels, each its own ledger line with the same reference. The Free plan is $0 per month for 50 shipments per month; Pro is a flat $40 per month with unlimited shipments.

The limits are real and worth stating plainly. GoatLabels has no native NetSuite connector and no SuiteApp; the connection is the CSV you export or code you write against the REST API. Nothing is written back into NetSuite automatically, so tracking and cost return by file or by your own script. You cannot bring your own carrier accounts or negotiated rates, there is no LTL or freight, and it does not produce retailer compliance labels or EDI documents. Support is by email and the in-app assistant, with no phone line.

If that trade is acceptable, the NetSuite shipping page walks through the setup, and B2B shipping software covers the wider picture. If you need labels generated inside NetSuite with automatic write-back, a SuiteApp is the better match.