This dispute usually surfaces at the worst possible moment — when payment is already on the line. A client claims a deliverable was late, sometimes as a genuine misunderstanding about the agreed date, sometimes as leverage to negotiate a discount or delay payment. Either way, “I delivered it on time” is a much weaker position when it’s an assertion than when it’s a fact with a timestamp attached.
But it’s worth being precise about which kind of timestamp actually holds up, because the instinct most freelancers reach for first — a file’s own “date created” or “date modified” property — is a weaker form of proof than it feels like in the moment.
Why this dispute happens at all
The delivery date and the review date get conflated. A freelancer sends a draft on the 10th; the client opens and reads it on the 14th, and in their memory, “the draft” arrives on the 14th — because that’s when they actually experienced it.
“Delivered” isn’t clearly defined in the agreement. Does the clock stop when a file is emailed, when a link is shared, or when the client confirms receipt? If the contract doesn’t say, both parties can honestly believe a different definition.
Multiple versions blur the timeline. If v1 went out on time but v3 (after two rounds of client-requested revisions) is what’s actually being evaluated, “was it late” depends entirely on which version is being discussed — and that context can get lost.
A file's own timestamp is weaker evidence than it feels like
Here’s a correction worth making explicitly, because it runs against a common assumption: a file’s “date created” or “date modified” property — the thing most freelancers instinctively reach for first when a dispute happens — is trivially editable by anyone with basic file management tools, and it isn’t independently verifiable by anyone but you. In a real dispute, “my file says I made it on the 10th” is closer to an assertion than a fact, precisely because nothing stops that date from being anything you want it to say.
There’s a specific, easy-to-fall-into trap worth naming directly: re-exporting or “flattening” a document destroys its original metadata and replaces it with today’s date. If a dispute happens and a freelancer’s instinct is to open the original Google Doc, re-export it as a fresh PDF, and send that as “proof” of the original version, the resulting file’s own metadata will show it was created today — the day of the dispute, not the original delivery date — which can actively work against the freelancer rather than for them, even though nothing dishonest happened.
Email timestamps have a related, subtler issue: what an email client displays isn’t always what actually happened. Email clients frequently reformat timestamps into local time and can drop timezone information entirely, showing something that looks precise but isn’t fully verifiable at a glance. The more reliable version of that timestamp lives in the email’s raw header — the server-received time, generally untouched by either party’s device — which is more precise and harder to dispute than whatever a client sees rendered on screen, though it takes a bit more effort to actually pull up.
Worth knowing too, mostly so it doesn’t cause unnecessary panic: a device with its system clock set incorrectly can make an entirely honest file look suspicious — a timestamp that seems “off” isn’t automatically evidence of dishonesty, just a reminder that any single device’s self-reported time has real limits as standalone proof.
A worked example — where the instinct to “prove it” backfires
A consultant delivers a strategy document on March 3rd, shared as a live Google Doc link. Seven weeks later, the client disputes the timeline, claiming the deliverable arrived in April. The consultant, wanting concrete proof, opens the original Google Doc and exports a fresh PDF to send as evidence — reasoning that a PDF feels more official than a live doc link.
That PDF’s own metadata now shows a creation date of today, seven weeks after the actual delivery — because exporting a new file is creating a new file, regardless of when the underlying content was originally written. If the client’s side has any reason to scrutinize the file itself rather than take the consultant’s word for it, the “proof” the consultant just generated technically supports the client’s version of events, not the consultant’s.
The stronger move would have been screenshotting the Google Doc’s own version history (which shows genuine edit timestamps tied to Google’s own servers, not the consultant’s local export), or — better — pointing to any system record generated independently at the time, such as a project-management tool’s activity log or a portal’s own upload timestamp, rather than manufacturing a new file after the fact and hoping its properties would cooperate.
Building a record before you need one
Timestamp every delivery, not just the final one. A quick “Sharing the v1 draft now — [date]” message, even informally, creates a marker independent of the client’s memory of when they got around to opening it. It’s still a self-reported timestamp with the limits described above, but it’s meaningfully better than nothing, and it’s genuinely hard to falsify retroactively across an entire email thread without it looking obviously inconsistent.
Separate “delivered” from “approved” explicitly. If your process distinguishes the moment work is sent from the moment it’s reviewed and signed off, a later dispute about lateness only has one date to argue about — the delivery date — not a blurred combination of both.
Keep dated version history. If a project goes through several rounds, being able to show “v1 was sent on the 3rd, on schedule; v3 — the version under discussion — reflects two rounds of revisions the client requested afterward” reframes a “you were late” claim into an accurate account of what actually happened.
What to do when the dispute happens anyway
Resist responding defensively in the moment. “Actually, I sent that on time” as a first reply reads as combative even when accurate. Instead: “Let me pull up exactly when each version went out so we’re both looking at the same timeline” — this signals you’re not arguing from memory, and it buys a moment to actually gather the dates before continuing the conversation.
If the record genuinely shows you delivered late, own it plainly rather than relitigating — a freelancer who says “you’re right, that one was 3 days late, here’s what happened” tends to preserve more trust than one who argues a clearly incorrect timeline. This matters more than it might seem: when a timestamped record and someone’s memory genuinely conflict, the systematic, contemporaneously-generated data is generally trusted over the recollection — which cuts both ways. It protects you when you’re right, and it’s not worth fighting when the record shows you weren’t.
Where a portal changes this conversation entirely
The strongest version of “proof of delivery” isn’t a file’s self-reported date, and it isn’t even a sent email — it’s a timestamp recorded independently, by a system neither party individually controls, at the exact moment an action happened. That’s the real, meaningful distinction between a file property you could technically edit yourself and a server-side log entry generated automatically the instant something was uploaded or opened — the latter isn’t something either party can quietly adjust after the fact.
SwiftSignoff’s decision log captures exactly when each asset was uploaded and exactly when the client first viewed the portal — both logged automatically, independent of either party’s own device or files, and both visible to both sides throughout the project rather than reconstructed after a dispute begins. If a “you were late” claim comes up, the answer is a specific timestamp the client has already seen, not a file property either side could plausibly have altered.
Related guideHow to build an uneditable decision log for your freelance projects
FAQ
Is a sent email enough proof on its own?
It helps, but it only proves you sent something — not that it was received, or which version it was. A record both parties can independently verify (like a portal view log) is stronger.
What if the client claims the file was sent but corrupted or unreadable?
This is a real, if uncommon, failure mode — worth confirming receipt explicitly on higher-stakes deliverables (“let me know once you’ve been able to open this”) rather than assuming a sent file was a usable one.
Should delivery deadlines be defined by send date or by a confirmed-open date?
Define it in the contract as send/upload date specifically — a confirmed-open date puts the deadline partly outside your control, since it depends on the client actually checking.
Does this kind of dispute usually happen with new clients or repeat ones?
It’s more common with newer or one-off clients, where there isn’t yet a track record of trust — which is exactly why building the habit of timestamped delivery from the first project matters most early in a relationship.
Can I just check a file's “date created” property to prove when I finished it?
That property is trivially editable with basic file tools and isn’t independently verifiable, so on its own it’s weaker proof than it feels like. It can support a timeline but shouldn’t be relied on as the sole evidence, especially since re-exporting or re-saving a file can overwrite it with today’s date without you realizing.
“I delivered on time” is stronger as a fact than as a claim — and stronger still as someone else’s fact, not just yours.
PricingSee how SwiftSignoff’s automatic timestamps work on the pricing page