# POD dispute records retention timeline | SourceX

Canonical: https://refer.sourcex.si/guides/preserve-proof-of-delivery-disputes-records
Last updated: 2026-10-19

Before a carrier or delivery-platform integration changes, list every copy of the dispute evidence and the clock that ends each one: detailed status codes that cutover may flatten, delivery photos hosted by the old platform, signature letters on the carrier's portal, support tickets, adjudication notes and credit memos. Note which copy is still readable and linked to its case after cutover, who owns it, and who must approve keeping it. Then introduce the executive who can authorize a licensing discussion.

This retention timeline is part of the [proof-of-delivery disputes guide](/guides/workflow-proof-of-delivery-disputes), which explains which records make a dispute readable. Here the question is narrower: in what order do those records disappear, and what has to happen for each one to survive?

## Why one dispute has several clocks

A delivery photo can sit in three places at once: the delivery platform that captured it, the carrier's portal and the company's own archive. Each copy has its own end date. An integration change rarely deletes all of them. It usually breaks one link, and the dispute loses the piece that link held.

Four mechanisms do most of the damage:

- **Identifiers change.** New tracking-number formats or stop IDs leave old tickets pointing at numbers the new platform has never seen.
- **Status codes get flattened.** A code such as "left at reception" can be mapped into a plain "delivered", erasing the fact a dispute turned on.
- **Hosted media stays behind.** Photos and signature images often live with the platform that captured them. Whether they can be exported in bulk depends on the vendor and contract; confirm it with the vendor rather than assume it. Carrier photos are not universal either: FedEx notes on its picture proof page that some deliveries may not include a photo.
- **Carrier windows close.** Some carrier copies are only retrievable for a limited time, so a company that relied on the portal may find older disputes have lost their proof.

## The retention timeline, record by record

Read the table left to right: the copy, what starts and stops its clock, the documented anchor if one exists, and who has to approve keeping it. Where no public figure exists, the cell says so; the company's own retention schedule is the only real answer.

| Record copy | What sets its clock | Documented anchor | Fades when | Who approves keeping it |
|---|---|---|---|---|
| Detailed status codes | The status mapping chosen for cutover | None published; set by the mapping plan | On cutover day, if mapped to a simpler code | Operations director with the integration lead |
| Photos hosted by the old platform | Platform contract and storage policy | Vendor contract; confirm with the vendor | Contract end or storage purge | Operations director, with counsel for the contract |
| Carrier signature letters | Carrier retrieval window | FedEx Express: up to 18 months | When the window passes | Customer service manager saves a company copy |
| Support tickets with tracking numbers | Help desk retention and migration scope | Company retention schedule | Help desk renewal or migration | Customer service manager |
| Adjudication notes | Wherever claims were recorded | Company retention schedule | When the claims tool or spreadsheet owner leaves | Claims lead |
| Credits, refunds and denials | Accounting retention | IRS: generally 3 years after filing for records supporting a return | Accounting system cutover, if history is not migrated | Finance director |

Two outside clocks explain why the history matters beyond the courier. Card networks typically allow cardholders to start a dispute within 120 days of payment, with more time in some cases, so a retailer client's delivery evidence has to outlive that window. And records that support a tax return are generally kept until its period of limitations runs out, usually 3 years from filing, which is why credit memos tend to outlast the operational records they reference.

## What disappears first

A common order, though each company should check its own plan:

1. **Status detail, at cutover.** It goes first because it is lost by a mapping decision, not a deletion. Nobody notices until a dispute needs it.
2. **Hosted photos, at the platform's storage end.** If the old vendor holds the images and the contract ends, the photos leave with it unless someone exports them under the contract's terms.
3. **Carrier copies, at the retrieval window.** These fade steadily rather than on one date, oldest first.
4. **Adjudication notes, when people move.** Notes kept in a spreadsheet or a personal mailbox are lost when the owner changes roles, which is not on any project plan.
5. **Tickets and credits, last.** Help desks and ledgers usually migrate or stay read-only longest, so the outcome often survives the evidence that justified it.

That last point is the trap. A history where credits survive but photos and notes do not records what each exception cost, not how it was decided.

