How to Document Exactly What Was Submitted, Received, and Filed

Almost every argument about a file comes down to three questions. What was sent? What actually arrived? And where did it end up? When a job is going well, nobody asks them. When a file goes missing, a payment is held, or a claim is contested months later, they are the only questions that matter, and the firm that can answer all three in plain records wins the conversation quickly. The firm that cannot is left reconstructing events from memory and an inbox.

Most teams try to answer these after the fact, digging through sent folders and chat threads to piece together what happened. That is backwards. The answers are cheap to capture at the moment each thing occurs and expensive to reconstruct later. This guide covers how to document all three stages, submitted, received, and filed, as a byproduct of the normal handoff rather than as paperwork anyone has to remember. It is the wider view around proving a file actually landed, which is really just the middle question of the three.

The three questions that settle disputes

Think of a packet as passing three checkpoints on its way from a crew to a closed job. Each checkpoint answers one question and leaves one small record behind. Capture the record at the checkpoint and the answer is always there when you need it. Skip it and you are betting that nobody will ever ask. Here is what to document at each of the three, and why it is the piece that holds up when challenged.

Submitted: capture the list and the fingerprints at send

The submitted record answers a question people forget to ask until it is too late: what was in the packet in the first place? If all you have is “I sent the photos,” you cannot later prove whether the set was 40 images or 400, or whether the moisture log was in there at all. So the first thing to capture is the file list itself, taken at the moment of sending: the names, the count, and the total size, frozen as a fact rather than a recollection.

The second thing is a fingerprint for each file. A checksum, computed on the device before the file leaves, is a short string that stands in for the exact bytes. Capture it at send and you can later prove that a specific file, not just a file with the same name, is the one that went out. This is what separates a real submitted record from a line in a sent-mail folder. The list says what you meant to send; the checksums say exactly what those files were.

The third thing is a receipt. The instant the files upload and verify against their checksums, issue a numbered receipt that ties the list and the fingerprints together under one handle everyone can quote. In RoverDrop this happens automatically at submit: the packet gets a number, a verified file count, and a verified size the crew can see before they drive away. The submitted question is now answered permanently, and no one had to fill anything in.

Received: a confirmation tied to bytes, not a “got it”

The received record is the one most teams think they have and usually do not. A reply that says “got it, thanks” feels like confirmation, but it proves almost nothing. It does not say which files arrived, whether they arrived whole, or whether the person who typed it actually took responsibility for the work. It is a courtesy, not a record. When a file turns out to be truncated or missing, a friendly reply is no defense at all.

A real received record is tied to the bytes. Every file is checked against the checksum computed at send, and the packet only counts as received when each one matches. That check is the difference between “a message was accepted” and “these exact files arrived intact.” This moment is the heart of creating proof of file delivery, and it is worth getting exactly right, because it is the hinge the other two questions swing on.

Two more details make the received record usable. First, a timestamp set when the last byte lands and verifies, not when someone hit send and not when they got around to replying. Second, a named receiver: the person who deliberately took the packet, so the record says who has it now. Downloading a file to look at it is not the same as taking responsibility for it, and the received record should reflect the deliberate act, not the glance.

Filed: record the final placement and keep the original

The filed record answers the question that comes up long after everyone has moved on: where did this end up, and is the original still there? A packet that was received but never filed is still unfinished work, and without a filed record you cannot tell the two apart. So the filed stage needs a recorded final step: a deliberate action that says the packet has been placed where it belongs and the job is closed, stamped with who did it and when.

Recording placement is only half of it. The other half is keeping the original. Wherever the files ultimately live, the working copy can be edited, moved, or aged out by a retention rule, and two years later the version you find may not be the version that arrived. A write-once archive copy, stored the moment the packet is submitted and untouched by anything downstream, is what lets you answer “what was actually filed” with a stored file and a matching checksum instead of a best guess.

Together, the filed record and the retained archive close the loop. The record shows the packet reached its destination and who put it there; the archive guarantees the original is still available to check against. That pairing is what turns a folder of files into something you can stand behind when a client, an adjuster, or a court asks what you delivered.

Do it as a byproduct, not as paperwork

If documenting these three stages means someone filling in a log by hand, it will not happen. Logs get skipped on the busy days, which are exactly the days a file goes missing. The only version of this that survives contact with real work is the version where the records are a byproduct of the handoff itself. The crew submits the way they always would, the office accepts and files the way it always would, and each of the three answers is written automatically as a side effect.

That is the design principle behind a tracked handoff: the submit action produces the submitted record, the verify-and-accept action produces the received record, and the file action produces the filed record. Nobody keeps a ledger, because the workflow keeps it for them. If you are moving off email and building this into your own process, the concrete pieces look like this:

• One intake queue. Every packet enters the same way, so there is a single place each of the three records is produced.
• Checksums at the edge. Fingerprint files on the device, so the submitted and received records describe the same bytes.
• An accept that means received. The received record is tied to a verified, deliberate acceptance by a named person.
• A file step that closes the packet. Placement is a recorded action, not an assumption that someone put it somewhere.
• An automatic archive. A write-once copy is stored at submit, so the original outlives the working file.
• An append-only trail. Every event carries an actor and a time and cannot be edited after the fact.

Those last two points are where the submitted, received, and filed records stop being three separate notes and become a single connected history. For the full list of events worth capturing across a packet, see what a file-transfer audit trail should include. And if you want a written procedure your crews will actually follow, the field-to-office handoff SOP template lays out the roles and steps you can edit for your own firm.

Answer all three before anyone asks

Proof of delivery gets most of the attention because the received question is the one that comes up first. But a firm that only documents what arrived is still exposed on both ends: it cannot prove what was supposed to be in the packet, and it cannot prove where the packet finally went. Documenting all three stages closes those gaps. Submitted says what you sent, received says it arrived whole and into whose hands, and filed says where it landed with the original kept safe.

None of it requires extra effort from the crew or a heavier process for the office. It requires a workflow that produces each record at the moment it is cheap to capture: a receipt at submit, a verified confirmation at accept, and a placement record with a retained copy at file. Build the handoff that way and the three questions that decide most file disputes are already answered, in writing, long before anyone thinks to ask them.