What does it mean to sign a contract electronically?

A contract is signed electronically when the parties express their intent by electronic means and that expression is linked to a digital document. This may involve a simple confirmation, an advanced electronic signature or a qualified electronic signature.

In everyday language, “digital signature” and “electronic signature” are often used interchangeably. In legal terms, electronic signature is the relevant umbrella term. A digital signature has a narrower technical meaning: it usually refers to a cryptographic method used to verify a document’s integrity and the origin of a signature.

Not every online contract requires a visible handwritten signature in a PDF. Clicking an unambiguous confirmation button, confirming by email or typing a name may constitute an electronic signature if the action is linked to the signer and clearly expresses their intention to accept the document.

Are electronically signed contracts valid?

Many contracts in Germany and other EU Member States are not subject to a specific statutory form. In principle, they can be concluded orally, by email or through an electronic signature workflow. Depending on the circumstances, this may include business purchase agreements, non-disclosure agreements and accepted quotations.

Under the eIDAS Regulation, an electronic signature cannot be denied legal effect or admissibility as evidence solely because it is electronic or does not meet the requirements for a qualified electronic signature. This does not mean that every type of electronic signature is suitable for every contract.

Before digitising a contractual process, the parties should therefore determine:

• Does the applicable law prescribe a particular form?
• Can that form be satisfied electronically?
• Is electronic form expressly excluded?
• Which law applies to a cross-border contract?
• What evidence may be needed if the transaction is later disputed?

Under German law, statutory written form can generally be replaced by electronic form unless legislation provides otherwise. Meeting electronic form normally requires a qualified electronic signature. For certain legal transactions, however, electronic form is excluded. A well-known example is the termination of an employment relationship. Special rules may also apply to guarantees, fixed-term employment agreements and consumer transactions.

The correct assessment depends on the contract, the parties and the applicable jurisdiction. If the position is unclear, it should be reviewed by a qualified legal professional; a signing service does not replace that assessment.

The three eIDAS signature levels

The eIDAS Regulation distinguishes between three signature levels that are relevant in practice.

Simple electronic signature (SES)

A simple electronic signature is not tied to one specific technology. It may take the form of:

• a name typed below a document,
• an inserted image of a handwritten signature,
• consent given through a button,
• a signature using an email link and confirmation.

An SES is often suitable for transactions without statutory form requirements and with a manageable risk profile. Its evidential value depends heavily on how reliably the workflow records the signer’s identity, consent, document version and actions.

Advanced electronic signature (AES)

Under eIDAS, 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.

Cryptographic methods, stronger authentication and tamper-evident records may be used to meet these requirements. An AES can be appropriate where stronger evidence or security is needed, but statutory written form does not require a QES.

Qualified electronic signature (QES)

A QES is an advanced electronic signature based on a qualified certificate and created using a qualified signature creation device. The certificate is issued by a qualified trust service provider after the individual has been reliably identified.

Within the EU, a QES generally has the equivalent legal effect of a handwritten signature. It can also be created as a remote signature, with the qualified signature creation device operated securely on behalf of the signer by a trust service provider.

Which signature level should be used?

The choice should not be based on contract value alone. Relevant factors include statutory form, liability exposure, identity requirements and the quality of evidence required.

Practical examples include:

• Approval of a standard quotation: An SES may be sufficient if no special form applies and the process is clearly documented.
• Non-disclosure agreement: Depending on the risk profile, an SES or AES may be suitable. Stronger authentication may be appropriate for particularly sensitive projects.
• Fixed-term employment agreement: Specific statutory form requirements may apply. Before using an electronic process, the parties should confirm whether electronic form is permitted and what conditions must be met.
• Termination of employment: German law excludes electronic form. A QES does not replace the required paper-based declaration in this case.
• Contract subject to statutory written form: A QES will generally be required if electronic form is permitted and has not been excluded by law.

Organisations should not make this assessment from scratch for every document. An internal matrix can map contract types to applicable law, formal requirements, signature levels, approval rules and retention periods.

How the electronic signing process works

A typical electronic signature workflow consists of six steps:

