Shipping Integration with ERP

Of all the integration seams in a warehouse, the one between the ERP and the carriers is where the most avoidable cost hides. Orders get released, someone opens the carrier's web portal in a browser, keys in the address a second time, guesses at a service level, prints a label, writes the tracking number back into the ERP by hand, and moves on. Every one of those steps is a place for a fat finger, a wrong rate, a missing customs field or a tracking number that never makes it back to the customer. Shipping integration removes the browser tab and the retyping entirely, and lets the ERP drive rating, labelling, manifesting and tracking as a single automated flow. This guide is part of the warehouse automation complete guide, and it goes deep on the shipping seam specifically: what integrates, why it matters, and where the sharp edges are.

The message up front: shipping integration is not about printing labels faster. It is about making the ERP the single source of truth for the entire shipment lifecycle, from the moment an order is ready to ship to the moment proof of delivery lands back against the sales order. Get that loop closed and the manual re-keying, the rate leakage and the "where is my order" calls all shrink at the same time.

1. Why shipping integration matters

Start with what the manual process actually costs, because the case for integration is economic before it is technical. A warehouse that dispatches by logging into carrier portals is paying in four currencies at once. It pays in labour, because every shipment is keyed twice, once in the ERP and once in the portal. It pays in errors, because address transcription mistakes, wrong service selections and missing declared-value or customs fields all produce returned parcels, surcharges and re-ships. It pays in rate leakage, because a human under time pressure picks a familiar carrier and a familiar service instead of the cheapest one that meets the delivery promise. And it pays in blind spots, because tracking numbers live in a carrier portal or a spreadsheet and never get back to the ERP where customer service and the customer can see them.

Integration attacks all four. The address, weight, dimensions and contents come straight from the sales order and the pick, so there is no second keystroke and no transcription error. The rate is shopped programmatically across every eligible carrier and service, so the cheapest compliant option is chosen every time rather than the one a clerk happens to remember. The label and manifest are generated to the carrier's exact specification, so parcels are not rejected at induction. And the tracking number and delivery status flow straight back onto the order, so the ERP, customer service and the customer are all looking at the same truth.

There is a compounding benefit too. Once the ERP owns the shipment record, everything downstream gets easier: freight cost lands against the order for margin analysis, carrier performance becomes measurable because the ERP holds both the promise and the delivery, and the "did it ship, where is it, was it delivered" question is answerable without anyone opening a carrier site. This is the same closed-loop principle that makes the rest of warehouse automation ERP integration pay off: the automation is only worth building if the result comes back into the system of record.

2. The order-to-carrier flow

Before naming the individual integration points, it helps to see the whole flow end to end. An order that is ready to ship in the ERP triggers a call to the shipping system. The shipping system rates the shipment across carriers, selects a service, generates the label and manifest, hands the parcel off to the carrier, and then, over the following hours and days, feeds tracking events and finally proof of delivery back to the ERP. The diagram below is the mental model I keep in front of every shipping-integration project.

The shape that matters here is the loop. Data does not just flow left to right and stop at the carrier. The dashed return path, tracking and proof of delivery flowing back onto the order, is the half of the integration that manual processes almost always drop, and it is the half that turns a shipping tool into a genuine ERP integration.

3. The shipping integration points

The flow above decomposes into five discrete integration points, each of which can be built, tested and monitored independently. Understanding them separately is what lets you phase a rollout, isolate a failure and reason about carrier differences one capability at a time. The table below is the reference I hand to teams scoping a shipping-integration project.

Read the direction column and the architecture becomes obvious. The first three points are the ERP pushing a request out and getting an immediate synchronous response. The last two are asynchronous events arriving back from the carrier over hours or days, which is why they need a different plumbing pattern, typically a webhook or a polling job rather than a request-response call. Confusing the two is the single most common design mistake I see: teams build the outbound rating and labelling beautifully and then bolt tracking on as an afterthought, and the return loop is exactly where the value was.

4. Rate shopping and carrier selection

Rate shopping is where the integration pays for itself fastest, because it directly attacks freight spend on every single shipment. When a clerk selects a carrier by habit, the business overpays quietly and constantly. When the shipping system rates the parcel across every contracted carrier and service in real time, it can apply a selection rule that no human under pressure would apply consistently: pick the cheapest service that still meets the customer's delivery promise.

