Almost every document process ends with a signature, and almost every document process buys the signature separately. The extraction platform produces structured data, a template engine or a person produces the contract, and then somebody exports a PDF, uploads it to a signature product, waits, downloads the signed file and puts it back.
That export step is where the case leaves the system that understands it. The signature product knows nothing about the extracted fields, the confidence bands, the review that happened or the case it belongs to. It knows about a PDF and some email addresses. Everything the pipeline learned is dropped at the boundary and reassembled by hand on the way back.
The alternative is to treat signature as a phase of the same run. That is a smaller change than it sounds, and it moves several problems that are usually operational into the design.
What the envelope has to carry
The unit of a signature process is not a document, it is an envelope: the documents to be signed, the ordered set of people who must sign them, the authentication each of those people faces, and the events that accumulate as it progresses.
Modelled as a workflow phase rather than an external product, the envelope inherits context that would otherwise have to be re-entered:
- The case identity — the envelope belongs to the run, so the signed artifact returns to the case without a reconciliation step.
- Signer identity from the flow — the people who must sign are frequently the people whose identity documents the flow already collected and verified.
- The document's provenance — which template version produced it, from which extracted values, reviewed by whom.
- The routing decision — whether this document needs one signer or four, and at what assurance level, can be a conditional on an extracted value rather than a manual choice.
That last point is the one that changes daily work. Contract value above a threshold routes to a stricter signing path; below it, to a lighter one. As a workflow condition that rule is enforced and measurable. As a human instruction it is a policy document that someone follows most of the time.
Signer authentication is the actual product
The drawn signature image is the least important part of an electronic signature. What gives the artifact weight is the evidence that a specific person, authenticated in a specific way, expressed intent at a specific moment.
Authentication of the signer is therefore a spectrum, not a checkbox, and the choice is a risk decision:
| Binding to the signer | What it actually evidences | Reasonable for |
|---|---|---|
| Link possession alone | Someone with access to the delivery channel acted | Low-stakes internal acknowledgements |
| One-time code to a verified channel | Control of a phone number or mailbox at signing time | Routine commercial documents |
| Identity document plus liveness | A present person matching a verified document | Onboarding, credit, first-time counterparties |
| Certificate under sole control | A key the signer alone can use | Documents where repudiation is the live risk |
Regulatory frameworks name tiers along roughly this axis — simple, advanced and qualified in the European scheme, with comparable structures elsewhere. The tier names differ by jurisdiction; the underlying question does not. It is always: how strongly is this signature bound to a person, who controls the signing means, and is there an independent timestamp.
Buying one tier for everything is the common mistake in both directions. Uniformly light means the documents that actually get disputed are the weakest ones you hold. Uniformly heavy means paying certificate-grade cost for internal acknowledgements, and pushing counterparties through identity checks they will abandon.
Choose the level per document class, inside the flow
Because the flow already knows what the document is — it classified the inputs, extracted the values and rendered the output from a known template — the assurance level can be a property of the document class rather than of the contract with the signature vendor.
That reframing has a useful side effect: it forces the levels to be written down. A table mapping document class to required assurance, reviewed by whoever owns legal risk, is a short artifact that most organisations do not have. Producing it usually surfaces at least one class that everyone assumed was covered and is not.
Record the level that was actually applied on the envelope, not just the level that was requested. Those diverge when a fallback path fires — a signer who could not complete a stronger check and was let through on a weaker one. A signature that silently downgraded is worse than one that failed, because it looks complete.
The sealed artifact and the timestamp
When signing finishes, the output is a document that should be able to demonstrate its own integrity without your database being available. Two mechanisms do that work.
The seal binds the signature data into the PDF so that later modification is detectable. Without it, the signed document is just a PDF with an image on it, and the evidence lives entirely in your system — which is precisely the party whose word is in question if it is ever disputed.
The timestamp answers when, and the reason to source it from an independent authority is that your own clock is not evidence against you. A timestamp token from a third party is what separates “our records say March” from something a counterparty cannot simply dispute.
Both belong in the artifact, and the event log belongs in the case. Envelope created, opened, authenticated, signed, sealed, delivered — each with an actor and a time. That log is the part auditors read, and it is much easier to produce when the envelope never left the system that owns the audit trail.
API-first, because signature is rarely the last step
A signature product designed around its own web interface makes the human path excellent and the machine path an afterthought. That ordering is backwards for a document pipeline, where the signature is usually followed by something: a record written to a core system, a webhook to a partner, an archival copy, a downstream approval.
The parts that need to be first-class for machines:
- Envelope creation from data — documents, signers and levels submitted as a request, not assembled by clicking.
- Signed webhooks on state change — with retry and a delivery record, so the caller is not polling. Our webhook documentation covers the signature and retry contract.
- Retrieval of the sealed artifact and its evidence — addressable by case, not only by envelope.
- Idempotent submission — a retried envelope creation must not send a second copy to the signer.
That last one is the operational scar tissue. Duplicate envelopes are the single most visible failure a signature integration can have, because the counterparty sees them.
What integration actually costs
The argument for keeping signature inside the flow is usually made on user experience. The stronger argument is arithmetic. Every export boundary in a document process adds a reconciliation, a failure mode and a place where state can diverge. The signature boundary adds all three at the most sensitive moment, when a legally meaningful artifact is being produced.
Removing it does not make signature simpler. Envelope state, signer authentication, sealing and timestamping are still hard, and pretending otherwise is how teams end up with a signature step that works until the first dispute. What it removes is the class of failure where the pipeline and the signature product disagree about what happened — which is the failure that costs the most to explain.
If the flow already collected the documents, classified them, extracted the values, routed the exceptions and generated the output, the signature is the last phase of the same run. Building it anywhere else means reconstructing the case from a PDF and an email address.