Your Transporter Says Delivered, but Your Customer Reports Missing Goods

A manufacturer dispatches 60 cartons to a customer.

The transporter collects the material.

The invoice, delivery challan and transport documents are prepared.

Two days later, the transporter's tracking portal shows:

Delivered.

The dispatch team updates its records.

Sales informs the customer that the material has reached.

But the customer replies:

We have received only 56 cartons. Four cartons are missing.

The transporter maintains that the consignment was delivered.

The customer's warehouse says the receipt is incomplete.

Your dispatch team has a transporter receipt, but nobody can immediately confirm where the missing cartons are.

Now three parties have different versions of the same delivery.

The transporter says the shipment is delivered. The customer says the quantity received is incomplete. Your company needs evidence to establish what happened.

For small manufacturers, FMCG distributors, industrial suppliers and trading businesses, this is not simply a transport issue.

It is a failure to distinguish shipment movement, delivery reporting and actual goods receipt.

The solution does not necessarily require another logistics platform.

It starts with understanding what each record proves.

Cover image: AI-generated editorial illustration. The business, employees and delivery shown are fictional.

A delivery status is not always the complete delivery story

Consider the information available during a normal shipment.

The supplier knows how many cartons were dispatched.

The transporter knows which consignment was accepted for transportation and what delivery events it recorded.

The customer's receiving team knows what physically arrived at its premises.

These records serve different purposes.

The problem begins when a business treats these records as interchangeable.

A transporter scan is not necessarily a detailed carton-by-carton reconciliation.

A signed delivery document may confirm receipt of a shipment without establishing that every internal item was inspected.

An invoice shows what was billed, not independently what was physically received.

The official Indian e-Way Bill system describes the e-way bill as a document associated with goods movement under applicable rules. It should not be treated as a substitute for the customer's actual receiving record.

A reliable delivery process should connect these records without pretending that they establish exactly the same facts.

What does “Delivered” actually mean?

This depends on the carrier and service.

UPS India's tracking guidance describes the Delivered status as a carrier-recorded delivery to the final destination, with a delivery timestamp. It also identifies separate exception statuses when unexpected events affect delivery progress.

That is useful information.

However, for a B2B supplier, several additional questions may remain:

• Was the shipment delivered to the correct business premises?
• Who accepted it?
• Was the recipient authorised to receive it?
• How many packages were actually handed over?
• Were any cartons visibly damaged?
• Was the delivery complete or partial?
• Did the customer's receiving team record a shortage?

The answers may be available through a proof-of-delivery document or another carrier record.

They may also require direct confirmation from the consignee.

Tracking and proof of delivery are different

DHL Express India explains that customers can access electronic proof-of-delivery information and digitally captured receiver signatures, where available, through its tracking services.

FedEx also provides a process for obtaining proof-of-delivery documents. Availability and details depend on the shipment and service.

This does not mean every Indian transporter uses the same system.

A smaller road transporter may work with signed paper challans, driver acknowledgements and manually shared documents.

The business should understand what evidence its actual transport partner provides.

The first mistake: treating dispatch quantity as received quantity

Suppose your warehouse dispatches 60 cartons.

The loading team records 60.

The transport booking also states 60 cartons.

Later, the carrier reports successful delivery.

Your internal report automatically changes the shipment to:

60 cartons delivered.

But where did that received quantity come from?

If the system copied the original dispatch quantity into the delivered field, it may not represent an independently confirmed receipt.

This is an important data-design issue.

A better structure keeps the following quantities separate.

The quantities are hypothetical.

Notice that the carrier tracking field does not automatically establish a carton count.

If the carrier provides a reliable package-level delivery record, include that information separately.

If it provides only a shipment-level Delivered status, do not invent a package-level result.

This distinction prevents a dashboard from creating false certainty.

One shipment can have several delivery exceptions

Not every disputed delivery is the same problem.

A shipment marked delivered can produce very different situations.

The customer says nothing was received

The carrier reports delivery, but the intended recipient cannot locate the consignment.

Possible explanations may include delivery to the wrong receiving point, an internal receiving delay, an incorrect scan or another issue requiring investigation.

Do not assume the transporter or customer is at fault before checking the evidence.

The customer received fewer cartons

The supplier dispatched 60 cartons, but the customer recorded only 56.

This is a quantity discrepancy.

The investigation should establish whether the remaining cartons were separated in transit, recorded under another consignment, left at a transport hub or affected by another event.

The customer received damaged cartons

The quantity may match, but some material is damaged.