## An Illustrative timeline for one courier

Illustrative only; the company and dates are fictional. A 420-person regional parcel courier is moving from one delivery platform to another and changing its main carrier integration at the same time. Its operations director fills in the timeline from the project plan.

| Month relative to cutover | Event | Record affected | Status after the event |
|---|---|---|---|
| Month minus 3 | Inventory with the records owner | All six record copies | Listed, with owners and dates |
| Month 0 | Cutover; status codes mapped to five values | Detailed status codes | Detail lost unless the old codes are kept alongside |
| Month 6 | Old platform storage purged under the contract | Hosted delivery photos | Gone unless exported before the purge |
| Month 18 | Carrier window passes for deliveries made at cutover | Carrier signature letters | Only company-saved copies remain |
| Month 24 | Claims spreadsheet owner retires | Adjudication notes | At risk unless moved to the claims tool |
| Month 36 | Accounting history still kept | Credits and denials | Survives under the finance retention schedule |

In this example, only one outcome is set by an outside vendor figure: the 18-month carrier window. The rest come from the company's own contracts and plans, which is why the timeline has to be filled in by the people who hold them.

## Who must approve keeping a record

Keeping data is a decision, not a technical step. The operations director can say which copies exist. Keeping a copy past its normal end date may need the finance director for budget, counsel for vendor and client contracts, and whoever owns privacy, because recipient names, addresses and doorstep photos are personal data. Do not recommend retaining anything without that authority.

For a courier that delivers for shipper clients, client service agreements may also say who owns delivery records; [3PL data ownership](/questions/3pl-data-ownership) covers the common patterns. If the integration change is part of an acquisition, the [3PL acquisition integration guide](/guides/3pl-acquisition-integration-wms) shows how the timing usually runs.

## What the partner writes down, and what stays unknown

Discovery stays at metadata level. Nobody sends files, photos or ticket exports. Write down: the record copies that exist, the years each covers, the system and owner of each, and every documented date on the timeline. Record a date only when it is written somewhere, such as a contract end or a decommission plan; that is the real urgency in this workflow. The [referral brief template](/resources/proof-of-delivery-disputes-referral-brief-template) has a field for it.

The introduced company needs 50+ full-time employees at peak (contractors excluded, which matters for couriers using independent drivers), a documented operating history, rights to license the records and an authorized contact. Companies in the U.S., Canada and the EU qualify, as do companies in the UK, Australia, New Zealand, India, Singapore, South Africa, Latin America, the UAE and Saudi Arabia when at least 90% of the data is in English.

What stays unknown until SourceX reviews it: whether buyers need these records, how client contracts and recipient data affect rights, what preparation is needed and any offer. SourceX licenses approved business data directly from companies for AI training and evaluation, and manages the agreement, rights review, data preparation, delivery and payout. Partners sign the Channel Partner Agreement before submitting, and the first valid introduction within the 90-day window is credited when the company submits a verified application. Related record types: [freight audit exceptions](/data-types/freight-audit-exceptions) and [chargeback representment records](/data-types/chargeback-representment-records). The [who-can-license tree](/questions/who-can-license-proof-of-delivery-disputes-records) names the executive to introduce.

## Next step

> **Refer a company. Earn up to $100,000.** Default reward: 25% of Actual Supplier Payout, capped at $100,000 cumulatively per referred company. Eligibility and payment conditions apply, and a signed Schedule A or addendum can differ. A lead, meeting or signature alone does not trigger payment.

If the timeline shows dispute evidence that fades on a documented date and an owner who can decide what happens to it, [register as a partner](/register), check the company on [who qualifies](/who-qualifies) and read the [program terms](/terms) before the introduction.

## Sources

- https://www.fedex.com/en-il/customer-support/faq/receiving/tracking-questions/fedex-proof-of-delivery.html
- https://www.fedex.com/en-us/tracking/picture-proof-delivery.html
- https://docs.stripe.com/disputes/how-disputes-work
- https://www.irs.gov/businesses/small-businesses-self-employed/how-long-should-i-keep-records
- https://refer.sourcex.si/terms
