What Is an .edoc File? How to Open, Sign and Verify Latvia's eDoc Format

An .edoc file is a signed-document container: a single file that holds the document (or several documents) being signed, plus the electronic signatures, the signers' certificates and the timestamps that prove when each signature was made. The format is defined and maintained in Latvia's eParaksts ecosystem by LVRTC, the state trust-services operator, and it is the standard way Latvian public institutions exchange electronically signed documents. If a Latvian ministry, municipality or court sends you a signed decision, it will very likely arrive as an .edoc.

Technically, the current eDoc format is built on the European ASiC-E container standard (an ETSI standard) with XAdES XML signatures inside. That puts it in the same family as Estonia's .asice files: under the packaging, both are ZIP archives with a defined internal structure. You can rename an .edoc to .zip and look inside, and you will see the original documents plus signature files, but doing that tells you nothing about whether the signatures are valid — validation needs proper software.

Legally, the container is just the envelope. What matters under eIDAS is the level of the signatures inside: simple (SES), advanced (AES) or qualified (QES). A qualified electronic signature has the legal effect of a handwritten signature across the EU, and signatures made with Latvian state-issued eID means are designed to meet that qualified level. The eDoc container's job is to bind signature, certificate and document into one tamper-evident file.

The simplest route needs no installation and no account: the eParaksts portal at eparaksts.lv has a free browser-based check (the "Verify or Sign" function) where you upload the .edoc file and see the documents inside and the status of every signature. Anyone can use it — you do not need to be an eParaksts user, hold a Latvian eID, or register anywhere. For an occasional .edoc from a Latvian counterparty, this is usually all you need.

If you handle signed containers regularly, the free eParakstītājs 3.0 desktop application from the eParaksts ecosystem opens .edoc and .asice files directly: once installed, double-clicking the file shows the contents and a validity verdict for each signature. Some commercial e-signing platforms operating in the Baltics can also open and validate eDoc containers, which helps when your team standardises on one tool.

Be prepared for validation to return more than a clean yes or no. Alongside valid and invalid, validators can report an indeterminate result — typically when the tool cannot build the full certificate chain or reach revocation data at that moment, not necessarily because anything is wrong with the document. The eDoc specification has also evolved through versions over the years, so a very old file may behave differently from a fresh one. In both cases the same advice applies: re-check with a maintained official tool before drawing conclusions, and ask the sender to confirm which tool they used to sign.

One rule matters more than any tool choice: only the original electronic file carries legal force. Verification checks that the document has not been altered since signing and that the certificates and timestamps check out — all of that lives in the container itself. A printout of an .edoc, or a PDF exported from it, is just an unverifiable copy. Store the original file, and send the original file when someone needs the signed version.

For individuals in Latvia, the state tools cover the basics. With a Latvian eID card and a card reader you can sign through the eParakstītājs 3.0 application, and the eParaksts mobile app lets you sign from a phone without a card reader. The eparaksts.lv portal's same "Verify or Sign" flow also supports signing an uploaded document. In each case the output is a signed container that any of the verification routes above can check.

Before you sign anything, it is worth being deliberate about the signature level, because the container format does not determine it. The same .edoc envelope can carry a simple, advanced or qualified signature, and different documents justify different levels — our guide to SES, AES and QES walks through how to choose. For many routine B2B contracts an advanced signature backed by a national eID is proportionate; some documents are required by law to carry a qualified electronic signature.

Two practical habits prevent most disputes later. First, sign only the final agreed version — a signed container is tamper-evident, so any late edit means re-signing from scratch. Second, agree the format with your counterparty before signing: if they cannot open .edoc, a signed PDF or an ASiC-E container may save a week of back-and-forth. Both habits are easier when the negotiation and signing happen in one place instead of over email attachments.

A signed PDF (the PAdES approach) embeds the signature inside the PDF itself. Its great strength is familiarity: the file opens in any PDF viewer, on any platform, and the counterparty sees a normal document even if their software cannot check the signature. For international counterparties who have never seen a Baltic signed container, PDF is usually the path of least resistance.

ASiC-E (.asice) is the pan-European container standard, and it is the default signed format in Estonia. The eDoc format is Latvia's national profile built on the same standard — so the two are close cousins rather than rivals. Within Latvia, eDoc is the safe choice: the public sector issues and accepts it, local businesses recognise it, and every state verification tool handles it. Between Baltic countries, tooling increasingly reads both containers, but it is still worth confirming rather than assuming.

The honest caveat is cross-border readability. Outside the Baltics, most desktop software has never met the .edoc extension, and a signed container a counterparty cannot open is a real operational problem even when the signature inside is legally sound. Practical options: point the recipient to the free browser validator at eparaksts.lv, or agree up front on a more portable format for international deals. The legal validity under eIDAS does not depend on the counterparty's software — but their willingness to countersign often does.

The file format is the last step of a longer chain, and in practice most contract pain sits earlier: finding the right starting text, tracking what changed during negotiation, and knowing which version was actually signed. A contract workflow such as DokDesk handles that chain end to end — reusable templates, negotiation on one live version instead of duelling attachments, and then eIDAS signing with national eIDs such as Smart-ID and Mobile-ID over a no-account secure link, at the SES and AES levels. DokDesk is architecture-ready for QES but does not issue qualified signatures today, and we say so plainly.

The same discipline applies to the signed containers you receive. Treat the original file as the record: store it unchanged next to the contract it belongs to, note which format the counterparty used, and resist the urge to "tidy up" by keeping only a PDF export — the export strips the very thing that makes the document provable. Teams that handle a mix of .edoc, .asice and signed PDFs benefit from one agreed home for signed originals rather than a scatter of inboxes and shared drives, so that three years later nobody is hunting for the one file that actually carries the signatures.

After signing, the question shifts from "what format is this file" to "can we prove what happened". Whatever container your documents live in, keep the original signed file, and keep the context around it: who was invited, what they saw, when they signed. DokDesk captures that trail in a court-ready evidence base, with data stored in the EU under GDPR. The product is in early access — but the principle applies to any tooling you choose: the format proves integrity, while the workflow around it proves the story.