This requires a different investigation from a missing-package case.

The business needs evidence of condition and may need to preserve goods and packaging for inspection.

The delivery reached the wrong branch

A customer may operate several factories or warehouses in the same city.

A shipment can reach one legitimate company location while still failing to satisfy the agreed delivery instruction.

The transporter has not supplied a POD

The tracking system reports delivery, but a signed or otherwise appropriate acknowledgement is missing.

That does not automatically mean the goods were not received.

It means the business has an evidence gap to resolve.

The shipment was delivered in multiple parts

A larger consignment may be divided into several packages or handled in separate movements.

One tracking reference may not provide enough information to establish the position of every package.

The investigation should check whether package-level tracking or separate consignment references exist.

Each exception needs a specific investigation. A generic “delivery issue” status is insufficient.

The most useful starting point is a shipment evidence record

A small business can manage this without custom software.

Start with one reliable record for every shipment requiring delivery confirmation.

The record should identify the shipment and the documents needed to understand its movement.

For example:

This can initially be a spreadsheet supported by your existing ERP or dispatch records.

Do not maintain separate manually edited totals if the original system already records quantities reliably.

The objective is to connect the evidence, not create another independent inventory ledger.

Your proof-of-delivery process needs more than a signature

A signature can be useful evidence.

It is not always sufficient to resolve every delivery dispute.

Consider a delivery document bearing the customer's receiving stamp.

The transporter says this proves successful delivery.

The customer says four cartons were missing.

Before reaching a conclusion, examine what the document actually records.

• Does it identify the person who received the goods?
• Does it show the number of packages acknowledged?
• Was the quantity checked?
• Were any shortage or damage remarks recorded?
• Was the signature given for receipt of the vehicle or for a verified count?

These distinctions depend on the document, receiving procedure and applicable contractual terms.

A signature should not automatically be interpreted as confirmation of every item inside a sealed carton.

Preserve the receiving remarks

Where the receiving process and contractual arrangements permit, discrepancies should be recorded clearly at the time of handover.

For example:

56 cartons physically received against 60 cartons shown on the delivery document. Four cartons pending reconciliation.

Such a record is more useful than a vague remark such as:

Material not proper.

The description should reflect what was actually observed.

Do not instruct warehouse staff to make unsupported remarks or alter documents retrospectively.

If the shortage is discovered only after receipt, record when and how it was discovered and follow the applicable notification process.

Why missing delivery evidence can become expensive

When the business has no dependable receiving record, several operational decisions become difficult.

• Should it dispatch replacement material?
• Should it ask the transporter to search for the missing cartons?
• Should it wait for the customer's warehouse investigation?
• Should it issue a commercial adjustment?
• Should it submit a carrier claim?
• Should it inform the production team that the customer requires additional material?

These decisions may involve different people.

They should not be made automatically from a single Delivered status.

Preserve evidence before it disappears

Useful records may include the original dispatch information, package count, booking reference, relevant shipment photos, tracking events, delivery acknowledgement, customer shortage report and subsequent correspondence.

The appropriate evidence varies by shipment and carrier.

FedEx India's claims guidance, for example, describes documentation requirements for lost or damaged shipments. It also specifies notification periods for certain international shipment claims. Those periods should not be treated as universal rules for every domestic transporter or freight contract.

For your actual consignment, check the applicable carrier terms, claim procedure, insurance conditions and contractual responsibilities.

The business should know these requirements before a major dispute occurs.

A digital record helps only if it preserves accurate evidence within the time available.

A worked example: four cartons missing from a manufacturing shipment

Consider a fictional company called Sahyadri Engineering Supplies Pvt Ltd.

It manufactures and distributes industrial components to factories in Maharashtra and Gujarat.

This is a hypothetical scenario, not a GreyBath client case.

The company dispatches 60 cartons to a customer.

Each carton contains material with an illustrative invoice value of ₹2,500.

The shipment value is therefore:

60 × ₹2,500 = ₹1,50,000

The transporter accepts the consignment.

Two days later, its system marks the shipment Delivered.

However, the customer's receiving team confirms only 56 cartons.

The initial position is:

The ₹10,000 is not an established financial loss or guaranteed claim amount.

It is the invoice value associated with the four cartons whose location is not yet confirmed.

What the dispatch team discovers

The original dispatch record confirms 60 cartons were recorded as handed over.

The transporter booking reference also shows 60 cartons.

The carrier's main tracking number is marked Delivered.

However, the transporter's detailed investigation shows that the shipment had been divided during movement.