1. Check formal requirements: Determine whether the contract is form-free or requires a specific signature level.
2. Prepare the final document: Include all schedules, prices, terms and parties. Any substantive change during the process should create a new version.
3. Define signers and signing order: In addition to names and email addresses, verify signing authority and decide whether signatures must be collected in a particular sequence.
4. Authenticate the signers: Depending on risk, the process may use an email link, one-time code, account login or formal identity verification.
5. Capture consent and signature: The signer is given access to the document, confirms their intent and completes the required signature action.
6. Archive the document and evidence: Each party receives the completed version. Relevant certificate, timestamp and workflow evidence should also be retained.

For example, a supplier receives a link to a purchasing agreement. After entering a one-time code sent by SMS, the supplier opens the complete PDF, confirms their consent and signs it. An authorised representative of the customer then signs the same document. Both parties receive the completed agreement and the associated process record.

What evidence should be retained?

A visible image of a handwritten signature says little about who actually signed the document. Technical and organisational records are more important when the process needs to be reconstructed.

An audit trail may record:

• which document version was presented,
• when invitations, views and signatures occurred,
• which authentication method was used,
• which individuals and roles participated,
• whether the document changed after signing,
• which certificates and timestamps were used.

An audit trail is not automatically an electronic signature and does not replace a QES required by law. It can, however, support the evidential record. It should be exportable in a comprehensible format and remain reliably linked to the relevant contract.

Common signature formats for PDF files allow recipients to check whether a document has been modified after signing. Suitable timestamps and validation data may be relevant for long retention periods because certificates can expire or be revoked after the signature was created.

A verification process should also distinguish between the validity of a certificate at the time of signing and its status at the time of a later review. Merely opening a file and seeing a graphical signature is not a sufficient validation method.

Data protection and security

Electronic signature workflows involve the processing of personal data. This may include names, business contact details, authentication information, event logs and contract contents. Identity verification can involve additional and potentially sensitive information.

Under the GDPR, controllers should address at least the following questions:

• Which data is needed and for what purpose?
• What is the legal basis for processing?
• Does the signing provider act as a processor, and is an appropriate agreement in place?
• Which subprocessors and international data transfers are involved?
• How long are documents, logs and identity data retained?
• Which technical and organisational measures protect the data?
• How are deletion, access and other data subject rights handled?

Data minimisation also applies to audit trails. The fact that a system can collect a particular attribute does not mean that it should. Logging should be limited to data necessary for security, evidence and reliable operation.

A sound security framework should also cover role-based access, multi-factor authentication for administrative accounts, encryption in transit and at rest, traceable changes to permissions, and controlled backups and exports.

The contract itself and the workflow metadata may require different retention rules. Deleting an envelope from an active signing platform does not necessarily remove statutory or contractual retention obligations for the completed agreement. Conversely, a general need to retain the contract does not justify keeping every authentication artefact indefinitely.

Integration into contract workflows

Electronic signing is most reliable when it is integrated into the wider contract process rather than treated as an isolated final step. The source of the document, approvals, signing authority and final storage location should be defined in advance.

A structured workflow can include:

• generation of the contract from approved templates,
• internal legal or commercial approval,
• automatic selection of the required signature level,
• sequential or parallel signing,
• reminders and expiry rules,
• transfer of the completed document to a contract management system,
• recording of renewal and termination dates.

Where an API is used, the organisation should prevent document IDs, signer details and status messages from being assigned to the wrong transaction. Error handling is also important: an expired invitation, rejected signature or failed identity check should produce a defined result rather than leave the contract in an unclear state.

Common mistakes to avoid

Several problems in digital contract processes can be prevented through clear rules:

• An SES is used even though statutory written form requires a QES.
• A signature image is inserted without reliable evidence of identity and consent.
• The document is modified after one party signs and is not signed again.
• Schedules are provided only through changeable links and are not clearly incorporated into the signed file.
• Signers are invited without checking their authority to represent the organisation.
• Only the PDF is retained, while the relevant process evidence is discarded.
• Contract and identity data remain in the signing platform without a defined retention period.
• A successful technical signature check is treated as proof that all contractual and legal requirements were satisfied.

A robust process therefore combines a review of formal requirements, identity and authority checks, document integrity, data protection and controlled archiving. An electronic signature is not merely an image at the end of a PDF; it is a documented process extending from document preparation to long-term retention.