The Dubai–Africa Trade Lane: Two Systems, One Consignment
A Dubai entity buys and consolidates; an African operating company clears, distributes and collects. Almost every group runs these on separate systems and reconciles by email — which works right up until somebody asks what the group actually earned on a container.
There is a shape of business this corpus keeps meeting from one side and rarely describes from both: a buying and consolidation entity in the UAE feeding operating companies further south. Electronics into Nairobi, building materials into Dar es Salaam, spares into Lagos, FMCG into Lusaka. From Dubai it looks like an export business. From Nairobi it looks like an import business. It is one business, and the gap between those two views is where the money goes missing.
We should be upfront about our position. We are a Nairobi company, our depth is heavier on the African leg, and that is exactly why we are interested in this shape rather than in UAE domestic operations, where local vendors will serve you better. This post is the argument, and it includes the parts that argue against us.
Two systems, one consignment
The default architecture is not chosen; it accretes. The Dubai entity buys a system that suits a trading office. The operating company buys one that suits a distributor. Both are reasonable purchases. Neither was bought to answer a question that spans them.
What each end owns, and what has to cross
The Dubai end
Well understood, well served, and the part every local vendor can do.
- Supplier selection, purchase orders and payment out to Asia and Europe.
- Consolidation of several suppliers into one shipment.
- Free zone stock, with duty suspended while it sits there.
- Re-export documentation and the outbound customs event.
- The invoice to the operating company, in whatever currency the group has decided on.
The African end
Where the cost is genuinely made, and where most systems sold in Dubai stop looking.
- Clearing, duty, port charges, demurrage and inland transport.
- Landed cost at the rate actually paid, not the rate assumed when the order went in.
- Stock across branches, depots and delivery vehicles.
- Collection on rails that are frequently not bank transfers — mobile money, cash, staged credit.
- Field and depot capture that has to work without a signal.
What has to cross the seam, and usually does not
- The consignment identity. One reference that survives from the Dubai purchase order to the African receipt. Without it there is nothing to join on.
- The true cost at handover, including the Dubai-side charges, in a currency both ends can read.
- The physical reality — what shipped, what arrived, what was short, what was damaged.
- The eventual sale, so somebody can subtract one from the other and get a group margin.
The question that fails
Each system answers its own questions perfectly well. Dubai knows what it paid the supplier and what it invoiced the subsidiary. Nairobi knows what it cost to land and what it sold for. Neither can answer the only question the shareholder actually asks.
What did the group make, net of both legs, on this container? Nobody can say without a week of spreadsheet work.
And because it takes a week, it is done annually at best, usually for a bank or an auditor, and never in time to change a buying decision. The consequence is not a reporting inconvenience. It is that the group is pricing, buying and stocking on a margin figure it has never verified.
| The question | Dubai system | African system | Answerable today? |
|---|---|---|---|
| What did we pay the supplier? | Yes | No | Yes |
| What did it cost to land? | No | Yes | Yes |
| What did we sell it for? | No | Yes | Yes |
| What did the group earn on it? | Partial | Partial | Only by hand |
| Which supplier is actually most profitable after landing? | No | No | No |
| Is the transfer price doing what we intended? | Partial | No | No |
The last two rows are the expensive ones. A supplier who looks cheapest in Dubai can be the most expensive after landing — because of packaging that fails inspection, lead times that force air freight, or short-shipping that nobody attributes back. With two disconnected systems that pattern is invisible, and the buying team keeps rewarding it.
Three architectures, honestly compared
Shape one
Two systems, reconciled deliberately
Keep both, but agree a consignment reference that both carry, and a monthly join done to a written procedure rather than by whoever is free. Cheapest and genuinely underrated. The cost is that it depends on discipline, and discipline decays. If your volume is low, stop here — this is the right answer.
Shape two
One system across both ends
Both entities on one platform, the consignment as a single object from purchase order to final sale, group margin as a query rather than a project. This is what we propose, with the honest caveat that our depth is uneven — heavier on the African leg than the Gulf one, and with no UAE fiscal or payroll layer at all.
Shape three
Two systems plus a warehouse
Keep both operational systems and push both into a reporting layer. Common in larger groups and perfectly respectable. The cost is a third thing to own, a lag between event and insight, and a tendency for the warehouse to become the only place the truth lives — which is fine until someone needs to act on it in the moment.
Notice that shape one is not a failure state. Plenty of groups running four or five containers a month should not consolidate systems, and a vendor telling them otherwise is selling. The threshold is roughly where the manual join stops being done monthly because it has become too long a job — which in our experience is somewhere around fifteen to twenty consignments a month, though it depends far more on SKU count than on container count.
If you do join them, join them in this order
-
Agree the consignment reference first
One identifier, created at the Dubai purchase order, carried onto the shipment, the African receipt and every downstream cost. This is the cheapest step, it is what makes everything else possible, and it cannot be applied retroactively to shipments already in flight.
-
Fix the transfer price policy before the software
What the Dubai entity charges the operating company, on what basis, and who may change it. This is a group finance and tax decision with real consequences in both jurisdictions, it belongs to your advisers, and no system should be allowed to make it by default.
-
Instrument the African receiving dock
Landed cost is created here or it is never created. Duty, port charges, demurrage and inland transport allocated to the consignment at the point they are incurred, rather than reconstructed from an agent statement two months later.
-
Then connect the Dubai end
Purchase orders, consolidation and the outbound event, joined to the same consignment reference. Deliberately last: the African leg is where the uncertainty lives, and proving it first means the Dubai connection is a plumbing exercise rather than a discovery exercise.
-
Run one container end to end before switching anything
One real consignment, both legs, all the way to a group margin figure somebody in finance is willing to defend. If that number cannot be produced and explained, nothing about the wider rollout will improve it.
Where we are strong and where we are not
What AWRA OpsHub does today
- The African leg in depth — clearing and landed cost, branch and depot stock, van and route custody, mobile money collection, offline-first capture where the network is not.
- Consignment-level costing with freight, duty, port charges and inland transport allocated to the receipt and carried into unit cost.
- Multi-entity operation with each entity holding its own base currency, users and approvals, and a reporting view across them.
- Foreign-currency transactions at the rate actually applied, held on the record, so a bad month is distinguishable from a bad cross.
- Free zone and mainland as separate stock locations with governed, costed transfers between them and documents attached.
- Procurement that refuses above a threshold, RFQ comparison with the award reason recorded, and three-way matching before money moves.
What it does not do
- No UAE fiscal layer. No FTA e-invoicing, no corporate tax computation, no statutory accounts. The Dubai entity needs those from somewhere else.
- No WPS payroll for the UAE side, and no Arabic interface.
- No customs system integration at either end — not Dubai Trade or Mirsal, and not the African single-window systems either.
- No intercompany elimination or statutory consolidation. The group view is a reporting layer, and your auditor still does the consolidation.
- No transfer pricing engine. We record the price you set; we do not compute, defend or document a transfer pricing position, and you should not want a software vendor to.
- Our Gulf-side depth is younger than our African depth, which is an honest statement about a first market rather than a temporary caveat. Judge it on a demo, not on this list.
The last item in the right-hand column is the one to weigh hardest. If your problem is genuinely centred in Dubai, a UAE vendor knows that end better than we do and we will say so. Our claim is narrower and, we think, defensible: on the leg where this lane actually breaks — clearing, landing, distributing and collecting in Africa — very few vendors selling into Dubai have any depth at all.
What is not built for the UAE today can still be built for you
Anything described above as not built is a statement about what ships in the standard product today — not a limit on what AWRA OpsHub can do in the UAE. Kenya's eTIMS integration and its maintained payroll engine exist because Kenyan clients needed them and commissioned them; neither appeared by itself. The same door is open here. If FTA e-invoicing, a WPS salary file, a bank or mobile money feed, a statutory return format or a link to a system you already run is what stands between you and a decision, tell us and we will scope it as a build — written spec, timeline and price — before you commit to anything.
FTA e-invoicing and VAT output
Document structuring and submission through an accredited service provider under the Ministry of Finance programme, with the parts vendors gloss over — rejection handling, resubmission, and a daily report of sales carrying no registration identifier. Corporate tax computation stays with your adviser by design; what we would build is the record it is computed from.
Banks, acquirers and customs paperwork
Bank statement feeds, card acquirer settlements and instant-payment files pulled into the Payments Register, plus a data link to your clearing agent or port community system so a customs event updates the consignment instead of arriving as an email.
Payroll and statutory returns
WPS salary files in the layout MoHRE or your free zone authority expects, with end-of-service gratuity accrued on live employee records rather than estimated in a spreadsheet each year.
Systems you already run
The accounting package, CRM, online store or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. No roadmap slide, and no pretending in a demo that something exists when it does not.
Tell us what you need integratedWhere to go next
The cost arithmetic on the Dubai side is in one SKU, two landed costs, and the wider buying frame is in the UAE buyer's guide. For the African end in its own right, the closest equivalents are inventory and distribution for Lagos and operating across the continent, both of which assume the container has already arrived and take the story from there.
Our take
One consignment reference, a transfer price policy settled by your advisers rather than by a default, and landed cost created at the receiving dock instead of reconstructed afterwards. Those three make the group margin question answerable whether you run one system or two — and if you are under fifteen consignments a month, two systems reconciled deliberately is very likely the right answer. Above that, the manual join quietly stops happening, and what you lose is not a report. It is the ability to tell which supplier is actually making you money.
Bring one container and both ends
A real consignment, from the Dubai [purchase order](/glossary/purchase-order) to the African sale. We will produce a group margin figure and show our working — including the parts we would need your [clearing agent](/glossary/clearing-agent) or your adviser to fill in.
Explore AWRA for the UAEFrequently asked questions
Can one system really run a UAE entity and an African one?
Operationally, yes — that is the case we make. Each entity runs with its own base currency, users, approvals and records, and a reporting view sits across them so a consignment can be followed from a Dubai purchase order to an African sale. What does not travel between countries is fiscal integration and statutory payroll automation, which are Kenya-only today; every other entity runs on the general operations, multi-currency and VAT-aware layer with local compliance handled locally. And a group view is reporting, not a statutory consolidation.
How do you handle the transfer price between our entities?
We record it and carry it through the cost chain so the group margin arithmetic works. We do not compute it, benchmark it, document it or defend it, and we would be doing you harm if we implied otherwise — transfer pricing is a tax position with consequences in both jurisdictions and it belongs with your advisers. What we will do is make sure the policy they set is applied consistently and visibly rather than being re-decided per shipment by whoever raises the invoice.
What if we only have a few containers a month?
Then keep your two systems and reconcile them deliberately: one consignment reference carried by both, and a monthly join done to a written procedure. That genuinely works at low volume and we would rather tell you so than sell you a consolidation you do not need. The threshold where it stops working is not really about container count — it is about the point at which the manual join takes long enough that it silently stops being done every month.
Do you integrate with clearing agents or port systems?
Not as a shipped integration, at either end of the lane. Customs events are recorded as evidence and their costs as landed cost, but there is no data connection to Dubai Trade, Mirsal or the African single-window systems. Where a link to a specific agent or system would decide a purchase, we scope it as a build with a written spec, timeline and price — which is how Kenya's eTIMS integration came to exist — rather than describing it as a roadmap item.
Which end should we implement first?
The African end, and we recommend that even though it delays our own revenue on the Dubai side. Landed cost, branch stock and collection are where the uncertainty and the unrecorded money live; the Dubai leg is comparatively orderly and well documented. Proving the messy end first means the Dubai connection is a plumbing exercise. Doing it the other way round means discovering the hard problems after you have already committed the architecture.
Does this apply to lanes that are not Dubai to Africa?
The structure does. A consolidation entity in one jurisdiction feeding operating companies in another is a common shape, and everything here about consignment identity, transfer price policy and landing cost at the dock transfers directly. What is specific to this lane is the free zone duty suspension on the Dubai side and the collection and connectivity realities on the African one. Take the structure, and check the specifics against your own two jurisdictions.
