3PL Software in Nepal: Running Logistics for Other People's Goods

There is a step between being a courier and being a third-party logistics provider, and most operators in Nepal cross it without noticing. It happens the first time a merchant asks you to hold their stock rather than just move it.

From that moment you are responsible for goods you do not own, stored in your warehouse, picked and packed by your staff, on behalf of a client who needs to know their stock position as accurately as if it were in their own store. That is a different business with different software requirements.

Multi-tenancy is the whole problem

A courier system has one company’s data in it. A 3PL system has many companies’ data in it, kept strictly apart.

Every merchant needs to see their own inventory, orders, deliveries, returns and settlements, and none of anyone else’s. Not “filtered by default” — actually isolated, because a merchant who can construct a URL that shows a competitor’s stock levels is a commercial incident.

This shapes the whole system. Every record carries a tenant. Every query is scoped. Every report is scoped. It is straightforward if designed in from the start and a rewrite if bolted on later, which is why 3PLs that grow out of a courier system usually end up rebuilding.

Stock you do not own

Inventory in a 3PL warehouse is the client’s asset sitting on your floor. That has consequences:

• Ownership is a field. The same SKU can belong to two different merchants and must never be commingled in the record, even if it is physically identical.
• Storage is billable. Space occupied per merchant per day is revenue, and it has to be computed from actual stored quantities over time, not estimated monthly.
• Discrepancies are serious. A cycle count variance is not an internal accounting note — it is a shortfall of someone else’s property, and it needs an investigation trail.
• Batch, expiry and serial matter for some clients. A merchant selling cosmetics or food will need expiry-aware picking. If the system cannot do it, you cannot take that client.

Receiving is where trust is set

The first interaction with a new merchant is inbound: they send stock, you receive it. Everything afterwards depends on that count being right and being agreed.

The receiving flow should produce a document both sides accept: expected quantity from the advance shipping notice, actual counted quantity, variance, condition notes, and photographs of anything damaged. If a merchant later says they sent 500 and you have 480, this is the only thing that resolves it.

Orders arrive by API, not by hand

A 3PL serving even a handful of active merchants cannot have staff typing orders in. Orders arrive from the merchant’s storefront, marketplace or ERP, and they arrive continuously.

Practically this means the system needs an order intake API, and for merchants who cannot integrate, a bulk upload that validates before committing. It also means order status has to flow back — a merchant whose own store still says “processing” three days after you delivered will get customer service calls that end up with you.

Picking, packing and the SLA

Once orders arrive automatically, the warehouse side becomes the constraint. What a 3PL system has to support:

• Wave or batch picking across multiple orders, because single-order picking does not scale
• Pick lists ordered by location, so a picker walks the warehouse once
• Pack verification — scanning what goes into the box against what the order says — because a mis-pack becomes a return
• Timestamps at each stage, so SLA performance is measured rather than claimed

SLAs are the commercial heart of 3PL. A merchant is paying for orders received before a cut-off to ship the same day. If the system cannot report same-day compliance per merchant per month, you cannot defend your invoice and you cannot see which clients you are losing money on.

Billing is the hard part

Courier billing is a rate card applied to consignments. 3PL billing is a stack of different charge types accruing continuously:

• Storage, per unit of space per period
• Receiving, per unit or per pallet
• Pick and pack, per order and per line
• Packaging materials consumed
• Outbound delivery, at the courier rate card
• Returns processing
• Ad-hoc handling — relabelling, kitting, quality checks

Each merchant has their own rates for each. If this is assembled manually at month end, it will be late, wrong, and disputed. It has to accrue automatically as events happen, so at any point in the month a merchant’s bill so far is a query rather than a project.

Give merchants their own view

The single highest-value feature for a 3PL is a merchant portal. Stock on hand by SKU, inbound shipments and their receipt status, orders and their current stage, deliveries and proofs, returns, and the running bill.

It reduces support load enormously — most merchant contact is a question the portal answers — and it is what merchants compare when choosing between providers. A 3PL without one is competing on price.

The honest test

Before taking on fulfilment for a merchant, ask whether your system can answer, right now, for an existing client: what stock of theirs do you hold, where is it, what came in this week, what went out, how many orders met SLA, and what do they owe you so far this month.

If any of those needs a person to assemble it, adding merchants will add work faster than it adds margin.

We build logistics and fulfilment software for operators in Nepal, including multi-merchant inventory, order intake, SLA reporting and accrual billing. If you are moving from courier into fulfilment, talk to us.