Humanitarian Relief Supply Chain Software: Where Is the Donor's Consignment and When Does It Expire?

Why commercial supply chain software fails on a humanitarian pipeline

Every commercial warehouse and inventory system rests on a set of assumptions. One organisation owns the goods. Lanes are stable and repeatable. Customs is a routine cost. Connectivity exists. Currency is stable. A pallet is a pallet, and if you have two hundred of an item, you have two hundred available.

A relief pipeline violates all of that at once. The goods are owned in the accounting sense by different donors with different conditions, so two hundred blankets in a Dubai warehouse might be sixty against one grant, ninety against another and fifty unearmarked, and moving the wrong sixty to the wrong response creates a reporting problem that ends in a disallowed cost. Lanes are improvised, and a consignment might travel by commercial air, then by chartered aircraft, then be handed to a partner agency, then move on a truck arranged by a broker. Customs is not a cost line, it is a duty exemption application against a specific waiver in a specific country with a specific document pack. Connectivity in the warehouse that matters most is the one that has none.

The consequence is that logistics directors run pipelines on visibility that arrives late and in fragments. The question that cannot be answered on demand is the simplest one: where is the consignment funded by this donor, what condition is it in, and what in my pipeline is going to expire before it can be used. That last part is the one that hurts, because expiring pharmaceuticals, vaccines and therapeutic food are not just wasted money, they are money that was raised for a purpose and then destroyed instead.

The consignment nobody could find

A donor funds a shipment of medical supplies for a response. It ships from a prepositioning hub to a regional port. Half the consignment is transhipped and handed to a partner agency under a waybill, because they have the road access. The other half waits at the port for a duty exemption that is being processed against an import waiver granted to a different organisation.

Four weeks later the donor asks for a status report. The warehouse system shows the stock as dispatched. The partner agency has a paper waybill in a folder in a field office. The port half is in an email thread with a customs broker. Nobody can state where the goods are with confidence, and nobody can say what the shelf life position is, because expiry was recorded on the batch at receipt and the batch record stopped moving when the goods left the warehouse.

Meanwhile, in the same hub, a different pallet of therapeutic food is eleven weeks from expiry. It could still be programmed into an ongoing response if anyone knew. It expires in the warehouse and is destroyed, and the destruction is reported to a donor who funded it. That single line in a report costs more credibility than it does money, and credibility is the currency the agency actually runs on.

What RITA and Sahana Eden actually fail at

Both are real, both matter, and neither is a bad thing to be using. RITA, the relief item tracking application provided through the logistics cluster, is genuinely valuable during a coordinated response and is often the right answer for common services in an emergency. Sahana Eden is a long standing open source disaster management platform with a broad feature set.

RITA's design centre is common service provision during a response: a shared pipeline where the cluster moves items on behalf of organisations. That is a different thing from your own agency's continuous multi year pipeline across prepositioning hubs and country programmes, and it does not attempt to hold your donor earmarking, your grant reporting structure or your own procurement and finance linkage. Agencies use it for what it does and keep their own records alongside, which means two records that will not reconcile.

Sahana Eden is broad, which is its strength and its limitation. Broad open source platforms give you a large surface and a configuration project, and the practical experience of many agencies is that adapting it to their earmarking model, their document requirements and their offline needs becomes a development project regardless. At that point you are building, but on someone else's foundations and with a smaller pool of people who can maintain it.

Neither handles the handover boundary well, and that boundary is where consignments disappear. When goods move from your custody to a partner, a broker, a military logistics unit or a government counterpart, the record has to continue with a waybill that both sides can see and sign, often on paper, often offline, sometimes in a different language. Systems that treat dispatch as the end of the record cannot tell you where anything is once it leaves.

And neither carries earmarking as an attribute of physical stock. Finance systems hold grants. Warehouse systems hold pallets. The join between a grant and a pallet is made by a human in a spreadsheet, and that human is the reason your reporting is late.

What a custom relief logistics build has to include

Earmarking as a property of stock, carried down to batch and pallet and preserved through every movement. When a consignment is picked, the system allocates against the correct earmark under rules you set, and if a substitution is made in an emergency it is recorded as a deliberate exception with an approver rather than silently. Every donor report then derives from movement records instead of being assembled from memory and email.

Expiry as a pipeline wide, forward looking view rather than a warehouse report. What is expiring in the next ninety days, across every location, by donor, with an indication of which responses could still absorb it. This is the single feature most likely to pay for the build in the first year, because redeploying stock before it expires converts waste back into programme value, and the decision only needs to be made in time.

