Privacy

This page describes exactly what happens to a file you send to the FactureCheck validation API, in plain language. It is not a substitute for legal advice, but it is an accurate description of the code that runs this service.

What we never store

• The uploaded invoice file itself (XML or PDF).
• Any field or value from inside the invoice — no seller/buyer names, addresses, amounts, VAT numbers, dates, or line items.
• Any derived copy, cache, or backup of the invoice content.

The uploaded bytes are held in memory only for the duration of the request, sent to the validation engine, and discarded once the response is returned. Nothing about the file's content survives the request.

What we do log

For every /api/v1/validate request, a single log line records:

• A SHA-256 hash of the uploaded bytes — enough to tell whether two uploads were identical, not enough to reconstruct them.
• The rule codes that fired (e.g. BR-02, PEPPOL-EN16931-R008) — which validation checks passed or failed, never the values that caused them to fire.
• A timestamp.
• The detected format (UBL, CII, or hybrid PDF).

That is the complete list. No invoice content is ever written to a log.

Why this matters

Many free online invoice validators are anonymous services with no stated retention policy — you have no way to know whether your invoice (often containing customer names, prices, and VAT numbers) is kept, resold, or used to train something. FactureCheck is built so that it structurally cannot do that: the code path from upload to response never writes invoice content to disk or to logs.

Hosting and retention

The service is operated and hosted within the European Union. The only persistent data store is a small SQLite database holding API keys, waitlist signups, and rate-limit counters — never uploaded files. Rate-limit counters are pruned automatically once their one-hour window has passed.

Issued reports

Every PDF conformance report we issue is registered by the SHA-256 hash of its own bytes, so anyone can later confirm it is genuine at facturecheck.eu/verify — never by the invoice's content, a filename, or your IP address.

Three data contracts — read this carefully

Almost everything above describes one-off validation (/api/v1/validate, /api/v1/repair, /api/v1/validate/batch, and the MCP tools): nothing is ever stored, full stop. Regression monitoring (/api/v1/watch) is a separate contract with two modes of its own, and both work differently from one-off validation on purpose:

• One-off validation — the promise above holds completely unchanged. Your file is processed in memory and discarded.
• Watch, skeleton (the default) — you opt in, per sample, by sending store_document: true to POST /api/v1/watch. What is actually kept is not your document: before storing anything, the service pseudonymizes it — company names, addresses, IBANs, VAT ids, emails and phone numbers are replaced with synthetic, format-valid stand-ins (a fixed test IBAN with a correct check digit, "Sample Company 1", and so on). Amounts, currencies, tax rates, dates and every other rule-relevant field are left untouched, and this is proven, not assumed: both the original and the pseudonymized skeleton are validated, and if the two ever fire a different set of rules the request is refused (HTTP 409) rather than silently stored. What lands in storage therefore holds no personal data belonging to your supplier or customer. Without store_document: true, nothing is stored at all: send store_document: false instead and only a fingerprint (hash, verdict, fired rule codes) is kept — a ruleset change then marks that entry needs_resubmit instead of auto-rechecking it, since there is no document left to revalidate.
• Watch, full (opt-in, one flag further) — passing store_full: true as well stores the real, original document instead of a skeleton. This is never the default and never implied by store_document: true alone. The bytes are encrypted at rest (XChaCha20-Poly1305); the encryption key lives only in server configuration, never in this codebase. Each full-mode watch has a retention_days period (90 days by default, 365 at most): once it elapses, the stored document is hard-deleted automatically, and the watch entry stays on as metadata only, marked document_purged.

Either way, deleting a watch entry (DELETE /api/v1/watch/{id}) hard-deletes its stored document (skeleton or full) immediately — nothing about it survives in any table. GET /api/v1/watch/{id}/export returns everything the service holds about one watch, for answering a data-subject access request. Nothing about any of this weakens the one-off promise above — the three are entirely separate code paths, and the vast majority of usage (a single validate or repair call) never touches storage at all.

Repair requests

The same rules apply to /api/v1/repair: the uploaded invoice is processed in memory and discarded. Repairs are limited to a fixed whitelist of safe, mechanical fixes; monetary amounts, VAT rates, dates, and party identities are never altered, and arithmetic rule failures are always reported for you to fix, never silently changed.

Contact

Questions about this policy can be directed to the service operator.