Fifty-six cartons reached the customer's premises.

Four cartons remained at a transfer location and had not yet completed the final movement.

The main tracking status did not adequately communicate that distinction to the supplier.

This is an invented outcome used to explain the process, not evidence of a real carrier failure.

What happens next?

The logistics coordinator records a partial-delivery exception.

The transporter confirms the location of the remaining four cartons.

The customer is informed that the discrepancy is under investigation and given the confirmed next update.

The missing cartons are subsequently delivered.

The receiving team confirms their actual receipt.

Only then is the exception closed.

The business now has two separate delivery events linked to one original dispatch.

What should management learn?

The immediate problem was not necessarily poor warehouse counting.

It was the assumption that a shipment-level Delivered status established complete receipt of all 60 cartons.

The business needed a way to recognise partial delivery and investigate missing quantities.

That is an operational process requirement.

Technology can support it, but the definition must come first.

Do not automatically send replacement material

When a customer reports missing goods, the salesperson may want to dispatch replacement material immediately.

That can be appropriate in some situations, especially where a production line or urgent commitment is affected.

But it should be an authorised commercial and operational decision.

Consider the hypothetical example.

The customer reports four missing cartons.

If the supplier immediately dispatches four replacement cartons, and the original four cartons are subsequently located and delivered, the customer may receive eight cartons against the original four-carton discrepancy.

The company must then reconcile the additional material.

The appropriate response depends on urgency, the investigation, contractual obligations and the customer's operational needs.

Before sending replacement material, establish:

• What quantity is actually missing?
• Is the original material still in transit or under investigation?
• Who has authorised the replacement?
• How will the original consignment be handled if it arrives later?
• How will stock and commercial records be reconciled?

A properly documented exception reduces confusion.

It does not remove the need for judgement.

Transporter tracking and customer receipt should have separate statuses

A useful internal workflow should not copy external carrier statuses without interpreting them.

For example, an internal system might use the following states.

These are proposed management statuses, not mandatory statuses imposed by GST authorities or logistics providers.

Your process may not require individual customer confirmation for every low-risk shipment.

But where receipt confirmation is commercially important, the system should not silently convert the carrier's Delivered status into independently verified customer receipt.

Keep the original carrier event

Do not overwrite the transporter's reported status merely because the customer disputes it.

Instead, retain:

• Carrier-reported status: Delivered
• Customer-reported position: Four cartons missing
• Internal position: Delivery discrepancy under investigation

This preserves the differing evidence and makes the actual issue visible.

A reliable system should retain important status changes and their sources.

Assign one owner to each unresolved delivery

A delivery dispute often involves multiple departments.

Sales communicates with the customer.

Dispatch knows the original shipment.

The transporter controls its movement records.

The customer's warehouse knows what arrived.

Accounts may need the final documentation.

Without clear responsibility, each department may assume another person is handling the issue.

Use one internal owner for the investigation.

For example:

The transporter remains responsible for its own investigation and contractual obligations.

The internal owner ensures that your company knows what is happening.

A simple exception record should have a named owner, current position and next action date.

“Following up with transporter” is not enough.

A better entry is:

Transporter investigating four missing cartons. Logistics coordinator to obtain package-location update by the agreed review time. Customer informed of current confirmed position.

This makes follow-up measurable without implying that the cartons have already been found.

The customer's receiving process matters too

A supplier cannot independently determine everything that happens inside the customer's warehouse.

Some customers have a goods-receipt process where the physical delivery is first accepted at the gate.

The receiving warehouse may count and inspect the material later.

Other customers count packages before acknowledging receipt.

Some use purchase-order matching or require additional quality checks.

These differences matter.

Receiving the vehicle is not always completing goods receipt

Suppose a vehicle enters a large factory.

Security records its arrival.

The transporter unloads the material at a designated receiving area.

The warehouse records the actual quantities several hours later.

The transporter's event and the customer's inventory-receipt event may occur at different times.

A supplier should understand which event the customer considers official receipt.

Do not assume that a gate entry, unloading confirmation or security signature establishes accepted inventory quantity.

For important accounts, agree on the receiving procedure in advance.

This is especially useful where shipments are large, split across vehicles or require inspection.

What changes when several transporters are involved?

Many SMEs use different logistics partners depending on destination, shipment size and urgency.

For example:

• One courier handles small parcels.
• A road transporter handles bulk cartons.
• Another logistics provider serves distant branches.

Each may have its own tracking portal, reference format and status terminology.

A supplier can end up with several ways of interpreting the word Delivered.

