Shipping Company Management System in Egypt: Merchant Portal, Courier App, COD and Returns (2026 Guide)

Nine in the morning at a small sorting hub in Nasr City, or a warehouse on the edge of Obour: dozens of colourful polybags on the floor, three staff writing area names on each parcel with a thick marker, and couriers waiting for the printed run sheet before they head out to Maadi, Haram and Shubra. In the office, an agent juggles five WhatsApp chats: a merchant asking where his shipment is, a customer saying the courier never called, another merchant chasing COD money due two weeks ago. In the evening couriers return with cash and crossed-out sheets, and manual reconciliation runs past midnight.

The owner knows volumes jump every season. What he does not know is how many shipments were late today, how many returns are still sitting in the warehouse, which courier is holding more cash than he handed in, or why the company looks profitable on paper and feels short in the bank account. That is exactly when the search for a shipping company management system in Egypt begins: not because software is fashionable, but because paper and Excel can no longer carry this many parcels, couriers and merchants.

This guide is written for owners and managers of courier and delivery companies in Egypt, and for any business that runs its own delivery fleet: distributors, pharmacy chains, and e-commerce brands that deliver themselves. We cover the symptoms, what makes shipping different from a generic ERP, the modules courier management software actually needs from the merchant portal to the courier app, COD settlement and returns, then hardware and rollout. At Jad Digital (جاد للتطوير الرقمي) we have built custom business systems since 2019, and we will say plainly where a ready-made product is the smarter choice.

Nobody needs a delivery management system because competitors have one. You need it when specific symptoms appear, and they usually appear together:

If you recognise three of these, the problem is not effort; it is the absence of a single record every parcel passes through.

• Merchants send shipments in every possible format. An Excel file from one, a photo of a handwritten sheet from another, a voice note from a third, and someone re-keys all of it, so phone numbers, addresses and COD amounts go wrong.
• "Where is my parcel?" is the question you hear most. Customer service spends the day calling couriers to find out the status, because the real status lives in the courier's head, not in any system.
• Cash collection does not reconcile. A courier returns with less cash than expected, and the reason might be an unrecorded refusal, a partial payment or a run sheet error. Nobody can prove which.
• Merchant payouts are late and disputed. The merchant has no clear statement of delivered parcels, returns and fees, so every transfer is questioned.
• Returns pile up. Refused or unreachable parcels sit in the warehouse for weeks, and nobody knows whether they went back to the merchant or who pays for them.
• Nobody knows real performance. First-attempt delivery rate, the slowest areas, the best couriers: questions without numbers.
• Expanding to a new governorate means new chaos. Opening a point in Alexandria, Mansoura or Assiut multiplies paper and phone calls instead of profit.

A generic accounting program or ERP is built around invoices: sales, purchases, and stock going in and out. A courier company does not own the goods it moves, and its core unit is not the invoice but the shipment: an object that passes through dozens of statuses in a few days, changes hands many times, and carries cash that belongs to someone else, the merchant.

That creates three fundamental differences, especially in the Egyptian market.

A large share of Egyptian e-commerce still runs on cash on delivery. In practice, that turns the courier company into a collection agent: couriers collect cash from dozens of customers a day, hand it to the treasury, and the company transfers it to the merchant after deducting its fees. Any weakness in that cycle hurts the merchant's trust, a courier company's most valuable asset.

Delivering inside Greater Cairo differs from Alexandria, Delta villages or Upper Egypt cities in lead time, fees and sometimes the partner who completes the last mile. The system has to know zones, governorates and hand-off points, and price and route accordingly.

A parcel delivered on the first attempt makes money. One sent out twice and then refused can consume more courier time, fuel and calls than it earned in fees. A system that does not measure failed attempts and their reasons, and does not control returns tightly, leaves the biggest leak in the business untreated.

We explain the general logic of generic versus specialised software in ready-made accounting software vs a custom system. In shipping specifically, the parts a generic program cannot handle are exactly the parts that decide profit: shipment status, courier cash, and merchant settlement.

The portal is how merchants see your company. A merchant should be able to create a single shipment with recipient details, address, zone, COD amount and content description, or upload an Excel file with hundreds of shipments at once, with automatic validation before acceptance: a missing digit in a mobile number, an uncovered zone, an empty amount.

Once created, the merchant prints a label for each shipment carrying the air waybill (AWB) number and a barcode that will be scanned at every step. From the same portal the merchant tracks every shipment, requests a pickup, and sees the account statement and pending payouts.

A merchant selling through an online store does not want to copy orders into your portal by hand. The answer is an API that lets the store create the shipment automatically when an order is confirmed, and receive status updates automatically so they appear to the end customer. Store platforms and marketplaces connect through plugins or middleware, depending on what each allows.

A well-documented API is a sales tool: a merchant who is technically integrated rarely moves to a competitor.

The merchant requests a pickup from the portal with a time window and address; the request lands with the operations supervisor, who assigns it to a pickup courier or to an existing run in the same area. At pickup the courier scans parcels one by one, so the system knows what was actually collected versus what the merchant declared, and the familiar argument of "I gave you twenty parcels" disappears.

