Accepting and closing
What this page is — the path from "both sides agree" to a document that is sealed, signed, in force, and actually looked after.
What it is for — so agreement becomes a recorded state, the document goes into force only when it is really signed, and its commitments are tracked from day one.
The problem it solves — a deal agreed on a call sits in negotiation forever, gets treated as signed when it is not, and nobody diarises the renewal it commits you to.
Route: /org/papers/documents/<document> · Permission: the lifecycle permissions for each move;
Act on approval steps (approve/reject/return). for approval decisions
1. What it is
"Done" is really four separate facts, each with its own gate:
| Fact | Gate | Blocks |
|---|---|---|
| Accepted | The counterparty accepts in the portal, or you record acceptance | Nothing — it records agreement |
| Approved | Requires approval / approval workflows | Finalizing, and any move while an approval is pending |
| Sealed | Finalize | Signing — nothing can be signed before it is sealed |
| In force | Requires signature | The move to executed or active, until a signature request is completed |
A document can be accepted and not approved, or sealed and not in force. The banner on the document names the gate it is waiting on.
2. Why you would use it
- "Agreed on the call" stops being the end of the process. Agreement becomes a recorded state with a timestamp and a party, not an email somebody may or may not keep.
- Nothing is in force by accident. The signature gate refuses the in-force move until everyone has signed, so nobody starts delivering against an unsigned contract.
- The commitments get looked after. Recording obligations and a record series at closing is what turns a signed PDF into renewal reminders and a retention date.
- Auditors get one trail. Acceptance, approval, sealing, each signature and the move into force sit in the same Activity.
3. Step by step
- Acceptance. When the counterparty clicks Accept this document?, the type's
accepttransition is used if one is defined from the current state. Otherwise the document goes to out_for_signature. The owner is notified that the counterparty accepted. - Finalize once terms are settled and any approval is through. See finalize and numbering.
- Send for signature — see sending for signature.
- Completion. When the last signer signs, the signed PDF with its completion certificate is built, and a fully executed event is recorded.
- The move into force. Automatic only if the type has an
all_signedtransition — see §5. - Close the work: obligations, record series, validity date (§6).
4. Field reference — the refusals you may meet
| Message | Gate | Fix |
|---|---|---|
| "this document is waiting on an approval decision (…). Approve, reject or return it from the Approvals Inbox — moving it from here would leave the approval open. An administrator can force the state with an override and a reason." | Pending approval | Decide it in the approvals inbox |
| "this document type requires signature, so it cannot move to "executed" unsigned — finalize it, send it for signature, and let every signer sign." | Requires signature | Complete a signature request first |
| "document "…" must be finalized before requesting signatures" | Sealing | Finalize first |
| "action "…" is not allowed from state "…"" | Lifecycle | The move does not exist from this state |
| "you submitted this document, so you cannot approve it yourself …" | Self-approval | Someone else approves |
5. The automatic move after signing — check your types
The refusal in §4 continues "(The signing flow marks it executed automatically once they have.)" That is
only true when the type's lifecycle has a transition with action all_signed from the document's
state at completion.
It is easy to switch on Requires signature and forget the all_signed transition. On such a type the request completes, the signed PDF is produced, and the document stays where it was.
Somebody has to make the move by hand after being told it would happen by itself.
Administrators: in the lifecycle editor, add a transition
with action all_signed from your out for signature state to your in-force state.
6. Worked example
Distribution Agreement DA-2026-012 between Gatiro and Kestrel Foods.
- Mon 10:02 — Kestrel's counsel clicks Accept. The type defines
acceptfrom negotiation to ready_to_finalize, so the document moves there. Maria is notified. - Mon 14:30 — The contract value is over the ₹50 lakh guardrail, so finalizing first needs CFO approval. The CFO approves from the inbox.
- Mon 15:05 — Maria finalizes. The document is numbered DA-2026-012 and sealed.
- Mon 15:10 — She sends a sequential signature request: Kestrel's COO, then Gatiro's CEO.
- Wed 09:40 — The CEO signs last. The signed PDF and certificate are built, and the type's
all_signedtransition moves the document to executed. - Wed 10:00 — Maria's closing checklist:
- Runs Extract key terms, which adds Minimum purchase review — quarterly and Renewal notice — 90 days before 31 Mar 2029 to the obligation register.
- Classifies the document into the Commercial contracts — 7 years record series.
- Confirms the validity date of 31 Mar 2029.
If the type had lacked all_signed, step 5 would have ended at completed with the document still out
for signature. Maria would then move it herself.
7. The admin contract
| What must be configured | Otherwise |
|---|---|
An accept transition from your negotiation state | Acceptance falls back to out_for_signature |
| Requires signature on types that must be signed | Documents can be marked in force unsigned |
An all_signed transition on those types | The move into force stays manual (§5) |
| Approval workflows on approval states | Decisions go to the unrouted section, where anyone with rights decides |
| A file plan mapping the type to a record series | No retention date is set at closing |
8. Downstream
- The
paper.fully_executedwebhook fires on completion, for integrations such as billing. - Obligations drive reminders and the expiring-documents list. Without them, auto-renewals pass unnoticed.
- A record series starts the retention clock and makes the document eligible for disposition review.
- The signed PDF's verification code shows the signed flag.
9. Don't confuse this with…
| Accepting a redline | Agrees to one change — see redlines and rounds |
| Finalizing | Seals and numbers. Acceptance is agreement |
| Signing | The formal act on the sealed copy — see the signing page |
10. Troubleshooting
| Symptom | Cause |
|---|---|
| Everyone signed, but the document is not executed | No all_signed transition on the type (§5) |
| The move to executed is refused | Requires signature, and no completed request exists |
| Accept moved the document somewhere unexpected | The type's accept transition target |
| Cannot move it from the document page | An approval is pending — decide it in the inbox |
| No renewal reminder ever arrived | No obligation was recorded at closing |
| Never appears in a retention queue | No record series |