Getting a contract signed online requires a defined process. Uploading a PDF and sending a link is not sufficient on its own. Before the document is distributed, the organisation needs to determine the applicable form requirements, how signers will be identified and what evidence must remain available after completion.

Technology, legal requirements and internal procedures are closely connected. A structured process reduces questions, prevents the wrong document version from being used and makes the completed transaction easier to verify later.

1. Check form requirements before sending

Not every contract requires the same type of signature. Many contracts can generally be concluded without a prescribed form. Specific declarations may nevertheless be subject to statutory, contractual or internal requirements.

Before selecting the technical workflow, answer the following questions:

• Is a particular form required for this type of contract?
• Does an existing agreement contain a written-form clause?
• Are there sector-specific rules or internal approval policies?
• How reliably must the signer's identity be established?
• Is notarisation or another additional formality required?

Under the eIDAS Regulation, an electronic signature may not be denied legal effect or admissibility as evidence solely because it is electronic or does not meet the requirements for qualified electronic signatures. However, only a qualified electronic signature, or QES, expressly has the equivalent legal effect of a handwritten signature throughout the EU.

If the required form is unclear, the individual transaction should be assessed by an appropriately qualified professional. A signing platform cannot replace that assessment.

2. Select the appropriate signature level

eIDAS distinguishes three levels of electronic signature:

• Simple electronic signature: This broad category can include a typed name, an uploaded image of a signature or confirmation by clicking a button. Its evidential value depends heavily on the surrounding process.
• Advanced electronic signature: An AES must be uniquely linked to the signer, be capable of identifying the signer, be created under the signer's control and make subsequent changes to the signed data detectable.
• Qualified electronic signature: A QES is an advanced signature based on a qualified certificate and created using a qualified signature creation device. It normally involves identity verification through a qualified trust service provider.

The choice should not be based on contract value alone. Relevant considerations include statutory form, the likelihood of an identity dispute, the sensitivity of the transaction and the required strength of evidence.

For example, a routine commercial proposal may use a traceable simple or advanced signing process if no stricter form applies. A high-risk framework agreement may justify stronger authentication even if QES is not legally mandatory. Where German statutory written form is to be replaced electronically, a QES is generally relevant, subject to exceptions and the rules governing the particular declaration.

3. Prepare a signature-ready document

A binding final version should be available before upload. Editorial changes made after a signing process has started create additional versions and can invalidate signatures already collected for the previous document.

A practical document review includes the following steps:

1. Check names, legal entity details and addresses.
2. Include all schedules, specifications and referenced attachments.
3. Verify prices, terms, notice periods and dates.
4. Remove unnecessary comments, hidden content and metadata.
5. Convert the document into a stable PDF.
6. Position signature, date and text fields unambiguously.

If several documents are involved, signers must be able to see exactly what they are signing. Attachments can be combined into one PDF or supplied as part of a connected signing package. In either case, the relationship between the signature and the documents should remain verifiable.

A visible signature image is not the same as a cryptographic signature. The image mainly provides a visual representation. Integrity evidence, certificate details and process records must be preserved separately within or alongside the signed file.

4. Define signers, roles and signing order

The next step is to configure the participants and the sequence. Common arrangements include:

• all parties signing in parallel,
• one party signing only after another,
• internal approval before external distribution,
• several representatives signing for one organisation,
• a recipient receiving the document for information only.

For sequential workflows, define what happens if a signer rejects the document, the invitation expires or the responsible person changes. Authority to represent an organisation also requires attention. The ability to open a signing link does not, by itself, prove that a person is authorised to bind a company.

Email addresses should be entered and checked carefully. Depending on the risk level, the process can add SMS one-time codes, login through a customer account, identity-document checks or a QES identification procedure. More friction is not automatically better: the measure should be proportionate to the transaction and accessible to the intended signers.

5. Make the invitation and signing process clear

The invitation should identify the sender, explain the purpose, name the relevant document and provide a contact for questions. Vague automated messages increase the chance that recipients will mistake the invitation for phishing or abandon the process.

A typical signing journey is:

1. The recipient opens a time-limited link.
2. Additional authentication takes place if configured.
3. The complete document is available for review.
4. Required fields are completed and necessary confirmations are given.
5. The signature is created and technically associated with the document.
6. All parties receive the completed version or secure access to it.

Reminders can support completion but should be sent at reasonable intervals. Expired or revoked links must not continue to provide access. If the document needs to be corrected, editing an active signing version is unsafe. The clearer approach is to cancel that transaction and issue a distinctly labelled new version.

The interface should also allow signers to download or otherwise retain the terms they accepted. Consent to use an electronic process should not be hidden in unrelated wording, particularly where applicable law requires specific information or agreement.

6. Preserve the audit trail and time evidence

In addition to the signed PDF, the audit trail is a central part of the transaction record. It may document events such as sending, access, authentication, consent, signature and completion, together with timestamps. The exact information collected depends on the provider and its configuration.

An audit trail does not automatically prove every asserted fact. It can, however, provide a coherent record of the sequence of events. A distinction should also be made between ordinary system timestamps and qualified electronic timestamps. Qualified timestamps meet eIDAS requirements and benefit from specific legal presumptions concerning the accuracy of the time and the integrity of the linked data.

The unchanged original PDF, relevant certificate and validation information, and the associated audit trail should be retained together. Printing and rescanning the contract does not preserve the full technical signature information.

When reviewing a completed signature, check more than the visible mark. A PDF validator can indicate whether the document was changed after signing, whether the certificate was valid at the relevant time and whether the trust chain can be established. The result depends on the available validation data and the software's trust settings.

7. Address GDPR and access controls

Signing transactions process personal data, potentially including names, email addresses, IP addresses, authentication data and contract contents. Organisations should determine which data is needed for each purpose and how long it will be retained.

Relevant review points include:

• the allocation of controller and processor roles,
• a data processing agreement where required,
• subprocessors and possible international data transfers,
• encryption in transit and at rest,
• role-based permissions and multi-factor authentication,
• retention and deletion periods,
• logging of administrative access,
• procedures for data subject requests.

Data minimisation also applies to the audit trail. The fact that technical data can be collected does not mean it should be retained indefinitely. Statutory retention duties and the need to preserve evidence must be balanced against deletion obligations and internal privacy policies.

Access should follow the need-to-know principle. For example, a sales employee may need to see the status of a proposal without receiving access to identity documents used in a separate verification procedure. Permissions for templates, completed contracts and system administration should therefore be assigned separately where possible.

8. Review and archive the completed contract

The process should not simply be marked as finished after the final signature. A completion check should confirm that all required participants signed, the signatures validate as expected and the completed version matches the internally approved document.

The signed original should then be stored in an access-controlled contract archive. Useful index data may include the parties, contract type, completion date, term, notice deadline and responsible business unit. The archive should avoid altering the signed file, while still allowing authorised users to retrieve it together with its evidence record.

For long retention periods, it may be necessary to preserve validation data or renew signatures and time evidence. Certificate expiry does not necessarily mean that a signature was invalid when created, but missing historical validation information can make later verification more difficult. Long-term validation requirements should therefore be considered when choosing the PDF format, signature profile and service provider.

A reliable online contract process does not end with a visible signature. It combines an appropriate signature level with controlled document versions, clear signer authentication, a comprehensible audit trail, proportionate privacy safeguards and verifiable archiving.