The mechanics are a rating call per shipment. The ERP passes the origin, destination, weight, dimensions and any service constraints, and each carrier's rating endpoint returns a price and a transit estimate. The shipping system ranks the responses and applies the business rule. That rule is rarely just "cheapest." A realistic rule is layered: exclude services that miss the promised delivery date, exclude carriers that do not serve the destination or the parcel profile, honour any customer-mandated carrier, and only then choose the lowest cost among what remains. Encoding that logic once, centrally, means every shipment gets the disciplined decision instead of the habitual one.

The honest caveat: rated prices are estimates, not invoices. Carriers apply dimensional weight, residential and fuel surcharges, and address corrections that a rating call may not fully reflect, so the number you rate is not always the number you are billed. Build the integration to capture the actual billed cost when the carrier invoice arrives and reconcile it against the rated cost, otherwise your "cheapest service" logic is optimising against a price that is not quite real.

There is also a service-quality dimension that pure price shopping misses. The cheapest carrier on paper is not a bargain if it damages parcels or misses delivery windows, because the cost of a failed delivery, a re-ship and an unhappy customer dwarfs the few dirhams saved on the rate. Mature rate-shopping logic weights carrier reliability, not just price, which is only possible because the tracking and proof-of-delivery loop feeds performance data back into the ERP. The deeper mechanics of talking to each carrier's rating and label endpoints are covered in the carrier integration guide.

5. Label and manifest automation

Once a service is selected, the shipping system requests the label. This is more consequential than it sounds, because a shipping label is not a piece of paper the warehouse designs, it is a carrier-controlled artifact with an exact specification. The barcode symbology, the routing and sortation codes, the placement of the tracking number, the human-readable address block and, for cross-border shipments, the customs and commercial-invoice data all have to match what the carrier's induction scanners and sort systems expect. A label that is almost right gets rejected at the depot, and a rejected parcel is a delayed shipment and a manual exception.

The value of automating label generation is that the carrier's own system produces the compliant label from the data the ERP supplies, so there is no design guesswork and no drift when the carrier changes its specification. The ERP sends structured shipment data, the carrier returns a print-ready label, usually as a ZPL stream for a thermal printer or a PDF, along with the tracking number it has assigned. That tracking number is the critical return value: it is the key that links every subsequent tracking event and the proof of delivery back to this specific order, so it must be captured and stored against the shipment the instant the label is created.

Manifesting, or end-of-day close-out, is the step teams most often forget until the carrier asks for it. Rather than the driver scanning every parcel individually at collection, the shipping system produces a single manifest, an electronic and printed summary of every parcel tendered that day, so the carrier accepts the whole consignment against one document. Beyond speeding up collection, the manifest is often the point at which the carrier officially takes liability for the parcels, which matters for insurance and for dispute resolution. The full mechanics of producing compliant labels across carriers, including the ZPL and customs details, are the subject of the shipping label automation guide.

6. Tracking and proof of delivery back to the ERP

This is the return half of the loop, and it is where a shipping tool becomes an ERP integration. After handoff, the carrier generates scan events as the parcel moves: collected, in transit, arrived at hub, out for delivery, delivered, or an exception such as a failed delivery attempt or an address problem. Each of those events is valuable to the ERP because it answers the question customer service and customers ask constantly, "where is my order," without anyone opening a carrier portal.

The plumbing here is different from rating and labelling. Those were synchronous: the ERP asked and the carrier answered immediately. Tracking events are asynchronous, arriving over hours and days, so the integration either subscribes to carrier webhooks that push events as they happen or runs a scheduled job that polls the carrier for status on open shipments. Webhooks are cleaner and closer to real time; polling is simpler and more resilient to missed messages. Many robust implementations use both, treating polling as a safety net that catches any webhook the carrier failed to deliver. Whichever pattern you choose, the events must be posted against the order so the status lives in the ERP, not in a separate tracking silo.

Proof of delivery is the final event and the one that closes the record. It carries the delivery timestamp and, depending on the service, a signature name or a delivery photo. When that lands back on the sales order, the shipment lifecycle is complete and auditable end to end: the ERP holds the order, the chosen service, the freight cost, the tracking history and the delivery confirmation in one place. That completeness is what makes downstream reporting possible, from on-time-delivery performance by carrier to freight-cost margin analysis by order. On the ERP side, wiring these inbound events cleanly is a well-trodden path in platforms like Business Central; the Business Central APIs and integrations guide covers the API surface for posting tracking and delivery data back onto orders.