At the sorting hub every parcel is scanned on arrival. The system suggests the zone or route it belongs to based on the address, and produces the list of parcels for each courier or run. If you have points or hubs in other governorates, the system manages transfers between them: Alexandria parcels are consolidated into one bag or crate with its own barcode, scanned when leaving Cairo and when arriving in Alexandria, so at any moment you know what is in transit and what has arrived.

This is the heart of the system in the field. The delivery courier app on an Android phone shows the courier today's assigned run: the list of parcels with addresses, phone numbers and COD amounts, in a suggested route order. At every step the courier scans the barcode: picked up from the hub, out for delivery, delivered, or failed attempt.

On delivery, the app records proof of delivery in the way that suits the shipment type: the customer's signature on screen, a photo of the parcel at the door, or a one-time password (OTP) sent to the customer, who reads it to the courier. On failure, the courier picks a reason from a fixed list: customer not answering, refused, wrong address, asked to reschedule, did not have the money. That simple list is the most valuable data source in the whole company, because it tells you why deliveries fail.

The app must work in weak-coverage areas: record locally and sync when the signal returns. And when the courier management module shows supervisors each courier's location on a map, intervening in time becomes possible.

Every scan by a courier or sorter changes the parcel's status, and every status change can trigger a notification: an SMS or WhatsApp message telling the customer the parcel is out for delivery, with the courier's name and how to reach them, and another on delivery. A public tracking page by shipment number lets customers and merchants check without calling anyone.

A notification before dispatch reduces failed attempts: a customer who knows the parcel is coming prepares the cash and answers the phone, or reschedules before the courier sets off.

This module protects merchant trust and company cash. It starts with the courier: every delivered parcel adds its amount to the courier's cash custody, and every partial collection or refusal is recorded with its reason. At the end of the day the courier hands cash to the treasury, and the system compares handed-in versus due, parcel by parcel, showing any difference against the courier's name and date.

Then comes the merchant cycle. The system aggregates each merchant's delivered parcels for the period, deducts shipping fees, return fees and any extra charges as agreed, and issues a clear statement visible in the portal; the transfer is then recorded when executed. If collection happens through several channels, such as cash, mobile wallets and InstaPay, the payment method must be recorded for each parcel so the treasury reconciles with the bank.

A return to origin (RTO) is not the end of a shipment but the start of a reverse journey that needs full management. A parcel that fails after the agreed number of attempts moves to "return" status, is grouped with the same merchant's other returns, is handed back with a scan and signature, and its fees are applied to the merchant's statement according to the agreement.

An exchange is two shipments in one visit: the courier delivers a new item and collects the old one. The system must link the two so delivery is not considered complete until the returned item is collected, and that item then travels back to the merchant through the same returns flow.

Real-world shipping pricing is not one number but a set of rules: a base rate by destination zone, a surcharge by weight or volume above a threshold, a COD fee, a return fee, and special rates for a large merchant or a specific shipment type. The pricing engine stores these rules in a table that can be edited without a developer, and applies them automatically to every shipment the moment it is created.

The bigger benefit is reviewing profitability per zone and per merchant: do the fees for a remote area cover the cost of reaching it, given its failure rate?

Whether couriers are employees or contractors on their own motorcycles, you need a record for each courier and vehicle: covered zones, licences and documents with expiry dates, and vehicle maintenance schedules. Then come the performance indicators: parcels delivered per day, first-attempt delivery rate, average delivery time, the most frequent failure reasons per courier, and cash differences.

These indicators turn conversations with couriers from impressions into numbers and support incentive calculations.

Instead of scattered WhatsApp messages, the agent opens a ticket linked to the shipment number: a delay, a complaint about a courier, an address change, a re-attempt request. The ticket is routed to the right person, carries the full history of the parcel, and closes with an outcome. The same logic we describe in what is a CRM system applies here: every interaction with merchants and customers in one place.

The owner needs one screen to open every morning: parcels picked up yesterday, delivered, failed with reasons, returned, late against the expected lead time for each zone, cash still held by couriers, and merchant payouts due. Then weekly reports on profitability per merchant and zone and the performance of each point.

A shipping system does not live alone. The three integrations that matter most:

If your company operates in more than one country or serves clients in Saudi Arabia, the system should handle multiple currencies, branches and per-country taxes separately; the logic is close to what we describe in POS and ERP integration in Saudi Arabia.

• E-invoicing: a courier company invoices merchants for its services, and registered merchants need correct invoices. The system can generate fee invoices automatically from merchant statements and submit them to the e-invoicing system through the approved integration. We explain the mechanism in connecting your system to Egypt's ETA e-invoicing. Confirm your current obligations on the official portal or with your tax advisor, since details depend on how your business is registered.
• Accounting: revenue, collections and merchant transfers flow into the accounting software as entries instead of being re-keyed, so the COD money held on behalf of merchants stays clearly separate from the company's own revenue.
• Online stores and marketplaces: through the API and plugins above, with two-way status updates.

