Indian offers need stamping, not just a signature box

A US signature platform does one thing extremely well: it captures an authenticated signature on a PDF and produces an audit certificate. That is sufficient where the only requirement is evidence of assent. Many Indian commercial documents carry a second requirement that has nothing to do with signatures at all, which is stamp duty payable to a state government, evidenced on stamp paper or through electronic stamping.

Procuring stamp paper of the correct value, in the correct state, in the name of the correct party, is a workflow a US signature vendor does not offer and is not set up to offer. So an Indian agency using one ends up with a signed document and an unstamped one, and discovers the gap at the point where the document has to be relied on.

Aadhaar-based eSign authenticates the signatory through a one-time password sent against their own identity record, and the resulting signature is affixed by a licensed authority rather than drawn onto a page. Operationally, the candidate or client contact experiences a short verification step instead of a click-to-sign box, and the result is a document with an embedded digital signature.

For an Indian offer letter that difference is practical rather than academic. Larger Indian employers and their onboarding teams frequently expect execution in that form, and a scanned image of a signature does not satisfy the same expectation. The integration would route the document; the signing method and its acceptance remain matters between you, your counsel and the counterparty.

Two documents matter most. The client agreement, which sets the fee percentage and the replacement terms and which is worth having properly executed before a submittal rather than after a dispute. And the candidate offer, where the gap between verbal acceptance and executed paperwork is the window in which an Indian technology candidate is most likely to be counter-offered.

The integration would send from the placement or client record, track execution state, and file the executed and stamped document back against that record. Nothing about the legal effect of the document changes because a CRM sent it; what changes is that somebody can see it has not come back.

That visibility is the whole of the practical benefit here. Execution is a provider's job and a lawyer's judgement. Noticing on day four that an offer has not been executed is recruitment software's job, and at the moment it is done by whoever happens to remember.

Generate the offer letter or client agreement in Surhires, then execute it through your own Leegality account with whatever stamping and signing method your counsel has advised for that document. When it returns, attach the executed copy to the client, candidate or placement record and record the execution date and the signing contact.

If a document was stamped, note the stamp value and the state on the record as well. It takes seconds and it is the detail nobody can reconstruct later. The product supports document capture and expiry reminders against the record; the execution itself is a workflow you run, not a certification we hold.

Surhires will not advise on stamp duty, will not determine the correct stamp value, will not confirm that a document is enforceable and will not represent that any signing method is legally sufficient for your purpose. Those are questions for your counsel and for the provider that executes the document, and recruitment software answering them would be doing something worse than merely being wrong.

The product supports notice and consent records against candidate profiles and portability export under the DPDP Act, and you remain the entity responsible for the candidate data you hold, including executed documents. Primary data residency is on AWS us-east-1 with encrypted backups, which is worth knowing before an Indian enterprise client asks.