A compliance file often says "we checked the register on this date". Months later, an auditor asks: what exactly did the register say? Registers change, so re-running the check today doesn't answer. Fuentio's audit receipts do: every answer comes with a receipt that pins the exact data you were served, and you can retrieve it later. This page explains how receipts are built and how to use them.
Method as of 15 October 2026.
Short answer: each Fuentio answer includes meta.receipt: the request ID, the time it was served, a SHA-256 hash of the exact data returned and, when the answer came from a stored version of the record, that snapshot's ID (otherwise null). Snapshots are append-only. With the same key, you can fetch a receipt by its request ID for 24 months, free, and check that the data you stored still matches the hash.
What you'll learn
- What a receipt contains
- How snapshots make receipts reliable
- How to verify a receipt
- How long receipts are kept
- What a receipt proves, and what it doesn't
What does a receipt contain?
From a real recorded answer:
"receipt": {
"request_id": "req_example",
"served_at": "2026-10-05T14:02:11+00:00",
"data_sha256": "5d6838bcd5ffc2516d441637c3d5a416d023ddffe901552f86557931fa47ec31",
"snapshot_id": "FR-SIREN-441639465@2026-10-05T14:02:11+00:00"
}| Field | Meaning |
|---|---|
request_id | The answer's identifier, also in meta |
served_at | When the answer was served |
data_sha256 | A SHA-256 hash of the exact data you received |
snapshot_id | The stored version of the record the answer came from, or null when the answer was served without one |
Why are snapshots the foundation?
Every record Fuentio fetches is normalised and stored. A new snapshot is written only when the record's content changes; volatile fields like check times are left out of that comparison, so an unchanged company doesn't create noise. Snapshots are append-only: they're never updated or deleted, with one documented exception, erasure requests, which redact a snapshot in place and mark it with the redaction time.
A receipt points to a snapshot rather than copying it, so receipts stay small and always refer to the exact version you were shown. See provenance on every answer.
How do you verify a receipt?
- Store the receipt with the decision it supports.
- Later, fetch it with the same key:
GET /v1/receipts/{request_id}(free). The API returns the exact record it served, its provenance, andverified: truewhen re-hashing it gives the samedata_sha256. Another key getsnot_found. - Hash the data you stored yourself: SHA-256 of its canonical JSON (keys sorted, separators
,and:, UTF-8), and compare it withdata_sha256. - Match means you're holding exactly what we served; mismatch means the stored copy was changed.
A worked example
You onboard a Spanish customer and approve it. Your system stores the record you were served, its provenance and the receipt.
Nine months later, the BORME publishes the company's dissolution, and an auditor asks why you approved it. You:
- Fetch the receipt by its request ID.
- Hash the record you stored and compare it with
data_sha256: they match. - Show the record: no dissolution, liquidation or closure act at the time, with the BOE references of the acts that did exist.
The question "what did you know, and when?" has a precise answer, and nobody has to rely on memory or screenshots.
Why a hash, and why SHA-256?
A hash is a short fingerprint of a piece of data: change one character of the data and the fingerprint changes completely. SHA-256 is a hash function standardised by NIST in its Secure Hash Standard, and widely used for exactly this kind of integrity check. Publishing the hash with each answer lets anyone holding the data check, without trusting us, that it hasn't been altered since it was served.
What the hash doesn't do is prove who served the data or when: that's what the request ID, the serving time and our stored record are for. Together, they make a check you can defend.
What a receipt looks like in your file
For one onboarding decision, keep:
| Item | Example |
|---|---|
| Company | FR-SIREN-441639465 |
| Facts relied on | Status, legal name, registered office |
| Receipt | Request ID, served at, data hash, snapshot ID |
| Stored data | The data object exactly as received |
| Decision | Approved, by which rule or person, on which date |
With these five lines, the file answers both "what did you know?" and "can you prove it?".
How receipts fit with provenance
Provenance says where a fact came from and when it was checked. A receipt adds proof that the copy you hold is exactly the one you were served. Use both: provenance for every fact in your file, receipts for the decisions that matter most, such as onboarding, payouts and contract approvals.
Receipts and erasure
Append-only storage and data protection law can look like they pull in opposite directions. Our rule is narrow: snapshots are never deleted or rewritten, except when a removal request applies, in which case the personal fields in the stored snapshot are redacted and the snapshot is marked with the time of redaction. A receipt pointing to that snapshot then reads back as changed, with its redaction time, so you can see what happened instead of meeting a silent difference.
Who asks for receipts
- Compliance teams that must show what they checked when onboarding a business customer.
- Payment and lending teams approving payouts or credit lines on the basis of a company's status.
- Auditors and partner banks reviewing a sample of past decisions.
- Product teams debugging a dispute about what a customer was shown.
In each case, the value of a receipt is the same: it turns "we checked" into something another person can verify for themselves, months later, without trusting anyone's memory.
Good practice for teams
- Store the receipt with the decision, not in a separate log nobody reads.
- Hash the canonical form. The hash covers the
dataobject's canonical JSON (keys sorted, no spaces, UTF-8): re-serialise your stored copy that way before hashing. Any changed value changes the hash. - Use a key. A receipt from a keyless call can only be read back from the same internet address.
- Keep your own retention. If your obligations run longer than 24 months, keep the data and the receipt in your own archive.
- Record who decided. A receipt proves what was served; your file still needs to say who approved, under which rule.
How long are receipts kept?
24 months from the answer. Keep your own copy of the data and receipt if your retention obligations are longer.
What does a receipt prove?
- It proves what Fuentio served you, and when, and that it came from a specific stored version of the official record.
- It doesn't prove the official register was right, and it doesn't replace the register's own certified documents where a law requires them.
For the full method, see how we read French data and how we read the BORME.
See what we cover in France and Spain.
Limits. Method as of 15 October 2026. Receipts prove what Fuentio served; they aren't certified extracts from a register. Not legal advice.
Frequently asked questions
What is an audit receipt?
A record attached to each answer, with a hash of the exact data served and, when there is one, a reference to the stored snapshot, retrievable by request ID with the same key.
How long are receipts kept?
24 months.
Can I prove later what a register said?
You can prove what Fuentio served from the official source, and when, by matching your stored data with the receipt's hash.
Does a receipt replace a Kbis extract?
No. Where a certified document is required, use the register's own. See Kbis, Sirene notice and RNE extract.
Sources
- API Recherche d'entreprises, documentation: recherche-entreprises.api.gouv.fr
- BOE, BORME daily gazette: boe.es
- NIST, Secure Hash Standard (SHA-256): csrc.nist.gov