Establish a common internal language

The company should decide what its own shipment statuses mean.

Then map each carrier's actual information into those statuses.

For example:

This mapping must follow the carrier's documented events.

Do not assume that two carriers use identical meanings merely because their portals display the same word.

Preserve the original tracking details

If you build a combined dashboard, retain the source carrier's event text and timestamp.

Do not display only a simplified internal label.

When an issue occurs, the original event details may be important.

A spreadsheet can solve the first version

For a business dispatching a manageable number of consignments, a shared register may be sufficient.

• Start with one row per consignment, with separate records for package-level exceptions where necessary.
• Link the required documents.
• Track unresolved exceptions.
• Assign owners.
• Review cases until resolution.

This is better than immediately commissioning software that duplicates information from transporter websites.

When the spreadsheet becomes difficult

Problems begin when:

• Multiple dispatch locations maintain separate registers.
• Several employees overwrite statuses.
• Carrier updates must be checked manually throughout the day.
• POD documents are scattered across email and WhatsApp.
• Management cannot identify unresolved delivery discrepancies.
• Different team members use inconsistent shipment references.

At that point, a more structured workflow may be worthwhile.

The business should first document the information flow and pain points.

A custom system cannot correct missing or unreliable data merely by placing it on one dashboard.

Use existing transporter tools before building another application

Many established carriers already offer tracking and proof-of-delivery services.

For example, DHL Express India describes digital proof-of-delivery retrieval. FedEx India provides tracking and POD access, subject to the shipment information and service conditions.

Before considering an integration, ask your logistics partner:

• Can we retrieve delivery status electronically?
• Can we retrieve package-level events?
• Is a signed POD available?
• Can shortage or damage remarks be recorded?
• Is there a customer portal?
• Are supported APIs or scheduled data exports available to our account?
• What are the applicable charges and access restrictions?

These questions determine whether integration is practical.

Do not assume that a tracking website automatically provides an API your business can use.

Screen scraping or unofficial access should not become the foundation of an important business process without proper permission and reliability controls.

Mobile delivery confirmation can be useful, but only with a real operating process

For companies using their own delivery vehicles, the driver or delivery employee may be able to record handover information directly through a mobile application.

A suitable workflow might capture:

• Shipment reference
• Destination
• Delivered package quantity
• Receiving person
• Delivery timestamp
• Shortage or damage remarks
• Acknowledgement or supporting evidence

The exact fields should be defined according to business requirements.

An external transporter's employee may not be willing or authorised to use the supplier's application.

That limitation should be established before designing the solution.

Consider weak mobile connectivity

Some industrial and warehouse locations have unreliable network access.

If a mobile application is proposed, decide what happens when the employee cannot connect.

A properly designed offline workflow may save authorised delivery events locally and synchronise them later.

However, the system must distinguish the original event time from the later synchronisation time.

It should also handle duplicate submissions, lost devices and conflicting records.

GreyBath's published mobile-app capabilities include offline-first applications and synchronisation, but any proposed delivery application would require these use cases to be designed and tested for the actual project.

Do not collect more delivery data than you need

A delivery workflow may involve names, mobile numbers, signatures, photographs and location information.

Not every shipment requires all of these.

For example, a normal delivery to a known factory receiving department may have a suitable business acknowledgement process without collecting an employee's personal identification documents.

A photograph may help document a visible package condition, but it may be inappropriate in a restricted factory area.

Location data may be useful for a delivery event, but continuous tracking of staff is a different privacy and employment consideration.

• Define the purpose of each field.
• Restrict access.
• Use appropriate security and retention controls.
• Follow applicable privacy and contractual requirements.

Do not treat additional data collection as an automatic improvement in delivery verification.

Measure unresolved deliveries, not just deliveries completed

Many logistics reports focus on shipment volume and delivery performance.

Those measures are important.

However, this particular business problem requires visibility into disagreements between transporter status and customer receipt.

Delivery discrepancies

Track consignments where the recorded customer receipt does not match the expected delivery.

Classify the type of discrepancy.

For example:

• Missing cartons
• Damaged cartons
• Wrong receiving location
• Unidentified recipient
• Missing evidence
• Disputed delivery

Do not count every missing POD as a confirmed missing-goods incident.

The categories measure different problems.

Time taken to identify discrepancies

Measure the interval between the relevant delivery event and the first recorded exception.

Use a consistent definition and preserve the source timestamps.

An issue discovered quickly may be easier to investigate while employees and records are available.

Time taken to resolve exceptions

