Qualified electronic signature in business applications: how to integrate it and what legal effect it has

How to integrate a qualified electronic signature into a DMS, ERP or business portal: eIDAS, Romania’s Law 214/2024, QTSP, PAdES, validation, timestamping, workflow and legal effect.

Legal disclaimer. This article is for informational purposes only and does not constitute legal advice. For specific situations, consult a qualified legal professional.

Digitising a business process is not complete if the document ends up being printed only so it can receive a signature.

The contract is generated electronically. The request moves through a digital workflow. The invoice, offer, minutes or decision are stored in a Document Management System. The manager approves the document from a laptop or phone.

Then someone says: “It needs to be printed for signature.”

At that moment, almost all the advantages of the digital process are lost.

A qualified electronic signature solves exactly this break between the digital document and the legal act. Integrated correctly into a business application, it allows the entire cycle — creation, review, approval, signing, transmission and archiving — to remain electronic.

But integrating a qualified signature means more than adding a “Sign” button.

You need to understand the differences between signature types, the role of the trust service provider, certificate validation, document format, timestamping, archiving and, above all, the legal effect of the result.

Why electronic signature becomes a business function, not only a legal one

In the past, many organisations saw electronic signature mainly as a tool for dealing with tax authorities or filing declarations.

Today the situation is different.

Companies can use electronic signatures in supplier contracts, employee relations, internal document approval, procurement, commercial processes, technical documentation or management flows.

In a DMS, ERP, CRM, HRM or an application built specifically for an organisation, signing can simply become a workflow step:

Document created → reviewed → approved → signed → sent → archived.

The user should no longer need to download the document, open it in a separate application, sign it and then upload it again.

Signing must be part of the application.

That is the difference between “we use electronic signature” and “we have an end-to-end digital process”.

What is a qualified electronic signature, really?

In the European Union, the legal basis is the eIDAS Regulation — Regulation (EU) No 910/2014 — later amended by Regulation (EU) 2024/1183 on the European Digital Identity framework.

The regulation distinguishes between electronic signature, advanced electronic signature and qualified electronic signature.

The difference is not purely commercial.

For a signature to be qualified, specific technical and legal requirements must be met, including a qualified certificate and a qualified signature creation device.

The most important legal effect is set directly by Article 25 of eIDAS:

a qualified electronic signature has the equivalent legal effect of a handwritten signature.

In addition, a qualified signature based on a qualified certificate issued in one Member State must be recognised as a qualified electronic signature in the other EU Member States as well.

This cross-border recognition is one of the greatest advantages for European companies. A contract no longer needs to be thought of strictly within the digital infrastructure of a single country.

What Romanian legislation says

In Romania, the framework was substantially updated by Law No. 214/2024 on the use of electronic signatures, timestamps and the provision of trust services.

The law explicitly confirms that an electronic document signed with a qualified electronic signature is assimilated, in terms of its conditions and effects, to a private deed under handwritten signature, and that a qualified electronic signature produces the same legal effects as a handwritten signature.

Romanian legislation goes further and also regulates situations in which certain advanced electronic signatures or, under specific conditions, simple signatures may produce certain legal effects.

For a business application, however, a qualified signature offers the clearest legal position when the objective is equivalence with a handwritten signature.

There is an important limit, though.

If the law requires authentic form for a particular act — for example notarisation — simply applying a qualified electronic signature does not automatically replace the authentication procedure. Law No. 214/2024 expressly states that where an authentic instrument is required, the special authentication rules apply.

Therefore: a qualified signature is equivalent to a handwritten signature, not to every additional legal formality that may be required for a particular act.

Who can issue a qualified signature?

This is where the notion of a Qualified Trust Service Provider — QTSP appears.

A company that develops an ERP or DMS cannot simply declare that its own technology produces qualified signatures.

Qualified service status is tied to the eIDAS regime and specific supervision.

EU and EEA states publish Trusted Lists of qualified providers and services. The European Commission provides a common browser through which these can be checked.

It is very important that the lists have constitutive effect: for a service to benefit from eIDAS qualified status, it must appear on the corresponding trusted list.

That is why, when you integrate a qualified signature into a software product, the provider must not be chosen only by commercial page or price. You must verify exactly the qualified service offered.

What an integration architecture looks like

