Printing parcel labels from a WMS wave comes down to a five-step loop: export the wave as a file, capture the real weight and dimensions of each carton, buy the labels in one batch, let them print at the station without anyone clicking a print dialog, and send every row that failed to a separate exception lane. The loop works with any warehouse system that can produce a flat file, and it does not require a native connector between the WMS and the label tool. What it does require is discipline about which fields are in the file and who owns the rows that fail.

What does a WMS wave need to hand to a label tool?

A wave needs to hand over one row per carton with a ship-to address, a weight, dimensions, and a reference that ties the label back to the order. Everything else is optional. Most waves are released as pick work, so the first job is deciding at which point the wave becomes a shipping file: at release, at pick completion, or at pack completion.

Pack completion is usually the right point. Before then, the system knows what was ordered but not how many cartons it became or what they weigh. A file exported at release carries planned weights from the item master, and those are only as good as the item master.

A workable export has these columns:

Column	Source in the WMS	Why it matters
Reference	Order number plus carton sequence, for example SO-10482-2	Joins the label and its cost back to the order
Ship-to name and company	Order header	Carriers print both; B2B deliveries need the company line
Address lines, city, state, postal code, country	Order header	Drives rating and delivery
Weight	Pack station scale	Rated weight; planned weight is a fallback only
Length, width, height	Carton type or measurement	Dimensional weight is priced from these
Service rule or ship-by date	Order header or wave attribute	Tells the buyer of the label what "fast enough" means
Wave ID	Wave header	Lets you reconcile the batch against the wave

Keep the reference identical on every carton of a multi-carton order except for the sequence suffix. That one convention makes later cost allocation and customer service lookups much easier. The same field logic applies to exports from an ERP, covered on the ERP shipping integration page.

Why weigh and measure at the pack station instead of trusting the item master?

Weigh and measure at the station because carriers bill on what they scan, not on what your item master says. If the label was bought at a planned weight and the carrier measures something heavier or larger, an adjustment arrives after the fact, and now the shipping cost on the order is wrong in two places.

The practical setup is modest: a scale at each station and a short list of standard carton sizes with fixed dimensions. The packer picks the carton type, the scale supplies the weight, and both values are written to the carton record before the export runs. Non-standard cartons get measured by hand and keyed in. Two habits prevent most surprises:

Record weight after void fill and tape, not before.
Round up to the carrier's billing increment rather than down.

How do you buy the labels for a whole wave at once?

You buy them by importing the export file into the label tool as one batch, with each row rated and purchased on its own. Rate shopping per row matters in B2B waves because cartons in the same wave can vary widely in weight, zone, and deadline, so one carrier is rarely right for all of them.

Large warehouse systems treat this as a standard handoff. According to Manhattan's developer documentation, Manhattan Active Warehouse Management integrates with external parcel providers for rate shopping, shipping label generation, and manifest assignment. A file-based batch is the same idea with a simpler transport: the WMS decides what ships, and an external system decides how it ships and produces the label.

Size the batch to the tool's import limit and to how your stations work. If the limit is 500 rows and a wave holds 800 cartons, split the wave by pack zone or carrier cutoff rather than at an arbitrary row number, so each file maps to a physical area of the floor.

How does auto-print keep the pack line moving?

Auto-print keeps the line moving by sending each purchased label straight to the printer at the right station, so the packer never opens a PDF or picks a printer from a list. Each click removed from a station is removed from every carton that station ships.

The floor practice that makes auto-print reliable has little to do with software:

Assign each station one printer and name both the same way, such as PACK-03.
Print in the order the cartons sit on the line, which usually means sorting the export by pack sequence before import.
Have the packer match the reference on the label to the reference on the carton or packing slip before applying it.
Keep a spare roll and a spare printer within reach, because a jammed printer stops the whole station.
Define a reprint path that reuses the purchased label instead of buying a second one.

What belongs in the exception lane?

The exception lane holds every carton whose row failed to produce a label, kept physically and logically apart from the cartons that succeeded. The point is that one bad address should not hold up the other cartons in the wave.

Typical failures and their owners:

Failure	Typical cause	Who fixes it
Address rejected	Missing suite, bad postal code, PO box on a service that does not deliver to one	Customer service
Weight or dimensions missing	Carton skipped the scale	Pack lead
No service meets the ship-by date	Order released late or date keyed wrong	Planner
Duplicate reference	Carton exported twice	WMS admin

Run the lane with three rules. First, the failed rows are corrected in a new, small file and imported again, not edited into the original file, so the first batch stays a clean record. Second, the cartons wait on a marked shelf or cart, with the wave ID visible, until their labels print. Third, someone is named as the owner of the lane on each shift, and the lane is empty before the last carrier pickup or the leftovers are reported to the planner by name.

A worked example

This example uses hypothetical numbers to show the flow. A distributor releases a wave of 240 cartons at 1:00 pm for a 4:30 pm pickup. Packing finishes at 2:15 pm, and the export is imported as one file. Of the 240 rows, 233 produce labels and print at four stations in pack sequence. Seven rows fail: four with address errors, two with missing weight, one duplicate. The pack lead re-weighs two cartons in a few minutes, customer service confirms three of the four addresses by phone, and the duplicate is deleted. A second file of five rows is imported at 3:05 pm and prints at the exception station. One carton stays on the shelf overnight with a note for the planner. The wave closes with 238 shipped, one held, and one row removed as a duplicate, and all 240 are accounted for.

How do you close the loop back to the WMS?

You close the loop by getting each tracking number and label cost back onto the carton record, matched by the reference you exported. Without that step, the WMS shows the wave as packed but customer service cannot answer "where is it" from the system people already use.

For file-based setups, that means exporting the batch results from the label tool and importing them into the WMS or ERP through whatever inbound file or API it supports. Reconcile counts on every wave: rows exported, labels bought, rows in exceptions, rows held. If the four numbers do not add up, find out why before the next wave is released.

Where GoatLabels fits

GoatLabels covers the middle of this loop, not the ends. You import a CSV of up to 500 rows per file, each row is rate-shopped across USPS, UPS, FedEx, and DHL, and errors name the row and the field, so one bad row does not fail the batch. That maps directly onto the exception lane described above. Labels can print automatically on printers connected through PrintNode. A multi-carton order produces several labels, each a ledger line carrying the same reference, which keeps the cost tied to the order. The file format is described on the bulk shipping labels from CSV page.

The limits are worth stating plainly. GoatLabels has no native WMS connector: anything beyond its 13 store connectors is CSV or the REST API, and there is no automatic write-back into a WMS or ERP, so the return trip for tracking numbers is an export or your own integration using webhooks. Labels are bought at GoatLabels rates from a prepaid wallet, so you cannot bring your own carrier accounts or negotiated rates. It does not produce retailer compliance labels such as GS1-128, and it does not handle LTL or freight. If those limits fit your operation, the WMS shipping integration page covers the file and API options in more detail.