Delivery incident reference

Last updated: August 26, 2026

This is a field-by-field reference for delivery incidents: the seven incident types and what each one leads to, the fields you fill in when requesting a refund, the evidence rules behind them, and how a request's status maps to what you see on the Refund Requests page. It doesn't cover the flow of filing a report or how a provider decides — for that, see how delivery incidents work, request a refund, and report a poor delivery experience.

Incident types

Every report starts with picking one of these seven types. Six lead to a refund request; one doesn't.

Type What it means Outcome
Arrived Late The delivery arrived after its scheduled window. Can request a refund
Delivered Early The delivery arrived before it was expected. Can request a refund
Delivered to Wrong Address The delivery went to the wrong location. Can request a refund
Missing or Incorrect Items What arrived wasn't what was ordered, or part of it never showed up. Can request a refund
Never Delivered The delivery never arrived at all. Can request a refund
Poor Delivery Experience Something about the driver or the experience — not the timing or the contents — was the problem. No refund by default — flags the driver and can request a block
Other Anything that doesn't fit one of the six types above. Can request a refund

Note

Poor Delivery Experience is the one type that doesn't default to asking for money back. You can still add a refund request to a Poor Delivery Experience report, but the type itself exists for raising a concern about the driver — see report a poor delivery experience for what that path is for and its honest limits.

Refund amount fields

When a report is on the refund path, you set the amount you're asking for across three fields. Each is prefilled from the delivery, with the original value shown alongside it:

Field What it is
Package Value The value of the item(s) in the delivery, prefilled from the delivery's own record.
Delivery Fee The delivery fee charged, prefilled the same way.
Tip Amount The tip attached to the delivery, prefilled the same way.
Total Refund Amount The sum of the three fields above, updated as you edit them.

Requesting more than a field's original value isn't blocked — it just shows a soft warning so you can double-check the number before sending the request on. What you request and what's ultimately granted aren't guaranteed to match — that's the provider's call, covered in refund eligibility.

Evidence rules

  • A receipt is required whenever you're requesting a refund. Submit is blocked without one.
  • A damage photo is required when the item was damaged — this comes up as its own question on the Missing or Incorrect Items type.
  • Up to 5 files, 5 MB each, in PNG, JPG, or PDF.

For Never Delivered and Delivered to Wrong Address reports, the delivery's own proof-of-delivery photos are also surfaced as part of the flow, so you can check what was actually captured before you file — see review proof of delivery photos.

Refund statuses

A refund request moves through a small set of statuses, and the Refund Requests page groups them under three tabs:

Status Tab What it means
Under review Pending The request has been filed and is with the provider, waiting on a decision.
Approved Refunded The provider granted the refund, with an amount and a response recorded. A refund attributed to Nash rather than the provider can also land here — a fallback approval that ends up in the same place: an approved refund reflected on your next invoice.
Denied Rejected The provider decided not to grant the refund.
Cancelled Rejected The request was withdrawn before a decision came back.

Important

A filed request is view-only from your side — there's no edit or cancel control in the portal once it's submitted. You may see a request land on Cancelled, but it isn't a status you trigger yourself from here; treat it the way you'd treat Approved or Denied — an outcome you track, not an action you take.

Approved, Denied, and Cancelled are all endpoints. Once a request reaches one of them, it doesn't move again — there's no reopening a decided request from the portal.

The Refund Requests page

Every incident report — refund or not — shows up as a row on the Refund Requests page. These are the columns:

Column What it is
Provider The delivery provider the request was sent to, and who decides its outcome — see manage providers.
Requested Amount The total you asked for, across Package Value, Delivery Fee, and Tip Amount.
Request Breakdown That requested total split back out by Package Value, Delivery Fee, and Tip Amount.
Total Value The delivery's original value before any refund — Package Value, Delivery Fee, and Tip Amount added together.
Total Breakdown That original value split out the same three ways.
Refunded Amount What's actually been granted, once the provider has decided.
Incident Type Which of the seven types the report was filed under.
Notes The details you entered when filing the report.
External ID Your organization's own reference ID, if one was set.
Stops The delivery stop or stops the request is tied to.
Reported On When the incident report was filed.
Status Under review, Approved, Denied, or Cancelled — mapped to the tabs above.

Opening a row shows a read-only detail drawer with:

Field What it is
Refund ID The identifier for this request.
Delivery ID The delivery the request was filed against.
Incident Type The type selected when the report was filed.
Requested vs. refunded amounts What was asked for, side by side with what's been granted so far.
Provider response Any free-text response the provider has recorded.
Reported On When the report was filed.

The drawer also links back to the delivery itself. For the object model underneath a delivery, see how deliveries work; for how a provider ends up carrying the delivery in the first place — a prerequisite for filing a report against it — see how dispatch works.

Availability

Report Incident, refund amounts, and the specific columns and fields described here aren't guaranteed to appear the same way for every organization or every provider — availability varies by org and by provider setup. If something described on this page is missing for you, reach out to Nash rather than assuming it's broken.

Related