7. Multi-carrier and multi-channel

Everything above describes a single carrier. Real operations run several, and the moment you add a second carrier the case for a shipping abstraction layer becomes overwhelming. Every carrier has its own API, its own authentication, its own label format, its own field names for the same concepts, and its own webhook schema for tracking. If the ERP talks to each carrier directly, that carrier-specific complexity leaks into the ERP, and adding or swapping a carrier becomes a development project every time.

The pattern that scales is a shipping layer, whether a dedicated multi-carrier platform or an internal service, that presents one normalised interface to the ERP and hides the per-carrier differences behind it. The ERP asks the layer to rate, label, manifest and track in one consistent vocabulary, and the layer translates to and from each carrier's dialect. Adding a carrier then becomes a change inside the layer, not a change to the ERP, and rate shopping across carriers becomes trivial because they all already speak the same normalised language internally.

The insight that saves the most rework: design the shipping integration around a carrier-neutral internal model from day one, even if you launch with a single carrier. The cost of adding the abstraction later, after the ERP has grown direct dependencies on one carrier's field names and quirks, is far higher than building it in from the start. This is the same lesson the broader warehouse automation guide teaches about every integration seam: normalise at the boundary so the core stays clean.

Multi-channel adds the mirror-image complexity on the order-in side. When orders arrive from an e-commerce storefront, a marketplace, a B2B EDI feed and a phone-in channel, they all have to converge on the same shipping flow, and the shipping integration should not care where the order originated. If the ERP is the point of convergence, one shipping integration serves every channel. If each channel has its own bolt-on shipping, you rebuild the same rating, labelling and tracking logic several times and maintain it several times. Centralising shipping in the ERP is what lets one well-built integration serve the whole business.

8. References

The material below is the standing reference set I point teams to when they are scoping or building a shipping integration. It is deliberately vendor-neutral: carrier developer documentation for the mechanics, and the surrounding warehouse-automation guides on this site for the architecture around the shipping seam.

• Carrier developer documentation: the rating, label, manifest and tracking API references published by the major carriers (for example the express-carrier and postal-operator developer portals) are the authoritative specification for each integration point and should be read directly rather than through a reseller summary.
• Multi-carrier platform documentation: the API references for shipping-abstraction platforms document the normalised model discussed in section seven and are a useful blueprint even if you build your own layer.
• GS1 labelling and barcode standards: the shared standards behind carrier label barcodes and logistics identifiers, useful background for understanding why label compliance is so strict.
• Warehouse automation complete guide: the pillar this article belongs to, covering the full automation picture the shipping seam sits inside.
• Carrier integration: the deeper mechanics of talking to individual carrier rating and label APIs.
• Shipping label automation: producing compliant labels and manifests across carriers.
• Business Central APIs and integrations: the ERP-side API surface for posting shipment, tracking and delivery data back onto orders.

Final thoughts

Shipping integration is one of those projects where the effort and the payback are unusually well aligned. The five integration points are discrete and buildable in sequence, the value of each is measurable, and the whole thing rests on a single principle: make the ERP the system of record for the entire shipment, from ready-to-ship through rate selection, labelling, handoff, tracking and proof of delivery. Do that and the manual re-keying disappears, the freight spend tightens because rating is disciplined instead of habitual, and the "where is my order" question answers itself from the order record.

The mistake to avoid is building only the outbound half. Rating and labelling are the visible, satisfying part, but the return loop, tracking and proof of delivery flowing back onto the order, is where the shipping tool becomes an ERP integration and where most of the ongoing customer-facing value lives. Design for the whole loop, normalise at the carrier boundary so multi-carrier and multi-channel stay manageable, and reconcile rated cost against billed cost so your optimisation is honest. Get those three things right and shipping integration delivers exactly what it promises: an automated, auditable dispatch process that costs less and surprises no one.

Related reading: Warehouse automation complete guide, Carrier integration, Shipping label automation, Warehouse automation ERP integration, Business Central APIs and integrations.