There are four practical ways to connect an ERP to parcel carriers: use the ERP's own shipping module, install a connector from the ERP's marketplace, license an enterprise multi-carrier system, or write a small script that calls a label API. The right choice depends less on the ERP than on your order volume, how many carriers you need, and who will own the integration after go-live. This post lays out what each route costs you in money, time, and maintenance, and gives a simple way to score them.

What are the four routes, in plain terms?

The four routes differ in who writes the carrier logic and who maintains it. In every case the job is the same: take a fulfillable order, get a rate, buy a label, print it, and put the tracking number and cost back on the order.

Route	Who builds it	Who maintains it	Typical fit
Native ERP shipping module	ERP vendor	ERP vendor and your admin	You already have it and it covers your carriers
Marketplace connector	Third-party vendor	That vendor, plus your admin at each ERP upgrade	You want labels inside ERP screens without custom code
Enterprise multi-carrier system	Vendor and an implementation partner	Vendor, partner, and an internal owner	Many sites, own carrier contracts, compliance labeling
Script on a label API	Your developer	Your developer	One or a few ship points, a developer on hand, standard parcels

None of these is the default answer. A distributor with one warehouse and 80 parcels a day has a different problem than a manufacturer with six plants and retailer compliance programs.

Is the ERP's native shipping module enough?

Sometimes, but check that the module exists for your account and does the carrier work itself before you plan around it. Two vendor statements show why the check matters.

Oracle's NetSuite help states that its built-in shipping integration with FedEx, UPS, and USPS is not available to new customers. If you signed recently, the feature older guides describe may not be an option for you, so confirm it in your own account before budgeting zero for shipping software. Our NetSuite shipping software page covers the export-based alternative.

Microsoft says that small parcel shipping in Dynamics 365 Supply Chain Management requires a rate engine that the organization develops in cooperation with its carrier or a carrier hub service. In other words, the module gives you the framework and the screens, and the piece that talks to the carrier is still a build or a purchase. See Dynamics 365 Supply Chain shipping software for how that plays out.

The lesson applies to any ERP: "native" can mean a finished carrier integration, a framework that needs an engine, or a feature closed to new accounts. Ask your ERP administrator these three questions:

Is the shipping feature enabled or available on our account today?
Which carriers and services does it support without extra development?
Does it buy the label itself, or does it need a third-party service behind it?

When does a marketplace connector make sense?

A connector makes sense when the people shipping must stay inside ERP screens and you do not want to own code. The connector vendor has already mapped the ERP's order and fulfillment records, so your team works from the same forms it uses now.

The trade-offs are structural rather than specific to any vendor:

You add a second vendor relationship, with its own contract, pricing model, and support queue.
The connector is installed inside your ERP, so each ERP upgrade needs a compatibility check before it reaches production.
Customizations you have made to order or fulfillment records may need mapping work the vendor's demo did not show.
Carrier coverage and rate sources are whatever the connector supports; confirm them in writing.

Ask for a sandbox install against a copy of your own data before you sign. A demo on the vendor's clean tenant tells you little about your custom fields.

When is an enterprise multi-carrier system worth it?

An enterprise multi-carrier system is worth it when your shipping rules are complex enough that the rules themselves are the product. That usually means several ship points, your own negotiated carrier contracts, parcel and LTL in one flow, retailer compliance labels, hazmat, or regional carriers.

The cost is not only the license. Expect an implementation project with a named internal owner, integration work on both the ERP and warehouse side, testing across every site, and an ongoing administrator. For a shipper that needs those capabilities, that is a fair price for control. For a shipper that does not, it is a long project to print a label that a much smaller tool could have printed. Our enterprise shipping software page lists the questions that separate the two cases.

What does building a script on a label API involve?

Building a script means your developer writes a small program that reads fulfillable orders from the ERP, calls a label API, and writes results back. For standard parcels this is a modest amount of code, but it is real software and needs an owner.

A dependable script has six parts:

Read. A saved search, report, or API query that returns orders ready to ship, with address, weight, dimensions, and a unique order reference.
Rate. A call that returns carrier options, with a rule your operations lead has approved (for example, lowest cost that meets the promised days).
Buy. A label purchase that sends an idempotency key built from the order and carton number, so a retry cannot buy twice.
Print. The label goes to the pack station printer, ideally without a person downloading a file.
Write back. Tracking number, carrier, service, and cost are posted to the order through the ERP's own API or import. This is the step most often skipped, and the one finance cares about.
Handle failures. Bad addresses and missing weights go to an exception list a person reviews, not a log file nobody reads.

If you have no developer, the same flow works as a file: export a CSV from the ERP, import it into a label tool, and import the results back. It is less elegant, but it needs no code. The ERP shipping integration guide walks through both versions.

How do you compare the routes with numbers?

Compare them on total first-year cost and on who carries the maintenance, using your own quotes. The figures below are a hypothetical example to show the method; they are not prices from any vendor.

Example (hypothetical numbers). A wholesaler ships 120 parcels a day from one warehouse. It values internal developer and admin time at $90 an hour.

Route	Setup hours	Setup cost at $90/h	Annual fees (example)	Yearly upkeep hours	First-year total
Native module (if available)	20	$1,800	$0	10	$2,700
Marketplace connector	40	$3,600	$6,000	20	$11,400
Enterprise system	300	$27,000	$30,000	80	$64,200
API script	80	$7,200	$480	40	$11,280

The totals matter less than what the table forces you to write down. Replace every figure with a real quote or an honest estimate, then add three columns the arithmetic misses: which carriers each route covers, whether cost and tracking land back in the ERP, and what happens when the one person who understands it leaves. A cheap route with no write-back often moves the cost to the finance team, which then matches shipments to invoices by hand.

Where GoatLabels fits

GoatLabels fits the fourth route: a script or a CSV file against a label tool. It rate-shops USPS, UPS, FedEx, and DHL from one account, and the REST API is included on every plan with unlimited calls, live and test keys, Idempotency-Key support, signed replayable webhooks, and an OpenAPI 3.1 spec. Without a developer, bulk CSV import takes up to 500 rows per file and reports errors by row and field. Each label debits a prepaid wallet as a dated ledger entry carrying your reference, which is what you join back to the ERP order. Plans are $0 a month for 50 shipments or a flat $40 a month for unlimited shipments; see pricing and the shipping API for developers page.

The limits are real. GoatLabels has no native ERP, WMS, or EDI connectors, and it does not write back into any ERP automatically; your script or import does that. You cannot bring your own carrier accounts or negotiated rates. There is no LTL or freight, no retailer compliance labels, no hazmat service, no SSO, no SLA, and no SDKs. Support is by email and the in-app assistant, with no phone line. If your requirements include any of those, the connector or enterprise route is the better use of your time.