When machines sign: scenarios for company signing
In many processes nobody signs. Invoices are generated and sent automatically, certificates issued in batches, confirmations sent after a payment arrives, reports transmitted to authorities on fixed dates. Recipients still want to know who a document comes from and whether it is unchanged. That is what the electronic seal is for: it proves origin and integrity of a document for a legal person, not for a human being. This article describes how an automated company signature via API can be architected.
We say upfront what this is about and what not. The article is an architecture pattern. It explains how a sealing process is built in principle, which roles take part and which decisions an ISV must make. It is not a product promise: which sealing functions are or will be available through Sign2x in which form is not the subject of this text, and we derive no commitments from the pattern. Anyone planning a concrete sealing flow should clarify the status directly with us.
Typical scenarios for seals are mass documents with a high need for formalisation: invoices within electronic invoicing, certificates and attestations from educational institutions, extracts, evidence and certificates, delivery notes and freight papers, records of automated checks. Common to them is that the issuing organisation stands behind the document, not an individual person, and that human intervention in the individual case is neither sensible nor possible.
The one hard distinction of this article: a signature binds a person to a document, a seal binds an organisation to a document. Different requirements for identification, responsibility and use follow. Anyone misunderstanding a seal as a “signature without a click” risks claiming legal effects that do not apply. A seal is not a human declaration of intent but proof of origin and integrity.
Why does this matter for ISVs? Because customers increasingly demand that outgoing documents are verifiable. Anyone sending documents automatically, such as contracts, confirmations or evidence on behalf of customers, will sooner or later be asked how the recipient can check they are genuine. A cleanly implemented seal pattern answers that question. At the same time this is a topic where overpromising would be especially harmful, because qualified seals presuppose regulated trust services.
For the legal foundations we refer to the eIDAS Regulation, which regulates electronic seals alongside signatures, and to the amendments by Regulation (EU) 2024/1183. Terms, seal levels and provider requirements are defined there. For our purposes it suffices: there are simple, advanced and qualified electronic seals, similar to the tiers for signatures, and qualified seals are provided by qualified trust service providers.
Seal versus signature: what differs
The first difference concerns the holder. An electronic signature belongs to a natural person who declares their will or confirms a document with it. An electronic seal belongs to a legal person, such as a company, authority or institution, and serves as proof that a document comes from it. The seal is thus closer to a company stamp proving origin than to a signature expressing intent.
The second difference concerns legal effect. The qualified signature equals the handwritten signature. The qualified seal, by contrast, enjoys a presumption of integrity of the data and correctness of the origin stated but replaces neither a signature nor a declaration of intent. Where the law requires written form, a seal does not help. That is a frequent error in projects where “company signature” is understood as shorthand for “signature on behalf of the firm”.
The third difference concerns control. With a seal not a person but the organisation controls the creation means, usually through systems and key management. That makes governance central: who may trigger the seal, for which documents, under which conditions, and how is misuse prevented? In a signing flow a human clicks. In a sealing flow a system triggers, and the system must be secured so every trigger is traceable and authorised.
The fourth difference concerns identification and certificate. With a qualified signature a person is identified by the QTSP. With a qualified seal the organisation is verified, for instance through register extracts and proof of representation, and the certificate refers to the legal person. This process sits with the QTSP and can take time. It is not a software question but an organisational precondition you should include in project plans.
For product design a clear rule follows: use the terms cleanly. In interfaces, contracts and sales material, “signature” should stand for persons and “seal” for organisations. Show the levels, simple, advanced and qualified, each time. A classification of signature levels is in AES vs QES via API and SES, AES and QES in SaaS. Similar principles apply to seals, with their own requirements.
API pattern for automated sealing processes
A sealing process via API follows a basic pattern of five steps. First trigger: an event in the business system, such as the completion of an invoice, starts the transaction. Second preparation: the document is finalised, checked and given a reference. Third sealing: a service controlling the seal creation device applies the seal to the document. Fourth storage and delivery: the sealed document is stored and transmitted to the recipient. Fifth evidence: the transaction is logged.
Two basic decisions are architectural. The first concerns the location of keys. Seal keys belong in secured environments, for qualified seals in qualified seal creation devices operated or provided by a QTSP. Your system should never hold the key itself but address the sealing service through an interface. The second decision concerns authorisation: who or what may trigger sealing? Fine-grained permissions, separate credentials per application and tenant and a log of every call are advisable.
Important is the separation of trigger and content. The system triggering a seal should not be allowed to seal arbitrary documents unchecked. Better is a flow where the seal is created only for documents that passed certain checks: templates from an approved set, plausibility controls, volume limits. Ignoring this creates a tool that, if compromised, certifies arbitrary documents in the organisation's name. That is the greatest risk of these patterns.
For seals too: idempotency and repeatability. A sealing transaction must not be triggered twice when a call is repeated. References from your business system and a check before every trigger prevent duplicates. The state model matches that of signing transactions as described in webhook state management for e-signature events: events are received, verified, stored and translated into follow-up processes.
For mass flows the link to the patterns in bulk signature API for enterprises is obvious: packages, error lists, restart and observability apply analogously. The most important difference is that no human has to react to the transaction, so errors would be noticed only afterwards unless actively monitored. Alerts on unusual volumes, deviations from patterns and error rates matter even more for sealing than for signing.
Verification should be considered from the start. A seal the recipient cannot check is useless. Check with which tools recipients can establish validity, whether seals are recognised in common document viewers and how you explain to recipients how checking works. A short guide in accompanying mails or the customer's portal reduces queries markedly. Long-term validity belongs here too: how long must seals remain verifiable, and how do you secure that?
Limits and partner QTSP: what an ISV should not do itself
Qualified seals are regulated trust services. They are provided by qualified trust service providers who are audited and supervised for it. Sign2x is not a QTSP. Where qualified services are needed we work with partner QTSPs such as Sign8. That applies to signatures and would be no different for qualified seals. An ISV should not try to take on this role itself, because the requirements for technology, organisation and supervision are substantial.
The division of tasks resembles qualified signatures. The QTSP verifies the organisation, issues the certificate and operates or provides the seal creation device. The API layer orchestrates the flow, integrates it into your product and returns events. Your customer, the sealing organisation, bears responsibility for triggering and use. You should name these three roles clearly before a project starts. A deeper look at the partner role is in QTSP partners for ISVs.
On hosting: Sign2x runs via data-sovereign cloud hosting in Germany, a European operation under European law. That concerns the platform. For seals the location and legal framework of the QTSP and the seal creation device also matter, which you should check separately. An explanation of why location alone is not enough is in Cloud Act vs data sovereignty. In data protection terms the GDPR applies here too, especially if sealed documents contain personal data.
A further limit concerns legal effect. A seal does not turn a document into a signed contract. Where a declaration of intent is needed, you need a signature of an authorised representative. Where written form is required, it stays with QES or the handwritten signature. Check each document type legally before providing it for the seal pattern. That applies especially to documents sent “on behalf of the firm” in practice but containing consent legally.
Finally the limit of organisation. A sealing process is only as secure as the governance behind it. Who manages the credentials? Who monitors the runs? How is the response when misuse is suspected? How does revocation of a certificate work? These questions are no side topics but the core of the responsibility an organisation takes on with a seal. The security recommendations of the BSI offer guidance for operating such systems.
What is not a product claim: a delimitation for readers
To avoid misunderstandings we state what this article does not say. It does not say Sign2x provides a productive, qualified sealing offer today. It does not say particular seal levels, partners or connectors are available. It quotes no performance data, prices or timelines. And it replaces no advice on the legal situation. It describes a pattern so product teams and architects understand which questions must be clarified before planning a sealing flow.
If you have a concrete project, we recommend open exchange. We clarify with you whether and how your scenario can be mapped, which partners are needed and which preconditions exist on your side. Bring three things: a description of documents and volumes, an assessment of which legal effect you need and your requirements on hosting and operations. With these details it is quickly said whether seals are the right tool or whether a signature by authorised representatives fits better.
Until then much can be prepared that is useful independent of the seal: a clean event model, tenant-capable configuration, clear references, an export of evidence and documented governance for automated flows. These building blocks make your product more robust for signatures and seals alike. How the evidence side looks in the context of regulatory requirements is shown in DORA Article 30 and the signature audit trail. It is evidence, not certification.
Technical basics for getting started are in the developer hub, terms in the help centre, practical cases under use cases and more articles in the Sign2x blog. The Sign2x quiz supports a first classification of your requirements.
Discuss your seal scenario without obligation
Further reading: eIDAS 2.0 and the EUDI wallet for SaaS relying parties and AML-ready signature API for ISVs.
Frequently asked questions
What is the difference between an electronic seal and a signature?
A signature binds a natural person to a document, a seal binds a legal person. The seal proves origin and integrity but replaces no signature or declaration of intent.
Does a seal replace written form?
No. Where the law requires written form, the qualified signature or handwritten signature is needed. A seal is proof of origin and integrity.
Does Sign2x offer a qualified seal?
This article describes an architecture pattern, not a product promise. Sign2x is not a QTSP, qualified services run through partner QTSPs. We clarify the current status in conversation.
Where is Sign2x hosted?
On the data-sovereign cloud hosting in Germany. For seals the location and legal framework of the QTSP are also relevant.
What matters most in automated sealing?
Governance: who may trigger, for which documents, with which checks and logs? A compromised trigger could otherwise certify arbitrary documents in the organisation's name.
