What is in the completion report

When a document completes, a second file comes into being alongside the signed PDF: the completion report. It is a separate PDF describing who signed, when, by what means, and with what proof.

This page lists what it contains — both so you know what it shows to whoever receives it, and so you can answer when someone asks what is recorded about them.

The report is in English

The report’s headings and labels are written in English and do not follow your account language. A document signed entirely in Portuguese still produces a report with sections called Signatures, Timeline and Audit chain (tamper-evidence).

The data inside the fields — names, emails, signature types — comes from the document and appears as it is.

The document

Field	What it is
Document ID	The document’s public identifier
Document	The file name
Subject	The subject
Created on · Completed on	When it was created and when it completed
Signature count	How many signatures it has, and how many are qualified
Document hash (SHA-256)	The file’s fingerprint
Report generated at	When this report was produced

The Document hash is what later proves the PDF in your hands is the one that was signed: change a single byte and the value changes.

Who sent it

The report identifies whoever created the document, with Name, Email, Phone and IP address.

Who signed

Each signer gets a section of their own:

Field	What it is
Email · Phone	The contacts used for the send
IP address	The address the signature was made from
User-agent	The browser and system used to sign
Signature type	Simple, SMS OTP, CMD, CMD with attributes
Security level	The identity assurance attached to it
ID document · Code (last 4)	Where identity confirmation or an SMS code was used, the last four digits
Certified attributes	The professional attributes, where the signature carries them

Why the IP address is there

This is the field that most surprises people opening the report for the first time.

The report exists to identify who signed and to hold that identification up in front of third parties. The IP address, the user-agent and the time are part of that proof: without them the document would say someone signed, but have nothing to stand on if the signature is ever disputed. It is not incidental logging that could be dropped at no cost — it is part of why the file exists.

Whoever receives the completed document receives this too. Worth knowing before forwarding the report outside the organisation: the signed PDF and the report are separate files, and you do not always need to send both.

For what the platform keeps and for how long, see Data retention and privacy.

The audit chain

The Audit chain (tamper-evidence) section says whether the document’s history is still intact. It carries the Chain root hash (SHA-256), the number of verified entries, and one of three verdicts:

Verdict	What it means
VALID — chain reproducible	The chain was recomputed and matches
INVALID — chain broken or tampered	The recomputation does not match
NOT VERIFIABLE — no chained audit entries	There are no chained entries to check

The third is not a fault in the document. An older document, completed before chaining existed, has no chained entries to recompute — and the report says so rather than inventing a verdict.

For how the chain is built, see Audit trail.

The PDF’s own signatures

The report also describes what is applied to the file itself, not only what the platform recorded:

Certified with and AATL Digital Certificate (Adobe Approved Trust List) — the platform’s certifying seal.
Certificate (extracted from signed PDF) — data read from the file itself: Common name, Serial number, Valid from, Valid to.
LTV type — what allows the signature to be validated in the future.
Unreconciled signatures — signatures found in the PDF that the platform could not match to a registered signer.