Configure Automatic Document Expiration (Completion deadline)

The Expiration Date feature in Acrobat Sign allows senders to set a time limit for recipients to complete their signatures before the agreement is automatically canceled. This helps control signing deadlines, particularly for time-sensitive agreements, such as seasonal contracts or special offers. It also streamlines agreement management by removing old or unlikely-to-complete agreements from the In Progress list, making active agreements easier to track.

Senders can set expiration dates up to 180 days from when an agreement is sent. By default, agreements are scheduled to expire at 11:59 PM local server time, but senders can modify this setting. To optimize system performance, agreements always expire during off-peak hours for their assigned server group. If an expiration is set during peak hours, the system automatically adds 12 hours, ensuring expiration occurs during non-peak times.

Note:

If no expiration date is manually set, agreements automatically expire after 365 days in an In Progress status, ensuring long-standing agreements don't remain indefinitely open.
All expiration times are based on the server group's time zone (see the FAQ at the bottom of the page).

Configuration

Availability:

Acrobat Standard and Acrobat Pro: Not Supported
Acrobat Sign Solutions: Supported; Disabled by default
Acrobat Sign for Government: Supported; Disabled by default

Configuration scope:

Administrators can enable this feature at the account and group levels.

Access this feature by navigating the administrator's configuration menu to Send Settings > Document Expiration

The Document Expiration controls on the Send Settings menu.

The sender experience for Document Expiration will vary depending on if you are configuring a commercial Acrobat Sign Solutions account, or an Acrobat Sign for Government account.

Please select the tier of service you are using from the below options to review the configuration options in their respective environments:

When Document Expiration is enabled, either Allow senders to set or modify expiration settings per document or Limit number of days signers will have to sign documents to must also be selected.

The Document Expiration controls on the Send Settings page with the "Enable document expiration" option highlighted.

This makes the Completion Deadline value in the Agreement settings available.

If the setting is disabled, the Completion Deadline option is locked and can't be edited.

The Agreement settings section of hte Compose page highlighting the locked out "Completion date" field.

When enabled, senders have the option to change the expiration date to any day within 180 days of the agreement creation.

New agreements automatically set the expiration date to 180 days from the day of sending (unless a limited number of days is defined).

The sender is free to select a different expiration date within the 180 days.

When enabled, agreements that are In Progress have the option to edit the deadline date on the Manage page.

The Expiration Date in the agreement meta data displays a pencil icon to open the Add or Edit interface for the deadline.

Two examples of the Manage page, one highlighting where the Edit icon is, and the other highlighting that no icon is present.

When enabled, new agreements automatically adopt a completion deadline measured in the number of days defined by the input field.

If the option to allow sender to set or modify the expiration date is not enabled, then the date picker to the right side of the expiration date field will be locked, and only the default expiration window is enforced.

The Agreement settings section of the Compose page highlighting the completion deadline with the locked date picker.

When enabled, the document expiration date does not apply to internal recipients—users within the same Acrobat Sign account as the sender.

This ensures that external recipients must complete their actions within the defined expiration window, as stated in the agreement details and email notifications. Meanwhile, internal counter-signers are not restricted by the expiration date, preventing situations where they run out of time to complete their actions before the agreement expires.

When enabled, this option inserts the deadline information on any email communications to the recipient.

Examples below show the request to sign, and a reminder email with the deadline information visible.

If the option is disabled, the expiration information is not included in the email template.

Example emails to the recipient with the deadline information highlighted.

When Document Expiration is enabled, either Allow senders to set or modify expiration settings per document or Limit number of days signers will have to sign documents to must also be selected.

New agreements display the Completion Deadline option. The experience will depend on whether the default deadline is being used or if the sender can set the deadline.

If the Document Expiration is not enabled, the Completion Deadline option is omitted from the page entirely.

the classic compose page highlighting the Completion Deadline option

When enabled, senders have the option to change the expiration date to any day within 180 days of the agreement creation.

The Document Expiration controls on the Send Settings page with the "Allow sender to set the date" option highlighted.

New agreements display the Completion Deadline option with no value inserted. The sender can provide a number of days before the agreement will expire, or no expiration will be defined.

When enabled, agreements that are In Progress have the option to edit the deadline date on the Manage page.

The Document Expiration controls on the Send Settings page with the "Allow modification of date" option highlighted.

The Expiration Date in the agreement meta data displays a pencil icon to open the Add or Edit interface for the deadline.

When enabled, new agreements automatically adopt a completion deadline measured in the number of days defined by the input field.

The Document Expiration controls on the Send Settings page with the "Limit number of days" option highlighted.

If the option to allow sender to set or modify the expiration date is not enabled, then the Completion Deadline option will be checked, but locked. Only the default expiration window is enforced in this case.

