Finalize and numbering
What this page is — the moment a document stops being a draft and becomes an issued instrument: numbered, sealed as a PDF with a verification code, and immutable.
What it is for — so there is exactly one version that was sent, signed and relied on, and anyone holding a copy can check it is genuine.
The problem it solves — several "final" copies circulate with no way to tell which was actually issued, or whether a copy has been altered.
Route: /org/papers/documents/<document> → Finalize · Permission:
Finalize (number + seal) a document..
1. What it is
Finalizing does four things in one step, after a confirmation:
- Allocates a document number from the type's numbering sequence.
- Renders and seals the PDF — template, values, letterhead, seal, watermark, a running footer carrying the number and verification code.
- Issues a verification code, unique, so anyone holding a copy can check it.
- Makes the content immutable.
Finalize is not the same as approval, signature or publishing:
| Step | Is | Blocks finalize? |
|---|---|---|
| Approval | A decision by a person | Yes, when the type requires approval |
| Finalize | The act of sealing | — |
| Signature | Agreement by the parties, collected on the sealed PDF | No — it cannot, because it happens afterwards |
| Publishing | Making it public in the library | No |
The type's Requires signature is enforced later, on the transition that declares the document in force — executed or active — not at finalize.
2. Why you would use it
Without a moment where a document is sealed, "which version did we send them?" has no answer — only a folder of PDFs with similar names.
- One authoritative artifact. Signing, distribution and share links all work on the sealed PDF, so every recipient has the same bytes.
- Verification defeats a doctored copy. The code on the footer resolves on the public verify page, and reports a revoked document as revoked.
- Integrity can be re-checked at any time. Verify integrity re-derives the stored hashes and signature chain and compares them with what was sealed.
- Numbering becomes real. Only finalized documents carry numbers, so a number is always an issued document.
3. How it spreads
| Finalizing unlocks… | See |
|---|---|
| Download PDF | §5 |
| Send for signature | Sending for signature |
| Email document and Create share link | Shared links |
| Publish to library | Public library |
| Redactions for outbound copies | Redaction suggestions |
| Public verification | Verifying a document |
| Retention, once classified | File plans and series |
4. Step by step
- Complete the fields and take the document through any required approval.
- Finalize → read the confirmation → confirm.
- The number appears in the header; the toast reads "Document finalized — PDF sealed".
- If the type requires signature, the toast adds that it still needs one — send it from the Signature card.
- Classify it into a record series if prompted.
5. Field reference
Refusals
| Refusal | Cause |
|---|---|
| document is under legal hold and cannot be finalized | A legal hold is active on the document |
| this document type requires approval before finalizing — route it through an approval-gated transition (Lifecycle tab) and get it approved first | Requires approval is on, and the document has not been approved |
| behavior_config.numbering_sequence_id "…" is not a valid UUID | The type's numbering setting is corrupt |
| The PDF engine is unavailable | The server cannot render PDFs — an operations problem |
Numbering
| Situation | Result |
|---|---|
| The type has a numbering sequence | The next number, e.g. AGR/2026/00042 |
| The type has no sequence | The document is sealed without a number — the list shows — |
| A sequence is added later | Only documents finalized from then on are numbered. Nothing is renumbered retrospectively |
An organisation that adds sequences after going live keeps every earlier sealed document permanently unnumbered. Numbering belongs in setup, before the first real document.
What a sealed document offers
| Action | Does |
|---|---|
| Download PDF | The latest sealed PDF. With an active redaction layer and no right to see through it, you get the redacted copy |
| Verify integrity | Re-derives hashes and the signature chain, and compares them with the seal |
| Publish to library | Puts the sealed PDF in the public library — the seal is its precondition |
| Redactions | Audience-tagged masks burned into outbound copies; the source is never altered |
| Amend ▾, Supersede, Revoke, Override | See Amend, renew, supersede |
The next-step hint
| Situation | Hint |
|---|---|
| Sealed, signature required | This document is finalized and sealed, but its type requires a signature — send it for signature from the Signature card. |
| Sealed, nothing further | This document is finalized and sealed — download the PDF from the artifacts below. |
Classify it, or retention never starts
A finalized document without a record series has no keep-until date and never appears in the retention, disposition or vital-records queues. The panel says so, with Classify beside it.
6. Worked example
A finance controller finalizes a vendor services agreement.
The type Services Agreement has Requires approval on, a numbering sequence AGR/{YYYY}/{#####}, and
Requires signature on.
- They press Finalize before the approval completes: this document type requires approval before finalizing…. They route it through Submit for approval; the CFO approves.
- Finalize → confirm. The header shows
AGR/2026/00042. The toast: "Document finalized — PDF sealed. It still needs a signature…". - The Stage badge in the list moves from Working draft to Finalized.
- They send it for signature. When both signers complete, the transition to
executedsucceeds — it would have been refused if they had tried before signing. - Classify → record series Vendor contracts — 8 years. A keep-until date appears.
Months later, Northwind forwards "the signed PDF" in a dispute. The controller enters the verification code from its footer on the verify page; it resolves, and Verify integrity on the document confirms the seal still matches.
7. The admin contract
| Must be true | Where | What breaks without it |
|---|---|---|
| The role holds Finalize (number + seal) a document. | Role editor | No Finalize button |
| A numbering sequence is set on the type | Behaviour settings, Numbering sequences | Documents seal without numbers, permanently |
| An approval workflow exists, if Requires approval is on | Lifecycle | Finalize is refused forever |
| Letterhead and seal are configured | Branding assets | The PDF is unbranded |
| The PDF engine is installed | Operations | Finalize fails |
| Record series exist | File plans | Retention never starts |
8. Downstream
| After finalize | Then |
|---|---|
| The content | Immutable. Fields, restores and attachments are locked |
| Changing it | Only through an amendment, renewal or addendum — new documents |
| The lifecycle state | A separate axis: a sealed document can still move through later states |
| The verification code | Public — it resolves for anyone holding it |
9. Don't confuse this with…
| Submitting for approval | A decision. Finalize is the seal |
| Sending for signature | Happens on the sealed copy, after this |
| The preview | A live render. The sealed PDF is fixed |
| Public library | Publishing is optional, and separate |
10. Troubleshooting
| Symptom | Cause |
|---|---|
| …requires approval before finalizing… | Get it approved through an approval-gated transition first |
| …under legal hold… | Release the hold, or leave it unsealed |
| Finalized with no number | The type has no numbering sequence — and it will not be renumbered later |
| Finalize is missing | Your role lacks Finalize (number + seal) a document., or a sealed artifact already exists |
The move to executed is refused | The type requires signature, and signing has not completed |
| The download is redacted | A redaction layer is active and you lack the see-through right |
| Never appears in a retention queue | No record series — Classify it |