When a sales order arrives in your ERP system, all the information needed to fulfil it is already included: the delivery address, line items, weights, and the promised delivery date. But once a delivery is triggered, the system's role ends. Your team prints a delivery note, selects a carrier from a dropdown list and marks the order as dispatched. Even though the shipment hasn’t been booked with anyone yet.
Someone then has to open a carrier portal, enter the address, book the shipment and copy the tracking number back into the ERP. The next shipment is handled in the same way, just through a different portal.
This is how shipping works in most manufacturing companies: partly inside the ERP and partly outside it. The extent to which your ERP covers the process depends on the system you use, where it is hosted, and what happens when you migrate to a new version.
What your ERP's shipping module does, and where it stops
The shipping module in your ERP system is designed to record deliveries. It assigns a carrier, prints a delivery note, and marks the order as dispatched. If you ship domestic parcels with one or two carriers, this can be enough.
But it was never designed to compare live rates across your carriers before booking, book directly with carriers, automatically pull in tracking data, or check freight invoices against agreed rates. Your ERP vendor is not planning to build these features either, since carrier connectivity has never been part of their product offering. We discuss the gaps in detail in our ERP vs TMS article.
Three ways to add shipping to your ERP
When the native module is no longer sufficient, teams usually choose one of three options.
- Keep using the native module. Assigning, printing, and dispatching stay in the ERP. The rest happens manually in carrier portals. This option requires no setup, but involves a lot of running costs. Minutes lost per shipment, and errors that go unnoticed until a customer calls.
- Install a plugin for each carrier. One for DHL, one for DSV, one for the regional carrier. Each one works fine until the carrier changes its API, at which point the problem becomes yours. With five carriers, you need to maintain five integrations, keep track of five data formats and have five support contacts on file.
- Implement a shipping layer over the ERP. Connect the ERP to a platform that supports every carrier and maintain a single connection from then on. Adding a carrier becomes a matter of configuration or a request to the provider rather than another project.
How ERP shipping differs by platform
The same shipment is handled differently depending on which ERP system is used. The table below shows how this varies across the systems used by most European manufacturers:
ERP | What the shipping module covers | Where it stops | With a shipping layer |
Business Central: shipping agents, services and delivery notes. F&O adds a transportation management module. | Booking and rate comparison are not part of the package, and the F&O module is a project in itself. Most mid-sized manufacturers find it more complex than necessary. | Pre-built connectors for both BC and F&O. The carrier side lives outside the ERP and the link is configuration-based rather than custom-built. | |
SAP | The basic delivery document; a heavy transport module exists, aimed at large enterprises. | Most manufacturers never activate the transport module. If you are on ECC, you will need to migrate at some point (see the note below). | Connects via API or secure file exchange, whether your SAP is cloud-based or on-premises. |
A single cloud-based record of orders, inventory and finance. | Native carrier support leans towards parcel shipping. Multi-mode freight across LTL and FTL was never really its remit. | One integration connects all carriers. SomnoMed cut label creation in France from 90 minutes a day to 20, then rolled the setup out across its other European hubs. | |
Affordable and flexible, with delivery connectors aimed mostly at parcel carriers. | The gaps start to show once you move pallets and mixed freight across a real carrier list. | A pre-built Cargoson connector lets you scale up shipping without maintaining a separate plugin per carrier. | |
Monitor | Production planning, MRP and shop floor management. | Multi-carrier shipping was never its intended purpose. | A clean fit for a layer on top that handles rates, booking, labels and tracking, and sends the cost back into Monitor. |
Cloud vs on-premise ERP: what it changes for shipping
There are two changes when your ERP runs in the cloud.
- The vendor controls the release schedule. New versions are released according to their timeline, not yours, so whoever maintains your shipping connection must keep track of every release. Find out who is responsible for compatibility before you sign the contract.
- The label still needs to be printed at the packing station. Whether the ERP is cloud-based or not, someone at the loading bay needs the correct label and freight document. The shipping setup must route this information to a local printer without creating a separate workflow for each carrier.
What happens to your shipping when your ERP migrates
The situation is different if your carrier contracts, shipping rules, labels and tracking sit in a separate layer instead of the ERP. Then a migration means repointing one connection instead of redoing all the carrier work.
Stokker, a tools and machinery wholesaler, ran into this exact issue when they moved to a new ERP. Rather than rebuilding integrations with each transport partner individually, Stokker connected them all through Cargoson, which reduced the setup time from weeks to minutes. They now process 15,000 shipments per month with just two members of staff.
Who owns ERP shipping over time
ERP shipping integration is not a one-time setup. ERPs get upgraded. Carriers change label formats, service codes, and API versions according to their own schedule and without consulting you. And the person who knows which portal holds which password might eventually leave.
Therefore, the question is not just whether it connects, but who keeps it connected. With a shipping layer, the provider maintains the carrier connections centrally. If a carrier changes its API, it's the provider's job to fix it, not a change request against your ERP. With Cargoson, carrier connectivity comes as part of the product, not as an additional charge, and if you work with a carrier that is not yet connected, Cargoson will connect them at no extra cost.
The integrated approach, and where to go deeper
Your ERP system manages the order. A shipping layer on top handles transport: live rates from your carriers, booking, labels and documents, tracking and freight cost, so the financial record stays complete. Your team only needs to enter a shipment once and not via a portal.
Our TMS-ERP integration guide explains how that data moves and what questions to ask any vendor before committing. Whether your ERP module is sufficient in itself is covered in ERP vs TMS. This article describes the same layer from your ERP's perspective.
Cargoson is built exclusively for shippers, manufacturers, and wholesalers, not carriers or 3PLs. Every feature is designed to solve a problem for a logistics team rather than a freight forwarder. Because the platform is independent and not carrier-owned, the rates you negotiate remain yours. It comes with pre-built connectors for Microsoft Dynamics, Dynamics 365 F&O, NetSuite and Odoo, and connects to more than 2,000 carriers by direct API and EDI integrations. Pricing starts at €199 a month, a fraction of what a traditional enterprise rollout costs. And if you don't have a large IT team, you'll be reassured to know that support is the aspect that our customers rate most highly in reviews.
You can test it with your own ERP and carrier data before you decide. Book a free, no-obligation 30-minute consultation with our experts. We'll go over our features, your setup, and discuss whether and how Cargoson could help you.
LinkedIn
Cargoson
