Logistics Software Engineering
Custom logistics software engineering and freight management solutions built for UAE trade corridors: Mirsal 2 customs integration, telematics data ingestion, and transport management system (TMS) development.
A declaration is only as good as the line items behind it. We treat the 12-digit tariff code, the declared value, and supporting trade documents as structured data, ensuring seamless clearing across Dubai Trade and regional ports.
Regulatory Landscape
In the UAE, a consignment does not move because a truck arrived. It moves because a declaration was accepted, the duties were assessed, and the risk engine routed it to a channel. Software sits between the customer and that machinery, so the interface is where most logistics engineering projects go wrong.
Customs in the UAE is already electronic at scale, and the next layer is invoicing: the Ministry of Finance e-invoicing programme rolled out with a pilot from 1 July 2026 and mandatory dates running from January 2027, reported to the Federal Tax Authority. Carriers, forwarders and 3PLs that build one clean document model now will carry it into both regimes instead of retrofitting twice.
Sources: Dubai Customs Mirsal 2 documentation and Dubai Trade service notices for declaration submission through the Dubai Trade portal and the B2G channel; Ministry of Finance UAE e-invoicing programme portal (Ministerial Decision 243 of 2025 and Ministerial Decision 244 of 2025, as amended by Ministerial Resolution 66 of 2026); Federal Tax Authority e-invoicing guidance. Last reviewed October 2026.
Domain Overview
Every vehicle in a fleet is emitting a position every few seconds. Over a fleet, that is a firehose of low-value rows where the interesting events are rare and the ordering is not guaranteed. Modelling that as rows in a table is the first mistake: you spend your database on writes to answer a handful of questions that actually matter, like which vehicles have been stationary too long, and which are about to enter a restricted zone.
We ingest positions as an append-only stream, keep only the current state per device, and raise domain events for the things that warrant a human's attention. Stationary-too-long, geofence entry, route deviation, and driver phone-off all become events. The raw trail is retained for a defined period for dispute resolution, and not a moment longer. Turning that trail into the port, dwell and cost analytics for UAE corridors an operator can act on is the next step, and the field side is driver, proof-of-delivery and yard apps.
Perfect automatic assignment looks good in a demo and falls apart in reality, because a driver who has been driving eleven hours, a customer who needs a tail lift, and a load that must be collected inside a port time window are all constraints the solver cannot see. The useful transport management system (TMS) design is a recommendation engine that ranks options with the reasons visible, and a dispatcher who can override in one action. We optimise for the override rate, because that is the number that tells you whether the constraints are right.
For a large share of freight, the deliverable is a document: a clean bill of lading, a delivery note that satisfies the consignee, a customs declaration that clears without a query. That means the document has to be generated from real transaction data rather than typed into a form, has to be tamper-evident once signed, and has to be retrievable years later in a format that still opens.
We store documents as structured data with a rendered artefact beside them, sign the structured form, and keep the signature verifiable. A PDF is an output, not the record. The declaration workflow that produces those documents is freight management and customs declaration platform work, and for Mirsal 2 that means treating the 12-digit tariff code and declared value as first-class data.
Operational Friction
The recurring complaints from dispatch teams, transport managers, and supply chain operators.
Prices are calculated manually per route, so the quote takes hours and the customer has already booked with another carrier.
Rates derive from distance, vehicle type, fuel index, and surcharges, with every input recorded so a quoted price can be explained months later.
Proof of delivery is a signed sheet, so a dispute becomes an argument about whose paper is authentic.
Proof of delivery (ePOD) and electronic bills of lading are generated from transaction data, signed, and stored in a structured, tamper-evident form.
When a load is cancelled at 16:00, nobody has a list of who was told, and vehicles arrive for a job that no longer exists.
Every load has an explicit state, an owner, and a next action, so cancelling a job notifies exactly the people who need to know.
The customer sees a dot on a map with no ETA and no reason for the delay, so they call the depot for an update.
Customers get milestone updates and a reason code for any delay, sent automatically rather than after someone remembers.
Core Capabilities
Custom supply chain and transport modules that replace disjointed spreadsheets, legacy portals, and manual phone calls.
Orders, jobs, vehicles, drivers, and multi-leg routing managed as a unified state machine, with every state transition recorded and reversible where safe.
High-frequency GPS and CAN bus data from mixed device vendors, normalised, deduplicated, and reduced to meaningful events before storage.
Legally structured shipping documents with digital signature capture, tamper-evident storage, and long-term retrievability for dispute and audit.
Configurable rate cards by lane, vehicle, and service level, with fuel indexation, accessorials, and a margin floor applied consistently.
Structured declaration data with validation against HS codes and origin rules, submission tracking, and query-response handling in one workflow.
Barcode scanning, cross-docking, load planning, and yard slot management connected to the same order data the transport layer uses.
Reference Architecture
Ingest volume and operational latency pull in opposite directions, so the split matters in scalable logistics software.
Dispatch board, driver mobile app, customer portal, and back-office. Channel concerns stop at this layer.
Rate calculation, assignment ranking, load planning, and ETA prediction, with the constraints that drive them made explicit.
Order, job, and load state machines, capacity constraints, and driver hour rules enforced on every transition.
Position ingestion with event reduction, plus structured document generation, signing, and retention.
Customs and partner APIs, ERP and TMS connectors, and an immutable log of every state change and signature.
Position data is summarised on the way in. The database holds current state, not a row per ping.
Every state change is an event with a timestamp and an actor, so any dispatch decision can be reconstructed.
Documents are signed as structured data. The PDF is a rendering of a record, not the record itself.
Security & Trade Compliance
Logistics software platforms hold commercially sensitive pricing, driver personal data, and negotiable instruments. These are the controls we implement.
Location trails and personal data are retained for a defined operational period, then deleted, with the schedule configurable per data class.
Per-class retention schedule · automated purge
Bills of lading and delivery evidence are signed over their structured content, so an altered document fails verification rather than looking different.
Content hashing · signature verification on read
Telematics devices are provisioned per vehicle with key rotation, and a device that leaves the fleet is revoked so it can no longer report as that vehicle.
Per-device keys · revocation list
A driver sees their own route and consignment details only, and a depot user sees their own depot, not the whole network.
Assignment-scoped RBAC
Submitted declarations are retained with the exact payload sent, the response received, and a correlation reference for any query raised.
Payload retention · request/response correlation
Partner and ERP connections use scoped credentials with signed webhooks, and every inbound payload is authenticated before it reaches the transport core.
Scoped credentials · signed webhooks · payload authentication
Typical Stack
Delivery Lifecycle
We map the current dispatch process, the documents issued, and the integration points already in use, including manual workarounds.
OutputProcess map and document inventory
The structured document model, the load state machine, and the telemetry event definitions are agreed before any UI work.
OutputData model, state diagrams, event catalogue
We run the system against actual consignments alongside the current process and compare outcomes rather than assuming parity.
OutputPilot findings and gap list
Device protocol tests, customs channel submissions, and load tests at realistic fleet and order volume.
OutputVerification report with capacity headroom
Staged cutover per lane with the old process still available, plus runbooks for the dispatch and customs teams.
OutputRunbooks and team training
Use Cases
A declaration workspace that validates HS codes, declared values, and supporting trade documents before submission, keeping the broker, customer, and duty ledger on one record.
Fewer rejections, and no re-keying between the forwarder and the broker.
Device ingest, route history, reefer temperature excursions, and driver workflows in one place, with alerts that reach the operations desk rather than sitting in a vendor portal.
Excursions and delays are handled while there is still time to act.
Inbound and outbound bookings, gate movements, and container tracking, reconciled against the customs record so a discrepancy surfaces on the day it happens.
Stock and customs records agree without a monthly reconciliation project.
Digital signatures and photo capture at delivery, tariff and fuel calculation, and invoice generation that produces the data an accredited e-invoicing service provider can transmit.
Billing starts from the delivery event, not from an admin reminder.
Container and vessel movement data consolidated into a single operational view for forwarders and distributors, with exception alerts on dwell and gate time.
Planning runs on live data instead of a morning call.
Job assignment, navigation, document capture, and offline-tolerant proof of delivery (ePOD) for last-mile and linehaul drivers.
Proof of delivery is complete before the vehicle returns to base.
Integration Surface
Related Services
Fleet and warehouse work usually pulls in mobile and data engineering alongside the platform build.
FAQ
Through Mirsal 2, Dubai Customs' electronic declaration and clearance system. There are two channels: the Dubai Trade portal, and the B2G web service for eligible high-volume partners, where a client system calls a Customs web service to submit declarations directly. Either way a business code and a digital signature are required, so the integration is not just a data feed but a credentialed, authenticated channel. We map your order and inventory data onto the declaration structure, validate it, and keep the submission response and duty settlement attached to the shipment record.
As two representations of one record, not two records. Documents are captured once with their original language preserved, then indexed for retrieval in either language, so an Arabic-only original and its English translation stay linked to the same consignment. Printed output is generated from the same source in both languages and in both directions, and search works across both regardless of which script the user types.
Vehicle and journey data sourced from RTA where your operation needs it, combined with your own telematics devices for the things RTA data will not tell you: reefer temperatures, door events, engine diagnostics, and driver behaviour. The practical work is in identity resolution, keeping a device, a plate, and a driver on the same journey record, and in alerting: an exception has to reach an operator who can act on it.
It can produce an estimate and show its reasoning, which is the honest version of that question. Arrival prediction depends on traffic, route, driver hours, and historical behaviour, and it will be wrong sometimes. We build it as an event-driven estimate with a confidence band and a clear list of the factors behind it, so dispatchers can judge when to trust it rather than treating it as a fact.
It means your consignment and declaration data is structured and validated in our system, submitted to the authority's channel, and the response tracked against the original submission. Where an authority offers an API, we integrate directly. Where it requires a portal or a licensed intermediary, we design the workflow around that reality instead of pretending the integration is one API call.
The driver app is built offline-first. Actions a driver takes on a job capture locally and sync when connectivity returns, with the server rejecting rather than silently overwriting conflicting data. In practice that means a driver can complete a delivery with signature in a dead zone, and the record reconciles when they come back into coverage.
Send us the documents you issue and the trackers you run. We will come back with a written view of what we would build and where the manual steps would disappear.
A 30-minute technical conversation, not a sales call.