If you are a young delivery company with a limited number of couriers inside one governorate, and your few merchants are happy with a standard portal, a ready-made last-mile delivery software subscription may serve you well and be running within days. The same applies to a small brand that only wants to track its own drivers.

A custom system makes sense when the way you operate is your competitive advantage: merchant-specific pricing rules, a collection and settlement cycle with details a ready-made product does not support, a network of points across several governorates, deep integrations with large merchants' systems, or the wish to own a portal and app under your brand instead of an interface carrying another vendor's name.

Many companies start with one custom piece that solves the biggest problem, usually the courier app and cash settlement, connect it to existing tools, then add the merchant portal, pricing and reporting in phases. We explain the logic of this decision in ready-made vs custom ERP.

• Android phones for couriers: a decent camera for barcode scanning and photos, a battery that lasts the day, and accurate GPS. You do not need expensive rugged devices at the start.
• Barcode scanners at the hub: wired or wireless scanners on receiving and sorting tables, or handhelds with built-in scanners once volume grows.
• Thermal label printers: at the hub and at larger merchants, using one standard label size that carries the AWB and barcode.
• A digital scale: on the receiving table if you price by weight, ideally feeding the weight straight into the system.
• Connectivity: a main line and a backup at the hub.

A workshop to map the full journey of a shipment from the merchant's request to the merchant's payout, defining every status and every failure reason. Then preparing the master data: the list of zones, districts and governorates, the current pricing rules, and the lists of merchants and couriers. Building or configuration starts during this period against clear priorities.

Run the courier app and the hub with a small group of couriers in one area, East Cairo for example, and with two or three merchants willing to pilot. Compare the paper run sheet with the system daily and fix issues fast.

Move the remaining couriers and zones gradually, run the full collection, settlement and merchant payout cycle from the system, and retire the paper run sheet. Then start the weekly review of the management dashboard: first-attempt delivery, returns, and cash differences.

These periods illustrate the approach, not a promised timeline.

• Building a beautiful merchant portal before the courier app. A portal without real statuses from the field shows wrong data and creates more questions, not fewer.
• An open-text list of failure reasons. If every courier writes the reason in his own words, you cannot analyse anything.
• Separating cash from shipment status. If cash is counted in one file and status lives in a system, the differences stay exactly where they are.
• Ignoring returns in the design. Most systems are designed for successful delivery, and the reverse journey is left to improvisation.
• Training couriers in one lecture. Couriers learn in the field; ride along with the first group in their first days.
• No system owner. Someone must own zones, prices and users, or the data degrades within months.

Good preparation saves weeks of back-and-forth. Prepare the following:

Our guide on how to write a software project brief helps you turn this checklist into a clear document.

• A real paper or Excel run sheet from a normal day, with parcels, amounts and statuses.
• A sample of the shipment file your merchants send you, in every format you receive.
• The list of zones and governorates you cover, and which are served daily versus on fixed days.
• Your current pricing rules by zone and weight, plus COD and return fees, even if they live in a simple file.
• A merchant statement as you send it today, and how and when payouts are made.
• The list of failure and return reasons that repeat in your operation.
• The number of couriers, supervisors, sorters and customer service staff, and each role's part in the system.
• The number of points or hubs in other governorates, and how parcels move between them.
• Existing systems that must be integrated: accounting, online stores, e-invoicing.
• The three biggest problems you want solved first, in order.

• Show me a full shipment cycle live: merchant creation, courier delivery, merchant settlement.
• How does the courier app behave without internet, and how does syncing work?
• Which proof-of-delivery methods are available, and can I set the method per shipment type?
• How are returns and exchanges handled, and how do they appear on the merchant statement?
• Can pricing rules and zones be changed without a developer?
• Is there a documented API for merchants, and who supports merchants during integration?
• How are customer notifications sent, and who bears the messaging cost?
• How are permissions for cash and status edits controlled, and is every change logged?
• Who owns the data and the code, and how do I export all the data?
• What does support look like during peak seasons?

Our ERP and business systems work starts with a discovery workshop at your site or over a video call, where we map the shipment journey as it actually happens today, not as it is supposed to happen: who picks up, who sorts, who settles with couriers, and where information gets lost. Then we agree on the first phase that solves the biggest problem.

We then build in short phases you can see and test: an Android courier app through our mobile app development team, a merchant portal and dashboard with Arabic and English interfaces, a pricing and zones engine, collection, settlement and returns, and integrations with accounting, e-invoicing and online stores. We support your team through training, and you own the code and database at handover. If your company also runs warehouses or production alongside delivery, this guide pairs with our articles on factory management systems in Egypt and warehouse management systems in Egypt.

Choosing who builds it follows the rules for any technology partner: a documented process, references you can call, and clear ownership at handover. Our pillar guide to choosing the best software company in Egypt covers those criteria.

And if we see in the first meeting that a ready-made product will serve you better at this stage, we will say so. Book a free consultation with our ERP solutions team, bring the checklist above, and leave with a clear map of your next step.