Offline first warehouse capture, genuinely offline rather than nominally. Receipts, inspections, picks and dispatches happen on a device with no connection, queue locally, and sync when a connection appears, with an explicit conflict rule and a visible sync state that a warehouse manager can check. This has to survive a device being offline for days, because it will be.

Waybills as shared objects across the handover boundary. Generated with the items, batches, quantities and conditions, printable for the paper reality of the field, signable on a device where possible, and reconcilable when the counterparty confirms receipt. Discrepancies between dispatched and received quantities become a tracked exception rather than a conversation in three months.

Customs documentation as an assembled pack per destination rather than a folder. Each country has its own requirements for a duty exemption or waiver: proforma invoices, packing lists in a particular format, certificates of donation, product registration references. Modelling the pack per destination means the third shipment to a country is faster than the first, which over a long pipeline is a considerable saving in both time and demurrage.

Charter and movement tracking that reflects how goods actually travel: mixed commercial and chartered legs, handovers, temporary storage, and periods where a consignment is simply somewhere in transit with no telemetry. Model uncertainty explicitly. A status that honestly says last confirmed location and date is more useful than a status that implies precision the organisation does not have.

Cold chain where it applies, with temperature excursion records attached to the batch, because a vaccine consignment that broke cold chain is not stock, it is a disposal, and finding that out at the point of use is the worst possible time.

What it costs and how long it takes

In Digital Heroes delivery experience, a first release runs $80,000 to $160,000 and ships in 14 to 20 weeks. That covers earmarked stock at batch level across multiple warehouses, offline capture, and the pipeline wide expiry view. The offline requirement is the main reason this sits above a comparable commercial inventory build, because doing offline properly is engineering work that cannot be shortcut.

A full platform at $200,000 to $450,000 phased over 8 to 14 months adds waybill handover with partner reconciliation, charter and consignment tracking, customs document packs per destination, cold chain records, last mile distribution capture, and donor reporting derived from movements.

What raises the cost here: the number of donors with distinct reporting requirements, since each is a different way of slicing the same movements. The number of countries in the pipeline, because each brings a customs document pack. Integration with your finance or enterprise system, which is worth doing because the grant structure has to match. Multiple languages and scripts in field interfaces. And partner participation, since every counterparty who touches a waybill is an onboarding exercise.

What holds it down: two hubs, your three largest donors, and one country programme for the first release. That proves the earmarking model against real reporting before you scale it, and if the earmarking model is wrong you want to find out at week twelve rather than at month nine.

When you should not build this

If you operate in one country, from one warehouse, on one or two funding sources, do not build. Use RITA where the logistics cluster is active, keep clean spreadsheets with real discipline about batch and expiry, and put the money into the response. A system nobody has capacity to maintain is worse than a spreadsheet somebody owns.

Build when you hold prepositioned stock across borders, when donors with different reporting rules fund the same warehouse, when you routinely hand consignments to partners and lose sight of them, when expiry write offs have appeared in a donor report, or when your logistics team spends more time compiling reports than moving goods. The honest test is whether your global logistics director can answer, in an hour and without phoning three people, where a specific donor's consignment is and what is expiring next quarter. If not, the pipeline is being run on memory.

How to choose a developer for humanitarian logistics software

Ask them to model donor earmarking on a whiteboard against a single pallet split across three grants. A developer who understands this asks what happens during an emergency substitution, who approves it, and how the report reflects it afterwards. A developer who adds a donor field to the stock table has not understood that the same physical item can be committed and reported in more than one way.

Ask what offline means in their design. The answers you want involve a local store, a sync queue, an explicit conflict resolution rule, and a visible sync state for the warehouse manager. If offline is described as caching, the system will lose receipts in the field, and receipts lost in the field become discrepancies that take months to resolve.

Ask how a waybill works when the receiving party has no access to your system and no smartphone. The field reality includes paper, and a design that cannot degrade to paper and reconcile afterwards will not survive contact with an actual handover at a border.

Ask who owns the code and settle it before kickoff. You should own the repository, the infrastructure accounts and the right to hire anyone else, and for a humanitarian organisation that also means the right to share the work with peer agencies if you choose to. At Digital Heroes the client owns the code from the first commit, and in this sector we think that ownership question deserves more weight than usual, because the systems agencies build tend to outlive the funding that paid for them.