On this page
The main agreement may be ready while its attachments are still moving. A schedule of services, price sheet, drawing set, or security exhibit can change after someone has assembled the signing package. The resulting risk is simple: the document people approve may differ from the document people receive.
An attachment map is a small record connecting each required component to the approved source and the actual signing transaction. It supports document administration; it does not determine which terms legally control or replace a review of incorporation language by the appropriate professional.
Start with the package the recipient must receive
List the components required for this agreement, including exhibits mentioned inside other exhibits. A reference to “the attached schedule” is difficult to check when three schedules have similar names. Give each required component a stable label that matches the agreement's own references.
For each item, identify its purpose and approving owner. A technical drawing may need engineering approval, while a price schedule needs a commercial owner. The sender should know whom to ask without becoming the assumed authority on every attachment.
Check whether the intended package is one combined PDF, several uploaded documents, or another supported arrangement. A folder containing the right files is not yet proof that the signing service will present all of them.
Keep source identity separate from display name
Filenames help people navigate, but names such as final, final-new, and final-approved are weak evidence of version identity. Record a controlled version number or repository revision, approval date, and source location alongside the readable title.
A file hash can provide an additional exact-byte comparison when your workflow supports it. It does not prove approval, correctness, or legal effect. Conversion to PDF, applying fields, or adding signatures can legitimately change the file bytes, so compare hashes only at the stage they describe.
The contract version-control guide covers the wider review history. The attachment map focuses on the handoff from that history into a specific request for signature.
Use a compact map with distinct checkpoints
One row per component is usually easier to inspect than a long narrative email. Include enough information to answer who approved the file, which source was used, and where the recipient sees it.
| Map field | Question it answers |
|---|---|
| Component label | Which exhibit or schedule is this? |
| Approved source version | Which controlled source may be used? |
| Approval reference | Where is the approval recorded? |
| Uploaded filename or position | Where is it in this signing package? |
| Preview check | Did the assembled file display correctly? |
| Transaction identifier | Which request contains this package? |
| Retained copy reference | Where is the resulting record stored? |
Do not put unrestricted download links to confidential attachments in a broadly shared tracker. Use access-controlled references and give reviewers only the access their role requires.
Review the assembled output, not just the input folder
Open the signing preview and compare it against the map. Check the order of attachments, visible exhibit labels, page orientation, page count, and any places where a conversion could hide content. A correct spreadsheet source can become an unreadable PDF if columns are clipped.
Inspect cross-references in the main agreement. If the text mentions Schedule B but the package contains only Schedule A, pause the send. Resolve the mismatch through the document owner rather than silently renaming an attachment to make the labels appear consistent.
Check field placement separately. A signature or initials field placed over an attachment heading can obscure the version information you need later. A field assigned to the wrong participant is a routing problem even when the underlying documents are correct.
Treat a late replacement as a new decision
When someone supplies a newer attachment, ask whether the existing approval still covers it. The newest file is not automatically the approved file. Record the change reason and route any substantive differences through the established review process.
Do not assume that replacing a file in the source folder updates an already sent transaction. Adobe's modification feature, for example, depends on eligibility and enabled settings. The actual signing record must be inspected after any supported change.
If the current transaction cannot be safely modified, the responsible owner must decide how to handle it. The expiry and reissue guide provides an administrative framework for avoiding two ambiguous requests, but it does not authorize cancellation of a consequential agreement.
Track transformations explicitly
A source document, uploaded PDF, combined signing preview, and completed signed PDF can all be related versions of the same component without being identical files. Label each stage so a later reviewer knows what is being compared.
For example, an approved spreadsheet may produce a two-page pricing PDF. The map can record the spreadsheet revision and the exported PDF used in the transaction. If the signing service combines that PDF with the main agreement, record its position in the assembled package as well.
Avoid trying to reconstruct this chain from download timestamps alone. A timestamp can reflect when a colleague copied a file, not when its contents were approved or first sent. Use the workflow's actual evidence and identify any missing link honestly.
Retain the package and the evidence of its assembly
After completion, obtain the available completed documents through the service's supported download functions. Adobe also documents downloading individual agreement files, which can help when the package was assembled from multiple uploads. Verify which artifact you downloaded instead of assuming every download is the same kind of record.
Keep the map with the retained agreement record and applicable event evidence. Follow the established document retention policy, including access restrictions and disposal rules. Do not retain extra copies indefinitely simply because they are convenient.
When handing the agreement to operations, point to the appropriate completed package and explain which supporting files are operational references. An editable source file can be useful for maintenance without being presented as the executed agreement.
Resolve discrepancies before they become routine
If the map and signing package differ, record what you actually found: a missing exhibit, a wrong version label, an unreadable export, or a link that no longer resolves. Avoid a vague “document issue” that forces the next reviewer to repeat the investigation.
Have the responsible owner choose the correction and preserve the relevant history. The goal is a traceable package whose components can be identified and checked, not a perfectly tidy folder that conceals how the documents changed.
Sources and further reading
Primary and contextual sources used to verify definitions or give readers a relevant next resource.
- Adobe: Modify a sent agreement Editing sent documents or fields depends on the agreement state and enabled features, so a corrected source file does not itself change the signing transaction.
- Adobe: Download individual agreement files The service provides a way to retrieve the individual files associated with an agreement in PDF form.