Most DMCC tenants we observe blame their freight tooling for problems the tooling cannot fix. The platform feels broken. Updates are late. The status in the system does not match the status on the ground. Different parties report different things. The instinct is to look for better software. The honest answer is that there is no software product that fully fixes what is wrong, because what is wrong is not a software problem. It is a coordination problem between five or six independent actors, none of whom has end-to-end visibility, and none of whom has the structural authority to enforce a single source of truth across the others.
This piece is a contrarian view of why DMCC freight feels broken even when each individual system is working correctly. It is opinionated. We are not arguing that freight software is useless or that DMCC tenants should give up on tooling. We are arguing that the buy decision is consistently scoped against a problem the tooling cannot fully solve, and that the recovery position starts with recognising what is actually wrong rather than buying a different product. The cost of getting this wrong is paid in delayed shipments, surprise duties, broker disputes, and the slow erosion of trust between trading partners who blame each other for problems that none of them caused individually.
Where we describe specific DMCC, Dubai Customs, or Mirsal 2 processes, we are referencing publicly available information. Operational and pattern observations are our own. Where vendor categories are mentioned, they are descriptive rather than recommendations.
Six Actors, Six Partial Views
Below is the typical journey of a DMCC freight transaction across seven stages, with six actors involved at different points. Tap any actor to see what they have visibility of and what they do not. The pattern that emerges is that no single actor sees more than half the journey. The coordination problem is structural, not optional.
DMCC freight: who sees what
Tap any actor to highlight the stages they have visibility of
Why Software Cannot Fully Fix This
The most-asked question we hear from DMCC tenants is which freight platform fixes their visibility problem. The honest answer is that no platform fixes it because the data the platform would need does not all exist in one place. The freight forwarder's data lives in their booking system. The broker's data lives in Mirsal 2 and their internal workflow tools. Dubai Customs hold their own view in their internal systems. DMCC zone entry data lives with the zone authority. The supplier overseas often does not have a system that integrates with anything downstream. A platform that pulls one or two of these together is doing useful work; a platform that claims to pull all of them together is usually overselling.
The structural reason this is not a software problem
Software solves problems where the data exists and the issue is access, processing, or presentation. DMCC freight visibility is a problem where critical data is held by independent parties under no obligation to share it in real time, in a consistent format, or at all. No software product can manufacture data the upstream parties do not provide. The fix has to start with the coordination model, not with the tooling layer that sits on top of it.
This framing matters because it changes what a recovery looks like. A DMCC tenant who treats the visibility problem as a software problem keeps buying products that solve part of the picture, gets frustrated when the picture is still incomplete, and eventually gives up and goes back to managing freight by phone calls and emails to each individual party. A tenant who treats it as a coordination problem starts by mapping who has what data, what they are willing or able to share, what the cost of better coordination is, and where targeted software actually adds value within that coordination model. The second approach typically costs less, takes less time, and delivers a working operating model rather than a partly-fixed dashboard.
What Software Can and Cannot Fix
What software can genuinely improve
The slices where data already exists in a usable form. Customs declaration status (where the broker's view is digitised in Mirsal 2). Freight forwarder bookings (where the forwarder's system can be integrated). Internal workflow within the importer's own operation. Document management for the paperwork the importer does control. These are real software problems that real software can solve.
What software cannot fix
The gap between actors who have no commercial reason or technical capability to share data in real time. The supplier overseas who emails an updated despatch document three days late. The customs broker who is also handling fifteen other clients and updates each at the end of the day. The shipping line whose API does not expose what the importer needs. These gaps are addressed by changing the coordination relationship, not by adding a platform on top.
The middle case
Some gaps look like data problems but are actually contractual. The freight forwarder will not share certain data because their commercial agreement does not require it. The broker will not push real-time updates because they were not engaged on those terms. Software cannot fix this; renegotiating the engagement can. Many DMCC tenants buy software to solve what is, in practice, a renegotiation problem.
What good software does for coordination
Real freight tooling that helps DMCC tenants is the kind that supports the coordination model rather than trying to replace it. A consolidated workspace where document statuses, broker handoffs, customs declarations, and DMCC zone events are visible together, integrated with the parties whose data is genuinely available, with honest gaps where data is genuinely not. The tooling supports the operating model. It does not pretend to replace coordination work that has to happen in the relationships.
The Numbers
The Recovery Position
The recoverable position for most DMCC tenants is not a different freight platform. It is a focused mapping exercise that addresses the coordination layer first and then targets software at the parts of the picture where it genuinely helps.
| Step | What it involves | What changes as a result |
|---|---|---|
| 1. Map the actors | Identify every party in your typical freight transactions, what they hold, what they are obliged to share, what they currently share, and on what cadence | The visibility gap becomes visible: you can see exactly which stages no one is reporting on in real time |
| 2. Renegotiate the data layer | Identify which parties could share more, what it would cost commercially, and which renegotiations are worth doing first | Some "software problems" turn out to be commercial relationships that need updating, not technology that needs replacing |
| 3. Target software where data exists | Build or buy tooling for the slices where data is genuinely available: Mirsal 2 integration for customs status, forwarder API integration for freight tracking, internal workflow for paperwork, DMCC zone status updates | The tooling addresses real problems with real data rather than pretending to fix what cannot be fixed at the tool layer |
| 4. Accept and manage the residual gap | Some gaps will remain. Build operational practices around them: scheduled status calls, structured email updates, defined escalation paths, accountability for who is responsible for closing each gap when it surfaces | The coordination work is acknowledged rather than hidden under a partly-working dashboard |
The DMCC tenants who consistently run their freight well are not the ones with the most expensive freight platforms. They are the ones who treat the coordination layer as the primary problem and the software layer as a tool that supports it.
Where Structural Visibility Actually Helps
The conversations where this analysis is most useful are at the point where a DMCC tenant has bought one or two freight or supply chain visibility products, has not got the visibility they expected, and is starting to wonder whether more software is the answer. The honest analysis usually points the other direction: the coordination layer needs work first, and the targeted software work that makes sense afterwards is typically smaller, cheaper, and more focused than what was originally being considered.
For broader logistics platform context, our pillar overview is at logistics software, with deeper coverage of supply chain visibility, freight forwarding software, and customs brokerage software. The integration and custom-build practice sits within our broader operational platform work. Get in touch if a 45-minute conversation about a specific DMCC freight setup would be useful.
Frequently Asked Questions
Yes, and the pattern is consistent. The ones who have solved it are typically larger traders with enough volume to negotiate data-sharing into their commercial agreements with brokers and forwarders, plus internal operations capability to absorb residual gaps. Smaller DMCC tenants generally cannot use the same approach because they lack the commercial leverage. For them, the practical fix is targeted software for the slices where data is available plus operational practices for the residual gap, rather than trying to replicate the data-sharing model that only works at scale.
Mirsal 2 is the Dubai customs declaration system and the data accessible through it is genuinely useful for the customs and broker stages of the freight journey. Integration with Mirsal 2, where commercially appropriate and technically feasible, is one of the higher-value targeted software interventions a DMCC tenant can make. It does not solve the upstream visibility gap (supplier despatch, freight movement) or the downstream gap (DMCC zone entry, warehousing), but for the customs and broker layer it is genuinely a software-solvable problem. Treat Mirsal 2 integration as one component of the coordination model, not as a complete answer.
Partially. The better visibility platforms aggregate data from multiple sources and present it in one workspace, which is real value where the source data exists. They do not manufacture data that upstream parties do not provide, and they do not solve the contractual layer where parties have not agreed to share data in real time. A visibility platform is a useful component of a coordination model that has been worked out separately. It is not a substitute for working out the coordination model in the first place. DMCC tenants who buy a platform without doing the coordination work first usually end up with a partial dashboard and the same operational frustrations they started with.
The structural pattern of multiple actors with partial views applies to any free-zone freight in the UAE. The specific actors and the specific gaps differ between DMCC, JAFZA, DAFZA, KIZAD, and the various other free zones, but the coordination challenge is similar. DMCC's specifics include the commodity-trading concentration (gold, diamonds, agri-products) which adds compliance overhead at certain stages, and the integration between DMCC zone authority systems and broader Dubai customs flow. The general principle that this is a coordination problem rather than a software problem applies across UAE free-zone freight.
The pattern that works for a typical mid-volume DMCC tenant is usually three components. First, a workspace that consolidates document status, broker communications, customs declaration status, and DMCC zone events into one operational view. Second, integration with the data sources that genuinely have APIs (the customs broker's Mirsal 2 view, the freight forwarder where they expose tracking, internal ERP). Third, structured operational practices for the data that does not flow automatically: scheduled supplier check-ins, defined broker reporting cadence, escalation paths when an update is missing. The third component is where most platforms fall short because it is not really software work; it is operating model work that the software supports.
The DMCC tenants who run their freight well are not the ones who have found the right software product. They are the ones who recognised the coordination problem for what it is, did the unglamorous work of mapping actors and renegotiating data sharing, and then targeted software at the parts where it genuinely adds value. The recovery is not a different platform. It is a different framing of what the actual problem is. Once the framing changes, the software question gets a lot smaller and a lot more answerable.
DMCC, Dubai Customs, and Mirsal 2 process descriptions reflect publicly available information at the time of writing and may change. Treat the Dubai Trade portal and the Dubai Customs portal as canonical references for current process detail. Operational and pattern observations in this article reflect our own perspective on UAE free-zone freight and are not advice on any specific shipment, supplier, broker, or platform decision. References to DMCC, Dubai Customs, Mirsal 2, Dubai Trade, JAFZA, DAFZA, KIZAD, and any other named systems or bodies are descriptive only and do not imply endorsement, partnership, or affiliation. Public sources used in this piece are listed on our Sources and Data page.
Ready to Build Something?
If this resonated, let's talk about how we can apply these ideas to your business.
Start a Conversation