Any document — contract, invoice, report, certificate — can be anchored into the Invoance ledger as a tamper-evident, cryptographically signed record. The anchor proves the document existed in its exact form at a specific point in time.
Invoance stores the SHA-256 fingerprint, not the document itself. The fingerprint is sufficient to independently verify integrity. Original document custody remains with you.
Free up to 10,000 events · Available on all plans · No document storage required
A single call to POST /v1/document/anchor creates a permanent, immutable ledger entry binding your document hash to a timestamp and organizational identity.
SHA-256 of the exact document bytes. Any alteration to the document — a single character, a metadata change, a formatting tweak — produces a completely different hash.
A human-readable identifier you provide — invoice number, contract ID, file name. Used to locate the record later without storing the document itself.
The anchor is signed with your tenant's private key. The signature proves the record was issued by your organization and has not been altered since.
Recorded at ingestion and included in the signed payload. Cannot be backdated, adjusted, or overwritten after anchoring.
Every anchor produces a public URL. Any third party — a counterparty, auditor, or court — can verify the document's integrity without authentication.
Original document retention is available as an optional feature. When disabled, only the fingerprint is stored. Verification always resolves against the hash, not the stored file.
Document anchoring does not require document routing changes or storage delegation. Hash the document locally, submit the hash. The document never leaves your systems unless you choose otherwise.
import hashlib
with open("invoice_1042.pdf", "rb") as f:
document_hash = hashlib.sha256(f.read()).hexdigest()
# → "a94a8fe5ccb19ba61c4c0873d391e987982fbbd3"POST /v1/document/anchor
Authorization: Bearer invoance_live_xxx
Idempotency-Key: <uuid>
{
"document_ref": "Invoice #1042",
"document_hash": "a94a8fe5ccb19ba61c4c0873d391e987982fbbd3"
}{
"event_id": "evt_01HX…",
"document_ref": "Invoice #1042",
"document_hash": "a94a8fe5…",
"signature_b64": "…",
"public_key_b64": "…",
"created_at": "2026-02-25T14:22:01Z",
"verify_url": "https://invoance.com/verify/evt_01HX…"
}GET https://invoance.com/verify/evt_01HX…
# Returns: hash, signature, public_key, timestamp, tenant_domain
# Verifier recomputes SHA-256 of original document
# Compares → match = document unchanged since anchoringDocument disputes follow a predictable pattern: one party claims a document was altered after signing, after delivery, or after an event that changed the stakes. Anchoring resolves that dispute with cryptographic evidence rather than competing testimony.
Counterparty claims contract terms were changed after execution.
You have the file. They have a different version. Someone is lying. Courts cannot determine which.
Anchor at execution. SHA-256 at anchoring matches SHA-256 of your copy. Dispute resolved cryptographically.
Regulator questions whether a submitted report matches the version on file.
Metadata and version history presented. Auditor requests independent verification. Engineering reconstructs.
Anchor at submission. Regulator verifies via public URL. No engineering involvement required.
Invoice dispute — vendor claims payment terms were different at delivery.
Both parties have copies. Email chains are inconclusive. Legal fees accumulate.
Invoice anchored at delivery. Hash comparison proves which version was current at that moment.
Auditor requires proof that policies and procedures were in effect at a specific date.
Documents produced from file systems. Auditor cannot rule out post-dated modification.
Policy anchored when published. Anchor timestamp is signed and independently verifiable.
Any file that can be hashed can be anchored. Invoance is format-agnostic — it operates on bytes, not document structure. The hash is deterministic regardless of file type.
If the same document hash is submitted more than once, the API returns 409 Conflict with the original event details. This is by design — it prevents double-anchoring the same document and surfaces potential process errors.
Conflict — document already anchored{
"error": "document_already_anchored",
"message": "This document hash was already anchored.",
"event_id": "evt_01HX…",
"created_at":"2026-01-10T09:14:22Z",
"verify_url":"https://invoance.com/verify/evt_01HX…"
}The conflict response includes the original anchor details so you can retrieve the existing proof without a separate lookup.
Document anchoring is one of three proof endpoints in Invoance. Each addresses a different anchoring need — same cryptographic primitives, different data models.
Document anchoring uses the same cryptographic foundation as all Invoance records — SHA-256, Ed25519, and append-only Postgres. The proof is verifiable offline, independent of Invoance infrastructure.