Signatory matrix
What this page is — the rules for who inside your organisation may sign which documents, up to what value, checked the moment a signature request is created.
What it is for — so signing authority is enforced by the system at send time, rather than remembered by the person sending.
The problem it solves — anyone who can send a signature request can name a signer who has no authority to sign.
Route: /org/settings?tab=papers → Signatory matrix · Permission: Manage the authorized-signatory matrix..
1. What it is
A rule grants one member authority:
| Part | Blank means |
|---|---|
| Authorized signatory | — (required; an organisation member) |
| Document family | Any family |
| Document type | Any type |
| Max value | No cap |
| Currency | Informational — see below |
The matrix is opt-in. The moment the first rule exists, every internal signer on every new signature request must be covered by a rule — including all the people you have not added yet. Add every signing officer in one sitting.
How a send is judged, for each signer and each document in the request:
| Step | Rule |
|---|---|
| Who is internal | A signer is internal if their user or their email belongs to an organisation member |
| External signers | Not checked. The request carries a notice: "Name <email> is not a member of this organization, so the signatory matrix does not apply to them — they sign as an external counterparty." |
| The value | The first of the document's total, amount, contract_value, total_amount, grand_total, value. No monetary value is judged as 0 |
| A match | Any rule for that member whose family, type and max value all cover the document |
| No match | The request is refused |
Currency is not compared. A rule of 1,000,000 INR and a document of 900,000 USD pass, because only the numbers are compared.
2. Why you would use it
- Authority limits stop living in a PDF nobody reads. The person above their limit is told before the request exists.
- The refusal names the gap — which signer, which document, which family, what value.
- An internal signer cannot slip through by email. A member added by address is still checked.
- Members-only mode closes the personal-email gap. An operator can require every signer to be a member.
3. Step by step
- + Rule → pick the member.
- Optionally a family, a type, a max value and currency.
- Save. Repeat for every signing officer before the first send.
- To change a rule, delete it and add a new one — rules cannot be edited.
4. Field reference
| Field | Rules | Refusal |
|---|---|---|
| Authorized signatory | An organisation member | — |
| Document family | Blank or one of eleven | type_family must be empty (any family) or one of: … |
| Document type | Blank or a type | — |
| Max value | Blank = no cap; compared with >= | — |
| Currency | Stored, not compared | — |
The refusal at send time:
Priya Nair is not an authorized signatory for "MSA — Northwind" (family agreement, value 2500000.00). Check the signatory matrix in Organization Settings → Papers.
With no monetary field the message says no monetary value on this document.
Members-only mode. System Config papers.signatory_matrix_members_only = true refuses non-member signers
too, adding "This organization requires every signer to be an authorized member
(papers.signatory_matrix_members_only)."
Copying a type to another project copies the type-specific matrix rules with it.
5. Worked example
A CFO sets authority limits.
| Signatory | Family | Type | Max value |
|---|---|---|---|
| CEO | (any) | (any) | (no cap) |
| CFO | Agreement | (any) | 5,000,000 |
| Head of Procurement | Transactional | Purchase Order | 500,000 |
| Head of Procurement | Agreement | NDA | (no cap) |
A procurement analyst sends a 750,000 purchase order for the Head of Procurement's signature. Refused — value 750000.00 exceeds the 500,000 rule. They route it to the CFO instead; also refused, because the CFO's rule covers Agreement, not Transactional. The CEO signs.
An NDA with no value field goes to the Head of Procurement: judged as 0, covered, sent.
A supplier signer's email is not a member: the request goes out with the external-counterparty notice.
6. The admin contract
| Must be true | Where | What breaks without it |
|---|---|---|
| Every internal signer has a rule before the first rule exists | This screen | Sends are refused organisation-wide |
| Documents carry a monetary field for value limits | Fields | Everything is judged as 0 and passes value caps |
| Signers use their organisation email | Your process | A colleague on a personal address is treated as external |
papers.signatory_matrix_members_only is set deliberately | System Config | External signers are either always or never allowed |
7. Downstream
| When you… | Then |
|---|---|
| Add the first rule | Enforcement starts for all new signature requests |
| Delete the last rule | Enforcement stops |
| Delete a rule | That member's sends in its scope are refused from now on |
Requests already sent are not re-judged.
8. Don't confuse this with…
| Approval workflows | Who approves internally. This decides who may sign |
| Sending for signature | Where the check happens |
| Signature permissions | Who may operate the feature. This decides whose signature is authorised |
9. Troubleshooting
| Symptom | Cause |
|---|---|
| Everyone is suddenly refused | The first rule was added |
| A rule cannot be edited | By design — delete and re-add |
| A cap was ignored | The document has no monetary field, so it was judged as 0 |
| A USD document passed an INR cap | Currency is not compared |
| A colleague was not checked | They were added under a non-member email |
| External signers are refused | papers.signatory_matrix_members_only is on |