SaaS teams closing contracts digitally quickly hit the question: QES, AES or SES — which eIDAS level does our product need? Mixing them costs roadmap time: too much qualification slows every flow; too little triggers legal stops. This article maps the three levels to product decisions — not as a legal slide, but as an architecture question.
QES vs AES vs SES: the product question
The eIDAS Regulation defines three signature tiers: simple electronic signature (SES), advanced (AES) and qualified (QES).
QES is the highest level and in many cases equivalent to a handwritten signature — so under certain conditions it can replace statutory written form. AES carries strong evidential weight: unique link to the signatory, integrity after signing. It does not replace written form by default — neither under eIDAS nor under national civil law. SES is the fast, attributable click — useful for low-risk flows, not as the default for customer contracts.
Product copy that combines “AES” and “as legally valid as handwritten” in one sentence mixes two layers. Evidential validity in the sense of strong proof can come from AES; form replacement in the sense of statutory written form requires QES. Understanding that split saves weeks in legal review and prevents rework after the first enterprise deal.
The European Commission summarises the regulation here: EU Commission on eIDAS. For SaaS: legal picks the level per document; the API must deliver all tiers without a media break.
What is SES (simple electronic signature)?
SES is the entry level: attributable electronic consent without a qualified certificate. Typical uses are internal approvals, low-dispute confirmations, or steps in a longer workflow where AES or QES follows later.
SES is not “worthless” — it is just not right for every document. Standardising SES as the only level for customer contracts understates evidential and form requirements. Product-side, SES should be selectable, not forced as the minimum for everything.
Typical SES uses in SaaS: confirming an order change in the portal, internal approval in a workflow before the final AES contract, pilots with bounded risk. The mistake is marketing SES as “digital signature” when the customer expects binding effect in the AES sense or form replacement in the QES sense. Transparent UI communication — which level applies — reduces dispute and support load.
What is AES (advanced electronic signature)?
AES must be uniquely linked to the signatory and detect later changes to the document. That is what procurement and legal often mean by “binding, but not QES”.
In many B2B processes AES is enough: offer acceptance, NDAs, operational framework contracts without statutory written form, high-value internal approvals. Important: AES does not automatically replace written form. If you need form replacement, QES is required — not AES alone.
Technically AES must meet eIDAS requirements: unique link to the signatory, detection of later changes, control over the signature means. In practice that means identification and audit trail at the level procurement expects in due diligence — without a qualified certificate. AES is the sweet spot for many SaaS contracts when nobody demands written form.
Germany’s BSI frames trust services and security expectations: BSI on trustworthy services.
What is QES and when does it replace written form?
QES is the qualified electronic signature. It relies on a qualified certificate and a qualified signature creation device. Only QES — not AES and not SES — can be equivalent to written form under the conditions set in national law implementing eIDAS. That is the statutory separation of tiers, not a marketing claim. See the eIDAS Regulation for the EU framework.
Typical QES triggers: law or contract requires written form, banks, authorities or regulated groups mandate QES, or evidential bar is highest. Qualification runs through a Qualified Trust Service Provider (QTSP). Sign2x is the engine, not the QTSP: identity and certificate come via partners such as Sign8.
QES usually means an extra identity step for the end user — video ID, bank ID or a procedure your tenant already runs in compliance. Product-side, plan conversion: QES only where needed; AES as B2B default. The engine must support both paths in the same whitelabel UX without a portal hop.
When does SaaS need QES — and when is AES enough?
The call is document- and sector-specific. Rules of thumb for product teams:
- AES often enough: B2B contracts without statutory written form, operational agreements, approvals, many NDAs and mid-market framework contracts.
- QES required: written form by law or contract, financial and insurance products with form rules, public-sector and procurement paths, when the counterparty contractually demands QES.
- SES for low risk: internal confirmations, process steps before final AES/QES, low individual dispute value with explicit legal OK.
Legal must set the level per document type. The stack must be selectable per envelope — not three separate products. Depth in the Help Center.
Is AES enough in B2B?
Often yes — if written form does not apply and the counterparty does not demand QES. AES delivers strong evidence: link to the person, integrity protection, audit trail. That covers a large share of operational contract closes in SaaS platforms.
Errors appear when teams sell AES as “automatically replacing written form”. That is legally wrong and dangerous in RFPs. Communicate clearly: AES for B2B binding without form replacement; QES when written form or the counterparty requires it.
In due diligence, enterprises often ask: which level do you use by default — and can you upgrade per document? An engine that masters only one level forces parallel systems. Sign2x answers with configurable level per envelope, unified audit and whitelabel surface — whether the close needs SES, AES or QES.
Electronic seals: do not confuse with personal QES
Besides the three signature tiers, eIDAS provides electronic seals for legal persons — invoices, notices, outbound records the company issues, not a natural person. Seals and personal QES are distinct instruments.
Product rule: people sign contracts; the organisation seals documents that originate from the company. Sign2x ships seals alongside SES, AES and QES in the same API. More in the electronic seal article.
eIDAS levels in one API — not three portals
SaaS needs a level per envelope, not three isolated products with different logins. Sign2x supports SES, AES, QES and electronic seals through the same REST API: dispatch via email, link or SMS, whitelabel in your UX, audit trail under your tenant.
The engine hosts only in Germany on STACKIT and Deutsche Telekom — no US Cloud Act exposure on contract data. QES qualification runs through QTSP partners such as Sign8; Sign2x is not itself a QTSP. Integration: Developer Hub. Scenarios: Use Cases.
Hosting and data sovereignty in level choice
Signature level and storage location are two axes. A QES envelope with metadata under third-country jurisdiction does not solve compliance for many tenants — it moves it. DACH ISVs therefore often choose German hosting and processing regardless of level.
Sign2x processes only in Germany. On-premise is available without feature loss — same API, local pipeline. Overview of a German-engine alternative: German-hosted e-signature alternative. More: blog.
AML and regulated paths: level plus identity
AML-adjacent processes rarely need “any signature”. They need attributable identification and often a qualified path — with separate roles: identity provider, QTSP, engine. Sign2x wires the steps in your software but is neither identity provider nor QTSP.
Role split in the AML and QTSP article. Architecture questions: contact.
Product roadmap: level strategy instead of QES everywhere
The expensive mistake is “QES everywhere” because it sounds safest. QES needs identification and certificate path — every step costs time and conversion. The second mistake is “SES everywhere” because it is fastest — until legal stops the rollout.
What works: map document types (AES default B2B, QES for written-form cases, SES for internal/low-risk), set level per envelope in the API, involve legal once not per feature. Unsure what your current stack delivers? Start the quiz.
eIDAS continues to evolve in the EU; the three-tier logic remains relevant for product planning. When you pick an API today, check whether the vendor supports all tiers and seals in one model — not only the level the first customer needed. Sign2x is built for SaaS multipliers that grow without reinventing the signing path each time.
Paperless flows can close up to 80% faster and cut process cost in half — when the chosen level fits from day one and compliance does not catch up later.
Level choice in practice: document-type matrix
Product teams benefit from a simple matrix legal signs once:
- SES: internal confirmations, process checkboxes, pilots with explicit risk OK.
- AES: standard B2B contracts, framework agreements, NDAs without written-form clause, operational amendments.
- QES: employment contracts requiring written form, real-estate and financial products with form rules, authority and procurement documents, when the tenant contractually demands QES.
- Seals: invoices, notices, machine-generated company outbound — not personal contract signature.
The matrix belongs in product docs, not Slack threads per deal. Engineering implements a level field per envelope; legal maintains the mapping. That avoids both QES overkill and SES underkill.
Technical implementation: one endpoint, multiple levels
Anti-pattern: three separate integrations for SES, AES and QES with different logins. Target: one REST endpoint, signatureLevel parameter, QTSP connection only when QES or qualified seal is chosen. Identity path activates only for qualified routes — saving conversion on AES and SES flows.
Sign2x keeps that split in one API: whitelabel surface stays the same, backend picks certificate and evidence path. Webhooks report level and status uniformly — important for your audit and tenant reports.
Migrating from “one level for everything”
Many SaaS products start with SES or AES and later get a QES request from a large customer. Without API design from day one, QES becomes a fork: second portal, second UX, second audit path. Planning all levels in one envelope model activates QES as configuration — not a new product.
Switching the signature engine is feasible in about 90 days if envelopes and webhooks are documented. More in the API migration blog post. Upfront assessment in the evaluation quiz.
Cost logic: QES per envelope vs architecture
QES is often more expensive per transaction — rightly so, because identity and QTSP services apply. Still, “AES everywhere” is not automatically cheaper: legal rework, manual exceptions and lost deals for missing written form are TCO lines. The right question is what share of documents needs which level — not which level is cheapest.
Sign2x targets ISVs with up to 20% lower licensing versus comparable vendors at full capability — all levels, whitelabel, German hosting. Quotes via contact; no public grid because volume and operating mode drive the contract.
A final product test before you choose a level strategy: pick three real documents from your roadmap – one internal, one standard B2B, one with possible written-form risk. Run them past legal with the question: SES, AES or QES? If the answers differ, your API must support all three on day one. Sign2x ships SES, AES, QES and seals through one engine in Germany on STACKIT and Telekom — QTSP qualification via Sign8, not by claiming to be a trust service provider. Start with the evaluation quiz or contact for architecture scope.
Frequently asked questions
When does SaaS need QES?
When written form is required by law or contract, or the counterparty demands QES. Only QES can be equivalent to written form under the conditions in national law — not AES or SES by default.
Is AES enough in B2B?
Often yes, if written form does not apply. AES must be linked to the signatory and protect integrity. For many operational B2B contracts that is the right level.
What is the difference between SES, AES and QES?
SES is the simple electronic signature for attributable low-risk closes. AES is advanced with strong evidential weight but no blanket written-form replacement. QES is qualified, QTSP-mandatory and written-form equivalent under statutory conditions.
Is Sign2x a QTSP?
No. Sign2x is the signature engine. Qualified signatures and seals run through connected QTSPs such as Sign8. Hosting is in Germany on STACKIT and Deutsche Telekom.
Can I use all levels in one API?
Yes. Sign2x supports SES, AES, QES and electronic seals in the same API — selectable per envelope, whitelabel in your UX, without separate portals per level.
