Ask most freight forwarders whether they have EDI, and the answer is usually yes. Ask them what actually happens to a customs declaration between their booking system and the customs authority, and the answer gets murkier - a spreadsheet emailed to a broker, a login to a third-party portal, a re-key into a separate compliance tool. Data is moving. It's just not moving directly, and every extra handoff in that chain is a place where a shipment can stall.
For AU/NZ freight forwarders, this distinction matters more than the acronym suggests. EDI isn't a checkbox feature - it's the plumbing that determines whether a booking, a customs filing, or a status update happens automatically and correctly, or depends on someone manually bridging the gap between systems that don't actually talk to each other.
What EDI Actually Means in Freight Forwarding
Electronic data interchange, in a freight forwarding context, is the structured exchange of shipment data directly between systems - no manual re-entry, no PDF attachment, no person copying numbers from one screen into another. A booking confirmation lodged with a carrier, a house bill reconciled against a master bill, a container milestone update, a customs declaration - all of these are, in principle, EDI transactions: structured messages passed system-to-system in a known format.
The operative word is "directly." A lot of what gets called EDI in practice is closer to electronic paperwork: an email with a spreadsheet attached, a manual upload into a carrier's web portal, a PDF that someone on the other end re-keys into their own system. That's still electronic, and it still moves data between parties, but it isn't EDI in the sense that actually removes manual handling - it just moves the manual handling downstream to whoever receives it.
Real EDI matters because freight forwarding runs on data that has to be both accurate and timely across multiple parties at once: the forwarder, the carrier, the customs authority, and often the customer. A single shipment might generate a dozen data touchpoints between booking and delivery. Every one of those touchpoints that depends on a person re-typing information is a touchpoint where a transposed HS code, a missed field, or a delayed re-key can hold up the shipment behind it.
Why This Matters More for Customs Data Than Almost Anything Else
Most EDI failures are annoying. A missed carrier status update means someone makes a phone call. A delayed booking confirmation means a bit of chasing. Customs data is different, because the party on the other end of that exchange has the power to physically stop a shipment.
Customs authorities work from what's actually lodged in their systems, not from what's sitting in an inbox waiting to be processed. If a forwarder's customs data reaches the authority via a manual step - someone preparing a filing and submitting it through a portal, or a broker re-keying data from an email - there's a gap between when the data is ready and when it's actually lodged. That gap is exactly where delays, mismatches, and compliance exposure live. A direct, automated connection between the forwarding platform and the customs system closes that gap by removing the manual step entirely.
This is also where the difference between "we have EDI" and "we have a direct customs bridge" becomes concrete rather than semantic. Plenty of forwarding software vends data out via EDI to a carrier or a warehouse system perfectly well, while still relying on email, spreadsheets, or a third-party intermediary to actually get customs declarations lodged. The EDI claim is technically true and practically incomplete.
The Common Workaround: Email, Portals, and Third-Party Middlemen
Talk to enough AU/NZ forwarders and a pattern emerges. Most don't have a direct system-to-system connection to customs. Instead, customs data gets assembled in one system, then handed off - by email, by manual portal entry, or via a third-party intermediary such as Australia Post or Seko acting as a go-between - to actually reach the customs authority.
None of these workarounds are unreasonable choices in isolation. They exist because building and maintaining a genuine, direct customs connection is real engineering work, and most forwarding software vendors would rather integrate with an existing intermediary than build and support the connection themselves. But the practical cost of that choice lands on the forwarder using the software: an extra party in the chain, an extra system that can have an outage, an extra support queue when a declaration doesn't go through, and an extra step where a customs deadline can be missed because a hand-off didn't happen in time.
It also means the forwarder is downstream of someone else's priorities. If a third-party intermediary changes its own systems, has an outage, or deprioritises a support ticket, that's now the forwarder's problem too, even though the forwarder didn't choose that dependency - it came bundled with the software.
What a Genuine Customs Bridge Looks Like
A direct customs bridge means exactly what it sounds like: a system-to-system connection between the forwarding platform and the customs authority's own systems, with no email, no manual portal step, and no third-party service sitting in between relaying the data.
Expedient's EDI integration into Australian customs is built on exactly this model - IBM MQ, message-oriented middleware suited to the kind of reliable, ordered message delivery a customs bridge needs. It's a real, in-house-built connection, not a description of an aspiration: direct EDI, including an IBM MQ customs bridge built in-house, is how it's actually implemented, not a marketing gloss on an email-based process running underneath it.
That distinction is the practical difference between "our software can export data in an EDI format" and "our software talks to customs directly." The first is table stakes. The second is what actually removes the manual re-key, the email attachment, and the third-party hand-off from a customs filing's critical path.
Why In-House Matters as Much as Direct
There's a second dimension to this worth separating out from "direct": who built the bridge, and who's responsible for keeping it working.
A direct connection that's licensed from, or dependent on, an outside vendor still carries some of the same risk as a third-party relay - if that vendor's connection breaks, changes, or gets deprioritised, the forwarder is waiting on someone else's roadmap to get it fixed. An in-house-built connection doesn't have that dependency. The team that built the IBM MQ bridge to Australian customs is the same team that supports it, which matters when a customs message format changes or a connection needs troubleshooting on a deadline.
This is true of Expedient's other integration work as well, not just the customs bridge specifically: all integration work - EDI, Xero, ContainerChain - is built and supported in-house, with no third party in the middle. For a forwarder, that means one team to call when an integration issue comes up, rather than a chain of vendors each pointing at the other.
Underneath the customs bridge specifically, Expedient's Corporate Comprehensive EDI and Customer Interface modules are the platform's dedicated EDI and carrier/customer data-exchange components - built as core parts of the system, not a bolt-on feature layered over a manual process. The customs bridge is the sharpest example of what direct, in-house EDI buys a forwarder, but it's built on the same underlying approach that runs the rest of the platform's data exchange.
What to Look for in an EDI-Capable Freight Forwarding Platform
If you're evaluating a platform - or auditing what you're already running - a few questions cut through the marketing language quickly:
- Is the customs connection direct, or does it route through email, a manual portal, or a third-party intermediary? Ask specifically, because "we support EDI" doesn't answer this on its own.
- Who built and maintains the integration? An in-house-built connection means one team is accountable end to end; a connection licensed from or dependent on an outside vendor adds a party you don't control.
- How many manual handoffs exist between booking and customs lodgement? Every handoff is a place a shipment can stall, regardless of how the rest of the platform is described.
- Does the same EDI approach extend across carriers, customers, and container tracking, such as ContainerChain integration, or is customs the only place it's been built out?
- What happens when something breaks? A direct, in-house connection means the people who built it can fix it - a third-party relay means you're in someone else's support queue.
None of these questions require deep technical knowledge to ask. They just require not accepting "we do EDI" as a complete answer.
Practical Steps to Audit Your Own Setup
- Trace one customs filing end to end, from the moment the shipment data is ready in your booking system to the moment it's actually lodged with customs. Count the manual steps in between.
- Identify every third party currently sitting in that chain - a portal, an email hand-off, an intermediary service - and note what happens to your timeline if any one of them is unavailable for a day.
- Ask your current or prospective platform vendor directly whether their customs connection is built and supported in-house, or licensed from and dependent on someone else.
- Extend the same audit to your other integrations - carrier bookings, customs clearance, accounting - since the same direct-versus-relayed question applies to all of them, not just customs.
Next Steps
EDI is one of those pieces of infrastructure that's invisible when it works and expensive when it doesn't. The forwarders least exposed to customs delays and integration outages aren't the ones with the most EDI connections - they're the ones whose connections are direct and supported by the team that built them, rather than relayed through email or a third party with its own priorities. Contact us to see how Expedient's EDI integration and Australian customs bridge fit into your existing booking and clearance workflow.
Frequently Asked Questions
What is EDI in freight forwarding?
EDI (electronic data interchange) is the structured, automated exchange of shipment, booking, and customs data directly between systems - carrier systems, customs authorities, and forwarding platforms - without someone manually re-typing the same information into each one. In freight forwarding it typically covers booking confirmations, house and master bill data, manifests, and customs declaration data.
Is EDI the same as sending data by email or through a portal?
No. Emailing a spreadsheet or PDF, or logging into a carrier's web portal to re-key data, moves information between parties but isn't EDI - there's still a manual step, and still a place for the data to drift or go stale. True EDI is a structured, system-to-system connection with no manual re-entry in the middle.
Does Expedient connect directly to Australian customs?
Yes. Expedient runs its own in-house-built IBM MQ bridge directly to Australian customs, rather than exchanging customs data via email or handing it off to a third-party intermediary like Australia Post or Seko. It's a direct system-to-system connection, not a relayed one.
Why does it matter whether EDI is built in-house or run through a third party?
A third party in the middle is another system that can go down, another support queue when something breaks, and another party with its own release schedule and priorities. An in-house-built bridge means the team that built the connection also supports it directly, and can adapt it when customs requirements or message formats change, rather than waiting on an external vendor.
What freight forwarding processes typically rely on EDI?
Common examples include booking confirmations with carriers, house and master bill reconciliation, container status and milestone updates, manifest and cargo report submission, and customs declaration lodgement. Any of these can be handled manually, but each manual handoff is a point where data can be delayed, mistyped, or lost.