A business application should not, under normal circumstances, manage the user’s private key itself.

The application’s role is to orchestrate the process.

The architecture can be imagined as follows:

Business application → signing service → QTSP → user confirmation → signing → signed document → validation → archiving

Take an example. A manager needs to sign a contract.

• The document is prepared in the DMS.
• The user clicks “Sign”.
• The application creates the signing transaction and communicates with the qualified provider’s infrastructure.
• The user is identified and authorises the operation according to the provider’s mechanism.
• The signature is created using the qualified infrastructure.
• The signed document is returned to the application.
• The application validates the result and stores the signed document together with the relevant audit information.

For the user, the experience should be simple. Behind it, however, there is a serious cryptographic and legal infrastructure.

Physical token or remote signature?

Early electronic signature implementations often relied on USB tokens or smart cards.

These can work well in certain scenarios, but they create problems for web applications: drivers must be installed, the browser must communicate with the device, the user must have the physical token, and the experience on a phone is difficult.

For modern business applications, remote qualified signature is much more interesting.

The signing key can be managed in the qualified infrastructure, and the user authorises the operation through the mechanism set by the provider.

The new European digital identity framework also introduced a qualified trust service for managing remote qualified signature and seal creation devices.

From the perspective of a SaaS or DMS application, this enables a much better UX. The user can sign without physically connecting a device to the computer.

PDF and the PAdES standard

For business documents, PDF is probably the most common format used for signing.

This is where PAdES — PDF Advanced Electronic Signatures comes in.

There are also other important families of standards:

• PAdES for PDF;
• XAdES for XML;
• CAdES for CMS-based signatures;
• ASiC for electronic containers that can group data and signatures.

The European Commission develops the open-source Digital Signature Service — DSS library, intended for building and validating signature solutions and supporting PAdES, XAdES, CAdES and ASiC.

For a typical business DMS, PAdES is very attractive because the signature remains embedded in the PDF. The document can be downloaded, sent or archived as a single file.

Do not modify the document after signing

A digital signature protects, among other things, document integrity.

For that reason, after the signature is applied, the application must treat the signed document as a final object.

If the document is later modified, even apparently insignificantly, signature validation may indicate that the document was changed after signing.

From a DMS architecture perspective, it is healthier to keep:

• the version that was sent for signing
• the resulting signed document

as controlled elements linked through audit.

If the document must be corrected, a new version is created and the signing process is restarted. We do not modify the signed original.

The visible signature is not the legal signature

Another frequent confusion is the graphic signature displayed on the PDF.

The application may place a rectangle on the document saying: “Electronically signed by Ion Popescu — Date…”. Even an image of a handwritten signature may appear.

But that is only the visual representation.

The cryptographic and legal value sits in the digital signature structure, certificate, signed data and validation mechanisms.

A document can have a perfectly valid electronic signature without displaying a drawn “signature” on the page. And conversely: an image of a scanned signature does not automatically turn the document into a qualified electronically signed document.

Validation is as important as signing

A mature application must not only be able to create signatures. It must also be able to validate them.

When it receives a signed PDF from outside, the system must at least be able to determine whether the cryptographic signature is intact and evaluate the certificate and relevant trust information.

In the European ecosystem, Trusted Lists are fundamental for validating the status of qualified services. The Commission emphasises their role precisely for interoperability and the validation of signatures and seals.

For a DMS we can go even further. When a signed document is uploaded, the system could automatically display:

• Valid signature
• Type: qualified electronic signature
• Signer: Ion Popescu
• Signing date: 08.10.2026
• The document was not modified after signing
• certificate validation information

This turns the DMS into a document control system, not merely a place where files are stored.

Timestamping

In many processes it matters not only who signed, but also when.

This is where the electronic timestamp comes in.

A qualified timestamp provides, under eIDAS, specific presumptions regarding the accuracy of the indicated date and time and the integrity of the data to which they are linked.

In an important workflow, the combination can be:

document + qualified signature + timestamp + appropriate archiving.

This is particularly relevant for long-term contracts, regulated documents and processes where the exact moment of the operation must later be demonstrated.

Signature versus electronic seal

When designing a business application, the difference between an electronic signature and an electronic seal must also be understood.

An electronic signature is linked to a natural person. An electronic seal is intended for legal persons and is used mainly to guarantee the origin and integrity of data.