Measure how long it takes to reach a documented outcome.

Separate cases that were:

• resolved by locating material,
• resolved through an approved replacement,
• resolved through a financial or contractual process,
• or closed with another documented outcome.

Do not label an unresolved case completed because someone stopped following up.

Proof-of-delivery availability

For shipments where POD is required, measure:

Shipments with the required POD available ÷ shipments requiring POD × 100

This measures document availability.

It does not establish that every delivered quantity was correct.

Quantity discrepancies

Track the quantities involved in confirmed shortages or overdeliveries.

Preserve the original dispatched and received quantities rather than repeatedly changing the baseline.

This helps management identify recurring patterns across routes, carriers or dispatch locations.

Root causes

When an investigation is completed, record the cause only if it is supported by evidence.

Possible categories include:

• Dispatch-count error
• Transport short delivery
• Incorrect location
• Receiving-record error
• Tracking-status issue
• Packaging or handling damage
• Cause not established

Avoid forcing every case into a blame category.

Sometimes the available information will not establish exactly what happened.

When a connected delivery workflow becomes worthwhile

A custom dashboard or application becomes more relevant when shipment information exists in several systems but nobody has a dependable consolidated view.

For example:

• ERP: Stores sales orders, invoices and dispatch quantities.
• Transporter platform: Stores tracking events.
• Customer communication: Contains receipt confirmations and complaints.
• Warehouse records: Contain original loading details.
• Management: Needs an exception view across carriers and destinations.

A connected workflow could bring the relevant information together.

But the design should first establish which system is authoritative for each field.

The ERP may own the dispatch quantity.

The transporter may own its tracking events.

The receiving customer may confirm actual receipt.

The internal workflow may own the investigation status.

These responsibilities should remain clear.

A system that simply copies all four records into one page without distinguishing their meaning can still produce incorrect conclusions.

Where this approach may need to be adapted

Not every shipment requires the same level of verification.

A small parcel sent through a courier may have suitable electronic tracking and standard delivery evidence.

A full-truckload shipment may use a different receiving process.

A high-value industrial machine may require installation, inspection or acceptance milestones beyond physical delivery.

Temperature-controlled goods may require additional handling and condition records.

Hazardous chemicals, pharmaceuticals and other regulated products may have specialised transport, receiving and traceability requirements.

Export shipments can also involve different contractual, customs, insurance and document requirements.

Do not apply one generic POD form to every situation.

The correct level of evidence depends on the goods, customer agreement, transport service and risk.

For contractual disputes or insurance claims, obtain appropriate professional guidance.

The management decision

When the transporter reports Delivered and the customer reports missing goods, the first response should not be to accuse either party.

It should be to establish which evidence exists.

• What did the supplier dispatch?
• What did the transporter accept?
• What delivery event did the carrier report?
• What did the customer actually record as received?
• Where is the difference?
• Who is responsible for investigating it?
• And what must happen before the case can be considered resolved?

These questions are more useful than repeatedly asking the transporter:

Is my shipment delivered?

The status may already say yes.

The real issue is whether the supplier, transporter and customer agree on what was received.

• Begin with a dependable shipment record.
• Preserve the relevant documents.
• Define the exception categories.
• Assign responsibility.
• Resolve differences using evidence.
• Then assess whether your existing software can support the process.

A business does not need to build a new logistics platform to become better at delivery verification.

It needs to stop treating every Delivered status as the end of the delivery process.

Where GreyBath can contribute

GreyBath develops custom web applications, ERP/CRM workflows, dashboards, mobile applications and system integrations.

For manufacturers, distributors and trading businesses, a potential GreyBath implementation could connect internal dispatch information with transporter tracking and customer-delivery confirmation.

Depending on the existing systems, this could include a shipment-status dashboard, digital proof-of-delivery records, shortage and damage reporting, responsibility assignment, alerts and management reports.

Businesses using their own delivery teams could also assess a mobile or Progressive Web App for recording delivery events, subject to the required permissions and operational controls.

Where appropriate interfaces exist, GreyBath could evaluate integration with the client's existing ERP and logistics providers rather than replacing those systems.

Every proposed integration would depend on supported APIs, authorised access, data quality, privacy requirements and the agreed project scope.

For a smaller business, existing transporter tools and a controlled shared register may be sufficient.

Custom development becomes relevant when coordinating shipments, evidence and exceptions across several teams or transporters creates repeated manual work.

The starting point is identifying which delivery information your business cannot reliably see or reconcile. The technology should solve that specific problem.