The classic Compose page highlighting the completion deadline with the locked date picker.

When enabled, the document expiration date does not apply to internal recipients—users within the same Acrobat Sign account as the sender.

The Document Expiration controls on the Send Settings page with the "Include internal recipients" option highlighted.

When enabled, this option inserts the deadline information on any email communications to the recipient.

The Document Expiration controls on the Send Settings page with the "Include information in emails" option highlighted.

Examples below show the request to sign, and a reminder email with the deadline information visible.

If the option is disabled, the expiration information is not included in the email template.

Expiration timing

Document expiration always occurs during off-peak hours based on the server that sent the agreement. Off-peak hours are 7 PM to 7 AM in the server's local time zone.

By default, agreements sent through the modern Request Signatures process are assigned an expiration time of 11:59 PM, though senders may be allowed to set custom expiration dates and times. However, agreements sent through the API, integrations, or legacy interfaces don't default to 11:59 PM; instead, they adopt the timestamp of when the agreement was initially sent.

If an agreement is set to expire during peak hours, it's queued for expiration but automatically delayed by 12 hours, ensuring the expiration event is processed during off-peak hours.

Status and Editing During Expiration Queuing

While an agreement is queued for expiration, its status remains In Process on the Manage page and API responses.
Recipients cannot sign a queued agreement and will receive an error message stating that the agreement cannot be signed.
During the 12-hour queuing window, the sender can edit the Expiration Date on the Manage page to extend the deadline and allow recipients additional time to sign.

Best practices

Typically, setting at least a default expiration date is encouraged. This helps keep agreements organized and aligned with current policies. Expiring agreements that are unlikely to be completed improves efficiency by reducing clutter in the In Progress filter on the Manage page, making it easier to track and manage active agreements.

If you enable expiration dates, consider:

Enabling Include expiration information in emails sent to signers – Informing recipients of a deadline encourages timely completion and clarifies that the agreement will expire if they don't act.
Disabling Include internal signers when applying document expiration deadlines – Deadlines typically impact external recipients more than internal users. Disabling this option prevents agreements from expiring simply because internal counter-signers haven't completed their actions in time.
Enable Allow modification of expiration settings after document is sent - Whether to allow changes usually depends on compliance requirements. If your process doesn't require strict time constraints, enabling this option provides flexibility, giving the senders an option to save an agreement that is about to expire.

Things to know and Frequently asked questions:

Non-peak hours are from 7 PM to 7 AM based on the most central time zone for the shard group from which the agreement was sent. The time zones used for each shard group are:

Shard Group	Time Zone for Peak Hours (7 AM - 7 PM)
NA1, NA2, NA3, NA4	America/Chicago
EU1, EU2	Europe/Berlin
AU1	Australia/Sydney
JP1	Asia/Tokyo
IN1	Asia/Kolkata
SG1	Asia/Singapore

Note:

Some shard groups include multiple shards that span multiple time zones. All shards in the group apply the same non-peak expiration window.
For example, the NA1, NA2, NA3, or NA4 all observe the same non-peak hours based on Central Time (GMT -6).

The signer will not be able to sign after the expiration time, even if the agreement has not yet transitioned to EXPIRED status. They will see an error message:

If an agreement has been queued for expiration but the expiration has not yet been processed, the sender may still be able to edit the expiration date. This allows the recipient additional time to sign the agreement before it is expired.

When setting the expiration date/time on the Request Signatures page, it defaults to 11:59 PM, ensuring the expiration occurs during non-peak hours and is processed at that time or soon after. You can adjust this in the Agreement Settings section.

The "Agreement settings" section of the Request Signature page highlighting the Completion Deadline setting.

Get help faster and easier

New user?

Configure Automatic Document Expiration (Completion deadline)

Enable senders to set a password to view an agreement.

Configuration

Availability:

Configuration scope:

Acrobat Sign Solutions

Acrobat Sign for Government

Expiration timing

Status and Editing During Expiration Queuing

Best practices

Things to know and Frequently asked questions:

How are “non-peak hours” determined?

What happens if an agreement expires during non-peak hours?

What does “environment managing the agreement” mean?

What happens if an agreement is set to expire during peak hours and someone tries to sign it after the expiration time has passed?

What happens to API responses for agreements past their expiration time but not yet marked as expired?

Can I change the expiration date after the original expiration time/signing deadline has passed but before the agreement is marked as expired?

Is the expiration always delayed exactly 12 hours for agreements expiring during peak hours?

How can I ensure an agreement expires during non-peak hours?

What status will agreements show on the Manage page after the expiration time has passed but before expiration is processed?

How does this affect Data Governanace?

When is the expiration event recorded in the audit report?

Why was this change made?

Get help faster and easier