The European Commission describes the electronic seal as the functional equivalent of an organisation’s stamp, while the signature expresses the action of the natural person who signs.

In a well-designed system we can have both. The manager signs a contract. The company system can automatically seal certain generated documents.

They are not the same thing and must not be treated in the interface as the same mechanism.

Integration into a DMS

In a Document Management System, an electronic signature becomes much more valuable when combined with workflow.

For example: a contract is uploaded; Legal reviews it; the commercial director approves it; the administrator applies a qualified signature; the document is sent to the partner; the partner signs; the final version enters the archive automatically.

The DMS keeps the full history: who created the document, who modified it, who approved it, who sent it for signing, who signed it and which version is final.

Multiple signing and signer order

Many documents require multiple signatures. A contract may have two company representatives and later the client’s representative. An internal decision may require three approvals.

The application must know whether signing is:

• parallel — signers may sign in any order;
• sequential — person B may sign only after person A.

The workflow could be: Legal → Director → Administrator → Client, and the application should automatically manage notifications and statuses:

• In preparation
• Awaiting signature
• Partially signed
• Fully signed
• Rejected
• Expired

In this way, electronic signature becomes part of the company’s operational engine.

What the application must keep for audit

A business product should not keep only the final PDF.

For important processes a solid audit trail must be built: transaction identifier, document sent for signing, signing result, user, relevant timestamps, statuses and any errors.

The principle is simple: five years later we must be able to reconstruct what happened without relying on a system administrator’s memory.

In the case of a qualified signature, Romanian legislation also provides an important difference regarding challenges: for a qualified signature, the burden of proof regarding breach of legal and technical conditions falls on the party contesting the signature. For simple or advanced signatures, the evidentiary regime may differ.

This is one of the reasons for the additional legal certainty offered by a qualified signature.

eIDAS 2 and the European Digital Identity Wallet

The European landscape continues to evolve.

Regulation (EU) 2024/1183 updated the eIDAS framework and introduced the European Digital Identity Framework. The regulation entered into force on 20 May 2024.

One of the important changes is the appearance of the European Digital Identity Wallet.

The European wallet will enable electronic identification, storage and presentation of certain digital attributes, and electronic signing. The Commission notes that citizens will be able to use qualified electronic signatures through the wallet, including free of charge for non-professional purposes, according to the framework set by the regulation.

For business application developers, this matters. In the coming years, electronic identity and signing will become more integrated into the European digital experience.

Applications must be designed today so they can adopt these mechanisms tomorrow.

What is the real value for the company?

The argument for electronic signature is not only eliminating paper. The value comes from reducing the entire operational cycle.

A document that previously had to be generated, printed, signed, scanned, sent, returned, scanned again and archived can be processed fully electronically.

In an organisation that handles a few documents a month, the difference may seem small. In a company that processes thousands of contracts, addenda, minutes, HR forms and approvals a year, the time savings become significant.

Moreover, the organisation gains something perhaps even more valuable: traceability.

• We no longer ask “Who has the contract?” — the application knows.
• We no longer ask “Was it signed?” — the application knows.
• We no longer ask “Is this the latest version?” — the DMS must know.

A qualified signature is not a plugin. It is part of process architecture

The weakest implementation is adding an “Sign electronically” button at the end of the project.

The best implementation starts from the questions:

• Who must sign?
• In what order?
• Which version is signed?
• What happens if the person refuses?
• What happens if the document is modified?
• How do we validate a signature received from outside?
• What do we keep for audit?
• How do we archive the document long term?
• Which documents require a qualified signature, and for which is another mechanism enough?

Only after these answers do we choose the provider and API.

This approach turns electronic signature from a simple technical function into a component of the business process.

An ERP, CRM, DMS or business portal that correctly integrates a qualified signature can take a process all the way from creation to a final document with legal effect, without breaking the digital flow.

In Romania, Law 214/2024, together with the updated European eIDAS framework, now provides a much clearer legal basis for this type of process. At European level, cross-border recognition and the development of the European Digital Identity Wallet push the market in the same direction.

Therefore, the question for companies is no longer: “Can we sign documents electronically?” The answer is already yes in many scenarios.

The relevant question becomes: “Why are we still taking the document out of our application just to sign it?”

And for software developers, the answer should be simple: there should no longer be a need.