August 6, 2026
Introduction
In document workflows, a signer is a person who signs, while signee is an uncommon word for that same person—a signer or signatory—not the person who merely receives a request. Use recipient for whoever receives the request, and verify separately whether a signer is a signatory or an authorized signatory.
That distinction matters because role labels drive instructions, routing, and review. Calling every recipient a signee incorrectly suggests that everyone who receives a document must sign it. Calling every signer an authorized signatory makes a different mistake: a signature does not, by itself, prove authority to act for another party.
Signer vs Signee vs Recipient: What Does Each Term Mean?
Signer and signee both identify a person who signs; recipient identifies the person who receives a request or copy. In document usage, The American Heritage Dictionary defines a signee as someone who has signed a document such as a contract or petition. It is not a separate pre-signing role, and it should not replace recipient in workflow instructions.
The five related terms answer different questions:
The safest editorial rule is simple: use signer for the signature task, recipient for delivery, signatory for the signing party, and authorized signatory only when authorization is known. Use signee only when explaining the word itself or preserving wording that appears in a source document.
Does Signee Mean the Person Receiving a Document?
No. Signee means a person who signs; recipient is the correct label for someone who receives a document or signature request. A recipient can be asked to sign, approve, review, or simply receive a copy, so receipt alone does not make that person a signer or signee.
Consider four hypothetical people in one agreement workflow:
These labels can overlap, but they are not stages that a person automatically moves through. A recipient who signs is both a recipient and a signer. The word signee could describe that signer, but it does not describe the earlier act of receiving the request. Signatory and authorized signatory depend on party status and verified authority, not delivery order.
How Should an E-Signature Workflow Label Each Person?
An e-signature workflow should label each person by the action expected from them, then record party status and authority separately. Clear role names make the request easier to understand and reduce the risk of treating a reviewer, copied recipient, or witness as a required signer.
Before sending, map each participant with five fields:
- Delivery role: Will this person receive the request, a notification, or only the completed copy?
- Required action: Must the person sign, approve, review, or take no action?
- Agreement party: Is the person or represented entity a party to the agreement?
- Signing capacity: Is the person signing for themselves or in a representative role?
- Authority status: If signing for someone else or an organization, what internal evidence confirms the permitted scope?
The output should be a pre-send role map such as this:
Do not label the finance reviewer or records mailbox as a signee: neither signs. For the person signing on behalf of Acme Co., the role map should preserve both the signature task and the representative-capacity note. A field labeled Its, Title, or Capacity records that role according to the document's instructions; it does not establish authority.
Is Every Signer a Signatory or Authorized Signatory?
No. Every signer performs a signature act, but not every signer is a party to the agreement or authorized to sign for someone else. A witness, acknowledging reviewer, or person signing a receipt may be a signer without being the agreement's signatory.
An authorized signatory adds a verified authority layer. The relevant evidence and scope depend on the organization and transaction, so a team should not infer authorization from a job title, email address, signature field, or completed signature alone. The terminology cannot replace the organization's approval process or legal review; signatory meaning, signing capacity, and signing authority remain separate questions.
How Can Nota Sign Teams Standardize Role Labels?
Nota Sign teams can standardize role labels by turning the pre-send map into a template-naming convention and review checkpoint. Name each role by its required action—for example, Customer · Signer, Finance · Approver, or Records · Completed Copy—and keep signatory capacity and authority verification in separate fields or internal notes appropriate to the team's process.
The concrete output is a template whose participant labels, instructions, and signature fields agree. A person who only reviews is not described as a signer; a person who only receives the completed record is not described as a signee; and an organizational signer is not called an authorized signatory until that authorization has been checked.
Author: Charlotte, Marketing Manager, Nota Sign
Category: Guides & Tips
Updated: August 5, 2026
Editorial status: Independent editorial review checks terminology, source alignment, and claim boundaries; no independent legal review is documented.
Methodology: This guide uses the cited American Heritage Dictionary definition for signee, distinguishes signer, signee, recipient, signatory, and authorized signatory, and tests those distinctions against an operational role map. All named people, companies, and workflow examples are hypothetical.
Standardize signer and recipient labels in Nota Sign before your next template is sent. Explore Nota Sign's electronic signature workflow.
