Revoke or withdraw an offer signature request

Note: On commercial projects, offers are signed off-system: you print the offer, capture the paper signature, and upload the scan. The e-signature flow described here applies to residential offers. See the commercial planning guide.

This article covers three moments when a signature request needs to move backwards or sideways: pulling a pending link, changing an offer mid-flight, and forking a signed offer when the deal evolves. For the send flow itself, see Preview, variants, legal texts, and offer link validity.

Who this is for

Account managers, installer admins, and field workers who need to undo or change an offer after the signature link has gone out. You'll need an editor-or-higher role.

Before you start

• The offer must already have a signature row (pending, expired, or signed). Withdraw, resend, and fork all act on an existing signature row, so send the request first.
• Decide which case you're in: link sent but customer hasn't signed (pending), link expired without a signature, or customer already signed. Each case takes a different path.

Withdraw a pending signature request

When you need to kill the link the customer received (wrong pricing, wrong variant, typo in the PDF), withdraw the pending request.

1. Open the offer.
2. Go to Finalise > Signature.
3. On the pending signature row, click Withdraw (the undo-arrow icon).
4. Confirm in the prompt.

The customer's public link goes dead immediately, and the withdrawal is recorded in the offer's activities feed as "Signature request withdrawn". After withdrawal, you can edit the offer freely and send a fresh signature request.

Pro tip: If you built the offer through the simple-planning flow, you can manage the signature without switching to the full Finalise view. The Finish planning step carries the same actions: withdraw a pending request, open the public signed-offer link, and a per-variant indicator showing whether each variant is signed or signature requested — locked for editing. The behaviour is identical to withdrawing from Finalise.

Note: The customer keeps their old link until you tell them otherwise, so message them out-of-band (email, phone, WhatsApp) before or right after withdrawing, so they don't click their old link and hit an error.

Note: Withdraw is available while the signature is pending. Once the offer is signed or the link has expired, the row shows "Signed signature requests cannot be withdrawn" or "Expired signature requests cannot be withdrawn" instead. Withdraw each pending signature individually.

Change a pending offer (link sent, customer hasn't signed)

While a signature request is live, the variant it was sent on is locked for editing — you can't change that variant until you withdraw the link. So the flow is withdraw → edit → re-send.

1. Withdraw the pending signature request (see above). The customer's link goes dead and the variant unlocks for editing.
2. Edit the offer freely: pricing, components, PDF customisation, variants.
3. Send a fresh signature request from the Finalise tab. The customer gets a new email with a new link.

While the signature request is live, the variant it was sent on is locked for editing — not just the customer's view. Without withdrawing, you can review the offer or add and edit other variants, but to change the variant that's out for signature you must withdraw its request first. That's exactly what the withdraw step is for: it kills the customer's old link and unlocks that variant for editing. Until you withdraw and re-send, the customer is still looking at the old PDF.

Note: The sent variant is locked for editing while its signature request is pending. To unlock that variant so you can change it, withdraw the request.

Change an offer with an expired link

An expired link is already dead, so you can edit straight away.

1. Edit the offer freely.
2. Send a new signature request from the Finalise tab.

A new signature row is created, and the old expired one stays in the history.

Note: The Withdraw action is available while a link is pending. Once a link expires, it's already dead — to re-sign on the same variant with a fresh link, send a new request. The original expired row stays on the offer as a record.

Change a signed offer — fork to a new variant

Once the customer has signed, that variant is locked as a contract artifact. To capture a change after signature, fork to a new variant.

1. Open the offer.
2. Add a new variant (blank, or duplicated from the signed variant).
3. Edit the new variant with the updated pricing or scope.
4. If the customer needs to agree to the new version too, send a fresh signature request that includes the new variant from the Finalise tab.
5. When installation starts, choose which variant to build (the signed one or the updated one) via the installation handoff.

Duplicating is usually the faster fork. The copy inherits the source variant's line items, payment mode, financing details, subsidies, and solar layout, so you only tweak what changed.

Pro tip: A duplicate is an independent copy, not a live mirror, so edits on it don't bleed back to the original. It inherits the solar layout (modules, strings, parallel groups, each carried over as an independent copy), the payment mode, financing details, subsidies, solar economics (feed-in tariff, electricity price, post-EEG tariff), and the optional-component bundles (the duplicate dialog confirms "Optional components are duplicated" and "Subsidies are duplicated"). If you duplicate a variant that has financing attached, the copy keeps the same financing set-up, ready to tweak; remove the financing on the copy to get a plain cash variant. The customer's bundle selections reset to un-ticked so the customer re-selects optional components, and the new variant is unlocked even when the source was locked by a signature.

Note: The signed PDF and the signed-variant snapshot are kept on file permanently. They are contract artifacts, so forking preserves the original record exactly as the customer agreed to it.

Cancel, reject, or revoke a signed offer

The signed variant stays locked as a contract artifact, and the signed PDF is kept on file as such. Handle a cancellation off-system:

• Document the cancellation off-system (email, written agreement, or your CRM).
• Move the project status manually (for example to Lost with a reason) so your team and reporting reflect reality. Status changes don't touch the signed PDF; they document the deal outcome.

If the customer wants to renegotiate, fork to a new variant as described above. The customer signs the new variant, both signatures stay on file, you decide off-system which one binds, and you handle installation against the chosen variant.

Things to know

• A live signature request locks the variant it was sent on. While a request is pending you can review it, withdraw it, or add and edit other variants — but to change the variant that's out for signature you must withdraw its pending request first (that also kills the customer's link). The customer keeps seeing the send-time snapshot until you withdraw and re-send.
• A signed signature locks only its own variant. Other variants on the same offer stay editable, and you can add new variants even after one is signed (handy for an upsell). Fork by duplicating the signed variant into a new editable variant.
• Every offer keeps at least one variant. Each offer keeps its last remaining variant, and a variant attached to any non-withdrawn signature stays in place. Withdraw the signature, or wait for expiry or signing, before removing it.
• Pricing changes are silent to the customer. After a withdraw and re-send, the new email doesn't flag "Updated pricing" unless you write that in the message. To show what changed, point the customer to the updated PDF or note the change in your message.
• You own the customer ping. Message the customer out-of-band when you withdraw a link, so they don't click a dead link.
• Forks coexist. A signed variant and a new editable variant live side-by-side on the same offer. The signed one stays as the contract artifact, and the new one is what you work on going forward.
• Forking fixes a wrong uploaded document too. When the wrong paper PDF lands on a signed row, add a new variant, send a new signature request, and capture the correct paper signature on the new row.
• Forking straight into installation. When you start an installation on a signed multi-variant offer, fork the signed variant into an "Installation: <name>" variant in one step and set it as the one to build, so the installer can adjust installation specifics while the historical signed record stays put.

Related

• Preview, variants, legal texts, and offer link validity: send a fresh signature request after withdrawal or fork.
• Upload manual signature: capture an analog signature on a pending or freshly-issued row.
• Remind customer: resend the existing link without changing the snapshot.
• Track openings of offer: confirm the new email actually went out after a re-send.

Need help?

• Step-by-step questions about this flow. Contact your Reonic account manager.
• Feature requests / something missing. Drop a note to your account manager.
• Bug reports. Include a screenshot and the URL where it happened in your support email.

Last updated on August 4, 2026