Acknowledgement of Receipt: What to Put in One, and When It Holds

An acknowledgement of receipt needs five elements: what was received, described specifically enough to identify it later; who is acknowledging, by name and role; the date; a statement of what the person is confirming; and their signature. The common version confirms only that something arrived, which is the version that fails when it is needed.

If you would rather just have the document, the free acknowledgement of receipt generator builds one from a few answers and never sends anything anywhere.

The difference is one sentence. "I confirm receipt of the attached documents" establishes almost nothing nine months on. "I confirm receipt of the network documentation, the admin credentials for the six systems listed in Appendix A, and the four disclosed issues in Appendix B" establishes a great deal.

The five elements

1. What was received. Specific enough that a stranger could tell whether a given item was in scope. Counts, filenames, appendix references, or a content hash. Not "the documents".

2. Who is acknowledging. Full name and the role they hold. A signature with no name beside it starts an argument about who signed.

3. When. The date of acknowledgement, which is not always the date of delivery. Where the gap matters, record both.

4. What is being confirmed. Receipt alone, or receipt and review, or receipt and acceptance. These are three different statements and are routinely used as though they were one. Say which you mean.

5. Signature. Wet, electronic, or a recorded click, depending on what the situation warrants.

Receipt, review, acceptance

The single most useful thing in this whole document.

Ask for the weakest one that does the job. Asking someone to accept when you only need them to confirm receipt is how a simple form turns into a negotiation and then never gets signed at all.

A usable structure

ACKNOWLEDGEMENT OF RECEIPT

Received from:   [organisation]
Received by:     [full name], [role], [organisation]
Date received:   [date]
Date signed:     [date]

Items received:
  1. [item, with identifier or hash]
  2. [item, with identifier or hash]
  3. [item, with identifier or hash]

Disclosures included:
  1. [disclosure, with severity]
  2. [disclosure, with severity]

I confirm that I have received [and reviewed] the items and
disclosures listed above.

Signature: ______________________   Date: ____________

Two things earn their place. Listing items individually means the acknowledgement names its own scope. Listing disclosures separately means the person is confirming they were told the specific things you told them, which is the part that gets disputed.

When a paper acknowledgement is enough

Often. A signed form in a filing cabinet is a real record and has been for a long time. If both sides are cooperative, the amounts are small, and nobody is likely to contest it, that is a sensible amount of effort.

It gets thin in three situations:

• The other side stops cooperating. A signed page you hold is your copy of a document they may dispute signing.
• The contents matter as much as the fact of delivery. A list of filenames says nothing about what was in them. If a file is later swapped, an acknowledgement naming the filename still matches.
• Time passes. Signatures on paper age badly as evidence: the ink does not establish when it was applied, and neither does the date written next to it, because both were within reach of whoever held the page.

Making the acknowledgement provable

Three properties close those gaps, none of which need a lawyer:

1. Bind it to content, not filenames. A hash of each item means the acknowledgement covers exactly the bytes that were sent. Substitute a file afterwards and it no longer matches.
2. Verify the acknowledger. A one-time code to their own address, with the consent and the address and the time recorded, is meaningfully better than a name typed into a box.
3. Timestamp it with something neither side controls. Your systems and their systems are both partisan. An independent timestamp is not.

That is what Pactbound produces: an acknowledgement that names each item by hash, records who confirmed it and how their address was checked, and anchors the result to a public ledger so no party sets the clock. Under the E-SIGN Act an electronic record cannot be denied legal effect just for being electronic, though whether any specific record is accepted in a specific proceeding still runs through the ordinary rules. The honest boundaries are in what this evidence proves and what it does not.

Sources

• E-SIGN Act, 15 U.S.C. § 7001, on the legal effect of electronic records and signatures
• NIST FIPS PUB 180-4, specifying SHA-256, the hash that binds an acknowledgement to specific content